mod-security-users — General discussion about mod_security

Re: [mod-security-users] Hidden Fields

[Markus R. <we...@mr...>]

> 
>> 2) another
>> way would be to use md5-hashes for hidden fields. compute md5-hashes of each
>> or all hidden fields and send it also as hidden field. so you can recompute
>> the hash and check whether values have changed or not.
> 
>   Note that hashing alone isn't sufficient because it's trivial for
>   the attacker to recompute the hash. You have to encrypt the hash too.
> 

ok, just the md5-hash is not sufficient, but if you use an additional
"salt"-value then it should be good enough. eg.

	<input name="id" type="hidden" value="1234">

then generate an md5-hash from "id1234mySecretSalt". this should be good
enough as "mySecretSalt" could not be guessed that easy...

markus

Re: [mod-security-users] Ideas for future features..

[Zach R. <ad...@li...>]

A bayesian style filter is much better suited to an external daemon.

I hope you caught what Michael wrote about a softfail setting. If the 
external daemon fails having mod_security allow the connection anyway.

Zach

Ivan Ristic wrote:

>Zach Roberts wrote:
>  
>
>>Internal spam checker meaning a means of calling dnsrbl lookups from the
>>surbl based on backreferences or dnsrbl lookups on the remote address to
>>try to prevent open proxy access?
>>    
>>
>
>  That I will add. I was referring to e.g. having a Bayesian filter
>  built into ModSecurity.
>
>  
>

Re: [mod-security-users] Hidden Fields

[Ivan R. <iv...@we...>]

Markus Rietzler wrote:
> Ivan Ristic schrieb:
>> Diego Pellegrino wrote:
>>> Using mod_security, how can i prevent that users change forms parameters
>>> in POST requests? is it possible?
>>   Not possible, unless your hidden form field value is constant (probably
>>   not the case).
>>
>>   There's some chance this will be supported in the next release.
>> 
> ...
> i think mod_security could not really help with this problem. only if you use
> an output-filter that checks for type=hidden and compute md5-hashes...

  Exactly. Intercept outgoing forms, identify hidden fields, for every
  hidden field found generate another that contains a signature
  of the content.

  The same approach can be used to protect the cookies.


> 2) another
> way would be to use md5-hashes for hidden fields. compute md5-hashes of each
> or all hidden fields and send it also as hidden field. so you can recompute
> the hash and check whether values have changed or not.

  Note that hashing alone isn't sufficient because it's trivial for
  the attacker to recompute the hash. You have to encrypt the hash too.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Hidden Fields

[Markus R. <we...@mr...>]

Ivan Ristic schrieb:
> Diego Pellegrino wrote:
>> Using mod_security, how can i prevent that users change forms parameters
>> in POST requests? is it possible?
> 
>   Not possible, unless your hidden form field value is constant (probably
>   not the case).
> 
>   There's some chance this will be supported in the next release.
> 

this would be very complicated. there are two problems: 1) you have to know
which fields are hidden and which not. in a get or post request you only get
the pair name=value, no info about hidden or not hidden. 2) you have to know
the initial value of a field.
there are two ways to "protect" hidden fields: 1) use session vars, that are
stored on the server either in a file or db. with this you only send
"sessionId" to the browser, field values are stored on the server. 2) another
way would be to use md5-hashes for hidden fields. compute md5-hashes of each
or all hidden fields and send it also as hidden field. so you can recompute
the hash and check whether values have changed or not.
i think mod_security could not really help with this problem. only if you use
an output-filter that checks for type=hidden and compute md5-hashes...

markus

Re: [mod-security-users] Ideas for future features..

[Ivan R. <iv...@we...>]

Zach Roberts wrote:
> Internal spam checker meaning a means of calling dnsrbl lookups from the
> surbl based on backreferences or dnsrbl lookups on the remote address to
> try to prevent open proxy access?

  That I will add. I was referring to e.g. having a Bayesian filter
  built into ModSecurity.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Ideas for future features..

[Zach R. <ad...@li...>]

Internal spam checker meaning a means of calling dnsrbl lookups from the 
surbl based on backreferences or dnsrbl lookups on the remote address to 
try to prevent open proxy access?

Zach

Michael Shinn wrote:

>Ivan Ristic wrote:
>  
>
>>>I believe this sort of checking needs to be internal. Accessing an
>>>external Perl script for example would be far too resource intensive if
>>>it were used to scan a very large number of incoming connections.
>>>    
>>>      
>>>
>>  Forking to execute a Perl script might not be feasible, but
>>  talking to an already-running daemon may be better. I'd really
>>  hate to see ModSecurity integrate a spam checker :)
>>  
>>    
>>
>
>Oh god, please no internal spam checker.  :-)
>
>
>-------------------------------------------------------
>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&kid=110944&bid=241720&dat=121642
>_______________________________________________
>mod-security-users mailing list
>mod...@li...
>https://lists.sourceforge.net/lists/listinfo/mod-security-users
>  
>

Re: [mod-security-users] Ideas for future features..

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

Zach Roberts wrote:
>>
>>  Forking to execute a Perl script might not be feasible, but
>>  talking to an already-running daemon may be better. I'd really
>>  hate to see ModSecurity integrate a spam checker :)
>>
>>
>>  
>>
> I would hate to see the spam checker daemon die for some reason and
> then Apache serve broken pages.
>
> Perhaps backreferences and RBL lookups built internally for the sake
> of the system administrators? ;)

Or just fail safe with a pass.

Re: [mod-security-users] Ideas for future features..

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

Ivan Ristic wrote:
>> I believe this sort of checking needs to be internal. Accessing an
>> external Perl script for example would be far too resource intensive if
>> it were used to scan a very large number of incoming connections.
>>     
>
>
>   Forking to execute a Perl script might not be feasible, but
>   talking to an already-running daemon may be better. I'd really
>   hate to see ModSecurity integrate a spam checker :)
>   

Oh god, please no internal spam checker.  :-)

Re: [mod-security-users] Ideas for future features..

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

On 2/25/06, Zach Roberts <ad...@li...> wrote:
>
> >  I meant to ask if you had any specific knowledge of how
> >  FrontPage triggers mod_evasive. Does it perform too many
> >  request in a short period of time? Anything that would help
> >  me avoid the problem ;)
> >
> >
> >
> When I wrote that I meant that the method it uses to detect incoming DoS
> attacks interferes with Frontpage's operation. Most likely the reason
> being that it sees Frontpage's requests as a DoS due to the amount of
> connections Frontpage uses to publish.



I am assuming that you would be using Frontpage to allow a small group of
people to upload files.  With this in mind, you can tweak mod_evasive in 2
ways -

1) Use the whitelist directive to tell mod_evasive to ignore those
authorized addresses who are using frontpage, and/or

2) Tweak the DOSSiteCount/DOSSiteInterval and DOSPageCount/DOSPageInterval
ratios to a threshold that will allow frontpage to work but will still
trigger when some launches a DoS attack.

I had to tweak these settings in my environment to allow some of our own we=
b
monitoring tools to work.

Just my $00.2.


--
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] Ideas for future features..

[Zach R. <ad...@li...>]

Ivan Ristic wrote:

>Zach Roberts wrote:
>  
>
>>Ivan Ristic wrote:
>>
>>    
>>
>>>Zach Roberts wrote:
>>> 
>>>
>>>      
>>>
>>>>I apologize for being absent for most of the discussion. My schedule has
>>>>been quite full lately.
>>>>
>>>>I have been using a forked mod_access_rbl for about a year now. While I
>>>>don't use it to scan every request that comes in I do use it to control
>>>>access to two or three files that are accessed quite a bit. For these
>>>>three files I am using seven different blacklists and I've noticed no
>>>>drop in performance.
>>>>  
>>>>        
>>>>
>>> Without a local cache?
>>>
>>>      
>>>
>>Just a local DNS cache.
>>    
>>
>
>  Just to double-check: and by that you mean the cache that's in the
>  libresolve library, not a local caching DNS server?
>
>
>  
>
I meant a local caching DNS server.

