headers
Yi Li | 1 Oct 02:46
Picon

Re: GeoIP match rule, problem

thanks.
I may want to allow up to 20 countries finally. using within to block over 140 country code does not sound like a good idea  so i am looking at negate <at> winthin.
any easy way of doing so?



On Wed, Sep 30, 2009 at 6:41 PM, Brian Rectanus <Brian.Rectanus <at> breach.com> wrote:
Yi Li wrote:
hi, wish someone could give me a help here.

I want to write a rule that block http traffic whose source IP is from
any country other than US.

I can list all country code and use a <at> within operator, which actually
works.

but i want to find a better way, so I try to negate <at> within then it fails.

here is what I did:

# Specify GeoIP datafeed
    SecGeoLookupDb /etc/httpd/conf/modsecurity/GeoIP-106_20090512.dat


# GeoIP blocking rule, including complete country codes
  SecRule REMOTE_ADDR <at> geoLookup \
"phase:1,chain,drop,ctl:ruleEngine=DetectionOnly,ctl:auditEngine=On,msg:'banned
country code Geo-IP',logdata:'client ip:
%{REMOTE_ADDR},%{GEO:COUNTRY_CODE}'"

SecRule GEO:COUNTRY_CODE "! <at> within US"

   SecRule REMOTE_ADDR " <at> rx ^10\.128\.80\.10$" \
"phase:1,redirect:http://www.yahoo.com,ctl:ruleEngine=On,ctl:auditEngine=Rele
vantOnly,msg:'banned IP',logdata:'client ip: %{REMOTE_ADDR},%{REMOTE_ADDR}'"


my test case:

  1. connect to the web server from an internal IP 10.128.x.x.
   2. the negate rule never triggers

i checked the GeoIP database, the address '10.128.x.x' does not match
any country IP so the returned geo coutry code should be a blank string,
which should trigger the SecRule GEO:COUNTRY_CODE "! <at> within US".


any thoughts would be appreciated.

another related questions is that whether there is any tool which allows
me to generate http traffics but I can manipulate the source IP of these
http requests.

thanks in advance.


This is actually documented as an example for GEO:

SecRule GEO:COUNTRY_CODE "! <at> streq GB"

Just change that to US?

-B

--
Brian Rectanus
Breach Security

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 0 comments |
headers
Chris Wakelin | 1 Oct 16:20
Picon
Picon

Error while forwarding response data (130)

We've just upgraded our Apache from 2.2.11 prefork to 2.2.14 worker
(2.2.14 is in the process of being formally released - see e.g.
http://marc.info/?t=125374835200001&r=1&w=2) and have started to see odd
messages in the ModSecurity console

Output filter: Error while forwarding response data (130): Software
caused connection abort

These occur sporadically (I haven't been able to reproduce it on our
test box), and probably only for reverse-proxied pages (which most of
ours are). We're using ModSecurity 2.5.9, but I've tried 2.5.10 as well.

Is this something caused by the switch to the worker MPM (which,
incidentally, has halved our memory usage)? Does ModSecurity need to be
re-compiled for worker (I tried with a re-compiled version, but again,
no differences)?

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin <at> reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
Whiteknights, Reading, RG6 2AF, UK              Fax: +44 (0)118 975 3094

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 1 comment |
headers
Gerald Holl | 1 Oct 18:02
Picon
Favicon

SecRequestBodyLimit greater than 1GB

Hello list,

I already found an old thread concerning disabling the limitation of
SecRequestBodyLimit 1GB:
http://article.gmane.org/gmane.comp.apache.mod-security.user/5093

Unfortunately, it does not work for me. Brain wrote in this thread that
a patch which moves the content-length check after phase 1 is to be
contained in V2.5.7. I'm using mod_security 2.5.9. Is the patch already
in this release?
If not, at which place do I have to specify the proposed solution
(SecRule REQUEST_FILENAME "^/workspaces/UploadServlet$" \
         "phase:1,t:none,allow,nolog,ctl:ruleEngine=Off")?

Thanks,
Gerald
--

-- 
http://holl.co.at

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 5 comments |
headers
Brian Rectanus | 1 Oct 18:24

Re: Error while forwarding response data (130)

Chris Wakelin wrote:
> We've just upgraded our Apache from 2.2.11 prefork to 2.2.14 worker
> (2.2.14 is in the process of being formally released - see e.g.
> http://marc.info/?t=125374835200001&r=1&w=2) and have started to see odd
> messages in the ModSecurity console
>
> Output filter: Error while forwarding response data (130): Software
> caused connection abort
>
> These occur sporadically (I haven't been able to reproduce it on our
> test box), and probably only for reverse-proxied pages (which most of
> ours are). We're using ModSecurity 2.5.9, but I've tried 2.5.10 as well.
>
> Is this something caused by the switch to the worker MPM (which,
> incidentally, has halved our memory usage)? Does ModSecurity need to be
> re-compiled for worker (I tried with a re-compiled version, but again,
> no differences)?
>
> Best Wishes,
> Chris
>

These usually happen when a user clicks "stop" on their browser or if 
they double-click a POST button.  I have not seen that exact error 
before, but it may be that ModSecurity is just reporting too many 
details.  ModSecurity just reports back all errors.  There needs to be a 
way to suppress this. See:

https://www.modsecurity.org/tracker/browse/MODSEC-70

-B

--

-- 
Brian Rectanus
Breach Security

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 0 comments |
headers
Brian Rectanus | 1 Oct 19:14

Re: SecRequestBodyLimit greater than 1GB

Gerald Holl wrote:
> Hello list,
>
> I already found an old thread concerning disabling the limitation of
> SecRequestBodyLimit 1GB:
> http://article.gmane.org/gmane.comp.apache.mod-security.user/5093
>
> Unfortunately, it does not work for me. Brain wrote in this thread that
> a patch which moves the content-length check after phase 1 is to be
> contained in V2.5.7. I'm using mod_security 2.5.9. Is the patch already
> in this release?
> If not, at which place do I have to specify the proposed solution
> (SecRule REQUEST_FILENAME "^/workspaces/UploadServlet$" \
>           "phase:1,t:none,allow,nolog,ctl:ruleEngine=Off")?
>
> Thanks,
> Gerald

This is fixed as of 2.5.7.  Use the ctl:requestBodyAccess action in 
phase:1.  This would allow the rules to be processed, just not the 
request body:

SecRule REQUEST_FILENAME "^/workspaces/UploadServlet$" \
           "phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"

-B

--

-- 
Brian Rectanus
Breach Security

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 4 comments |
headers
Yi Li | 2 Oct 00:11
Picon

help with error in geo IP matching rule

hi, I wrote a rule to block traffics from a few countries using maxmind geo ip database and find it seems the rule resolve GeoIP code inproperly on some IP.

will appreciate if someone could help me to find out whether there is anything wrong with the rule I wrote.

thanks.

the rule is here:

SecRule REMOTE_ADDR <at> geoLookup \
  "phase:1,chain,drop,ctl:ruleEngine=On,ctl:auditEngine=RelevantOnly,msg:'banned country code Geo-IP'"
   SecRule GEO:COUNTRY_CODE " <at> within LT,UA,ID,EG,RO,BG,TR,RU,PK,MY,IL,NG,CO,CN"


I found that some IP in United states are being picked up by the rule, even though US is not in the blocking list.

I checked the source IP 64.150.191.227 in maxmind geoip db and verified this resovled as an US IP address.



here is the log entry:

[Sat Sep 05 07:05:37 2009] [error] [client 64.150.191.227] ModSecurity: Warning.
 String match within "LT,UA,ID,EG,RO,BG,TR,RU,PK,MY,IL,NG,CO,CN" at GEO:country_
code. [file "/opt/IBMIHS/conf/modsecurity/modsecurity_crs_15_customrules.conf"]
[line "7"] [msg "banned country code Geo-IP"] [hostname ....

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 0 comments |
headers
Gerald Holl | 2 Oct 08:52
Picon
Favicon

Re: SecRequestBodyLimit greater than 1GB

On 01.10.2009 19:14, Brian Rectanus wrote:
> This is fixed as of 2.5.7. Use the ctl:requestBodyAccess action in
> phase:1. This would allow the rules to be processed, just not the
> request body:
>
> SecRule REQUEST_FILENAME "^/workspaces/UploadServlet$" \
> "phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"

Brian,

I can't get it working. I still get the error: Message: Request body 
(Content-Length) is larger than the configured limit (134217728).

Maybe the location where I put the rule isn't right. In httpd.conf I do 
have following:
<IfModule mod_security2.c>
   SecRule REQUEST_FILENAME "^/my/folder$" 
"phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"
   Include /etc/apache2/modsecurity.conf
</IfModule>

The /etc/apache2/modsecurity.conf file includes all the core rules and 
removes some rules for specific locations.

cheers,
Gerald

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 3 comments |
headers
yersinia | 2 Oct 09:50
Picon

Re: SecRequestBodyLimit greater than 1GB

On Fri, Oct 2, 2009 at 8:52 AM, Gerald Holl <gerald <at> holl.co.at> wrote:
On 01.10.2009 19:14, Brian Rectanus wrote:
> This is fixed as of 2.5.7. Use the ctl:requestBodyAccess action in
> phase:1. This would allow the rules to be processed, just not the
> request body:
>
> SecRule REQUEST_FILENAME "^/workspaces/UploadServlet$" \
> "phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"

Brian,

I can't get it working. I still get the error: Message: Request body
(Content-Length) is larger than the configured limit (134217728).

Maybe the location where I put the rule isn't right. In httpd.conf I do
have following:
<IfModule mod_security2.c>
  SecRule REQUEST_FILENAME "^/my/folder$"
"phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"
  Include /etc/apache2/modsecurity.conf
</IfModule>

The /etc/apache2/modsecurity.conf file includes all the core rules and
removes some rules for specific locations.

Sure that it is a mod_security issue and not an apache issue ?

http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody

To work around the issue create a .htaccess file in the same directory as the page causing the issue. Insert one of the following lines:

LimitRequestBody 0 ## unlimited up to 2GB
LimitRequestBody 2097152 ## 2 MB, decent default for many cases.

and save this file. If you increased the size correctly the page should now be working.

hth

 
cheers,
Gerald

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 1 comment |
headers
Gerald Holl | 2 Oct 10:37
Picon
Favicon

Re: SecRequestBodyLimit greater than 1GB

On 02.10.2009 09:50, yersinia wrote:
> Sure that it is a mod_security issue and not an apache issue ?
>
> http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
>
> To work around the issue create a .htaccess file
> <http://kb.mediatemple.net/article.asp?article=10036&p=3> in the same
> directory as the page causing the issue. Insert one of the following lines:
>
>     LimitRequestBody 0 ## unlimited up to 2GB
>     LimitRequestBody 2097152 ## 2 MB, decent default for many cases.
>
> and save this file. If you increased the size correctly the page should
> now be working.

I already set the LimitRequestBody directive globally to 0 (unlimited). 
So it is a mod_security issue.

cheers,
Gerald

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 0 comments |
headers
Brian Rectanus | 2 Oct 19:22

Re: SecRequestBodyLimit greater than 1GB


Gerald Holl wrote:
> On 01.10.2009 19:14, Brian Rectanus wrote:
>> This is fixed as of 2.5.7. Use the ctl:requestBodyAccess action in
>> phase:1. This would allow the rules to be processed, just not the
>> request body:
>>
>> SecRule REQUEST_FILENAME "^/workspaces/UploadServlet$" \
>> "phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"
>
> Brian,
>
> I can't get it working. I still get the error: Message: Request body
> (Content-Length) is larger than the configured limit (134217728).
>
> Maybe the location where I put the rule isn't right. In httpd.conf I do
> have following:
> <IfModule mod_security2.c>
>     SecRule REQUEST_FILENAME "^/my/folder$"
> "phase:1,t:none,allow,nolog,ctl:requestBodyAccess=Off"
>     Include /etc/apache2/modsecurity.conf
> </IfModule>
>
> The /etc/apache2/modsecurity.conf file includes all the core rules and
> removes some rules for specific locations.

Are you sure that is where everything is pulled in?  Sometimes those 
IfModule blocks will get you.

If /etc/apache2/modsecurity.conf is including the reset of your config , 
then you may need to add the exception in there (or one of its included 
files), or after it (it is phase 1, so it will just be placed last in 
the phase:1 rules, which is fine).

Try this.  Note I changed "allow" to "pass" so the remaining rules would 
run...

   <IfModule mod_security2.c>
     Include /etc/apache2/modsecurity.conf

     # Do not bother looking at the body for these requests
     SecRule REQUEST_FILENAME "^/my/folder$" \
       "phase:1,t:none,pass,nolog,ctl:requestBodyAccess=Off"
   </IfModule>

I did this in my config:

SecRequestBodyLimit 10

And did a post > 10 bytes and got this:

[Fri Oct 02 10:08:35 2009] [error] [client 127.0.1.1] ModSecurity: 
Request body (Content-Length) is larger than the configured limit (10). 
[hostname "red-dwarf"] [uri "/cgi-bin/dump"] [unique_id 
"SsYzk38AAQEAAF <at> qIEIAAAHA"]

Then changed the config to this:

SecRequestBodyLimit 10
SecRule REQUEST_FILENAME "^/cgi-bin/dump$" \
   "phase:1,t:none,pass,nolog,ctl:requestBodyAccess=Off"

Retried the same POST and got no error.

If you are still having issues, then crank the debug log level to at 
least 5 and you should see something like this:

[4] Recipe: Invoking rule f58848; [file 
".../apache/conf/simple-frontend.conf"] [line "979"].
[5] Rule f58848: SecRule "REQUEST_FILENAME" "@rx ^/cgi-bin/dump$" 
"phase:1,auditlog,t:none,pass,nolog,ctl:requestBodyAccess=Off"
[4] Transformation completed in 2 usec.
[4] Executing operator "rx" with param "^/cgi-bin/dump$" against 
REQUEST_FILENAME.
[4] Operator completed in 33 usec.
[4] Ctl: Set requestBodyAccess to 0.
...
[4] Second phase starting (dcfg f59840).
[4] Input filter: Request body access not enabled.
...
[4] Audit log: Ignoring a non-relevant request.

-B

--

-- 
Brian Rectanus
Breach Security

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
Permalink | Reply | 0 comments |

Gmane