Chaim, On Mon, Dec 21, 2015 at 01:40:13PM +0000, Chaim Sanders wrote: > Thanks for the awesome breakdown!
You are welcome. It was a bit of work, but I really wanted to get a
feeling for the new rules. I think I have that now.
> We've really seen some of the older issues rear some nasty levels
> of false positives which as you noted was the reason behind many of
> these.
Glad my assumption was correct.
> However, based on your findings I'm open to including a more
> false-positive prone file that is maybe only anomaly based
> featuring some of the rules that have been taken out.
I'm afraid I do not understand the "maybe only anomaly based".
What do you mean by that?
Last week, I built an experimental group of rules based
on 981173 and a new variable tx.paranoia. The higher you set
the variable, the more aggressive the rules become.
With tx.paranoia=0 (default), they are skipped,
with tx.paranoia=1, the first few rules are applied,
with tx.paranoia=2, the second batch of rules are applied on top.
with tx.paranoia=3, the third batch of rules are applied on top.
So the stuff is cumulative.
I think it is quite easy to understand the ruleset that way.
And I get the feeling this concept is an answer to a wide
variety of false-positive issues. False-positives typically
happen on certain parameter (types) and you can tune away them
quickly, when you have identified them. Either you exclude the
rules, or in this particular case, the paranoia variable
allows you to lower the paranoia setting for certain requests
(but I agree, it is technically very close to adjusting the
anomaly score limit for certain requests, which I suspect is
leading to chaos).
> Additionally I have it on my list to defang 950907 just a bit as its
> EXTEREMLY overzealous.
Yes, the base file os.commands has quite a variety of strings
in it.
Do you know which strings warrant for the false positives?
I was about to suggest to try it out at my standard customer
for a few days / weeks, but then the language of most
users is German and the false positives thus probably not
representative.
> I'm surprised about the XSS rules as most of them were combined into single
> regex's (for speed reasons) I'll have to take a look
Thanks.
> We feel your concern about LibInjection but the concept seems to work and is
> used currently by a number of major WAF's. We can work with the author on a
> code review if this is something we want to prioritize.
There is nothing wrong with the concept. The little bit I understood
sounds very cool. But if the other WAFs not only use the concept,
but also the code, then this is a sure recipe for disaster.
For me, libinject lacks three things:
- A technical description
- A code review
- A community / group of developers working on the library
That thing is parsing input submitted by clients. That's why
we have the WAF after all. But if the parser is less tested
and less reviewed than the input parser of the backend application,
then I do not see the point of the WAF.
The more I think about it, the more I see this as a weak spot to
attack ModSecurity and then try the exploit on the other major WAFs
as well.
If you have the resources for a code review, then that would
be great.
> In terms of the 990012, I think this is something we should
> probably be able to add back, I'll submit a pull request
> sometime this week.
I tried to get around 990002, 990012 and 990902. They are close
but not quite, based on similar files, that overlap and then
leave gaps with 3.0.0-dev as well. So maybe this is just an
omission when trying to replace 990012 with a better 990902.
But I really can't tell.
> Thoughts from you, others?
> Do you think the false-positives file is the best way to handle it or do you
> think these belong in their respective files with a HUGE warning.
I thought about this too. Not sure about the best way to organise it.
One thing that bugs me is the seemingly wild use of the rule ID
namespace. SQLi rules stretch from 950001 up to 981319 for example...
That makes it hard to group rules.
> I think putting them in anomaly only isn't a horrible idea, I'm glad you did
> a look at anomaly scoring, this is always a little bit of a dark art.
I tend to think people do not know how their requests are scoring.
And if you do know how the requests are scoring you have no idea
where to start your tuning. It is essential to add the anomaly
scores to the access.log in my eyes.
> On the new one in some places we've set it up we bumped it up to 7 but it is
> usually below 10. Also there are now multiple different anon scoring areas.
I have not used these different areas so far. I get the point, but I
think it complicates things a lot.
One think I have a hard time understanding is the new 900003 with
the ..._threshold variables. They seem to cloak the incoming and
outgoing anomaly score via the way 981175-981187 set the
tx.inbound_anomaly_score=%{tx.anomaly_score} (only when the
threshold is met). I would rather have
setvar:tx.inbound_anomaly_score=%{tx.anomaly_score}
applied _before_ 981175-981187.
> We should resolve this quickly as I'd like to try and have an RC1 of 3.x by
> mid-February. Thoughts on that as well.
That sounds fair with me. Still thinking about a way to use the
RC in detection mode _next_ to 2.2.x in blocking mode.
Ahoj,
Christian
--
Given the choice between two theories, take the one which is funnier.
--- Blore's Razor, Author unknown
signature.asc
Description: Digital signature
_______________________________________________ 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
