|
From: Deanna S. <dst...@gm...> - 2018-03-04 04:14:15
|
Hi Kirk, I am running CRS/3.0.0, which I believe is the version that reduced large number of false positives, and modsec ver is 2.9. The rule is getting lot of hits and the traffic is malicious 99.9% of the time, so I'd rather not disable the rule. That article is great and have actually gone through it before, but don't think it addresses the problem/questions I am talking about. Thanks for your input. On Thu, Mar 1, 2018 at 5:46 PM, Kirk Jackson <ki...@pa...> wrote: > Hi Deanna, > > First thing I'd check is whether you're running the latest Core Rule Set - > that has been tuned to have less false positives (see > https://coreruleset.org/) > > Then if you decide that this particular rule is more trouble than it's > worth, I'd disable the rule by ID using SecRuleRemoveById. > > Chaim has a good article on tuning linked from the Core Rule Set blog: > https://www.oreilly.com/ideas/how-to-tune-your-waf- > installation-to-reduce-false-positives > > Even if you remove that rule, you've still got the libinjection rules that > will help detect "real" SQLi (again: assuming you're on a modern > modsecurity). > > Kirk > > On Fri, Mar 2, 2018 at 1:15 PM, Deanna Stevenson <dst...@gm...> > wrote: > >> Hello All, >> >> I have a problem where SQL injection rules like "Detects concatenated >> basic SQL injection and SQLLFI" attempts are firing, when the strings in >> the input fields are similar to SQL commands. Here is an example. >> >> 8d85025e-H-- Message: Warning. Pattern match >> "(?i:(?:[\\d\\W]\\s+as\\s*?[\"'`\\w]+\\s*?from)|(?:^[\\W\\d] >> +\\s*?(?:union|select|create|rename|truncate|load|alter|dele >> te|update|insert|desc)\\b)|(?:(?:select|create|rename|trunca >> te|load|alter|delete|update|insert|desc)\\s+(?:(?:group_)concat|char|load >> ..." at ARGS:address1. [file "/etc/modsec/sitebuyprod/rules >> /REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "451"] [id "942360"] >> [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI >> attempts"] *[data "Matched Data: 1922 ALTER found within ARGS:address1: >> 1922 ALTER St PHILADELPHIA, PA 19146"*] [severity "CRITICAL"] [ver >> "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "application-multi"] >> [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag >> "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag >> "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] >> >> How do I whitelist this behavior in a way, where >> 1. I am not whitelisting actual SQL injection commands. Like in above >> case, I can whitelist not to fire on string "alter" for args adress1, but >> doesn't that eliminate detection/blocking of any alter based SQL injection? >> 2. Is there a way to whitelist such false positives globally for all >> fields. The string could be present in address 2 next time or comments >> etc., and there are multiple sites. Do I have to collect all possible >> fields for all sites, or can I whitelist this false positive globally in >> some way? >> >> Appreciate your help! >> >> Sincerely, >> Deanna >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> 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/ >> >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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/ > > |
