Re: [mod-security-users] How to/feature requests?

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

Eli wrote:
> One of those was to prevent Apache from logging (to the access logs) certain
> requests coming in.

   ModSecurity doesn't help there because Apache rejects invalid requests
   long before they reach ModSecurity. One way to handle that is not to
   log the request line:

   LogFormat "%!414r" no414
   CustomLog logs/access_log no414

   Alternatively, you may try to use custom logging and SetEnvIf to
   avoid logging the requests altogether.


> "nolog,deny,status:403", we could have "nolog,deny,status:403,envtag:3a"

   The setenv action will appear in 1.9.


> Also, I was hoping to be able to use mod_security to log POST data (form
> data, not binary) in the event of hackers trying to do things, etc...

   It's possible. Look in the manual for the description of the audit
   logging.


> I was also hoping that it would be possible to use
> SecFilterCheckURLEncoding, SecFilterCheckUnicodeEncoding and
> SecFilterForceByteRange only on URL/URI data (ie, in a GET request), and not
> parse POST data with it.  You could implement a toggle, but then it may even
> be better to have specific filters just for the 2 POST data types because
> then you could have a very restrictive byte range for URI info, and then a
> more relaxed one for POST data being submitted in a form.  This was what I
> was hoping to have so I could restrict bytes to 32-127 in GET requests, but
> then for POST requests, relax it to 0-255 since it's very common for people
> to submit data with newlines in it and such (textareas) and other characters
> which I assume would be blocked when there's no reason to worry about
> situations like that.

   There's no reason to allow more characters in POST. Then the attacker
   would only need to change from GET to POST to execute the attack
   successfully. Still, you can turn off SecFilterForceByteRange
   completely and examine the bytes explicitly. E.g.

   SecFilterSelective THE_REQUEST "!^[\x0a\x0d\x20-\x7f]+$"

-- 
Ivan Ristic (http://www.modsecurity.org)