Apache mod-security

Ryan Barnett | 1 May 19:42

Re: Mod_Security and Content-Encoding: gzip

Very timely...  The short answer however is - No, Mod can not handle
compressed/gzipped data.  Ofer will be releasing an update to the Core
Rules shortly and there are some updates to address compressed content
(from an alerting perspective).  

This is from the CHANGES file -
ModSecurity does not support compressed content at the moment. Thus, the
following rules have been added:
- 960013 - Content-Encoding in request not supported
    Any incoming compressed request will be denied
- 960051 - Content-Encoding in response not suppoted
    An outgoing compressed response will be logged to alert, but ONLY
ONCE.

--

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
Author: Preventing Web Attacks with Apache

--------------
Web Security Threat Report Webinar on May 9, 2007 (12 pm EST)
Learn More About the Breach Webinar Series:
http://www.breach.com/webinars.asp
--------------

> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Jim Hermann

(Continue reading)

Jim Hermann - UUN Hostmaster | 2 May 00:50

Re: Mod_Security and Content-Encoding: gzip

How can I filter the RESPONSE_BODY so that mod_security does not receive it
when the Content-Encoding is gzip?

I like the idea of checking for code leakage when the Content-Encoding is
not gzip.

Thanks.

Jim

> -----Original Message-----
> From: Ryan Barnett [mailto:Ryan.Barnett <at> Breach.com] 
> Sent: Tuesday, May 01, 2007 12:42 PM
> To: Jim Hermann - UUN Hostmaster; 
> mod-security-users <at> lists.sourceforge.net
> Subject: RE: [mod-security-users] Mod_Security and 
> Content-Encoding: gzip
> 
> Very timely...  The short answer however is - No, Mod can not handle
> compressed/gzipped data.  Ofer will be releasing an update to the Core
> Rules shortly and there are some updates to address compressed content
> (from an alerting perspective).  
> 
> This is from the CHANGES file -
> ModSecurity does not support compressed content at the 
> moment. Thus, the
> following rules have been added:
> - 960013 - Content-Encoding in request not supported
>     Any incoming compressed request will be denied
> - 960051 - Content-Encoding in response not suppoted

(Continue reading)

Ryan Barnett | 2 May 00:58

Re: Mod_Security and Content-Encoding: gzip

You should be able to use a rule similar to this identify any
Content-Encoding (for compression) and then disable Mod
inspection/logging for it -

SecRule RESPONSE_HEADERS:Content-Encoding "!^Identity$" \
    "phase:3,t:none,nolog,pass,ctl:auditEngine=Off,ruleEngine=Off"

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
Author: Preventing Web Attacks with Apache

--------------
Web Security Threat Report Webinar on May 9, 2007 (12 pm EST)
Learn More About the Breach Webinar Series:
http://www.breach.com/webinars.asp
--------------

> -----Original Message-----
> From: Jim Hermann - UUN Hostmaster [mailto:hostmaster <at> uuism.net]
> Sent: Tuesday, May 01, 2007 6:50 PM
> To: Ryan Barnett; mod-security-users <at> lists.sourceforge.net
> Subject: RE: [mod-security-users] Mod_Security and Content-Encoding:
gzip
> 
> How can I filter the RESPONSE_BODY so that mod_security does not
receive
> it

(Continue reading)

Avi Aminov | 2 May 08:24

Re: Mod_Security and Content-Encoding: gzip

Ryan, this rule will not work, because Apache generates the response
headers just before it sends the response, only in phase 5 - logging.
The only headers available at this point are the ones generated by the
web application. In the new core rule set (should be available very
soon), the rule for logging outgoing compressed response is applied only
in phase:5, and this is the reason. 

When your rule is applied, the variable
<RESPONSE_HEADERS:Content-Encoding> doesn't exist, and the rule will
never satisfy (that is in modSec2. In modSec 1.9, however, it will
ALWAYS satisfy).

This means, unfortunately, that we cannot make an interruptive action
based on response-headers. I'm sure we will find a way to overcome this
in the future.

