Mod Security blocking wordpress

10 Views

I have a wordpress site with Modsecurity and apache. When I try to access wordpress it throws a 403 Forbidden error. Neither the admin panel nor the frontend is accessible. Here are the logs: 

[Tue Mar 18 08:17:41 2014] [error] [client 122.170.1.216] ModSecurity: Access denied with code 403 (phase 4). Pattern match "^5\\d{2}$" at RESPONSE_STATUS. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_50_outbound.conf"] [line "53"] [id "970901"] [rev "2"] [msg "The application is not available"] [data "Matched Data: 500 found within RESPONSE_STATUS: 500"] [severity "ERROR"] [ver "OWASP_CRS/2.2.6"] [maturity "9"] [accuracy "9"] [tag "WASCTC/WASC-13"] [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.6"] [hostname "www.bullion.ambab.com"] [uri "/research/wp-admin/index.php"] [unique_id "UygBJQoLkgUAABXkL-8AAAAX"]
[Tue Mar 18 08:17:41 2014] [error] [client 122.170.1.216] ModSecurity: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_60_correlation.conf"] [line "40"] [id "981205"] [msg "Outbound Anomaly Score Exceeded (score 4): The application is not available"] [hostname "www.bullion.ambab.com"] [uri "/research/wp-admin/index.php"] [unique_id "UygBJQoLkgUAABXkL-8AAAAX"]

This can be solved by disabling RuleByID 981205. But I do not want those rules to be bypassed because it might open a door for an attack.
Is there a way to solve this problem by modifying wordpress source?

Post Views: 10

Related posts

Leave a Reply

1 comment

  1. Modifying the WordPress sources is highly not recommended, because after update the modified files will be overwritten again.

    Better approach is to refine your mod_security rules by allowing some more requests to be sent to the WordPress system.

    ModSecurity (also known as “modsec”) has proven itself useful in a variety of situations, and again this is true in assisting with WordPress brute force attempts resulting in a Denial of Service (DoS) attack. While a number of WordPress plugins exist to prevent such attacks, custom modsec rules can prevent such attacks for all WordPress installations on a server. Modsec immediately filters incoming HTTP requests, which assists against taxing server resources.

    These rules will block access for the offending IP address for 5 minutes upon 10 failed login attempts over a 3 minute duration. These rules have been automatically updated in the custom rules for Liquid Web’s ServerSecure service. For customers without ServerSecure, these rules can be added to their custom modsec rules. To accomplish this, edit your custom modsec user rules and append the file with the rules provided below. For CPanel servers, this file is likely located at /usr/local/apache/conf/
    Below are the examples:

    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
 <Locationmatch "/wp-login.php">
 # Setup brute force detection.
 # React if block flag has been set.
 SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
 # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
 SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
 SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
 SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
 </Locationmatch>