mod-security-users — General discussion about mod_security

Re: [mod-security-users] v1.9 memory usage problem

[Justin G. <web...@sw...>]

Is this apache 2 or 1? If it's 1, try using pcre (look in the docs about compiling). This might speed
things a lot.

	Justin


Jim wrote:
> Hi,
> 
>> must be one of the rules I guess. We use 1.9.3 on several servers with way more than 500 rules
>> and don't see it. We're on RHEL 3/4 here.
> 
> That;s the thing, the *exact* same ruleset works perfectly on v1.8 but
> not on v1.9.  Is there any specific changes made to the software
> between these versions with regard to how 'SecFilterScanPOST' is
> handled which could cause this?
> 
> Jim
> 
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

Re: [mod-security-users] v1.9 memory usage problem

[Jim <st...@cl...>]

Hi,

> must be one of the rules I guess. We use 1.9.3 on several servers with way more than 500 rules
> and don't see it. We're on RHEL 3/4 here.

That;s the thing, the *exact* same ruleset works perfectly on v1.8 but
not on v1.9.  Is there any specific changes made to the software
between these versions with regard to how 'SecFilterScanPOST' is
handled which could cause this?

Jim

Re: [mod-security-users] v1.9 memory usage problem

[Justin G. <web...@sw...>]

must be one of the rules I guess. We use 1.9.3 on several servers with way more than 500 rules
and don't see it. We're on RHEL 3/4 here.

	Justin


Jim wrote:
> Hi all,
> 
> First time post here and newsgroup newbie in general so I hope I do this correctly :)
> 
> -----
> 
> Distro: CentOS 3.6 (cPanel control panel installed)
> RAM: 2 GB
> Swap: 4 GB
> 
> -----
> 
> root@xxxx [/usr/src]# uname -a
> Linux xxxx.xxxx.xxxx 2.4.21-40.ELsmp #1 SMP Wed Mar 15 14:21:45 EST 2006 i686 i686 i386 GNU/Linux
> 
> -----
> 
> Apache (v1.3.34) loaded modules:
> 
> Compiled-in modules:
>   http_core.c
>   mod_env.c
>   mod_log_config.c
>   mod_mime.c
>   mod_negotiation.c
>   mod_status.c
>   mod_include.c
>   mod_autoindex.c
>   mod_dir.c
>   mod_cgi.c
>   mod_asis.c
>   mod_imap.c
>   mod_actions.c
>   mod_userdir.c
>   mod_alias.c
>   mod_access.c
>   mod_auth.c
>   mod_so.c
>   mod_setenvif.c
>   mod_ssl.c
>   mod_frontpage.c
> suexec: enabled; valid wrapper /usr/local/apache/bin/suexec
> 
> -----
> 
> PHP (v4.4.2) compile line:
> 
> './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt' '--with-ming=../ming-0.2a' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--with-xmlrpc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot' '--with-sablot-js=/usr'
> 
> -----
> 
> 
> The issue I am posting about has previously been discussed here: http://www.gotroot.com/tiki-view_forum_thread.php?forumId=35&comments_threshold=0&comments_parentId=658&comments_offset=0&comments_maxComments=20&comments_style=commentStyle_threaded
> 
> The problem we (and others from the look of that thread) have seen is that mod_security is causing used RAM to go extremely high resulting in swapping.
> 
> We first saw this when upgrading from mod_security v1.8.7 to version 1.9.1.  After being unable to find the cause, we rolled back to 1.8 and all has been fine.  Recently, the upgrade has been tried again (this time to v1.9.3) with exactly the same problem.
> 
> This only happens on 2 of our servers out of about 45-50 which is very strange.  When Apache is started things are fine with each httpd process showing around 20-30 MB usage in 'top'.  Within approx 15 minutes, one httpd process (a parent) can then be seen to be using 1.0-1.1 GB of RAM in 'top'.  Soon after, things go downhill.
> 
> I have been using trial and error to try and find the cause of this but it's definitely related to mod_security.  When no rules are in use (but module still loaded in httpd.conf) there is no problem.  In fact, I have narrowed it down to the 'SecFilterScanPOST' setting - when this is enabled the problem occurs, when disabled/Off there is no problem.
> 
> Our ruleset is a custom ruleset comprising of around 500-600 rules.  We are continuing to troubleshoot this to see if we can find common factors between the very few servers affected.
> 
> This post is mainly to see if anyone has experienced similar problems with the 1.9 branch of mod_security?  Maybe the data in this post will be of use to anyone troubleshooting the same issue.
> 
> If any additional info is needed (or suggestions to try and post back), feel free to ask.
> 
> Thanks,
> 
> Jim
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

[mod-security-users] v1.9 memory usage problem

[Jim <st...@cl...>]

Hi all,

First time post here and newsgroup newbie in general so I hope I do this correctly :)

-----

Distro: CentOS 3.6 (cPanel control panel installed)
RAM: 2 GB
Swap: 4 GB

-----

root@xxxx [/usr/src]# uname -a
Linux xxxx.xxxx.xxxx 2.4.21-40.ELsmp #1 SMP Wed Mar 15 14:21:45 EST 2006 i686 i686 i386 GNU/Linux

-----

Apache (v1.3.34) loaded modules:

Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_so.c
  mod_setenvif.c
  mod_ssl.c
  mod_frontpage.c
suexec: enabled; valid wrapper /usr/local/apache/bin/suexec

-----

PHP (v4.4.2) compile line:

'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt' '--with-ming=../ming-0.2a' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--with-xmlrpc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot' '--with-sablot-js=/usr'

