Thread: [mod-security-users] How to/feature requests?
Brought to you by:
victorhora,
zimmerletw
|
From: Eli <eli...@ex...> - 2005-01-20 23:19:29
|
I recently installed mod_security on a server to hopefully do a few = things that I thought it may be able to do. One of those was to prevent Apache from logging (to the access logs) = certain requests coming in. Sites on servers have been getting bogus HTTP = SEARCH requests which Apache will reject and it causes no harm, however the = path provided with the SEARCH request is in high ascii, so Apache quotes the characters in the log files and you end up with an enormous line of junk = in your log files. This has been borking the stats software from reading = the logfiles which means we then have to fix the log files by hand (oh, yay = :P). Anyways, I set up this: SecFilterSelective "REQUEST_METHOD" "!^(GET|HEAD|POST)$" "nolog,deny,status:403" Initially I thought the nolog meant it wouldn't let Apache log it at all = - then I noticed it was just preventing it from being recorded by = mod_security in the error logfile. I then thought that if I used mod_security JUST = to filter based on that rule, I could use the environment variable trick = with a CustomLog line to prevent logging any lines that mod_security was = triggered on. However, that means I have to not log ANYTHING mod_security = touches, since it's just that one env variable for everything. So, I was wondering if there was any other way to do what I'm trying to = do, or if maybe a request for something more extensible with regards to = blocking requests from travelling further in Apache (I don't know enough about = the internal workings - does Apache log the request before mod_security can touch it? If so could it just be dropped if we didn't want to log it?), = or maybe having multiple environment variables possible - like rather than "nolog,deny,status:403", we could have "nolog,deny,status:403,envtag:3a" which would give an environment variable specific "tag" to that filter. Then when testing for mod_security-relevant in a CustomLog, we could = instead test for mod_security-relevant-3a (tag is appended to the variable) or something? This would allow people to selectively log stuff based on a = per filter basis. 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... I know the log file would be enormous, but it would still be nice to do. = The unfortunate part was that it seems there's no way to do this that I = could see either, however maybe if the suggestion above was implemented it = could be. 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. Sorry for rambling on like that, just figured I'd voice my wants and see = if others agree with them :) Thanks! Eli. |
|
From: Ivan R. <iv...@we...> - 2005-01-21 09:51:40
|
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) |