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.

mod_security how to trigger error page (custom rule for xmlrpc.php attack)

Discussion in 'Security' started by oempire, Sep 6, 2014.

  1. oempire

    oempire Registered

    Joined:
    Sep 6, 2014
    Messages:
    4
    Likes Received:
    1
    Trophy Points:
    3
    cPanel Access Level:
    Root Administrator
    Hi,

    Today i noticed alot of traffic to several sites - Apache status showed

    POST /xmlrpc.php HTTP/1.0

    so it was obviously part of or the target of some WP botnet using the XML RPC request.

    i thought id block this easily at the server level with mod_security and the rules below

    SecRule REQUEST_FILENAME "^/xmlrpc.php" "deny,log,auditlog,status:403,msg:'xmlrpc TOM FOOLERY',id:'1337',severity:'2'"

    SecRule REQUEST_URI "xmlrpc*" "deny,log,auditlog,status:403,msg:'xmlrpc TOM FOOLERY',id:'1338',severity:'2'"


    However i found that even though mod_security would log the request, (and CSF would block it after 5 times) it wasn't generating a 403 error page or even 500 error page when i changed the status to 500.

    It would just seem to trigger a 404 in the customers CMS both on wordpress (where the xmlrpc.php exists) and another where its not wordpress and (doesn't actually contain a xmlrpc.php).

    Id prefer it to not load the CMS 404 page, and use the default 403 page, that is text only and loads minimal resources.

    I found If I then created a 403.html through cpanels custom error pages, it wouldn't show the customers 404 page it would correctly show the custom 403 page. however id rather use the default page and not a custom one as i would have to add this page to every customers account.

    Is this possible? i thought mod security in the past was able to intercept before the customers CMS and send its internal server error or 403?
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,787
    Likes Received:
    665
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
  3. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    941
    Likes Received:
    56
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Usually what I do is set an odd status like status:411 in the rule.

    Many times CMS custom 404 still hijacks that causing load rendering the php 404 pages. What's happening is ModSecurity is intercepting it, but when it goes to give the 403 page for the status you set, it can't find it so a 404 is also triggered, and the CMS then runs from there with 404 handling.

    In this case I add this to the sites .htaccess (or even /home/.htaccess for all sites):
    Code:
    ErrorDocument 411 default 
    #(or 403 in your case)
    ErrorDocument 403 default 
    
    You could also do a custom errordoc relative to the docroot as outlined in the apache manual for "errordocument"

    Basically if you use a status action for a modsec rule, you have to make sure the errordocument exists for the status code you're returning, otherwise a 404 will also be triggered.
     
    #3 quizknows, Sep 8, 2014
    Last edited: Sep 8, 2014
  4. oempire

    oempire Registered

    Joined:
    Sep 6, 2014
    Messages:
    4
    Likes Received:
    1
    Trophy Points:
    3
    cPanel Access Level:
    Root Administrator
    thanks for the info mate.

    Im hoping for a way to intercept it before it even gets to the customers CMS.

    Ive had customers call in in the past where a rule has resulted in them getting an internal server error, until i white listed the rule in question. It just presented that really basic text only internal server error page - that way it uses nearly no resources.

    hmm

    - - - Updated - - -

    ok re-read your post i added that to the /home/.htacess and its working sweet across all sites :)
     
Loading...

Share This Page