-----


The issue I am posting about has previously been discussed here: http://www.gotroot.com/tiki-view_forum_thread.php?forumId=35&comments_threshold=0&comments_parentId=658&comments_offset=0&comments_maxComments=20&comments_style=commentStyle_threaded

The problem we (and others from the look of that thread) have seen is that mod_security is causing used RAM to go extremely high resulting in swapping.

We first saw this when upgrading from mod_security v1.8.7 to version 1.9.1.  After being unable to find the cause, we rolled back to 1.8 and all has been fine.  Recently, the upgrade has been tried again (this time to v1.9.3) with exactly the same problem.

This only happens on 2 of our servers out of about 45-50 which is very strange.  When Apache is started things are fine with each httpd process showing around 20-30 MB usage in 'top'.  Within approx 15 minutes, one httpd process (a parent) can then be seen to be using 1.0-1.1 GB of RAM in 'top'.  Soon after, things go downhill.

I have been using trial and error to try and find the cause of this but it's definitely related to mod_security.  When no rules are in use (but module still loaded in httpd.conf) there is no problem.  In fact, I have narrowed it down to the 'SecFilterScanPOST' setting - when this is enabled the problem occurs, when disabled/Off there is no problem.

Our ruleset is a custom ruleset comprising of around 500-600 rules.  We are continuing to troubleshoot this to see if we can find common factors between the very few servers affected.

This post is mainly to see if anyone has experienced similar problems with the 1.9 branch of mod_security?  Maybe the data in this post will be of use to anyone troubleshooting the same issue.

If any additional info is needed (or suggestions to try and post back), feel free to ask.

Thanks,

Jim

[mod-security-users] filtering based on an command result

[Jason E. <jed...@ca...>]

I'm looking at using an external tool like crm114 to filter post 
requests for comment and trackback spam.

I'm using apache as my web server.

Is there a way with mod_security or something else to block a request 
and do something based on the result of the external command (return 403 
or set a header)?


I could try to incorporate this into the weblog software, but the server 
level solution would share info across app installs and other apps.

Thanks,
Jason Edgecombe

Re: [mod-security-users] request body: Multipart: invalid boundary encountered

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

On 4/22/06, peter pilsl <pi...@go...> wrote:
>
> Is there a rule where I can disable this check for mod-security?  Or a
> small source-hack that allows further examination of the problem?

No, to both. But you can try to disable request body buffering using
something like (untested):

SetEnvIfNoCase User-Agent "Mac_PowerPC" \
"MODSEC_NOPOSTBUFFERING=3DSkip request body processing for buggy clients"

It's not a trivial issue - multipart parsing is a very sensitive area.
That's why I have hesitated to allow for invalid implementations (even
with a switch). The consequences of such actions are often difficult
to foresee.


> I dont think that mod_security is completely incompatible with MSIE 5.x
> on Apple when it comes to multipart-encoding !?

Could be. I don't have access to check for myself.

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

Re: [mod-security-users] request body: Multipart: invalid boundary encountered

[Thomas A. <tan...@oa...>]

It sounds unreasonable to me to expect mod_security (whether officially
or hacked) to modify standards-compatible behavior in order to account
for a 5-year out of date browser outputting incorrect information.  I do
not support anything less than MSIE 5.5 on any of my websites because
they do not comply with standards in regards to JavaScript, HTML, etc.,
and cannot be easily accomodated with graceful failures.  If this is
only occurring with one customer, why don't you recommend an upgrade to
at least MSIE 5.5 if not something more recent.  They will also be less
prone to security problems and other incompatabilities for their
trouble.  I doubt even Microsoft supports that version anymore.  The
browsers continue to be free of charge, so I don't see any downside.

Tom


On Sat, 2006-04-22 at 20:41 +0200, peter pilsl wrote:
> Ivan Ristic wrote:
> > 
> > The quickest solution for you is to change the encoding used to submit
> > the form.
>  >
> 
> thnx a lot for your answer. I would prefer a different solution, cause 
> some applications require  file-upload and the problem will pop up there 
> again. Unfortunately one of our partners is based on old macs, so I cant 
> avoid/ignore the problem.
> 
> 
> > 
> > The message you get means ModSecurity believes the request body is
> > invalid. Seing the User-Agent (Mozilla/4.0 (compatible; MSIE 5.0;
> > Mac_PowerPC) I would say this is probably true. ModSecurity 1.9.x does
> > not keep invalid request bodies around so I can't be completely sure,
> > I am guessing the browser is terminating lines with \n where the
> > specifications requires for \r\n.
> >
> 
> 
> Based on my logs the Problem occurs with **some** MSIE 5.0 and MSIE 5.23 
> on Power_mac. I've also entries from MSIE 5.23 on Power_Mac where the 
> problem did not occur when submitting the form.
> 
> Is there a rule where I can disable this check for mod-security?  Or a 
> small source-hack that allows further examination of the problem?
> 
> I dont think that mod_security is completely incompatible with MSIE 5.x 
> on Apple when it comes to multipart-encoding !?
> 
> 
> thnx,
> peter
> 
> > --
> > Ivan Ristic, Technical Director
> > Thinking Stone, http://www.thinkingstone.com
> > ModSecurity: Open source Web Application Firewall
> > 
> 
> 

Re: [mod-security-users] request body: Multipart: invalid boundary encountered

[peter p. <pi...@go...>]

Ivan Ristic wrote:
> 
> The quickest solution for you is to change the encoding used to submit
> the form.
 >

thnx a lot for your answer. I would prefer a different solution, cause 
some applications require  file-upload and the problem will pop up there 
again. Unfortunately one of our partners is based on old macs, so I cant 
avoid/ignore the problem.


> 
> The message you get means ModSecurity believes the request body is
> invalid. Seing the User-Agent (Mozilla/4.0 (compatible; MSIE 5.0;
> Mac_PowerPC) I would say this is probably true. ModSecurity 1.9.x does
> not keep invalid request bodies around so I can't be completely sure,
> I am guessing the browser is terminating lines with \n where the
> specifications requires for \r\n.
>


Based on my logs the Problem occurs with **some** MSIE 5.0 and MSIE 5.23 
on Power_mac. I've also entries from MSIE 5.23 on Power_Mac where the 
problem did not occur when submitting the form.

Is there a rule where I can disable this check for mod-security?  Or a 
small source-hack that allows further examination of the problem?

I dont think that mod_security is completely incompatible with MSIE 5.x 
on Apple when it comes to multipart-encoding !?


thnx,
peter

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


-- 
mag. peter pilsl
goldfisch.at
IT- & dataconsulting
tel: +43 650 3574035
tel: +43 1 8900602
fax: +43 1 8900602 15
pi...@go...

Re: [mod-security-users] request body: Multipart: invalid boundary encountered

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

On 4/22/06, peter pilsl <pi...@go...> wrote:
>
> I simply cant figure out whats going on.  A single user cannot access a
> certain webpage on my server (403 by mod_security).  All other users
> (including myself) dont have any problems doing so.  The "bad user" can
> surf the whole page, but as soon as he submits a searchterm he gets a
> 403.

The quickest solution for you is to change the encoding used to submit
the form. You are using multipart/form-data but this type of encoding
is only needed for file uploads. Since you don't need to upload files
you can simply remove the encoding information (from the form, the
enctype=3D"..." bit) altogether. The form will then default to
application/x-www-form-urlencoded and the error will not occur. Read
on for the explanation of the error.


> I dont have any clue how to solve this issue and I dont have any clue
> what the 'Extension: Security/Remote-Passphrase' - means. I found it a
> few times at google but it seems not related with mod_security but maybe
> with my problem?

Probably not.


> thnx for any hints, ideas and solutions ..

The message you get means ModSecurity believes the request body is
invalid. Seing the User-Agent (Mozilla/4.0 (compatible; MSIE 5.0;
Mac_PowerPC) I would say this is probably true. ModSecurity 1.9.x does
not keep invalid request bodies around so I can't be completely sure,
I am guessing the browser is terminating lines with \n where the
specifications requires for \r\n.

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

[mod-security-users] request body: Multipart: invalid boundary encountered

[peter p. <pi...@go...>]

I simply cant figure out whats going on.  A single user cannot access a 
certain webpage on my server (403 by mod_security).  All other users 
(including myself) dont have any problems doing so.  The "bad user" can 
surf the whole page, but as soon as he submits a searchterm he gets a 
403.  He has no problems with submitting terms at other forms or search 
at google ;)

I couldnt find any rule in the rule-set that correspond with the terms 
in audit-log. I googled unsuccessful for a similar problem.

I dont have any clue how to solve this issue and I dont have any clue 
what the 'Extension: Security/Remote-Passphrase' - means. I found it a 
few times at google but it seems not related with mod_security but maybe 
with my problem?

thnx for any hints, ideas and solutions ..

thnx
peter



==ddfbd861==============================
Request: www.adulteducation.at 80.121.27.113 - - [18/Apr/2006:10:29:05 
+0200] "POST /de/struktur/suchergebnis//sd/1/ HTTP/1.1" 403 304 
"http://www.adultedu
cation.at/de/struktur/" "Mozilla/4.0 (compatible; MSIE 5.0; 
Mac_PowerPC)" VQ8V8D5jlYoAAFjp7WQAAAAF "-"
Handler: perl-script
----------------------------------------
POST /de/struktur/suchergebnis//sd/1/ HTTP/1.1
Host: www.adulteducation.at
Accept: */*
Accept-Language: de
Connection: Keep-Alive
Referer: http://www.adulteducation.at/de/struktur/
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
UA-OS: MacOS
UA-CPU: PPC
Cookie: __utma=160909933.2016430368.1134477507.1144766388.1145348530.13; 
__utmz=160909933.1145348530.13.7.utmccn=(referral)|utmcsr=vhs.or.at|utmcct=/96/|ut
mcmd=referral; __utmb=160909933; __utmc=160909933
Content-type: multipart/form-data; 
boundary=---------------------------168071508944249
Extension: Security/Remote-Passphrase
Content-length: 597
mod_security-message: Access denied with code 403. Error processing 
request body: Multipart: invalid boundary encountered: 
-----------------------------168
071508944249\n [severity "EMERGENCY"]
mod_security-action: 403

28
[POST payload not available]

HTTP/1.1 403 Forbidden
Content-Length: 304
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--ddfbd861--

Re: [mod-security-users] Include rules file per Directory

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

On 4/19/06, Michael Shinn <mi...@go...> wrote:
> On Wed, 2006-04-19 at 21:45 +0100, Ivan Ristic wrote:
> > >
> > > Yep.  Will I be able to extract multiple URIs from a POST?
> >
> > If not in 2.0 then in 2.1 for sure (I have a very tight deadline for
> > 2.0). Were you thinking of having ModSecurity extract the URIs from
> > the request parameters?
>
> That would be ideal.  Did you have another thought about a better way to
> do this?

No (but it's not like I've spent a lot of time thinking about it :).
That and the check of the referrer URI should do it.

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

Re: [mod-security-users] Include rules file per Directory

[Michael S. <mi...@go...>]

On Wed, 2006-04-19 at 21:45 +0100, Ivan Ristic wrote:
> >
> > Yep.  Will I be able to extract multiple URIs from a POST?
> 
> If not in 2.0 then in 2.1 for sure (I have a very tight deadline for
> 2.0). Were you thinking of having ModSecurity extract the URIs from
> the request parameters?

That would be ideal.  Did you have another thought about a better way to
do this?

-- 
Michael T. Shinn                                    KeyID:0xDAE2EC86
Key Fingerprint:  1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86
  
Got Root?  http://www.gotroot.com
modsecurity rules: http://www.modsecurityrules.com
Troubleshooting Firewalls:  http://troubleshootingfirewalls.com

Re: [mod-security-users] Include rules file per Directory

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

On 4/19/06, Michael Shinn <mi...@go...> wrote:
> On Wed, 2006-04-19 at 20:56 +0100, Ivan Ristic wrote:
> > On 4/19/06, Michael Shinn <mi...@go...> wrote:
> > > On Wed, 2006-04-19 at 10:42 +0100, Ivan Ristic wrote:
> > > > On 4/17/06, Justin Grindea <web...@sw...> wrote:
> > > > > hi,
> > > > >
> > > > > I'm looking into using gotroot's blacklist.conf but would like to=
 restrict
> > > > > processing rules in this file only to specific scripts that need =
it, not load
> > > > > it like any other rules file, since the load goes very high on a =
busy server.
> > > >
> > > > You can do that, simply do something like:
> > > >
> > > > <Location /xyz>
> > > > Include conf/blacklist.conf
> > > > </Location>
> > > >
> > > > But using blacklist.conf is not a good idea (that's the one with ma=
ny
> > > > IP addresses in it?)
> > >
> > > blacklist.conf has all the spammer URLs in it.
> >
> > The next dev. release of ModSecurity will have the SURBL support. You
> > should be able to use that to replace blacklist.conf, right (i.e. just
> > do a single DNS lookup to verify a URI instead)?
>
> Yep.  Will I be able to extract multiple URIs from a POST?

If not in 2.0 then in 2.1 for sure (I have a very tight deadline for
2.0). Were you thinking of having ModSecurity extract the URIs from
the request parameters?

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

Re: [mod-security-users] Include rules file per Directory

[Michael S. <mi...@go...>]

On Wed, 2006-04-19 at 20:56 +0100, Ivan Ristic wrote:
> On 4/19/06, Michael Shinn <mi...@go...> wrote:
> > On Wed, 2006-04-19 at 10:42 +0100, Ivan Ristic wrote:
> > > On 4/17/06, Justin Grindea <web...@sw...> wrote:
> > > > hi,
> > > >
> > > > I'm looking into using gotroot's blacklist.conf but would like to restrict
> > > > processing rules in this file only to specific scripts that need it, not load
> > > > it like any other rules file, since the load goes very high on a busy server.
> > >
> > > You can do that, simply do something like:
> > >
> > > <Location /xyz>
> > > Include conf/blacklist.conf
> > > </Location>
> > >
> > > But using blacklist.conf is not a good idea (that's the one with many
> > > IP addresses in it?)
> >
> > blacklist.conf has all the spammer URLs in it.
> 
> The next dev. release of ModSecurity will have the SURBL support. You
> should be able to use that to replace blacklist.conf, right (i.e. just
> do a single DNS lookup to verify a URI instead)?

Yep.  Will I be able to extract multiple URIs from a POST?

As an aside, that zone is going to grow fast soon.   I'm already at over
10K unique SLDs used by spammers in test ruleset, the production ruleset
is well over 7K at last count, and thats all manually added by me.  So
getting rid of that ruleset will help with any performance issues.

Once I put bring autofeeder out of testing the number of new URIs will
probably grow by a 100-1000 a day.  So lookups will be the only way to
support that in the future, and I may have the autofeeder online this
month.  :-)

Trying to keep up with the spammers manually is just not practical
anymore for me, so its time to put those sneaky honeypots to work
automatically feeding the SURBLs.  Ah... robots fighting robots.  Now
all we need is a cool Anime theme song to go with it.

-- 
Michael T. Shinn                                    KeyID:0xDAE2EC86
Key Fingerprint:  1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86
  
Got Root?  http://www.gotroot.com
modsecurity rules: http://www.modsecurityrules.com
Troubleshooting Firewalls:  http://troubleshootingfirewalls.com

[mod-security-users] Re: Using Dshield Data to Block Well-Known Web Attackers

[Ryan B. <rcb...@gm...>]

Oops, I had to update the subject line - it is attackers and not attacks.

-Ryan

On 4/19/06, Ryan Barnett <rcb...@gm...> wrote:
>
>  For those of you who are interested in creating ACLs (with Apache or
> Mod_Security) to block access from well-known web attackers,  I thought I
> would present this small section of info from my book - Preventing Web
> Attacks with Apache (
> http://www.amazon.com/gp/product/0321321286/ref=3Dsr_11_1/104-3385017-897=
3538?%5Fencoding=3DUTF8
> )
>
> This is a complimentry method to those presented by the GotRoot blacklist
> data.  The data below shows how to use the Apache Deny directive, however
> similar Mod_Security rules could be created to block access from these
> hosts.
>
> I hope this is useful.
>
> *Blocking Well-Known Offenders*
>
> Utilization of IP based block lists has been common place for years in
> combating email abusers. There are many community project sites that make
> block lists available to the public so that they can download it and then
> implement access control lists to deny access attempts from these IP
> addresses/network blocks to their SMTP servers. The use of the data in th=
ese
> lists effective, however they need to be constantly updated as the SPAMME=
RS
> leverage new IP addresses.
>
>
>
> The Dshield.org <http://dshield.org/> web site ( www.dshield.org ) tracks
> Internet traffic and calls itself a distributed intrusion detection syste=
m.
> Dshield gathers its information by allowing anyone to submit their firewa=
ll
> and intrusion detection logs. There are client programs for the various
> security applications that will convert the logs into the correct Dshield
> format and forward them onto the web site. One of the resources available
> from Dshield is their own block list of the top twenty network blocks tha=
t
> have exhibited suspicious scanning activity -
> http://feeds.dshield.org/block.txt. While this data does illustrate the
> fact that these network blocks are conduction suspicious network
> connections, it does not provided the type of fidelity required to
> accurately categorize their activities. Are they SPAMMERS or Brute Forcin=
g
> password protected sites? We just don't know.
>
>
>
> It was this issue that prompted me to contact Johannes Ullrich of Dshield
> and the SANS Internet Storm Center. I asked him if it would be possible t=
o
> generate a list of only HTTP/Port 80 attackers. At first, he was a bit
> skeptical of the true value of this information as web attackers are
> constantly changing their IP addresses as they compromise more systems or
> loop through proxies. I agreed that any sort of port 80 block list would
> have to be dynamic and the hosts identified would only be valid for a sho=
rt
> period of time, however I still believed there was value in this list. I
> expres sed to Johannes that I was looking for a list of web attackers tha=
t
> I could import daily into my Apache server and then create deny rules for
> these hosts. The real value of using the Dshield information is that they
> have a much larger view of the Internet than most other individual
> organizations would have. A Dshield block list would be ba sed on
> information gathered from across the globe. Think of it as a cyber-ba sed=
community watch program.
>
>
>
> It wasn't until I gave this analogy to Johannes that he finally agreed
> with me on this concept. I said to imagine that you were in charge of
> security at a bank. You had the option of posting up the FBI's Top Ten Mo=
st
> Wanted Criminal posters or the FBI's Top Ten Most Wanted Bank Robbers. Wh=
ich
> one would you choose? Most people would choose the later as the bank robb=
ers
> present the greater threat to the bank. With regards to web security, a
> block list of port 80 attackers would be more relevant than a block list =
of
> generic Internet hooligans. After this exchange, Johannes went ahead and
> created a PHP web page that would extract out the information I desired.
> Here is the URL - www.dshield.org/topportsource.php?port=3D80&num=3D20. Y=
ou
> can change the port number if you are interested in services other the ht=
tp
> and you can also change the number of records returned. In the link above=
, I
> am querying for the top twenty port 80 attackers. Here is an example repo=
rt
> returned by the link.
>
>
>
> # Port 80 top 20 records ordered by number of targets hit.
>
> #
>
> # compiled Fri, 20 May 2005 03:02:51 +0000
>
> #
>
> # columns:
>
> # Source IP <tab> Targets Hit <tab> Total Records
>
> #
>
> # enjoy.
>
> 218.083.155.079     71199     193929
>
> 206.123.216.023     65011     118102
>
> 148.245.122.012     64071     116805
>
> 064.080.123.138     7724     8262
>
> 064.080.123.122     4897     5102
>
> 061.222.211.118     3370     3370
>
> 219.140.162.215     2192     2192
>
> 221.230.192.152     1341     1729
>
> 084.244.002.104     1331     1331
>
> 062.002.157.178     759     5575
>
> 213.202.216.156     757     807
>
> 219.159.102.184     612     627
>
> 207.044.142.115     586     808
>
> 063.151.041.210     546     902
>
> 066.193.175.084     531     1554
>
> 065.078.035.101     508     1014
>
> 193.146.045.103     436     870
>
> 221.201.184.165     421     421
>
> 216.167.232.087     408     1222
>
> 217.160.188.180     314      530
>
>
>
> We are interested in the first column as that lists the specific client I=
P
> address of the web attacker. I created a quick shell script that will
> automatically download an updated list daily using wget and then converts
> that data into the appropriate Apache deny directive format. Here is an
> example of manually running the script called dshield_blocklist.sh.
>
>
>
> *# cat dshield_blocklist.sh *
>
> #!/bin/sh
>
>
>
> /usr/bin/wget "http://www.dshield.org/topportsource.php?port=3D80&num=3D2=
0 "
>
>
>
> for f in `cat topport* | grep -v "#" | awk '{print $1}' | head -20 | sed
> -e 's/^0//g' -e 's/\.0/\./g' =96e 's/\.0/\./g'` ; do echo "Deny from $f" =
>
> /usr/local/apache/conf/blocklist.txt ; done
>
>
>
> exit
>
> *# ./dshield_blocklist.sh*
>
> *# cat /usr/local/apache/conf/blocklist.txt*
>
> Deny from 218.83.155.79
>
> Deny from 206.123.216.23
>
> Deny from 148.245.122.12
>
> Deny from 64.80.123.138
>
> Deny from 64.80.123.122
>
> Deny from 61.222.211.118
>
> Deny from 219.140.162.215
>
> Deny from 221.230.192.152
>
> Deny from 84.244.02.104
>
> Deny from 62.2.157.178
>
> Deny from 213.202.216.156
>
> Deny from 219.159.102.184
>
> Deny from 207.44.142.115
>
> Deny from 63.151.41.210
>
> Deny from 66.193.175.84
>
> Deny from 65.78.35.101
>
> Deny from 193.146.45.103
>
> Deny from 221.201.184.165
>
> Deny from 216.167.232.87
>
> Deny from 217.160.188.180
>
>
>
> The script places the converted data into a file called blocklist.txt in
> the Apache conf directory. I then reference this file with an include
> statement in my DocumentRoot directory directive like this =96
>
>
>
> <Directory "/usr/local/apache/htdocs">
>
>     Options -Indexes -Includes -FollowSymLinks -Multiviews
>
>     AllowOverride None
>
>     Order deny,allow
>
>     Allow from all
>
>     *include conf/blocklist.txt*
>
>
>
> <LimitExcept GET POST>
>
> Order allow,deny
>
> Deny from all
>
> </LimitExcept>
>
> </Directory>
>
>
>
> This blocklist is reactivated every night at midnight when I conduct my
> normal log rotation and restart Apache. This technique proves extremely e=
asy
> to implement and does provide protection from web clients who are up to n=
o
> good.
>
> --
> Ryan C. Barnett
> Web Application Security Consortium (WASC) Member
> CIS Apache Benchmark Project Lead
> SANS Instructor: Securing Apache
> GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> Author: Preventing Web Attacks with Apache
>



--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

[mod-security-users] Using Dshield Data to Block Well-Known Web Attacks

[Ryan B. <rcb...@gm...>]

For those of you who are interested in creating ACLs (with Apache or
Mod_Security) to block access from well-known web attackers,  I thought I
would present this small section of info from my book - Preventing Web
Attacks with Apache (
http://www.amazon.com/gp/product/0321321286/ref=3Dsr_11_1/104-3385017-89735=
38?%5Fencoding=3DUTF8
)

This is a complimentry method to those presented by the GotRoot blacklist
data.  The data below shows how to use the Apache Deny directive, however
similar Mod_Security rules could be created to block access from these
hosts.

I hope this is useful.

*Blocking Well-Known Offenders*

Utilization of IP based block lists has been common place for years in
combating email abusers. There are many community project sites that make
block lists available to the public so that they can download it and then
implement access control lists to deny access attempts from these IP
addresses/network blocks to their SMTP servers. The use of the data in thes=
e
lists effective, however they need to be constantly updated as the SPAMMERS
leverage new IP addresses.



The Dshield.org <http://dshield.org/> web site (www.dshield.org ) tracks
Internet traffic and calls itself a distributed intrusion detection system.
Dshield gathers its information by allowing anyone to submit their firewall
and intrusion detection logs. There are client programs for the various
security applications that will convert the logs into the correct Dshield
format and forward them onto the web site. One of the resources available
from Dshield is their own block list of the top twenty network blocks that
have exhibited suspicious scanning activity -
http://feeds.dshield.org/block.txt. While this data does illustrate the fac=
t
that these network blocks are conduction suspicious network connections, it
does not provided the type of fidelity required to accurately categorize
their activities. Are they SPAMMERS or Brute Forcing password protected
sites? We just don't know.



It was this issue that prompted me to contact Johannes Ullrich of Dshield
and the SANS Internet Storm Center. I asked him if it would be possible to
generate a list of only HTTP/Port 80 attackers. At first, he was a bit
skeptical of the true value of this information as web attackers are
constantly changing their IP addresses as they compromise more systems or
loop through proxies. I agreed that any sort of port 80 block list would
have to be dynamic and the hosts identified would only be valid for a short
period of time, however I still believed there was value in this list. I
expres sed to Johannes that I was looking for a list of web attackers that =
I
could import daily into my Apache server and then create deny rules for
these hosts. The real value of using the Dshield information is that they
have a much larger view of the Internet than most other individual
organizations would have. A Dshield block list would be ba sed on
information gathered from across the globe. Think of it as a cyber-ba
sedcommunity watch program.



It wasn't until I gave this analogy to Johannes that he finally agreed with
me on this concept. I said to imagine that you were in charge of security a=
t
a bank. You had the option of posting up the FBI's Top Ten Most Wanted
Criminal posters or the FBI's Top Ten Most Wanted Bank Robbers. Which one
would you choose? Most people would choose the later as the bank robbers
present the greater threat to the bank. With regards to web security, a
block list of port 80 attackers would be more relevant than a block list of
generic Internet hooligans. After this exchange, Johannes went ahead and
created a PHP web page that would extract out the information I desired.
Here is the URL - www.dshield.org/topportsource.php?port=3D80&num=3D20. You=
 can
change the port number if you are interested in services other the http and
you can also change the number of records returned. In the link above, I am
querying for the top twenty port 80 attackers. Here is an example report
returned by the link.



# Port 80 top 20 records ordered by number of targets hit.

#

# compiled Fri, 20 May 2005 03:02:51 +0000

#

# columns:

# Source IP <tab> Targets Hit <tab> Total Records

#

# enjoy.

218.083.155.079     71199     193929

206.123.216.023     65011     118102

148.245.122.012     64071     116805

064.080.123.138     7724     8262

064.080.123.122     4897     5102

061.222.211.118     3370     3370

219.140.162.215     2192     2192

221.230.192.152     1341     1729

084.244.002.104     1331     1331

062.002.157.178     759     5575

213.202.216.156     757     807

219.159.102.184     612     627

207.044.142.115     586     808

063.151.041.210     546     902

066.193.175.084     531     1554

065.078.035.101     508     1014

193.146.045.103     436     870

221.201.184.165     421     421

216.167.232.087     408     1222

217.160.188.180     314     530



We are interested in the first column as that lists the specific client IP
address of the web attacker. I created a quick shell script that will
automatically download an updated list daily using wget and then converts
that data into the appropriate Apache deny directive format. Here is an
example of manually running the script called dshield_blocklist.sh.



*# cat dshield_blocklist.sh *

#!/bin/sh



/usr/bin/wget "http://www.dshield.org/topportsource.php?port=3D80&num=3D20"



for f in `cat topport* | grep -v "#" | awk '{print $1}' | head -20 | sed -e
's/^0//g' -e 's/\.0/\./g' =96e 's/\.0/\./g'` ; do echo "Deny from $f" >
/usr/local/apache/conf/blocklist.txt ; done



exit

*# ./dshield_blocklist.sh*

*# cat /usr/local/apache/conf/blocklist.txt*

Deny from 218.83.155.79

Deny from 206.123.216.23

Deny from 148.245.122.12

Deny from 64.80.123.138

Deny from 64.80.123.122

Deny from 61.222.211.118

Deny from 219.140.162.215

Deny from 221.230.192.152

Deny from 84.244.02.104

Deny from 62.2.157.178

Deny from 213.202.216.156

Deny from 219.159.102.184

Deny from 207.44.142.115

Deny from 63.151.41.210

Deny from 66.193.175.84

Deny from 65.78.35.101

Deny from 193.146.45.103

Deny from 221.201.184.165

Deny from 216.167.232.87

Deny from 217.160.188.180



The script places the converted data into a file called blocklist.txt in th=
e
Apache conf directory. I then reference this file with an include statement
in my DocumentRoot directory directive like this =96



<Directory "/usr/local/apache/htdocs">

    Options -Indexes -Includes -FollowSymLinks -Multiviews

    AllowOverride None

    Order deny,allow

    Allow from all

    *include conf/blocklist.txt*



<LimitExcept GET POST>

Order allow,deny

Deny from all

</LimitExcept>

</Directory>



This blocklist is reactivated every night at midnight when I conduct my
normal log rotation and restart Apache. This technique proves extremely eas=
y
to implement and does provide protection from web clients who are up to no
good.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

Re: [mod-security-users] Include rules file per Directory

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

On 4/19/06, Michael Shinn <mi...@go...> wrote:
> On Wed, 2006-04-19 at 10:42 +0100, Ivan Ristic wrote:
> > On 4/17/06, Justin Grindea <web...@sw...> wrote:
> > > hi,
> > >
> > > I'm looking into using gotroot's blacklist.conf but would like to res=
trict
> > > processing rules in this file only to specific scripts that need it, =
not load
> > > it like any other rules file, since the load goes very high on a busy=
 server.
> >
> > You can do that, simply do something like:
> >
> > <Location /xyz>
> > Include conf/blacklist.conf
> > </Location>
> >
> > But using blacklist.conf is not a good idea (that's the one with many
> > IP addresses in it?)
>
> blacklist.conf has all the spammer URLs in it.

The next dev. release of ModSecurity will have the SURBL support. You
should be able to use that to replace blacklist.conf, right (i.e. just
do a single DNS lookup to verify a URI instead)?

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

Re: [mod-security-users] Include rules file per Directory

[Michael S. <mi...@go...>]

On Wed, 2006-04-19 at 10:42 +0100, Ivan Ristic wrote:
> On 4/17/06, Justin Grindea <web...@sw...> wrote:
> > hi,
> >
> > I'm looking into using gotroot's blacklist.conf but would like to restrict
> > processing rules in this file only to specific scripts that need it, not load
> > it like any other rules file, since the load goes very high on a busy server.
> 
> You can do that, simply do something like:
> 
> <Location /xyz>
> Include conf/blacklist.conf
> </Location>
> 
> But using blacklist.conf is not a good idea (that's the one with many
> IP addresses in it?) 

blacklist.conf has all the spammer URLs in it.

> because ModSecurity needs to test for each IP
> address individially (and that's slow when you have thousands of IP
> addresses to check). From what I've heard Mike (GotRoot) will be
> maintaining a proper RBL to replace blacklist.conf (and ModSecurity
> 2.x already supports RBLs). The combination will be an order of
> magnitude faster.

Yep.  badips.conf has the IPs, and is no longer maintained as its now in
RBL form.  I just haven't published the root zone yet for outside
use.  :-)

I'll try to get it published this week.

> 
> --
> Ivan Ristic, Technical Director
> Thinking Stone, http://www.thinkingstone.com
> ModSecurity: Open source Web Application Firewall
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
-- 
Michael T. Shinn                                    KeyID:0xDAE2EC86
Key Fingerprint:  1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86
  
Got Root?  http://www.gotroot.com
modsecurity rules: http://www.modsecurityrules.com
Troubleshooting Firewalls:  http://troubleshootingfirewalls.com

Re: [mod-security-users] Include rules file per Directory

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

On 4/17/06, Justin Grindea <web...@sw...> wrote:
> hi,
>
> I'm looking into using gotroot's blacklist.conf but would like to restric=
t
> processing rules in this file only to specific scripts that need it, not =
load
> it like any other rules file, since the load goes very high on a busy ser=
ver.

You can do that, simply do something like:

<Location /xyz>
Include conf/blacklist.conf
</Location>

But using blacklist.conf is not a good idea (that's the one with many
IP addresses in it?) because ModSecurity needs to test for each IP
address individially (and that's slow when you have thousands of IP
addresses to check). From what I've heard Mike (GotRoot) will be
maintaining a proper RBL to replace blacklist.conf (and ModSecurity
2.x already supports RBLs). The combination will be an order of
magnitude faster.

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

Re: [mod-security-users] ModSecurity rules for PHP vulnerabilities

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

> Steve West wrote:
> > Hi folks,
> >
> > I'm wondering if anyon knows how to prevent some PHP 4.4.x/5.x
> > vulnerabilities via mod_security until PHP group releases fixes for
> > these. Here is more info on the vulnerabilities:
> >
> > PHP copy() function: http://securitytracker.com/alerts/2006/Apr/1015882=
.html

For this one you could try looking for the string "compress.zlib:", e.g.

    SecFilterSelective ARGS_VALUES compress\.zlib:


> > PHP tempname() Arg: http://securitytracker.com/alerts/2006/Apr/1015881.=
html
> >
> > PHP crashing Apache: http://securitytracker.com/alerts/2006/Apr/1015880=
.html

These two require someone to be able to place code on the server. If
they can do that you have bigger problems :)


Terry Dooher wrote:
> If I read these right, jailing Apache and PHP should mitigate
> the potential damage.

Correct.


Terry Dooher wrote:
> SecChrootDir in mod_security will only jail apache, though, not PHP, so I
> don't think it will help in this case.

That's not true. SecChrootDir will chroot the entire process,
including the processes created at runtime (after chroot takes place).
(One does need to be carefull with "process daemons", such as
mod_cgid, though, as they may spawn before the chroot call. This
should not happen with 1.9.3 but it's better to check.) However, I
don't think it is possible to add SecChrootDir to an already-running
shared hosting platform. It would break too many things.

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

Re: [mod-security-users] ModSecurity rules for PHP vulnerabilities

[Terry D. <tdo...@na...>]

Steve West wrote:
> Hi folks,
> 
> I'm wondering if anyon knows how to prevent some PHP 4.4.x/5.x
> vulnerabilities via mod_security until PHP group releases fixes for
> these. Here is more info on the vulnerabilities:
> 
> PHP copy() function: http://securitytracker.com/alerts/2006/Apr/1015882.html
> 
> PHP tempname() Arg: http://securitytracker.com/alerts/2006/Apr/1015881.html
> 
> PHP crashing Apache: http://securitytracker.com/alerts/2006/Apr/1015880.html

Exploiting these three requires local acces. They're certainly fairly nasty 
bugs, especially if you're hosting a number of sites; but while you can filter 
the request, you can't filter the PHP that is executed, at least not with 
mod_security. If I read these right, jailing Apache and PHP should mitigate 
the potential damage.

SecChrootDir in mod_security will only jail apache, though, not PHP, so I 
don't think it will help in this case.

> PHP phpinfo() validation:
> http://securitytracker.com/alerts/2006/Apr/1015879.html

This one does rely on request input, though it's tricky to match. Any script 
could execute phpinfo(), any random padding could be used to overflow that 
buffer and the XSS could be any HTML/PHP. gotroot.com has a number of anti-xss 
filters. You could also block anything above a 4096 byte range with

SecFilterSelective "POST_PAYLOAD|QUERY_STRING" ".{4097,}"

though this will cause false positives if you're running a forum, for example. 
This vulnerability has been fixed, however, so the best course is to update.

Terry.


> Thanks,
> 
> SW
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 

[mod-security-users] ModSecurity rules for PHP vulnerabilities

[Steve W. <ste...@gm...>]

Hi folks,

I'm wondering if anyon knows how to prevent some PHP 4.4.x/5.x
vulnerabilities via mod_security until PHP group releases fixes for
these. Here is more info on the vulnerabilities:

PHP copy() function: http://securitytracker.com/alerts/2006/Apr/1015882.htm=
l

PHP tempname() Arg: http://securitytracker.com/alerts/2006/Apr/1015881.html

PHP crashing Apache: http://securitytracker.com/alerts/2006/Apr/1015880.htm=
l

PHP phpinfo() validation:
http://securitytracker.com/alerts/2006/Apr/1015879.html

Thanks,

SW

Re: [mod-security-users] So is ModSec no longer going to be free?

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

On 4/17/06, li...@32... <li...@32...> wrote:
>
> I notice that the ThinkingStone site has ModSecurity Pro, lowest license =
fee
> being $950 per year. Does this mean that once 2.0 drops, that MS will no
> longer be free?

No. ModSecurity for Apache will always be free. ModSecurity Pro is
just another name for ModSecurity + Certified ModSecurity Rules +
binaries (starting with v2) + support. I have big plans for
ModSecurity but for them to come true ModSecurity needs to start
paying my bills.

Hopefuly there will be a revenue stream coming from the organisations
that can afford to licence ModSecurity. Another might come from
ModSecurity Console (which will not be free).

> I am not complaining mind you, I think ModSec is every bit worth that
> amount. I just wanted to find out if it were the same thing?

In that case I'd be happy to sell you a couple of licences :)

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

[mod-security-users] So is ModSec no longer going to be free?

[<li...@32...>]

I notice that the ThinkingStone site has ModSecurity Pro, lowest license fee
being $950 per year. Does this mean that once 2.0 drops, that MS will no
longer be free?

I am not complaining mind you, I think ModSec is every bit worth that
amount. I just wanted to find out if it were the same thing?

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

[Jeff H. <ja...@mi...>]

Ivan, I think Thomas Anderson said it best but I would just like to add that for someone of your talent to develop such a useful piece of software, put it out as open source/GPL, free for all to use and then take the time to respond to virtually any and all questions is way more than anyone should expect.  I certainly appreciate it and I'm sure that other than Barbish, everyone else does too.

-Jeff