2

I have an old rule for ModSecurity 1.x to block admin brute force attacks, and only allow them in the internal network.

When I migrated to 2.x, it stopped working. Also the networking ipmatch rules drive me insane, as they do not allow a /8 and only work for a /16 or greater.

I tried to adapt the rule to modsecurity 2, and I came to this:

SecRule REMOTE_HOST "!^10." "chain,id:'1',phase:2,t:none,block,nolog"
SecRule REQUEST_METHOD "@streq POST" "chain"
SecRule REQUEST_FILENAME "@pm /wp-login.php /wp-admin/ /administrator/ /admin/" "chain"
SecRule ARGS:log "@streq admin"

However it is not working. Some suggestion from someone more experienced in modsecurity?

3
+50

Why don't you use .htaccess? It should protect you against brute force attacks, and it's easely configurable.

We do use something like this, an .htaccess file located into the root of the website, containing the following:

## Hardening wp - doublelogin
AuthUserFile /path/to/your/.htpasswd
AuthName "Double Login antibot"
AuthType Basic
<Files "wp-login.php">
  require valid-user
</Files>

and an .htpasswd file, located anywhere you want on your local drive. You just need to specify the full path to the .htpasswd file with the AuthUserFile directive. Choose whatever you deem to be a sane location for your password file. Just make sure Apache has read access to it.

The .htpasswd contain the credentials. You can configure username and password by running:

## if it is the first user use -c param (it create new file / or wipe it if exists)
htpasswd -c /path/to/your/.htpasswd username
## if you want to add more users omit the -c param

In addition we also put the following rule into .htaccess to deny access to wp-config.php (which contains sensitive info eg.: the WordPress security keys and the WP database connection details)

<files wp-config.php>
  order deny,allow
  deny from all
  allow from 192.168.1.1/24 #(replace with your IP address)
</files>

and the following one, which Block WP xmlrpc.php requests which is one of the most common causes for exploits. (read here for more info)

<Files xmlrpc.php>
  order deny,allow
  deny from all
  allow from 192.168.1.1/24 #(replace with your LAN info)
</Files>

Sorry I can't directly help with your issue, if the above is not what you are looking for, I hope this link can give you some help : http://artefact.io/brute-force-protection-modsecurity/

  • The .htaccess answer is a much better solution for you than trying to set up mod_sec rules. On a typical shared hosting server, there are more than 50 distinct rules and still brutes will hit the login pages. – rcjohnson Nov 10 '15 at 16:50
  • Thanks for the thoughtful answer. We provide services for internal customers, and I am talking about a server with around 300 vhosts, so while for some more problematic sites I can very well use .htaccess, and will follow your recommendations, it is not feasible to automate the process as I might destroy the actual ones. My main problem with modsecurity is the difference of syntax from v1 to v2, used to have a global rule that enforce server-wide rules working well. Will check with more attention your link. – Rui F Ribeiro Nov 11 '15 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.