A few requests :)

Re: A few requests :)

> I got a few friends that like to test out my filter and stuff with the 
> newest gadgets (retina for one) on my webserver.
> Can you make a keyword in mod_security that lets me take away the 
> protection/logging for certain ip's or ip ranges?

   That's easy, put this on top of your riles:

   SecFilterSelective REMOTE_ADDR "IP_ADDRESS" allow

> And while you are at it, can you make a black list as well? meaning that 
> i want to log everything from a certain ip.

   Can you be more specific? What does "everything" mean? Do you
   want to trigger the audit log only for a specific IP address?

> Also, a keyword in mod_security that makes the logs more readable to 
> *programs* wouldn't hurt.

   What stopping programs from reading the current format?

--

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

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

[Fwd: Re: Issue uploading files via http with Apache2, php 4.3.4, and mod_security.]

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

I had to modify the port myself because the maintainer hs not updated to
1.7.4 yet but once I reinstalled it the problem seemed to go away.  Thanks
for the heads up.

Also, I was going to post this to the mailing list but when I went to the
site I couldn't see the archives and when I tried to login to edit my
information it says that my e-mail addr doesn't exist, I tried copying and
pasting my e-mail address exactly as it is in the e-mail the system sent
me when I registered and it still wouldn't work.  I suspect that something
is wrong with the mailing list.

Anyway, it worked!

Regards,
Kevin

On Wed, 31 Dec 2003, Ivan Ristic wrote:

> modsecurity <at> bsdknight.org wrote:
> > I'm running on FreeBSD 4.9 STABLE, I installed Apache 2.0.48,
>  > PHP 4.3.4, and mod_security 1.7.3 from the ports.
>
>    Can you please try 1.7.4:
>
>    http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
>
>    A problem matching your descriptions existed in (probably all,
>    but confirmed for 1.7.3) versions before 1.7.4 and it was fixed.
>
> --
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]

Re: Restriction to / dir

>>>  What kind of restriction? Do you mean the root (/) of the
>>>  file system, or the root of the web server?
> 
> 
> Yes, I meant the root of file system.
> With /boot I can block access to the /boot dir but I'm not sure
> how can I block the upper (root) dir.
> 
> 
>>>  Both are possible. You don't need mod_security, mod_access
>>>  (built-in) already supports that with Allow and Deny
>>>  directives.
> 
> 
> seems not possible.
> how can I block root system dir with deny directive?

   Like this:

   # First you block everything
   <Directory />
      Order Deny,Allow
      Deny from all
   </Directory>

   # Then allow what you want
   <Directory /home/www>
      Order Deny,Allow
      Allow from all
  </Directory>

  The code above will tell the web server not to serve
  files that are not in the /home/www subdirectory (/, /boot, whatever).

  If you want a solution to prevent someone from exploiting a
  vulnerable script and trick it into serving a file from the
  root of the file system: the only real protection is to
  chroot the web server or your scripts (if we are talking CGI,
  use the safe mode for PHP).

  ModSecurity can scan parameters for suspicious strings but it's
  not foolproof. It needs something distinctive to act upon. For
  example, protecting "/boot" is easy. But the root "/" - not simple.

--

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

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Restriction to / dir

>   ModSecurity can scan parameters for suspicious strings but it's
>   not foolproof. It needs something distinctive to act upon. For
>   example, protecting "/boot" is easy. But the root "/" - not simple.

What about this regular expression?

  ^/[^/]*$

It will match strings that begin with a slash and then have zero or more characters that are something else
than slashes.

I think it might be useful for people who want to restrict mod_security to only allow files from the top-dir,
or for that matter, to restrict it to files in other dirs than the top-dir.

// Ulf Harnhammar
   kses - PHP HTML/XHTML filter (no XSS)
   http://sourceforge.net/projects/kses

--

-- 
___________________________________________________
Check out the latest SMS services  <at>  http://www.operamail.com, which allows you to send SMS through your mailbox.

Powered by Outblaze

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Restriction to / dir

Ulf Harnhammar wrote:
>>  ModSecurity can scan parameters for suspicious strings but it's
>>  not foolproof. It needs something distinctive to act upon. For
>>  example, protecting "/boot" is easy. But the root "/" - not simple.
> 
> 
> What about this regular expression?
> 
>   ^/[^/]*$
> 
> It will match strings that begin with a slash and then have zero
 > or more characters that are something else than slashes.

   That will work if you use it like this:

   SecFilterSelective SCRIPT_FILENAME "^/[^/]*$"

   but, again, that only covers the files executed and/or served
   by Apache. In my earlier email I was referring to various scripts
   that allow file download, accepting filenames as parameters.

   For example:

   http://www.xyz.com/cgi-bin/download.php?filename=/etc/passwd

   If you know about this script you can secure it (either by making
   sure it works properly, or by using mod_security to look after it).
   But in a shared hosting environment when you have customers uploading
   arbitrary scripts with arbitrary parameters crafting a filter to
   catch those / downloads is pretty difficult (without creating a
   large number of false positives, that is).

--

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

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

The directory traversal problem

I haven't tested this, but the following regexes should be helpful when trying to combat directory traversal:

  ^[/\]
  \.\.

The first matches any string that begins with "/" or "\" characters (like in "/etc/passwd"). The second
matches any string with two dots in a row (which of course disallows legitimate filenames like
"ulfs.nice.document..doc", but it also catches malicious things like "../../../../../../etc/passwd").

Any other ideas?

As Ivan wrote on webappsec, putting together a repository with regexes and other snippets for
mod_security would be a good idea.

// Ulf

--

-- 
___________________________________________________
Check out the latest SMS services  <at>  http://www.operamail.com, which allows you to send SMS through your mailbox.

Powered by Outblaze

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: The directory traversal problem

> As Ivan wrote on webappsec, putting together a repository
> with regexes and other snippets for mod_security would be
> a good idea.

   I'm half way there. The most boring bits of the (web)
   application are completed and I expect to have the rule
   database running (in a beta version) by the end of
   January.

   On a similar note, I've joined the WAS TC committee:
   http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=was

   to work on a specification for Web server/application
   protection. I expect the rule database to be compatible
   with the WAS spec. once it is completed.

--

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

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Directory traversal directive not working

Hi,

  I am testing mod_security with 2.0.48 on Solaris 8.
mod_security as been setup as a DSO.
My problem is that the very simple directory traversal directive ( below)
does not work:
SecFilter "\.\./"

The other directives preventing SQL injection or XSS work fine for me.
I have configured mod_security to return a HTTP 500 error and i am testing
the directory traversal directly from the command line with the runtest.pl
script.
Exemple:
./run-test.pl webserver1:666 ./03-evasion-traversal.test

I get a HTTP error of 404 instead of 500.

Here 's the request received in the log file:
[08/Jan/2004:18:20:25 +0100] 17.30.5.160 SSLv3 DHE-RSA-AES256-SHA "GET
/cgi-bin/dummy/../modsec-test.pl/keyword HTTP/1.0" 4954
( Just to show it has not been altered between the client and the server)

Note that I have tested the request through a SSL tunnel because Apache
only listens on a SSL port.

Running mod_security in debug mode gives me this:
[08/Jan/2004:18:31:08 +0100]
[webserver1/sid#188130][rid#21a528][/cgi-bin/modsec-test.pl/keyword]
Checking signature "\.\./" at THE_REQUEST

It's strange cause I don't see any  "regex_result: 17 is_allow: 0"
that i see for the other rules. Exemple:
[08/Jan/2004:18:31:08 +0100]
[webtest1/sid#188130][rid#21a528][/cgi-bin/modsec-test.pl/keyword]
check_sig_against_string: string
: /cgi-bin/modsec-test.pl/keyword regex_result: 17 is_allow: 0

Am i missing something?

Thanks in advance,
Luc

Here 's my complete configuration

############################################################

# Turn the filtering engine On or Off
 SecFilterEngine On

# Make sure that URL encoding is valid
 SecFilterCheckURLEncoding On

# Only allow bytes from this range ( ASCII caracters from 32 to 126)
# Avoid some of the buffer overflow attacks
 SecFilterForceByteRange 32 126

# Default action for security filters
 SecFilterDefaultAction "deny,log,status:500"

# Mask the signature of the server
 SecServerSignature "Microsoft-IIS/6.0"

# The audit engine works independently and
# can be turned On of Off on the per-server or
# on the per-directory basis
 SecAuditEngine RelevantOnly

# The name of the audit log file
 SecAuditLog /var/log/httpd/audit_log

# SecFilterDebugLog /var/log/httpd/modsec_debug_log
# SecFilterDebugLevel 0

# Should mod_security inspect POST payloads
 SecFilterScanPOST On
 SecFilterSelective THE_REQUEST "///"
 SecFilterSelective THE_REQUEST "/\.\.\.\."

# Prevent path traversal (..) attacks
 SecFilter "\.\./"

# WEB-MISC Apache Chunked-Encoding worm attempt
 SecFilter "CCCCCCC\: AAAAAAAAAAAAAAAAAAA"

# WEB-MISC WEB-INF access
 SecFilterSelective THE_REQUEST "/WEB-INF"

# WEB-MISC weblogic view source attempt
 SecFilterSelective THE_REQUEST "\.js\x70"

# Weaker XSS protection but allows common HTML tags
 SecFilter "<( |\n)*script"

# Prevent XSS atacks (HTML/Javascript injection)
 SecFilter "<(.|\n)+>"

# Prevent SQL injection attacks
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Directory traversal directive not working

> I am testing mod_security with 2.0.48 on Solaris 8.
> mod_security as been setup as a DSO.
> My problem is that the very simple directory traversal directive ( below)
> does not work:
> SecFilter "\.\./"
 >
 > ...
>  
> Am i missing something?

   The Apache is normalizing the path before mod_security
   gets to it (you can see it in the debug log if you increase
   the verbosity of the log). If you try something like:

   /cgi-bin/modsec-test.pl?p=123/../456

   it will work. Apache only normalizes the data on the
   left hand of the question mark character.

   For some time now I've been thinking whether to move
   mod_security processing into an earlier stage but there
   are so many advantages and disadvantages that I haven't
   made the decision yet.

--

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

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html