Apache stores this information in the variable r->content_encoding, but
I have no idea how to reach it from modSecurity.

Avi.

-----Original Message-----
From: mod-security-users-bounces <at> lists.sourceforge.net
[mailto:mod-security-users-bounces <at> lists.sourceforge.net] On Behalf Of
Ryan Barnett
Sent: Wednesday, May 02, 2007 1:58 AM
To: Jim Hermann - UUN Hostmaster;
mod-security-users <at> lists.sourceforge.net
Subject: Re: [mod-security-users] Mod_Security and Content-Encoding:
gzip

(Continue reading)

Jim Hermann - UUN Hostmaster | 3 May 14:09

Re: Mod_Security and Content-Encoding: gzip

How do I configure Apache to ignore requests for gzip, so that the RESPONSE
is never Content-Encoding: gzip?

Thanks.

Jim 

> -----Original Message-----
> From: Avi Aminov [mailto:avia <at> breach.com] 
> Sent: Wednesday, May 02, 2007 01:24 AM
> To: Ryan Barnett; Jim Hermann - UUN Hostmaster; 
> mod-security-users <at> lists.sourceforge.net
> Subject: RE: [mod-security-users] Mod_Security and 
> Content-Encoding: gzip
> 
> Ryan, this rule will not work, because Apache generates the response
> headers just before it sends the response, only in phase 5 - logging.
> The only headers available at this point are the ones generated by the
> web application. In the new core rule set (should be available very
> soon), the rule for logging outgoing compressed response is 
> applied only
> in phase:5, and this is the reason. 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Ryan Barnett | 3 May 15:58

Re: Mod_Security and Content-Encoding: gzip

Disable mod_deflate -
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
Author: Preventing Web Attacks with Apache

--------------
Web Security Threat Report Webinar on May 9, 2007 (12 pm EST)
Learn More About the Breach Webinar Series:
http://www.breach.com/webinars.asp
--------------

> -----Original Message-----
> From: Jim Hermann - UUN Hostmaster [mailto:hostmaster <at> uuism.net]
> Sent: Thursday, May 03, 2007 8:09 AM
> To: Avi Aminov; Ryan Barnett; mod-security-users <at> lists.sourceforge.net
> Subject: RE: [mod-security-users] Mod_Security and Content-Encoding:
gzip
> 
> How do I configure Apache to ignore requests for gzip, so that the
> RESPONSE
> is never Content-Encoding: gzip?
> 
> Thanks.
> 
> Jim

(Continue reading)

Ryan Barnett | 2 May 14:25

Re: Mod_Security and Content-Encoding: gzip

Good points, this is correct for embedded mode installations.  I guess I
am used to assuming that people are running Mod in a Reverse Proxy mode
and that is not always the case.  In the Reverse Proxy mode, these
headers should be present.

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
Author: Preventing Web Attacks with Apache

--------------
Web Security Threat Report Webinar on May 9, 2007 (12 pm EST)
Learn More About the Breach Webinar Series:
http://www.breach.com/webinars.asp
--------------

> -----Original Message-----
> From: Avi Aminov
> Sent: Wednesday, May 02, 2007 2:24 AM
> To: Ryan Barnett; Jim Hermann - UUN Hostmaster; mod-security-
> users <at> lists.sourceforge.net
> Subject: RE: [mod-security-users] Mod_Security and Content-Encoding:
gzip
> 
> Ryan, this rule will not work, because Apache generates the response
> headers just before it sends the response, only in phase 5 - logging.
The
> only headers available at this point are the ones generated by the web

(Continue reading)

Russ Lavoie | 2 May 14:47

Throttling

Is there a way inside modsecurity that can throttle IP addresses.
Meaning, IPs are only allowed 2,000 hits per day and then denied...

I went through the reference manual and saw nothing there regarding
this.

Thanks

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Christian Bockermann | 2 May 15:06

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)

Christian Folini | 2 May 15:28

Picon

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)

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)

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)

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)

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)

Return

Return to gmane.comp.apache.mod-security.user.

Project Web Page

Apache mod-security

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane