owasp-modsecurity / ModSecurity-nginx

ModSecurity v3 Nginx Connector
Apache License 2.0
1.48k stars 274 forks source link

SecRuleEngine logs only SecRuleID 949110 #281

Closed tarmo-profi closed 2 years ago

tarmo-profi commented 2 years ago

Describe the bug

If SecRuleEngine is set to On and a ShellShock attack is made, logs only present a SecRuleID 949110 Inbound Anomaly Score Exceeded (Total Score: 5). ModSecurity has a SecRule against ShellShock, ID 932170 but it won't be logged.

Logs and dumps

2022/04/21 09:08:11 [error] 7814#7814: *1431691 [client IPADDRESS] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator Ge' with parameter5' against variable TX:ANOMALY_SCORE' (Value:5' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "192.168.149.9"] [uri "/"] [unique_id "1650532091"] [ref ""], client: IPADDRESS, server: DOMAIN.COM, request: "GET / HTTP/2.0", host: "DOMAIN.COM"

Output of:

  1. DebugLogs (level 9)
  2. AuditLogs
  3. Error logs
  4. If there is a crash, the core dump file.

Notice: Be carefully to not leak any confidential information.

To Reproduce

Steps to reproduce the behavior:

A curl command line that mimics the original request and reproduces the problem. Or a ModSecurity v3 test case.

curl -H 'User-Agent: () { :; }; echo' DOMAIN.COM

Expected behavior

After curl, the ModSecurity will block the request and logs it with SecRuleID 932170.

Server (please complete the following information):

Rule Set (please complete the following information):

Additional context

Add any other context about the problem here.

martinhsv commented 2 years ago

Hi @tarmo-profi ,

As mentioned elsewhere (in your previous, now-closed issue), to get output in the nginx error.log file for rules that are not disruptive:

If your current setting for the nginx error_log is 'notice', i.e.:

error_log /var/log/nginx/error.log notice;

You should change that to a more detailed setting like 'info'

error_log  /var/log/nginx/error.log info;
martinhsv commented 2 years ago

Hi @tarmo-profi ,

Have you tried that out?

tarmo-profi commented 2 years ago

Hi @tarmo-profi ,

Have you tried that out?

Hello,

I did try that solution but i noticed that the error.log isn't logging into stdout where i usually look logs. So i assume that solution is working.. Question is, how do i change error.log's output to stdout?

I will try to arrange time to solve this.

airween commented 2 years ago

@tarmo-profi

I did try that solution but i noticed that the error.log isn't logging into stdout where i usually look logs. So i assume that solution is working.. Question is, how do i change error.log's output to stdout?

When Nginx (or most Unix process) starts and forks itself (we can call it as daemon), then it means the process drops the stdin, stdout and stderr descriptors. There are not exist anymore.

Therefore I can't interpret your question, that change the error.log's output to stdout. Or I can do that only, if your Nginx instance runs in foreground.

martinhsv commented 2 years ago

Since the original question has been addressed, I'm going to go ahead and close this.

(Moreover, if the OP's nginx configuration has become broken such that no logs lines of any kind are being written to the error.log file any longer, that's a question that's beyond the scope of this forum, as it's really more of a core nginx issue.)