>>> BTW, even now you can have protection better than with mod_evasive
>>> using httpd-guardian (http://www.apachesecurity.net/tools/). And,
>>> in terms of performance, probably faster than what will be available
>>> in ModSecurity v2.0.
>>>
>>>      
>>>
>>I'll look at it. It might prove useful.
>>    
>>
>
>  I am looking for testers. You can even cluster it using Spread.
>
>
>  
>
I'll try to look at it within the next week as I get time.

>>>>If the functionality works with Frontpage too (mod_evasive
>>>>does not) it will be all that much better.
>>>>  
>>>>        
>>>>
>>> That's interesting. What is the problem with FrontPage?
>>>
>>>      
>>>
>>It interferes with publishing content via port 80.
>>    
>>
>
>  I meant to ask if you had any specific knowledge of how
>  FrontPage triggers mod_evasive. Does it perform too many
>  request in a short period of time? Anything that would help
>  me avoid the problem ;)
>
>  
>
When I wrote that I meant that the method it uses to detect incoming DoS 
attacks interferes with Frontpage's operation. Most likely the reason 
being that it sees Frontpage's requests as a DoS due to the amount of 
connections Frontpage uses to publish.

Zach

Re: [mod-security-users] Ideas for future features..

[Ivan R. <iv...@we...>]

Zach Roberts wrote:
> Ivan Ristic wrote:
> 
>> Zach Roberts wrote:
>>  
>>
>>> I apologize for being absent for most of the discussion. My schedule has
>>> been quite full lately.
>>>
>>> I have been using a forked mod_access_rbl for about a year now. While I
>>> don't use it to scan every request that comes in I do use it to control
>>> access to two or three files that are accessed quite a bit. For these
>>> three files I am using seven different blacklists and I've noticed no
>>> drop in performance.
>>>   
>>
>>  Without a local cache?
>>
> Just a local DNS cache.

  Just to double-check: and by that you mean the cache that's in the
  libresolve library, not a local caching DNS server?


>>  BTW, even now you can have protection better than with mod_evasive
>>  using httpd-guardian (http://www.apachesecurity.net/tools/). And,
>>  in terms of performance, probably faster than what will be available
>>  in ModSecurity v2.0.
>>
> I'll look at it. It might prove useful.

  I am looking for testers. You can even cluster it using Spread.


>>> If the functionality works with Frontpage too (mod_evasive
>>> does not) it will be all that much better.
>>>   
>>
>>  That's interesting. What is the problem with FrontPage?
>>
> It interferes with publishing content via port 80.

  I meant to ask if you had any specific knowledge of how
  FrontPage triggers mod_evasive. Does it perform too many
  request in a short period of time? Anything that would help
  me avoid the problem ;)

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Ideas for future features..

[Zach R. <ad...@li...>]

Ivan Ristic wrote:

>Zach Roberts wrote:
>  
>
>>I apologize for being absent for most of the discussion. My schedule has
>>been quite full lately.
>>
>>I have been using a forked mod_access_rbl for about a year now. While I
>>don't use it to scan every request that comes in I do use it to control
>>access to two or three files that are accessed quite a bit. For these
>>three files I am using seven different blacklists and I've noticed no
>>drop in performance.
>>    
>>
>
>  Without a local cache?
>
>  
>
Just a local DNS cache.

>> As a matter of fact, ModSecurity 1.8.x-dev was able to interface
>> with external spam checkers. I announced it on the list (I think)
>> but since no one used it I removed it prior to 1.9 final.
>>
>>I believe this sort of checking needs to be internal. Accessing an
>>external Perl script for example would be far too resource intensive if
>>it were used to scan a very large number of incoming connections.
>>    
>>
>
>  Forking to execute a Perl script might not be feasible, but
>  talking to an already-running daemon may be better. I'd really
>  hate to see ModSecurity integrate a spam checker :)
>
>
>  
>
I would hate to see the spam checker daemon die for some reason and then 
Apache serve broken pages.

