Cool. Glad that solved this issue. If you have additional FPs at paranoia level 1, please do report them. We want to weed out all FPs in the default installation.
Best, Christian On Thu, Oct 18, 2018 at 03:20:25PM -0400, Jonah Potter wrote: > The upgrade from CRS 3.0.0 to 3.0.2 resolved the false positive - the > request no longer returns a 403. I have yet to see any more lonely anomaly > score errors in the logs, and hopefully that trend will continue. Thanks > again for the assistance. > - Jonah > > On Thu, Oct 18, 2018 at 1:55 PM Christian Folini < > christian.fol...@netnea.com> wrote: > > > Hey Jonah, > > > > Good luck and please report back with the results. > > > > Christian > > > > On Thu, Oct 18, 2018 at 10:48:40AM -0400, Jonah Potter wrote: > > > Gregory - good idea. Unfortunately, after adding part K to > > SecAuditLogParts > > > and reproducing the issue, I didn't get any output in part K. Oddly > > enough, > > > no logged requests are outputting anything under the part K heading, even > > > when they have warnings listed in part H. > > > > > > Christian - My mistake - I meant CRS 3.0.0. I'll update to 3.0.2, and if > > > that doesn't take care of it, I'll give 3.1-RC1 a shot, and let you know > > > what happens. > > > > > > Thanks again, > > > Jonah > > > > > > On Wed, Oct 17, 2018 at 2:57 PM Christian Folini < > > > christian.fol...@netnea.com> wrote: > > > > > > > Hey Jonah, > > > > > > > > I suppose you mean CRS 3.0.2 when you say OWASP v3. > > > > > > > > I think there is a silent rule in 3.0.x that raises the anomaly score > > > > without > > > > issuing an alert message. But I can't remember if we fixed that for > > 3.0.2 > > > > or > > > > only for the upcoming 3.1. Could you try with 3.1-RC1 and reproduce it? > > > > Alternatively, you could raise the debug log level and follow the > > > > execution of > > > > the rules. > > > > > > > > Best, > > > > > > > > Christian > > > > > > > > On Wed, Oct 17, 2018 at 01:46:42PM -0400, Jonah Potter wrote: > > > > > Hey guys, hoping you can help me out with a issue I'm having. I'm > > running > > > > > OWASP v3 with libmodsecurity 3.0 on top of nginx-1.15.3 via > > > > > Modsecurity-nginx. I'm experiencing false positives of this variety > > with > > > > > some regularity. A given request will be 403'd, but when I check > > > > > modsec_audit.log, the only rule violations logged are the two > > "inbound > > > > > anomaly score exceeded" codes. The rule that was presumably violated > > > > > leading to the anomaly score being incremented is not logged at all. > > > > Here's > > > > > an example: > > > > > > > > > > ---S4x9aI9l---A-- > > > > > > [17/Oct/2018:11:41:19 -0400] 153979087991.549389 [ip] 61929 [ip] > > 443 > > > > > > ---S4x9aI9l---B-- > > > > > > POST /path/file.php?args=args HTTP/2.0 > > > > > > accept-encoding: gzip, deflate, br > > > > > > cookie: PHPSESSID=xyz; notBot=notBot; _ga=xyz; > > > > > > > > > > > > 73d45a3f924337c011d46201c4a77d88c8b17afce961417c3e4fb7bbce09a31a=0thocmt2erfgbcpmrts35lqgh1; > > > > > > SideMenu=0; SearchLocation=49316; _gid=GA1.2.1268970541.1539790780; > > > > Me=xyz; > > > > > > _gat_UA-1302423-1=1 > > > > > > accept: > > > > > > > > > > > > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 > > > > > > cache-control: max-age=0 > > > > > > user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) > > > > > > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 > > > > Safari/537.36 > > > > > > content-type: multipart/form-data; > > > > > > boundary=----WebKitFormBoundaryCoCuOxmv7pZRNW9G > > > > > > upgrade-insecure-requests: 1 > > > > > > referer: https://www.mydomain.com/path/file.php?args=args > > > > > > origin: https://www.mydomain.com > > > > > > content-length: 1033 > > > > > > host: www.mydomain.com > > > > > > accept-language: en-US,en;q=0.9 > > > > > > ---S4x9aI9l---D-- > > > > > > ---S4x9aI9l---E-- > > > > > > <html>\x0d\x0a<head><title>403 > > Forbidden</title></head>\x0d\x0a<body > > > > > > bgcolor="white">\x0d\x0a<center><h1>403 > > > > > > > > > > > > Forbidden</h1></center>\x0d\x0a<hr><center>nginx/1.15.3</center>\x0d\x0a</body>\x0d\x0a</html>\x0d\x0a<!-- > > > > > > a padding to disable MSIE and Chrome friendly error page > > > > -->\x0d\x0a<!-- a > > > > > > padding to disable MSIE and Chrome friendly error page > > -->\x0d\x0a<!-- > > > > a > > > > > > padding to disable MSIE and Chrome friendly error page > > -->\x0d\x0a<!-- > > > > a > > > > > > padding to disable MSIE and Chrome friendly error page > > -->\x0d\x0a<!-- > > > > a > > > > > > padding to disable MSIE and Chrome friendly error page > > -->\x0d\x0a<!-- > > > > a > > > > > > padding to disable MSIE and Chrome friendly error page -->\x0d\x0a > > > > > > ---S4x9aI9l---F-- > > > > > > HTTP/2.0 403 > > > > > > Server: nginx/1.15.3 > > > > > > Date: Wed, 17 Oct 2018 15:41:19 GMT > > > > > > Content-Length: 571 > > > > > > Content-Type: text/html > > > > > > Connection: close > > > > > > ---S4x9aI9l---H-- > > > > > > ModSecurity: Access denied with code 403 (phase 2). Matched > > "Operator > > > > `Ge' > > > > > > with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' > > ) > > > > [file > > > > > > > > > > > > "/usr/local/owasp-modsecurity-crs-3.0.0/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] > > > > > > [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score > > Exceeded > > > > > > (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] > > > > > > [accuracy "0"] [tag "application-multi"] [tag "language-multi"] > > [tag > > > > > > "platform-multi"] [tag "attack-generic"] [hostname > > "173.167.228.139"] > > > > [uri > > > > > > "/path/file.php"] [unique_id "153979087991.549389"] [ref ""] > > > > > > ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' > > against > > > > > > variable `TX:INBOUND_ANOMALY_SCORE' (Value: `5' ) [file > > > > > > > > > > > > "/usr/local/owasp-modsecurity-crs-3.0.0/rules/RESPONSE-980-CORRELATION.conf"] > > > > > > [line "61"] [id "980130"] [rev ""] [msg "Inbound Anomaly Score > > Exceeded > > > > > > (Total Inbound Score: 5 - > > > > > > SQLI=0,XSS=5,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): XSS Filter - > > > > Category > > > > > > 5: Disallowed HTML Attributes"] [data ""] [severity "0"] [ver ""] > > > > [maturity > > > > > > "0"] [accuracy "0"] [tag "event-correlation"] [hostname > > > > "173.167.228.139"] > > > > > > [uri "/path/file.php"] [unique_id "153979087991.549389"] [ref ""] > > > > > > ---S4x9aI9l---I-- > > > > > > ---S4x9aI9l---J-- > > > > > > ---S4x9aI9l---Z-- > > > > > > > > > > > > > > > I know what the issue is - the user is submitting a text field > > containing > > > > > HTML tags - but I'm not sure precisely which rule is being > > triggered, so > > > > I > > > > > can't figure out how to write a custom rule that disables it for that > > > > > particular argument. Any help in either determining which rule was > > > > > triggered or ensuring the rule is logged would be much appreciated. > > If > > > > more > > > > > information would be helpful, just ask, I'm happy to provide > > whatever I > > > > can. > > > > > > > > > > Thanks, > > > > > Jonah > > > > > > > > > _______________________________________________ > > > > > Owasp-modsecurity-core-rule-set mailing list > > > > > Owasp-modsecurity-core-rule-set@lists.owasp.org > > > > > > > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > > > > > > > > > _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
