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

[oempire]

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?

 

[cPanelMichael]

Hello

Are you sure the CMS has not implemented custom error page rules in the .htaccess file for the account?

Thank you.

 

[quizknows]

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):

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.

 

[oempire]

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