Re: [mod-security-users] Rules manageability

[Ofer S. <OferS@Breach.com>]

Added it to the feature requests

=20

~ Ofer

=20

From: Marc Stern [mailto:mar...@ad...]=20
Sent: Tuesday, June 19, 2007 9:58 AM
To: Ofer Shezaf
Cc: Christian Bockermann; Mod Security
Subject: Re: [mod-security-users] Rules manageability

=20

Yes, that's my question ;-)
You seem to be quite positive about that, so I feel confident ...

Marc

Ofer Shezaf wrote:=20

Do you mean to offer the @contained operator for the a coming version? I
think it is the only thing missing to make the method below work.=20

 =20

~ Ofer=20

 =20

From: Marc Stern [mailto:mar...@ad...]=20
Sent: Monday, June 18, 2007 10:38 AM
To: Ofer Shezaf
Cc: Christian Bockermann; Mod Security
Subject: Re: [mod-security-users] Rules manageability=20

 =20

Here is one way to easily handle order:

I use a separate conf file for security (pointing to other ones) - say
"security.conf".
I use a separate conf file for all proxy path handling - say
"proxy.conf".
The trick is to include "security.conf" *before* "proxy.conf", and have
the rule inside a location, like:=20

* proxy.conf *
<Location "/webdav">
    ...
    SecAction
"setvar:rx.allowed_method=3D'%{TX.ALLOWED_METHODS},PUT,DELETE,...'"
phase:2
    ...
</Location>

* security.conf *
SecAction
"setvar:rx.allowed_method=3D'GET,POST,HEAD',%{TX.ALLOWED_METHODS}"
<Location "/">
  SecRule REQUEST_METHOD "!@contained %{TX.ALLOWED_METHODS}"
<mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d>  phase:2
</Location>=20


Another solution is indeed to use:=20

* proxy.conf *
SecRule REQUEST_FILENAME "/webdav"
"phase:1,pass,nolog,setvar:tx.allowed_methods=3D...."

* security.conf *
SecAction
"setvar:rx.allowed_method=3D'GET,POST,HEAD',%{TX.ALLOWED_METHODS}"
SecRule REQUEST_METHOD "!@contained %{TX.ALLOWED_METHODS}"
<mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d>  phase:1=20

This one is better regarding security, as we can use it in phase 1.
It may be a bit less readable, especially if you already have a big
location with a lot of directive, so this is really a matter of personal
style I guess. Anyway, both solutions would work.

Ofer, could you propose this as an enhancement for (a) next version ?

Thanks

Marc


Ofer Shezaf wrote:=20

  =20
Christian wrote: =20
   =20

		Interestingly enough we are getting closer to your
request: =20
		  =20
		- We have request parameters - the tx collection. =20
		- We have variable substitution in rules - the new non
regexp =20
		operators =20
		such as @contains or @streq accept variable substitution
in their =20
		operand. =20
		- We have variable substitution in actions so you can
modify =20
		  =20
		So you could maintain a tx variable containing your
condition, =20
		modify it =20
		in a directory scope and use a single rule to test
against the =20
		       =20

	current =20
	     =20

		value of the condition variable. =20
		  =20
		Why aren't we there: =20
		- The only thing you can do to your condition variable
is add to it =20
		       =20

	or =20
	     =20

		replace it. No fancy string manipulation. =20
		- The current operators that allow variables are pretty
limited and =20
		are =20
		ill-adjusted to such logic as they assume the operand is
part of the =20
		input and not visa-versa. =20
		  =20
		But let's assume that we would have the operator
@contained =20
		(opposite of =20
		@contains). You could do something like that: =20
		  =20
		SecAction "setvar:rx.allowed_method=3D'GET,POST,HEAD'" =20
		  =20
		<Location "/webdav"> =20
		  SecAction =20
=09
"setvar:rx.allowed_method=3D'%{TX.ALLOWED_METHODS},PUT,DELETE.....'" =20
		</Location> =20
		  =20
		SecRule REQUEST_METHOD "!@contained
%{TX.ALLOWED_METHODS}" <mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d>

		  =20
		One issue I'm not sure about is order of execution.
Details... =20
		       =20

	  =20
	Having looked at that I have some questions/additions: =20
	  =20
	  - setvar:rx.allowed...  is meant to be  setvar:tx.allowed... ?

	    I do ask this, because using tables is sometimes a bit
tricky. =20
	  =20
	     =20

  =20
Yes, tx of-course. This is not a production code and as you pointed =20
later, not very useful. =20
  =20
   =20

	  - All this has to be done with phase:2 set as the =20
	     =20

Location-directives =20
   =20

	    are not applied before phase-2. =20
	     =20

  =20
True. Though sub-sectioning can be done also using a rule: =20
  =20
SecRule REQUEST_FILENAME "/webdav" =20
"pass,nolog,setvar:tx.allowed_methods=3D...." =20
  =20
   =20

	  - According to Marc's e-mail I do not see the benefit of this

	     =20

complex =20
   =20

	    way of specifying the allowed methods for a sub-context.
Just =20
	     =20

using =20
   =20

	    SecRemoveRuleById and writing a new rule seems somewhat more

	readable =20
	    and cleaner to me: =20
	  =20
	SecRule REQUEST_METHOD !^(GET|POST|HEAD)$ "phase:2,id:123" =20
	  =20
	<Location "/webdav"> =20
	 SecRuleInheritance On =20
	 SecRuleRemoveById 123 =20
	  =20
	 SecRule REQUEST_METHOD !^(GET|POST|PUT|DELETE)$ "phase:2" =20
	</Location> =20
	     =20

  =20
The problem Marc raised, and I find very true, is that using =20
SecRemoveById completely eliminates the original, so updates to the =20
original are not preserved. Using TX, if a new method is added to the =20
original (GET|POST|HEAD), it would be propagated to the sub context. =20
Using SecRuleRemoveByID is would not. =20
  =20
Saying that, my code was just a demonstration of a potential roadmap. I

even used a non-existing operator. Today, only your way will work. =20
  =20
   =20

	  =20
	The complex tx-table setup (Don't get me wrong - I really like =20
	ModSecurity's tables and use them a lot) does not help on
forgetting =20
	"replacement-rules" - or did I miss anything? =20
	  =20
	Using chained rules you could also have your specialized rules
in =20
	one part of your conf-file - which might help on the
"forgetting"- =20
	thing: =20
	  =20
	    # specialized rule for webdav-app/location =20
	    # =20
	    SecRule REQUEST_URI ^/webdav "phase:2,chain,skip:1,id:123" =20
	    SecRule ARGS "@validateByteRange 5,9,10,13,32-126" =20
	  =20
	    # general rule for all other webapps =20
	    # =20
	    SecRule ARGS "@validateByteRange 9, 10,13,32-126"
"phase:2,id:123" =20
	  =20
	As the first two lines are glued together by "chain", this
snippet =20
	defines exactly 2 rules of which the last one is skipped in case
of =20
	the uri starting with /webdav =20
	  =20
	These a just my two cent. I think this is somewhat related to
"style" =20
	on writing rulesets and thus a quite nice topic for discussing.

	Perhaps there are other advices on how to handle that ;-) =20
	  =20
	     =20

  =20
I hope I made it clear where I think it is not style anymore: when you =20
copy the original rule when making an exception, you lose any future =20
changes to the original rule. Ideally exceptions could be a delta from =20
the existing rule and not copy it. We are not there yet. =20
  =20
Another upcoming addition to ModSecurity engine that will help in this =20
would be a RemoveByID action. It will enable the use other request parts

such as source IP or a parameter value as exception conditions. Since =20
SecRemoveRuleByID is currently a directive it is limited to the global =20
scope or to Apache location scopes. =20
  =20
~ Ofer =20
  =20
  =20
   =20

			-----Original Message----- =20
			From:
mod...@li... [mailto:mod- =20
			sec...@li...] On
Behalf Of Marc =20
			         =20

	Stern =20
	     =20

			Sent: Friday, June 15, 2007 12:43 PM =20
			To: Mod Security =20
			Subject: [mod-security-users] Rules
manageability =20
			  =20
			I'm quite prolix today ;-) =20
			  =20
			I'm trying to find a better way to manage some
rules, depending on =20
			the =20
			location. This is very important in the context
of a reverse proxy =20
			serving several applications. =20
			  =20
			Concrete example (just one between others): I'm
blocking, by =20
			         =20

	default, =20
	     =20

			all characters outside some ranges =20
			    SecRule ARGS     "@validateByteRange 9, 10,
13, 32-126" =20
			phase:2,id:xxx =20
			  =20
			In case I have an application using another
character (say 5), the =20
			         =20

		only =20
		       =20

			ways I found to have it working are =20
			 - adding the character for all applications
(easy but insecure =20
			approach) =20
			 - inside the location, remove the rule, and
create a brand new one =20
			Although the second approach is better regarding
security, it is =20
			quite =20
			difficult to manage; if I ever want to modify
the main rule (xxx), =20
			         =20

I =20
   =20

		do =20
		       =20

			not have to forget to change all "replacement"
rules for the =20
			different =20
			locations. =20
			  =20
			Is there a way, maybe with the new features in
the development =20
			         =20

		version, =20
		       =20

			to do something like =20
			 - define a variable containing a range (or the
complete rule =20
			         =20

string =20
   =20

			like "@validateByteRange 9, 10, 13, 32-126") =20
			 - inside each location, extend this variable
with additional data =20
			 - check the rule against the variable =20
			  =20
			Any other mechanism is obviously welcome. =20
			  =20
			Marc =20
			         =20

=20

  =20
  =20
   =20