Someone could help please with the OPNWAF-Plugin

[Wuensch-AG-Adm]

Dear OPNSense community,
I'm missing some information about the OPNWAF-Plugin. It's not clear with the certificate management where NGINX + NAXSI it's clear and explained. When I try to activate this plugin the service doesn't start and the settings are the same with a functional NGNIX+NAXSI. The problem with NAXSI is that this block the Apple devices with Safari and without a disabling of a base Ruleset, it won't work. It's not really safe like that.

OPNWAF seems to be easier but it simply doesn't work with our certificates. (no let's encrypt here)
here some info from the log: pass request body failed, AH00898: Error during SSL Handshake with remote server
The Set-UP is simple: Der HTTPS Port für den Virtual Server is not standard, SSL Proxy check peer is enable and the URI matches the CN, the certificate field in the Virtual Server is the same as in HTTP Server from NGNIX in the field TLS Certificate. The Location>Remote destinations in OPNWAF is the https://XX.XX.XX.XX (X = IP) of our Webserver.
With the same certificate-setting with NGNIX + NAXSI it will work, that's why I don't understand.

I hope with these information you can help me.

I was thinking that with the business license it would be easier for us.

Thank you ahead.

Joel T.

[Reiner030]

Same Problem here with LE certifcates and got errors like:

• AH00898: Error during SSL Handshake with remote server returned by
• AH01097: pass request body failed to

while checking out

Code Select Expand

tail -n 0 -f /var/log/apache/access/access_*.log /var/log/apache/error/error_*log
and found several pages with the common solution / found the entry also in

Code Select Expand

/usr/local/etc/apache24/Includes/gateway_vhosts.conf

I had to deactivate "SSL Proxy check peer" on each (backend) Virtual Server to get communication up because the "Firewall: Web Application: Gateways" seems to have the problem, that e.g. "host.example.com" didn't match the wildcard certificate "*.example.com" which is a very weird behavior...

The problem must be known and has to be solved without deactivating this option, but nothing can be found - the parameter cannot even be found in the documentation under:
https://docs.opnsense.org/vendor/deciso/opnwaf.html#configure-virtual-hosts

[franco]

We've tested this just now and there doesn't seem to be a general problem.

The error indicates the trust is broken for whatever reason so it might be specific to a setup or domain. Any hints on how to reproduce?


Cheers,
Franco

[Reiner030]

Luckily it's "good old Apache" which is used so I knew howto search for it's config and howto debug it

The OpenWAF Module is missing important basic functionalities like:

• LogLevel cannot be set by GUI
  (for informational or like here debug purposes)
• Description has very limited allowed charset 0-9a-zA-Z_
  so I am not able to uses dashes or more in it's field
• Servername cannot use *
  (for default server 1:1 mapping or https rewrites only on port 80)
• Servername would be nice to has multiple entries (1st ServerName, additional entries as ServerAlias)
• There is no http => https rewrite vhost possibility;
  maybe as dedicated vhost or best as option in each Virtual Server (best on by default)
• EDIT: There is also a loadbalancer/proxy status page available from Apache which would be nice to included for status summary view
• EDIT2: It would be nice to have also the optional possibility to bind each virtual server to IP or Interfaaces like HAproxy plugin does.
  Maybe also like Lighthttpd/other services for full WAF service so ports can be dedicated managed by IP and have not to roll the dice on every server / service start what they get.
• EDIT2: Custom error pages would be also nice in feature

As in https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeercn
documented it was a not so nice journey to the different parameter behavior naming in 2.4.
So the plugin might be still thinking the old way but behaves totally different caused by apache updates.

After having time I made a request with SSLProxyCheckPeerName Off and with On and checked for differences.
The final result can be easily compacted to this log line which also clarify where the think failure lives:

Code Select Expand


[ssl:debug] [pid 8000:tid 35876042752] ssl_util_ssl.c(451): AH02412: [test.example.com:443]
Cert does not match for name '10.30.22.30' [subject: CN=*.example.com / issuer: CN=R3,O=Let's Encrypt,C=US /
serial: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX / notbefore: Apr 13 21:26:03 2024 GMT / notafter: Jul 12 21:26:02 2024 GMT]


There are multiple logical reasons for this false mismatch:

• Common Name and especially Subject Alternatives Names must not contain IP addresses (of private ranges) .
  https://www.geocerts.com/support/ip-address-in-ssl-certificate
  
• The backend server
  
  
  
  • has by default no internal DNS resolution for reference
  • can also have multiple vhosts referenced by SNI
  • would be failing if called by internal DNS Name but not forwarded (and to be checked) SNI vhost

Hope this helps to fixes/improve the plugin.

[franco]

I'm just not sure how helpful this is.. you're obviously looking at a difference in configuration file result but I don't see the wrong config and the right config side by side here which would make that process snappy and unambiguous.


Cheers,
Franco

[Reiner030]

In discussion with Caddy server thread we found out with maintainer that there is since Caddy 1.5.1 the advanced "hidden" parameter TLS Server Name which is documented as:

If the SAN (Subject Alternative Name) of the offered trusted CA certificate or self-signed certificate doesn't match with the IP address or hostname of the Upstream Domain, enter it here. This will change the SNI (Server Name Identification) of Caddy to the TLS Server Name. IP address e.g. 192.168.1.1 or hostname e.g. localhost or opnsense.local are all valid choices. Only if the SAN and SNI match, the TLS connection will work, otherwise an error is logged that can be used to troubleshoot.

Luckily I setup "ages" ago also similar Apache proxies (aand later NGinx proxies) so I remembered that there is a similar ProxyPreserveHost parameter available.
Checking then default behavior of TLSStrictSNI which is On and can here set in Advances Options to Off now I additional searched for ProxyPreserveHost parameter is Off by default and as checked in config it's also explicit set as Off.

After setting it manually to On and reload Web Access service it was running as expected with TLS background service check with correct TLS name in certificate.

The LogLevel option would be nice to have it basically set in general settings but it would be also a good idea to let it set by vhost sometimes in future to avoid useless logging for higher used Web Access proxies if only one backend has to be debugged.
Here one example vhost generated by Web Access GUI:

/usr/local/etc/apache24/Includes/gateway_vhosts.conf:

Code Select Expand

<VirtualHost *:443>
    ServerName host.example.com
    Options -FollowSymLinks
    Options -Indexes
    Options -ExecCGI
    LogLevel warn
    ProxyRequests Off
    SSLProxyEngine On
    SSLProxyCheckPeerName Off

    SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile    /var/etc/apache_b465c420-6703-481e-acab-6a91a06e08bf.pem
    SSLCertificateKeyFile /var/etc/apache_b465c420-6703-481e-acab-6a91a06e08bf.key

    # https://wiki.mozilla.org/Security/Server_Side_TLS
    # TLS Intermediate configuration
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
    SSLHonorCipherOrder     off
    SSLCompression          off
    SSLSessionTickets       off
    SSLOptions              +StrictRequire

    SSLUseStapling          On


    <Location "/">
        ProxyPreserveHost Off
        ProxyPass "balancer://64e6acb1-3b46-4006-9a46-a5e582df6f24/"
        ProxyPassReverse "balancer://64e6acb1-3b46-4006-9a46-a5e582df6f24/"
    </Location>

    Header always merge Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
    # Add security and privacy related headers
    Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
    Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
    Header set Referrer-Policy "strict-origin"
    Header set X-Frame-Options: "deny"
    SetEnv modHeadersAvailable true


</VirtualHost>
<Proxy balancer://555f9699-86b5-4214-a027-437004b5f9d7>
    BalancerMember https://10.30.2.167
</Proxy>

Would be nice to get the 5 failure points fixed/implemened and maybe also the addition 3 points sometime in future when possible.

[AdSchellevis]

Would be nice to get the 5 failure points fixed/implemened and maybe also the addition 3 points sometime in future when possible.

Secure defaults you mean, see also the notes in passing and reusing headers in https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

I don't mind if you would like to add some advanced toggles to deviate from these defaults, just open a ticket in https://github.com/opnsense/plugins (although these plugins don't live there, in terms of workload planning I rather have some ticket).

When opening a ticket, make sure to use our template and be exact in which options you would like to see and for which reason.

Best regards,

Ad

[Reiner030]

Secure defaults you mean, see also the notes in passing and reusing headers in https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

This is not about passing / reusing "unsecure" common/all headers (which are by the way passed often by default even you wouldn'dnt have the possibility to use PHPSESSID cookies and other relevant informations)...
its only about the SNI Host header without no communication can be done (Hello "unknown". Are you there?) and was introduced in 2003 so over 20 years ago.
AWS let you pay over 600 USD monthly to get a dedicated CDN IP if you need this SNI-less case.

It takes longer time to "rebuild" each needed services "from ground" with patching if the new system modifies itself within the migration path from pfSense to OPNsense (IPSec, OpenVPN, DHCP and more) ... so testing and public patch requests takes also time to create.
Thats not so funny, too.

[franco]

I'm not sure who is who but this is a good and  very recent example of a feature request:

https://github.com/opnsense/plugins/issues/3970

Discussed, solved, ready in 24.4.1.

Talking semantics on the forum not so much.


Cheers,
Franco