WAF anormaly

Hi Service Informatique2,

You have to allow the id  as per the log on policy if the ID does not come out, put the WAF service in debug from the advanced shell.

service WAF:debug -ds nosync

Check the logs again from log viewer or from the /log/reverseproxy.log and you should see more information from the log since the service is in debug mode.

To disable the debug, please run the command again.

For more information refer the below link : 

https://support.sophos.com/support/s/article/KB-000036242?language=en_US 

and 

https://support.sophos.com/support/s/article/KB-000035562?language=en_US 

Thanks and Regards

Hello, I've tried your command, but I have this result :

SFOS 18.0.6 MR-6-Build655# service WAF:debug -ds nosync
400 Bad Request

Hi  Service Informatique2 ,

Please check the below steps and share the output : 

• Check that the WAF is running: # service WAF:status -ds nosync
• Do a manual restart of WAF: # service WAF:restart -ds nosync
• Record the error messages in the logs if reverseproxy cannot start.
• Check if the network socket is created for the WAF (netstat natup | grep httpd).
• Verify that no other service is running on Port 80 or 443 in the UTM.

• Check if the WAF is running correctly on Port 80: # netstat natup |grep :80
• Check that the service is running: # service WAF:status -ds nosync
• Start/Restart/Stop: # service WAF:<start/restart/stop> -ds nosync
• View Live Log: # tail –f /log/reverseproxy.log

Thanks and regards

Hi Service Informatique2: WAF anomaly may get triggered if any of the data or packets OR the header content gets matched with any of the conditions set in the OWASP core rule sets. This could be a false positive or false negative as well however the exact details can be validated by referring to reverseproxy.log and checking the log lines around this anomaly detection. Generally, if the triggered rules are non-infrastructure rules then sometimes bypassing them in the protection policy fixes the issue for the end-user however if you wanted to confirm is it safe to bypass that rule or not and want to double-check then you may consult the internal Web Server team with those logs who has developed the web app server which is hosted behind the WAF - so they can validate more on the detection part and confirm is it due to any coding side issue or header level things due to which anomaly triggered or just completely false positive which is safe to add an exception. 

www.netnea.com/.../

Hello, thanks for your support.

WAF is running well.

I can't restart WAF because we are in a production environnement and so I can't have any downtine.

Waf is running correctly on Port 80

And I have many many logs in reverseproxy.log

I've downloaded a copy of reverseproxy.log to see if I have more information about the false positive Waf anomaly.

Here what I can see in reverseproxy that match the url of false positive on WAF :

[Mon Jun 20 09:48:31.701223 2022] [form_hardening:error] [pid 17165:tid 139690019632896] [client xx.xx.xx.xx:35252] Form validation failed: Received unhardened form data, referer: https://mywebsite/

and

[Mon Jun 20 09:48:41.022792 2022] [security2:error] [pid 17061:tid 139689692317440] [client xx.xx.xx.xx:35246] [client xx.xx.xx.xx] ModSecurity: Warning. Operator GT matched 400 at ARGS:passwordKey. [file "/usr/apache/conf/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "777"] [id "920370"] [msg "Argument value too long"] [data "ARGS:passwordKey=xxx"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag] [tag] [tag] [tag] [tag] [tag] [hostname "website.something"] [uri "/Account/Login"] [unique_id "YrAmWX8AAAEAAEKlBL4AAACS"], referer: https://mywebsite2.something

you see [id "920370]
You may have to skip this pattern in the linked protection rule for the web server!