|
From: Manuel S. <spa...@gm...> - 2019-01-28 03:58:47
|
Hi Dan, you may take the audit log and rebuild the request with problems and send it to a debugging instance or vhost with debugloglevel 4 at least and track what is going on. You may even do that as part of your regular process by adding a rule right before 949110 with inspectfile and do whatever you want in an external script to very specific use cases. Cheers! Sent from my iPhone > On 27 Jan 2019, at 07:34, Dan Oppenheimer <dan...@po...> wrote: > > Thanks for your responses! > > I tried updating to CRS 3.1.0 and modsecurity 3.0.3. Unfortunately, I get the same behavior. I see a log entry for rule 949110 in the nginx error.log file. But I do not see any other log entries that tell me which rules led to the high anomaly score in either the nginx error.log nor in the modescurity audit log. The modsecurity debug log is more helpful, but I can't run with debugging turned on in production. This context is needed for us to understand why traffic was blocked so that we have information required to address an attack or exclude a rule. At this point, I think I need to switch from anomaly scoring mode to self contained mode. It looks like anomaly scoring mode with nginx does not provide enough context in the logs to be usable. As a future request, it would be good to have rule 949110 provide a list of rule ids which led to the high anomaly score. > > Thanks, > > Dan > >> On Fri, Jan 25, 2019 at 3:13 PM Gregory LeFevre <gr...@cl...> wrote: >> >> Hi Dan, >> >> Just a guess, but what happens if you change the nginx error_log severity level to info and restart (rather than reload) nginx? >> >> Granted that I don't know what you may already have the nginx log level set to and whether the fact that you already see the "Anomaly Score Exceeded" message disrupts my theory, but, again, just a guess. >> >> Gregory >> >>> On Fri, Jan 25, 2019 at 8:45 AM Dan Oppenheimer <dan...@po...> wrote: >>> Hi all, >>> >>> We have modsecurity 3.0.2 being used by nginx 1.14.0 via the modsecurity/nginx connector. We are using the core rule set 3.0.2 configured for anomaly scoring. The following is being blocked by modsecurity: >>> >>> 2019/01/24 10:17:52 [warn] 22326#0: *120 [client 172.16.17.54] ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `10' ) [file "/etc/nginx/modsec/owasp-modsecurity-crs-3.0.2/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 10)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "172.16.17.54"] [uri "/api/auto-engagement/list/b107e2c8-b4e4-470a-b10d-025b11b376cd"] [unique_id "154834307287.337943"] [ref ""], client: 172.16.17.54, server: stress-secure-pointillist.altidev.net, request: "DELETE /api/auto-engagement/list/b107e2c8-b4e4-470a-b10d-025b11b376cd HTTP/1.1", host: "stress-secure-pointillist.altidev.net", referrer: "https://test.pointillist.com/studio/story/d5fac22e-e0eb-49ea-8297-a0ec11ce1149" >>> >>> But I do not see any other log message in either the nginx error.log or the modsecurity audit log. As rule 949110 is the rule which determines whether or not the anomaly score is high enough to be blocked, I would expect to see more context in one or both of those files. That is, I would expect to see one or more log message for the rules that triggered the high anomaly score. I have set DELETE to an allowed header in the crs-setup.conf file: >>> >>> SecAction \ >>> "id:900200,\ >>> phase:1,\ >>> nolog,\ >>> pass,\ >>> t:none,\ >>> setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE'" >>> >>> I have also enabled audit logging in the modsecurity.conf file: >>> >>> SecAuditEngine On >>> >>> SecAuditLogRelevantStatus "^(?:5|4(?!04))" >>> >>> # Log everything we know about a transaction. >>> SecAuditLogParts ABIJDEFHKZ >>> >>> SecAuditLogType Serial >>> SecAuditLog /var/log/nginx/modsec_audit.log >>> >>> Thanks, >>> >>> Dan >>> -- >>> DevOps Engineer >>> Pointillist, Inc >>> _______________________________________________ >>> mod-security-users mailing list >>> mod...@li... >>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: >>> http://www.modsecurity.org/projects/commercial/rules/ >>> http://www.modsecurity.org/projects/commercial/support/ >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: >> http://www.modsecurity.org/projects/commercial/rules/ >> http://www.modsecurity.org/projects/commercial/support/ > > > -- > DevOps Engineer > Pointillist, Inc > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ |
