The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Understanding mod_security

Discussion in 'Security' started by GaryT, Jun 9, 2010.

  1. GaryT

    GaryT Well-Known Member

    Joined:
    May 19, 2010
    Messages:
    321
    Likes Received:
    3
    Trophy Points:
    16
    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.
     
  2. garrettp

    garrettp Well-Known Member
    PartnerNOC

    Joined:
    Jun 18, 2004
    Messages:
    312
    Likes Received:
    0
    Trophy Points:
    16
    cPanel Access Level:
    DataCenter Provider
    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.
     
  3. santrix

    santrix Well-Known Member

    Joined:
    Nov 30, 2008
    Messages:
    223
    Likes Received:
    2
    Trophy Points:
    18
    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 :D
     
  4. GaryT

    GaryT Well-Known Member

    Joined:
    May 19, 2010
    Messages:
    321
    Likes Received:
    3
    Trophy Points:
    16
    Thank you for your replies guys, Much appreciated by me.
     
  5. gruvin

    gruvin Member

    Joined:
    Feb 20, 2006
    Messages:
    12
    Likes Received:
    0
    Trophy Points:
    1
    How to get more log info on this rule?

    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.
     
    #5 gruvin, Jun 14, 2010
    Last edited: Jun 14, 2010
  6. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,482
    Likes Received:
    203
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    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
     
  7. gruvin

    gruvin Member

    Joined:
    Feb 20, 2006
    Messages:
    12
    Likes Received:
    0
    Trophy Points:
    1
    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.
     
Loading...

Share This Page