Perhaps backreferences and RBL lookups built internally for the sake of 
the system administrators? ;)

>>I can see you guys have a good handle on the situation. The future
>>features of 2.0.0 look very promising with functionality similar to
>>mod_evasive.
>>    
>>
>
>  BTW, even now you can have protection better than with mod_evasive
>  using httpd-guardian (http://www.apachesecurity.net/tools/). And,
>  in terms of performance, probably faster than what will be available
>  in ModSecurity v2.0.
>
>
>  
>
I'll look at it. It might prove useful.

>>If the functionality works with Frontpage too (mod_evasive
>>does not) it will be all that much better.
>>    
>>
>
>  That's interesting. What is the problem with FrontPage?
>
>  
>
It interferes with publishing content via port 80. Nothing critical in 
my eyes since it gave me a good excuse to get rid of the Frontpage 
extensions completely. ;)

Zach

Re: [mod-security-users] Ideas for future features..

[Ivan R. <iv...@we...>]

Zach Roberts wrote:
> I apologize for being absent for most of the discussion. My schedule has
> been quite full lately.
> 
> I have been using a forked mod_access_rbl for about a year now. While I
> don't use it to scan every request that comes in I do use it to control
> access to two or three files that are accessed quite a bit. For these
> three files I am using seven different blacklists and I've noticed no
> drop in performance.

  Without a local cache?

>  As a matter of fact, ModSecurity 1.8.x-dev was able to interface
>  with external spam checkers. I announced it on the list (I think)
>  but since no one used it I removed it prior to 1.9 final.
> 
> I believe this sort of checking needs to be internal. Accessing an
> external Perl script for example would be far too resource intensive if
> it were used to scan a very large number of incoming connections.

  Forking to execute a Perl script might not be feasible, but
  talking to an already-running daemon may be better. I'd really
  hate to see ModSecurity integrate a spam checker :)


> I can see you guys have a good handle on the situation. The future
> features of 2.0.0 look very promising with functionality similar to
> mod_evasive.

  BTW, even now you can have protection better than with mod_evasive
  using httpd-guardian (http://www.apachesecurity.net/tools/). And,
  in terms of performance, probably faster than what will be available
  in ModSecurity v2.0.


> If the functionality works with Frontpage too (mod_evasive
> does not) it will be all that much better.

  That's interesting. What is the problem with FrontPage?

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Hidden Fields

[Ivan R. <iv...@we...>]

Diego Pellegrino wrote:
> Using mod_security, how can i prevent that users change forms parameters
> in POST requests? is it possible?

  Not possible, unless your hidden form field value is constant (probably
  not the case).

  There's some chance this will be supported in the next release.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Ideas for future features..

[Ivan R. <iv...@we...>]

Michael Shinn wrote:
>
> Based on this anecdotal experience,I don't think that an internal cache
> would be necessary for mod_security to support RBL lookups.

  I agree. Still, I will have a cache which will be used for other
  things (e.g. for brute force attacks detection). If this cache is
  enabled then there is practically no further cost for the RBL cache.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Ideas for future features..

[Zach R. <ad...@li...>]

I apologize for being absent for most of the discussion. My schedule has 
been quite full lately.

I have been using a forked mod_access_rbl for about a year now. While I 
don't use it to scan every request that comes in I do use it to control 
access to two or three files that are accessed quite a bit. For these 
three files I am using seven different blacklists and I've noticed no 
drop in performance. I don't think DNS lookups are all that heavy in 
terms of resource usage when compared to PHP/MySQL being run for every 
spambot request but, using dnsrbls to deny access to an entire website 
could be fairly resource intensive.

The idea of an internal cache was mostly to save additional DNS lookups 
to the local DNS server but, it isn't necessary. The performance of the 
existing modules with no internal cache is enough that it shouldn't be a 
problem for protecting a few files but, if this was going to be deployed 
to scan every request or every argument sent to the server it could be a 
problem.

----

The issue of IPs in a firewall that I mentioned wasn't really directed 
at 5000 - 10000 IPs but, more along the lines of 40000 - 50000 IPs. It 
scales for now but, we need a better solution for the future.

---

  As a matter of fact, ModSecurity 1.8.x-dev was able to interface
  with external spam checkers. I announced it on the list (I think)
  but since no one used it I removed it prior to 1.9 final.

I believe this sort of checking needs to be internal. Accessing an 
external Perl script for example would be far too resource intensive if 
it were used to scan a very large number of incoming connections.

I can see you guys have a good handle on the situation. The future 
features of 2.0.0 look very promising with functionality similar to 
mod_evasive. If the functionality works with Frontpage too (mod_evasive 
does not) it will be all that much better.

Zach

Michael Shinn wrote:

>On Fri, 2006-02-24 at 15:53 +0000, Ivan Ristic wrote:
>  
>
>>Michael Shinn wrote:
>>    
>>
>>>attackers, owned boxes, etc.).  This will use a modified mod_access,
>>>which will allow for real time lookups of the IPs.  rsync access will
>>>also be available to the zones for secondaries, and sites that wish to
>>>use the IPs for firewalling purposes.
>>>      
>>>
>>  How long do the lookups take to complete when the information
>>  is cached in a local DNS?
>>    
>>
>
>Good question, I'll have to generate some official stats to quantify the
>performance, but I've been running a modified mod_access doing lookups
>against the spamhaus.org RBL for about a year and I've never noticed a
>measurable change in performance as a user.  In short, a local DNS (in
>my case bind) seems to do an good job of caching the lookups, in the
>same manner that a local DNS seems to do a good enough job with SMTP
>RBLs.
>
>Based on this anecdotal experience,I don't think that an internal cache
>would be necessary for mod_security to support RBL lookups.  It may not
>even be optimal in some cases, as TTLs may require one lookup to be
>retried in 1 minute, another in 3600, etc. further complicating the code
>in mod_security to age these out differently.  But, I definitely could
>see some users not being aware of the need to setup a local DNS and
>experiencing a significant performance problem and then perceiving that
>as a mod_security issue.  
>
>Regardless, a local DNS in my experience does seem to do an adequate
>job, so my vote would be to add the RBL lookup capability to
>mod_security minus the cache for the initial testing release, and if the
>performance seems suboptimal with a local DNS, then add in a cache for
>the next phase of testing.  
>
>  
>

[mod-security-users] Hidden Fields

[Diego P. <die...@ho...>]

Using mod_security, how can i prevent that users change forms parameters in 
POST requests? is it possible?

I read that some web app firewalls (commercial products) checks the 
variables contained in the forms and validate against the POST (preventing 
that user change values)

thanks you

[mod-security-users] hidden fields

[Diego P. <die...@ho...>]

Using mod_security, how can i prevent that users change forms hidden fields 
in POST requests? is it possible?

I read that some web app firewalls (commercial products) checks the hidden 
fields contained in the forms and validate against the POST (preventing that 
user change values)

thanks you

Re: [mod-security-users] Ideas for future features..

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

On Fri, 2006-02-24 at 15:53 +0000, Ivan Ristic wrote:
> Michael Shinn wrote:
> >
> > attackers, owned boxes, etc.).  This will use a modified mod_access,
> > which will allow for real time lookups of the IPs.  rsync access will
> > also be available to the zones for secondaries, and sites that wish to
> > use the IPs for firewalling purposes.
> 
>   How long do the lookups take to complete when the information
>   is cached in a local DNS?

Good question, I'll have to generate some official stats to quantify the
performance, but I've been running a modified mod_access doing lookups
against the spamhaus.org RBL for about a year and I've never noticed a
measurable change in performance as a user.  In short, a local DNS (in
my case bind) seems to do an good job of caching the lookups, in the
same manner that a local DNS seems to do a good enough job with SMTP
RBLs.

