Re: [mod-security-users] IS this firewall code bullet proof

[Ivan R. <iva...@gm...>]

On 4/15/06, joe barbish <joe...@ya...> wrote:
>
> I have written a new section to the manual which may better explain where=
 I
> am headed with all this. I have attached it to this email.  Check out new
> section called "web Application firewall". This is really the direction I
> think you should be taking with mod_security. This new strategy in using
> mod_security is my "pay it foward" contribution to the project.  I await
> your feedback.

I appreciate your entusiasm but I am afraid your addition is not going
to make it into the manual. There are several reasons for this. A
major one is that I simply disagree with your statement that
ModSecurity has a "default usage strategy". ModSecurity is just a tool
that you can use one way or another.

Secondly, the advice you are giving in the text simply does not work.
I wish I had the time to explain every single problem in there but I
simply don't. Sorry. And it certainly isn't helping that you are
ignoring the advice I am giving you (see below).You can learn these
things by yourself but you'd have to learn much more about HTTP and do
a lot of testing.


> > # The logon membership process
> > # This script contains both the show form and process form functions.
> > # Need one rule to allow the show form function
> > # and second rule chained to the POST_PAYLOAD rule for
> > # the process form function.
> > SecFilterSelective REQUEST_URI "^/logon.php$" allow
> > SecFilterSelective REQUEST_URI "^/logon.php$" chain
>
> You don't need (nor want) the first of the two lines above. The first
> line will allow the transaction to proceed based only on the URI.
> Invalid values for parameters would be allowed.
>
> my reply*** I think you did not understand the comments in front of this
> code group.
> The second rule belongs to the 2 rules it is chained to. This way that po=
st
> will only be allowed if it matches all 3 conditions.

I don't think you are reading what I'm saying. The second rule and the
other rules chained to it will *never* execute. Nothing happens after
"allow" takes place.


> > SecFilterSelective COOKIE_PHPSESSID "^[0-9a-fA-F]{32}$" chain
> > SecFilterSelective POST_PAYLOAD \
> > "^id=3D[0-9a-z]{15,}$ \
> > &pw=3D[0-9a-z]{15,}$ \
> > &userdigit=3D[0-9a-z]{5,}$ \
> > &submit=3DSubmit$"
>
> I don't see the above working. You are using multiple lines but you
> may not be realising the empty space at the beginning of every new
> line is becoming part of the regular expression. You should use one
> rule per variable you want checked.
>
> myreply***  so are you saying the continuation  has to start on pos 1 of =
new
> line and the \  can not have space before it?  Could this be a bug in how
> mod_security handles regular _expression continuations? I dont remember p=
hp
> or perl or shell sh scripting regular _expression acting this way.

No, it isn't a bug. And it isn't even handled by ModSecurity.


> > All feedback is welcome.
>
> You should test your configuration using real-life examples. There's a
> nice utility included in the ModSecurity distribution, run-test.pl,
> which sends a raw request (contained in a file) to the web server.
> What you need to do is gather a bunch of requests, some valid some
> not, throw them against your web server and verify the reponse status
> codes are as you want them to be. That's the only way to foolproof
> your configuration.
>
> myreply***  I did test a lot during development. I have testbench with
> apache server box on same lan as  my box I develope the code on.  The deb=
ug
> log showed me what was happening.

Then you need to do more tests because your rules aren't working as
you want them to.


> Does this run-test.pl come with file
> containing invalid requests to run? How does a person create these real l=
ife
> requests to test with?

By crafting attacks against the application and watching if the rules
catch them.

> I dont thing you have grasped the strategy I am employing here.
> What I am doing is "outside of the box" of how mod_security is normally
> used. Hopefully reading the section I want to add to the manual will shin=
e
> some light on things.

If that's the case then I am sorry I can't keep up with your thinking.
Good luck with your efforts!

--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall