Understanding mod_security

[GaryT]

I have had this enabled for a while but recently I been getting emails with the following:

Time: Wed Jun 9 08:50:00 2010 -0600
IP: 8*.***.***.*0 (GB/United Kingdom/host8*.***.***.*0.range**-***.btcentralplus.com)
Failures: 5 (mod_security)
Interval: 300 seconds
Blocked: Permanent Block

Log entries:

[Wed Jun 09 08:49:03 2010] [error] [client 8*.***.***.*0] ModSecurity: Access denied with code 501 (phase 2). Match of "rx ^((??:POS|GE)T|OPTIONS|HEAD))$" against "REQUEST_METHOD" required. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "38"] [id "960032"] [msg "Method is not allowed by policy"] [severity "CRITICAL"] [tag "POLICY/METHOD_NOT_ALLOWED"] [hostname "hosting.*********"] [uri "/"] [unique_id "TA@p37IgX0wAAD58hV4AAAAa"]


This is around 4 times per email


Can someone explain the above and roughly what the attempt was.

Thank you in advance.

[garrettp]

Looks like someone is trying to make requests on your server other than the methods permitted by your mod_sec ruleset (GET, POST, HEAD, OPTIONS) and mod_sec is blocking that request. Usually this is someone who is trying to use the TRACE method to get unauthorized information from the server such as cookie data.

[santrix]

960032 is quite a common rule to be triggered. As garrettp says, it's a non standard type of http request. I think it's mainly bored kids learning how to use netcat to probe for vulnerabilities... If the probe is coming from a UK IP address, report it to the ISP concerned. A bit like painting a rivet on the severn bridge, but it'll make you feel better

[GaryT]

Thank you for your replies guys, Much appreciated by me.

[gruvin]

Hi

Is there a way to log the full request header so I can see exactly what is triggering this rule? Because...

I too have been seeing this rule getting triggered more regularly lately. I thought nothing of it, being thankful mod_sec was doing its job. That is, until two legitimate, definitely non-hacker type, local clients got blocked by it in this past week. :/ Hmmm!

I'm wondered if maybe they're running some kind of (crappy?) anti-virus software — you know, with those 'protect you from bad web links" modules — or perhaps some malware jumping on the back of their legitimate requests. One client didn't know if they had anti-virus software or not (!! *sigh*) and the other says definitely not — and they're on a Mac — and they have a static IP.

So what I really need to do now is get more log details about exactly what the request (the full header would be good) is, so I can figure out what's going on.

[Infopro]

modsecurity is like most everything else, you need to tweak it a bit for your own needs. If you see valid users being blocked you can always disable that one rule easy enough if you like.

Find this line:

SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD))$" \
"phase:2,t:none,log,auditlog,status:501,msg:'Method is not allowed by policy', severity:'2',id:'960032',tag:'POLICY/METHOD_NOT_ALLOWED'"

And change it to this:

#SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD))$" \
"phase:2,t:none,log,auditlog,status:501,msg:'Method is not allowed by policy', severity:'2',id:'960032',tag:'POLICY/METHOD_NOT_ALLOWED'"

Here: /usr/local/apache/conf/modsec2.user.conf

[gruvin]

Thanks for the comment.

Well yes, sure. We could simply disable the rule.

But surely there's a way to get log information of the full header-set that triggered the rule in the first place?

The customer (remote end) might have malware that we could detect and then help them remove, for example.

Personally, I don't think simply disabling rules that cause "problems" is an especially intelligent way to go — though there certainly are cases where such an action is the only way to go, and we've had a couple of those concerning the handling of GB Chinese character sets for example.