Based on this anecdotal experience,I don't think that an internal cache
would be necessary for mod_security to support RBL lookups.  It may not
even be optimal in some cases, as TTLs may require one lookup to be
retried in 1 minute, another in 3600, etc. further complicating the code
in mod_security to age these out differently.  But, I definitely could
see some users not being aware of the need to setup a local DNS and
experiencing a significant performance problem and then perceiving that
as a mod_security issue.  

Regardless, a local DNS in my experience does seem to do an adequate
job, so my vote would be to add the RBL lookup capability to
mod_security minus the cache for the initial testing release, and if the
performance seems suboptimal with a local DNS, then add in a cache for
the next phase of testing.  

-- 
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] Does this conf could run correctly?

[PERA, C. (S. TRANSICIEL) <chr...@ai...>]

Hi,

I try to implement basic rules as following:

--> in httpd.conf:

### < Security > ###
# Turn ModSecurity On
        SecFilterEngine On

# Reject requests with status 403
        SecFilterDefaultAction "deny,log,status:403"

# Some sane defaults
        SecFilterScanPOST Off
        SecFilterCheckURLEncoding On
        # for UTF8 encoding
        SecFilterCheckUnicodeEncoding Off

# Accept almost all byte values
        SecFilterForceByteRange 1 151

# Server masking is optional
        SecServerSignature " "

# Only record the interesting stuff
        SecAuditEngine RelevantOnly
        SecAuditLog logs/modsec_log

# You normally won't need debug logging
        SecFilterDebugLevel 0
        SecFilterDebugLog logs/modsec_debug_log

#Deny all unwanted characters
        SecFilterSelective REQUEST_URI "'"      deny
        SecFilterSelective REQUEST_URI "//"    deny
        SecFilterSelective REQUEST_URI "/\*"    deny
        SecFilterSelective REQUEST_URI "\./"    deny
        SecFilterSelective REQUEST_URI "/\."    deny
        SecFilterSelective REQUEST_URI "<"      deny
        SecFilterSelective REQUEST_URI ">"      deny

### < /Security > ###

--> In the mapping file:

RewriteRule             ^/web1(.*)          http://server1:8001/web1$1    [NC,P,L]

<Location ~ "/(web1|WEB1)">
        SecFilterSelective REQUEST_URI "//"     allow
        SecFilterSelective REQUEST_URI "/\*"    allow
        SecFilterSelective REQUEST_URI "'"      allow
        SecFilterSelective REQUEST_URI "/\."      allow
</LocationMatch>

RewriteRule             ^/web2(.*)          http://server1:8002/web1$1    [NC,P,L]
<Location ~ "/(web2|WEB2)">
        SecFilterSelective REQUEST_URI "<"     allow
        SecFilterSelective REQUEST_URI ">"    allow
        SecFilterSelective REQUEST_URI "\./'"      allow
</LocationMatch>


