You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm encountering an issue where ModSecurity is blocking requests with a 403 status code, but Nginx is returning a 500 error to the client. Additionally, there are cases where ModSecurity returns a 200 status, but Nginx throws a 499 error instead. The ModSecurity audit log shows the expected 403 or 200 status codes, but this is not reflected in the Nginx responses.
This issue tends to occur when I send a large number of requests or simulate a DOS attack. I've included the relevant access, audit, and error logs below for further context.
Any guidance on why these discrepancies are happening under high traffic conditions and how to resolve them would be greatly appreciated.
If I'm understand you correctly, you use libmodsecurity3 as a module for Nginx (through lingninx-mod-http-modsecurity), and Nginx (as a back end) sends a 5XX response to the client, but ModSecurity "transforms" it into 403, right?
That's a normal behavior if you use CRS. Please take a look the rule 950100. This rule catches the response with 5XX code, and the increments the tx.outbound_anomaly_score_pl2 by 5 (tx.error_anomaly_score). After that rule 959100 (which checks that score value) uses action deny. Default response code in case of deny is 403, so the behavior is normal.
that is ok the request is blocked but that 403 should be carried and NGINX should rely that to the client . What Im trying to say is whatever modsec is throwing that is not being displayed to the client.
I'm encountering an issue where ModSecurity is blocking requests with a 403 status code, but Nginx is returning a 500 error to the client. Additionally, there are cases where ModSecurity returns a 200 status, but Nginx throws a 499 error instead. The ModSecurity audit log shows the expected 403 or 200 status codes, but this is not reflected in the Nginx responses.
This issue tends to occur when I send a large number of requests or simulate a DOS attack. I've included the relevant access, audit, and error logs below for further context.
Any guidance on why these discrepancies are happening under high traffic conditions and how to resolve them would be greatly appreciated.
access_log.json
audit_log.json
error_log.txt
The text was updated successfully, but these errors were encountered: