Apache mod-security

Re: Throttling

You can do this using ModSecurity's collection-capabilities.
First you initalize a collection wrt the ip-address

	SecAction initcol:ip=%{REMOTE_ADDR},nolog

Now you have a collection called "IP" that you can use to save  
variables.
The following rule will check if there exists a variable "count"  
within the
ip-collection. If not, it will initialize such a variable to 0 and tell
ModSecurity to expire it after 1 hour (3600 seconds).

	SecRule &IP:COUNT "@eq 0" "setvar:ip.count=0,expirevar:ip.count=3600"

Then you can "count" the accesses using this collection

	SecAction setvar:ip.count=+1

For example within a certain location (then you need to add a "phase: 
2" to
the actions). This will increment the variable "count" within the  
collection
IP (which is assiciated with the REMOTE_ADDR) by one.

You can then use this variable to block an IP:

	SecRule IP:COUNT "@gt 2000" "deny,status:500"

Not the different cases when setting and querying collection-variables.

(Continue reading)

headers

Christian Folini | 2 May 15:28

Re: Throttling

On Wed, May 02, 2007 at 03:06:31PM +0200, Christian Bockermann wrote:
> You can do this using ModSecurity's collection-capabilities.
> First you initalize a collection wrt the ip-address
> 
> 	SecAction initcol:ip=%{REMOTE_ADDR},nolog
>
> ...
>
> You can then use this variable to block an IP:
> 
> 	SecRule IP:COUNT "@gt 2000" "deny,status:500"
> 

Smart use of modsecurity. But you should be very careful when using this
in practice. (a) do not deny access to someone using you site
extensively, but rather redirect him to a page exlaining your
policy. (b) Basing a session on an ip address is mostly a bad idea.
Even more so when you sum up all the requests from a single IP
address during a day (or a full hour in the example) and deny 
when a limit is reached. IP addresses change and what is even
more important: enterprise outgoing proxies make all users
behind the proxy look like they come from the same ip address.
This might sum up quickly.

You need different means to track users. Cookies and possibly even
ssl session keys spring to mind. Other variant exist and they all 
have their merits and disadvantages. IP address is the most
simple one and the one which will break your site most easily.

Russ, you are facing a problem that is definitely tricky to solve in

(Continue reading)

headers

Ryan Barnett | 2 May 15:12

Re: Throttling

Looks like Chris beat me again :)  

Just to show you, however, that there are many ways to implement this
collections here is another version.  The following ruleset will use
initcol to create a persistent collection based on the client's IP
address.  It will then start incrementing the "request_count" variable
on each request and will expire this same variable 24 hrs after the last
request.  It will then evaluate the request_count variable to see if it
is greater than or equal to 2000.  If it is, it sets a new variable -
ip.blocked.  The last rule will only check for the existence of
ip.blocked.  If it is set, it will deny the connection and then send a
redirect to the client to send them to a "friendly" page telling them
why they are blocked.  The 2nd rule in this ruleset is to allow clients
with ip.blocked set to get to this friendly page.

SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}, \
setvar:request_count=+1,expirevar:request_count=86400

SecRule REQUEST_URI "^/request_limit_exceeded\.html$" \
"log,allow,ctl:ruleEngine=off"

SecRule IP:REQUEST_COUNT "@ge 2000" \
"phase:1,pass,nolog,setvar:ip.blocked=1, \
expirevar:ip.blocked=3600"

SecRule IP:BLOCKED "@eq 1" "phase:1,deny,log, \
redirect:http://www.site.com/request_limist_exceeded.html"

--

-- 
Ryan C. Barnett

(Continue reading)

headers

Russ Lavoie | 2 May 15:54

Re: Throttling

I understand rule 1,2 and 4.

Why expire the ip.blocked after 1 hour in rule 3?  I would like to block
them for 24 hours.  Or am I not understanding the rule?

Thanks

-----Original Message-----
From: Ryan Barnett [mailto:Ryan.Barnett <at> Breach.com] 
Sent: Wednesday, May 02, 2007 8:12 AM
To: Christian Bockermann; Russ Lavoie
Cc: Mod Security
Subject: RE: [mod-security-users] Throttling

Looks like Chris beat me again :)  

Just to show you, however, that there are many ways to implement this
collections here is another version.  The following ruleset will use
initcol to create a persistent collection based on the client's IP
address.  It will then start incrementing the "request_count" variable
on each request and will expire this same variable 24 hrs after the last
request.  It will then evaluate the request_count variable to see if it
is greater than or equal to 2000.  If it is, it sets a new variable -
ip.blocked.  The last rule will only check for the existence of
ip.blocked.  If it is set, it will deny the connection and then send a
redirect to the client to send them to a "friendly" page telling them
why they are blocked.  The 2nd rule in this ruleset is to allow clients
with ip.blocked set to get to this friendly page.

SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}, \

(Continue reading)

headers

Christian Bockermann | 2 May 16:08

Re: Throttling


Am 02.05.2007 um 15:54 schrieb Russ Lavoie:

> I understand rule 1,2 and 4.
>
> Why expire the ip.blocked after 1 hour in rule 3?  I would like to  
> block
> them for 24 hours.  Or am I not understanding the rule?
>
...
>
> SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}, \
> setvar:request_count=+1,expirevar:request_count=86400
>
> SecRule REQUEST_URI "^/request_limit_exceeded\.html$" \
> "log,allow,ctl:ruleEngine=off"
>
> SecRule IP:REQUEST_COUNT "@ge 2000" \
> "phase:1,pass,nolog,setvar:ip.blocked=1, \
> expirevar:ip.blocked=3600"
>
> SecRule IP:BLOCKED "@eq 1" "phase:1,deny,log, \
> redirect:http://www.site.com/request_limist_exceeded.html"

This should already happen as the request count for a certain IP
is resetted after 86400 seconds (= 1 day). Don't know why Ryan
expired his "BLOCKED" after 1 hour, as it would immediately be
set to 1 again if another request from a formerly blocked IP hits
your server (since "@ge 2000" will still match the REQUEST_COUNT).

(Continue reading)

headers

Avi Aminov | 2 May 18:29

Re: Throttling

Why set the blocking to just one hour, then renewing it?
Suppose someone has made his 2000th access, 23 hours after his first
access. If you block him now for 24 hours, the result is that you let
him 2000 in TWO DAYS, instead of one.
With Ryan's logic, this will not happen.

-----Original Message-----
From: mod-security-users-bounces <at> lists.sourceforge.net
[mailto:mod-security-users-bounces <at> lists.sourceforge.net] On Behalf Of
Christian Bockermann
Sent: Wednesday, May 02, 2007 5:08 PM
To: Russ Lavoie
Cc: Mod Security; Ryan Barnett
Subject: Re: [mod-security-users] Throttling

Am 02.05.2007 um 15:54 schrieb Russ Lavoie:

> I understand rule 1,2 and 4.
>
> Why expire the ip.blocked after 1 hour in rule 3?  I would like to  
> block
> them for 24 hours.  Or am I not understanding the rule?
>
...
>
> SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}, \
> setvar:request_count=+1,expirevar:request_count=86400
>
> SecRule REQUEST_URI "^/request_limit_exceeded\.html$" \
> "log,allow,ctl:ruleEngine=off"

(Continue reading)