--> Problem: the simple quote is never allowed on web1 access, and sometimes i have problem to access with /*.

I have seen the list of metacharacters: $.[|()?* + { \ ^ - []
But the simple quote is not listed.

How can i do?

Thanks for your help.
Best Regards and good week end.

Christophe




This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.

Re: [mod-security-users] Re: What best to do with php, xmlrpc, cvs, mambo, blog, drupal, wordpress injection attacks?

[Ivan R. <iv...@we...>]

John Thomas wrote:
> Andras Got wrote:
> 
>> Just ban wget, fetch and other dl clients, suspicious name is URL-s and 
> 
> Apologies for my ignorance, but does this mean you add lines to the conf
> file as follows:
> 
> SecFilter wget
> SecFilter fetch

  That would probably result in many false positives. But you may
  want to try something like this:

  SecFilterSelective ARGS_VALUES "^(http|https|ftp):/.+(wget|curl)"

  Of course, an even better thing would be to put php in a jail
  where there are no user programs at all :)


>> of course you should secure your PHP (safe_mode, disable_functions,
>> open_basedir).
> 
> Does this apply if I am the only console user on the box?  I read that
> safe mode breaks some apps and it is most commonly useful when the box
> is shared.
> 
> Also, if I may, what are the most dangerous functions you disable with
> disable_functions?

  I covered that in my book. Incidently, the PHP chapter is free:
  http://www.apachesecurity.net/download/apachesecurity-ch03.pdf

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

Re: [mod-security-users] Ideas for future features..

[Ivan R. <iv...@we...>]

Michael Shinn wrote:
>
> attackers, owned boxes, etc.).  This will use a modified mod_access,
> which will allow for real time lookups of the IPs.  rsync access will
> also be available to the zones for secondaries, and sites that wish to
> use the IPs for firewalling purposes.

  How long do the lookups take to complete when the information
  is cached in a local DNS?

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

Re: [mod-security-users] Ideas for future features..

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

Jason Edgecombe wrote:
> Zach Roberts wrote:
>> I know at least a few of us that use mod_security to enhance security
>> in a shared webhosting environment have tried to tackle the problem
>> of comment spam. The idea of using mod_security rules to block it
>> isn't new. See gotroot.com's blacklist.conf for their attempt at it.
>>
>> The problem is that the idea of using flatfiles for a blacklist
>> cannot possibly be sustained indefinitely as more of this comment
>> spam surfaces. Even blocking the robots by IPs will be nearly
>> impossible using firewalls or flatfiles as even firewalls will start
>> to slow down servers after tens of thousands of IPs are added.
> I haven't encountered the problem of too many blacklisted IP's yet.
> For that problem, we may want a non-flat-file option such as berkely
> db, sqlite or something similar. Even sendmail compiles it's aliases
> file.
>
> The thing I have noticed is that there is no way to reload the file
> besides restarting apache. If you don't have firewall access and block
> Ip's using mod_security (which I don't), it would be nice to be able
> have the file reloaded periodically. something like check for an
> updated file every 5 minutes (configurable).

For those that are having problems with lots of IPs via the
blacklist.conf rules (either as firewall rules, or using mod_security),
I am setting up a special set of RBLs for those IPs (spammers,
attackers, owned boxes, etc.).  This will use a modified mod_access,
which will allow for real time lookups of the IPs.  rsync access will
also be available to the zones for secondaries, and sites that wish to
use the IPs for firewalling purposes.

RE: [mod-security-users] Re: What best to do with php, xmlrpc, cvs, mambo, blog, drupal, wordpress injection attacks?

[BassPlayer <bas...@an...>]

Doh  I did not see that. I claim lack of sleep as an excuse :D
Ral...@it... wrote:
> I agree,
> but it wasn't necessary to remind me.
> As I already told Ivan I had purchased a copy of his book when it
> had just been released in Germany,
> which was almost a year ago ;-)
>
>> -----Original Message-----
>> From: mod...@li...
>> [mailto:mod...@li...]On
> Behalf Of
>> BassPlayer
>> Sent: Thursday, February 23, 2006 9:26 PM
>> To: mod...@li...
>> Subject: Re: [mod-security-users] Re: What best to do with
>> php, xmlrpc,
>> cvs, mambo, blog, drupal, wordpress injection attacks?
>>
>>
>> http://apachesecurity.net/
>>
>> Great book
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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&kid=110944&bid=241720&
> dat=121642
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>
>
> -------------------------------------------------------
> 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_______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>
>
> !DSPAM:43fec89c298713037420726!
>

RE: [mod-security-users] Re: What best to do with php, xmlrpc, cvs, mambo, blog, drupal, wordpress injection attacks?

[<Ral...@it...>]

I agree,
but it wasn't necessary to remind me.
As I already told Ivan I had purchased a copy of his book when it
had just been released in Germany,
which was almost a year ago ;-)

> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On
Behalf Of
> BassPlayer
> Sent: Thursday, February 23, 2006 9:26 PM
> To: mod...@li...
> Subject: Re: [mod-security-users] Re: What best to do with=20
> php, xmlrpc,
> cvs, mambo, blog, drupal, wordpress injection attacks?
>=20
>=20
> http://apachesecurity.net/
>=20
> Great book
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&
dat=3D121642
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users