Christian,
My understanding is that what Kirk responded with doesn't address the
problems I am talking about. Looks like the reply I sent on March2 had a
delivery failure. I'll try to answer point by point here again. I'd be glad
if you can correct me if my thinking is wrong.
*"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/ <https://coreruleset.org/>)"*
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.
*"Then if you decide that this particular rule is more trouble than it's
worth, I'd disable the rule by ID using SecRuleRemoveById."*
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.
*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
<https://www.oreilly.com/ideas/how-to-tune-your-waf-installation-to-reduce-false-positives>*
This article, talks about tuning the noise in general and approach one can
take to identify what is causing most noise, and work down methodically.
Its a great post.
But, the problem I have here is very specific and don't see those concepts
covered in that article. My problem is how would I whitelist SQL command
like words in text fields, but not actually whitelist SQL commands part of
SQLI.
Here is the problem:
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|delete|update|insert|desc)\\b)
|(?:(?:select|create|rename|truncate|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?
Hope that better explains what am looking for. If the answer is that I
won't be able to do something like that, and just have to whitelist those
words by each field per URI, and hope other SQLI attack based rules capture
the attack when they are actual SQL commands, I'll take that, but wanted to
confirm and verify with experienced user community here. Would greatly
appreciate sharing your opinion.
Sincerely,
Deanna
On Fri, Mar 16, 2018 at 9:29 AM, Christian Folini <
chr...@ne...> wrote:
> Hey Deanna,
>
> Kirk Jackson responded to your message on March 2. Is there anything wrong
> with his advice?
>
> Best,
>
> Christian
>
> On Fri, Mar 16, 2018 at 09:17:49AM -0600, Deanna Stevenson wrote:
> > Hi All,
> >
> > Any advise on possible solutions for my problem?
> >
> > Sincerely,
> > Deanna
> >
> >
> >
> > On Tue, Mar 6, 2018 at 10:22 AM, Franziska Buehler <
> > fra...@gm...> wrote:
> >
> > > Hi,
> > >
> > > Just a note about the linked blog post:
> > >
> > > https://www.oreilly.com/ideas/how-to-tune-your-waf-
> > > installation-to-reduce-false-positives
> > >
> > > It was Christian Folini who has written this blog post about how to
> > > reduce false positives.
> > > Chaim linked it on https://coreruleset.org.
> > >
> > > Best regards,
> > > Franziska
> > >
> > > ------------------------------------------------------------
> > > ------------------
> > > 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/
>
>
> --
> https://www.feistyduck.com/training/modsecurity-training-course
> https://www.feistyduck.com/books/modsecurity-handbook/
> mailto:chr...@ne...
> twitter: @ChrFolini
>
> ------------------------------------------------------------
> ------------------
> 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/
>
|