SeRule ARGS:

how do we destinguish GET from POST variables in
  SecRule ARGS:dirty getme
  SecRule ATGS:dirty postme

(assuming that dirty is in the QUERY_STRING *and* the HTTP body)

Am I correct that POSTed dirty variable is not available in phase:2, but GETed
is?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: SeRule ARGS:

> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Achim
Hoffmann
> Sent: Monday, October 01, 2007 9:19 AM
> To: mod-security-users <at> lists.sourceforge.net
> Subject: [mod-security-users] SeRule ARGS:
> 
> how do we destinguish GET from POST variables in
>   SecRule ARGS:dirty getme
>   SecRule ATGS:dirty postme
> 
> (assuming that dirty is in the QUERY_STRING *and* the HTTP body)
> 
[Ryan Barnett] Yeah, this is a bit quirky to try and enforce these ARGS
to be only in either a QUERY_STRING or POST_PAYLOAD.  You essentially
have to check both locations.  This is how REMO rules accomplish this
issue.  If you want to enforce only allowing the "dirty" argument to be
allowed in the POST payload, then you can use a rule similar to this -

<Location /cgi-bin/foo.php>
SecRule QUERY_STRING "^dirty[=&]|^dirty$"
"phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
is present in query string. This is illegal.'"
SecRule ARGS:dirty "^postme$"
"phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
matched.'"
</Location>

Conversely, if you want to only allow the "dirty" argument to be allowed

Re: SeRule ARGS:

To make this easier in 2.5.0, you will be able to use ARGS_GET,
ARGS_POST, ARGS_GET_NAMES, ARGS_POST_NAMES.

Looks for these feature (and many others) in the next development
release for 2.5, 2.5.0-dev3 which should be out shortly.

later,
-B

Ryan Barnett wrote:
>> -----Original Message-----
>> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
>> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Achim
> Hoffmann
>> Sent: Monday, October 01, 2007 9:19 AM
>> To: mod-security-users <at> lists.sourceforge.net
>> Subject: [mod-security-users] SeRule ARGS:
>>
>> how do we destinguish GET from POST variables in
>>   SecRule ARGS:dirty getme
>>   SecRule ATGS:dirty postme
>>
>> (assuming that dirty is in the QUERY_STRING *and* the HTTP body)
>>
> [Ryan Barnett] Yeah, this is a bit quirky to try and enforce these ARGS
> to be only in either a QUERY_STRING or POST_PAYLOAD.  You essentially
> have to check both locations.  This is how REMO rules accomplish this
> issue.  If you want to enforce only allowing the "dirty" argument to be
> allowed in the POST payload, then you can use a rule similar to this -
> 

Modsecurity Chroot

Has anyone had experience using the chroot feature in mod_security?  I
read in the documentation that the chroot happens after the process
starts up so you dont need to copy in all your binary files to the
chroot however I have run into some strange issues when implementing.

First issue is that for some reason after jailing apache/php can not do
dns lookups so if your trying to connect to a database by cname it
fails.  After copying over the required shared libraries it appears to
work but i would rather not have todo that.  

Second issues is an apache graceful restart or reload.  It fails because
the process is now jailed and appears to look for the required files in
the chroot.  This can be fixed by either doing a restart instead or by
copying over the binaries.  

Third is the sendmail issue.  Sendmail appears to need to be copied or
installed to the chroot due to the issue that the binary is not
accessible.

Has anyone come up with a work around for these issues?

Thanks
-Alex

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Modsecurity Chroot

Hi Alex,

The issues you've run into are all drawbacks of the internal chroot
feature. You can find an extended discussion in Chapter 2 of my book,
which is available for download from http://www.apachesecurity.net.

See below for more comments.

On 10/1/07, Alex Barker <abarker <at> callutheran.edu> wrote:
> Has anyone had experience using the chroot feature in mod_security?  I
> read in the documentation that the chroot happens after the process
> starts up so you dont need to copy in all your binary files to the
> chroot however I have run into some strange issues when implementing.

The main problem is that, once you perform chroot, you can no longer
get to anything outside jail. This includes accessing libraries loaded
on demand, or binaries for programs that are executed on demand.

> First issue is that for some reason after jailing apache/php can not do
> dns lookups so if your trying to connect to a database by cname it
> fails.  After copying over the required shared libraries it appears to
> work but i would rather not have todo that.

The libraries required for DNS resolution are dynamically loaded and
we do not know about them at startup.

> Second issues is an apache graceful restart or reload.  It fails because
> the process is now jailed and appears to look for the required files in
> the chroot.  This can be fixed by either doing a restart instead or by
> copying over the binaries.

mod_security2 and upload script

My Perl upload script has a progress bar and it does not work properly if
mod_security is enabled.

Windows XP, Apache 2.2.4, mod_security2 version 1.3.2 build 4 2007/01/17

1. I tried to add a .htaccess file to the upload script's directory but
found out "SecRuleEngine Off" cannot be used in a .htaccess file.
2. I then added the <Directory "/www/cgi-bin/xuploadpro"> container (as per
upload script author) to my config file which is below. I have a separate
config file for my cgi-bin which is "included" in the main httpd.conf file.
The entire cgi-bin config file is below:
..........................................
LoadModule cgi_module modules/mod_cgi.so

ScriptLog logs/cgi.log

ScriptAlias /cgi-bin/ "/www/cgi-bin/"

<Directory "/www/cgi-bin">
	AddType text/html .php .php4 .php5 .pl .cgi

	Options ExecCGI
	AllowOverride None

	Order allow,deny
	Allow from all

	<IfModule php5_module>
		<FilesMatch "\.php[45]?$">
			Deny from all

Re: mod_security2 and upload script

Per the error_log ModSecurity alert message, the size of the uploaded
file is larger than what is allowed by the SecRequestBodyLimit
directive.  Since you didn't specify this directive, ModSecurity used
the default setting of 134217728.

Take a look at the documentation for this directive - 
http://www.modsecurity.org/documentation/modsecurity-apache/2.1.2/modsec
urity2-apache-reference.html#N104FC

You need in increase the size in this directive.

As a side note - it appears that you are still using some of the older
1.x rule syntax in your IfModule location.  Take a look at the Migration
Matrix -
http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pd
f

--

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

> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of jeffshead
> Sent: Tuesday, October 02, 2007 9:49 AM

Re: mod_security2 and upload script

I doubt you can use ModSecurity and get the progress bar to work, even
after solving the current configuration problem. ModSecurity is
providing security by buffering requests and making sure they do not
reach the application unless they have been checked and deemed safe.
Your progress bar script, on the other hand, relies on getting data in
real-time. This are two contradicting requests.

A future version of ModSecurity will be able to operate in streaming
mode, in which case the progress bar script would work while
ModSecurity would be able to detect attacks but not prevent them.

On 10/2/07, jeffshead <jeffshead <at> gmail.com> wrote:
> My Perl upload script has a progress bar and it does not work properly if
> mod_security is enabled.
>
> Windows XP, Apache 2.2.4, mod_security2 version 1.3.2 build 4 2007/01/17
>
> 1. I tried to add a .htaccess file to the upload script's directory but
> found out "SecRuleEngine Off" cannot be used in a .htaccess file.
> 2. I then added the <Directory "/www/cgi-bin/xuploadpro"> container (as per
> upload script author) to my config file which is below. I have a separate
> config file for my cgi-bin which is "included" in the main httpd.conf file.
> The entire cgi-bin config file is below:
> ..........................................
> LoadModule cgi_module modules/mod_cgi.so
>
> ScriptLog logs/cgi.log
>
> ScriptAlias /cgi-bin/ "/www/cgi-bin/"
>

Re: SeRule ARGS:

Hi Brian, Ryan,

thanks for this info, I'll wait 'til 2.5 ..

{-: Achim

On Mon, 1 Oct 2007, Brian Rectanus wrote:

!! To make this easier in 2.5.0, you will be able to use ARGS_GET,
!! ARGS_POST, ARGS_GET_NAMES, ARGS_POST_NAMES.
!!
!! Looks for these feature (and many others) in the next development
!! release for 2.5, 2.5.0-dev3 which should be out shortly.
!!
!! Ryan Barnett wrote:
!! > [Ryan Barnett] Yeah, this is a bit quirky to try and enforce these ARGS
!! > to be only in either a QUERY_STRING or POST_PAYLOAD.  You essentially
!! > have to check both locations.  This is how REMO rules accomplish this
!! > issue.  If you want to enforce only allowing the "dirty" argument to be
!! > allowed in the POST payload, then you can use a rule similar to this -
!! >
!! > <Location /cgi-bin/foo.php>
!! > SecRule QUERY_STRING "^dirty[=&]|^dirty$"
!! > "phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
!! > is present in query string. This is illegal.'"
!! > SecRule ARGS:dirty "^postme$"
!! > "phase:2,t:none,deny,id:1,status:501,severity:3,msg:'Postparameter dirty
!! > matched.'"
!! > </Location>

Making custom rules that use request header and method

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users