BFM, CSF/LFD - quicker/tighter ip-blocking rules on failed Wordpress-logins

BBM

BBM

Verified User
Joined
Jun 8, 2013
Messages
394
Location
Dutch Mountains
Currently I've got BFM blocking ip's that still manage to hit a Wordpress-website with 20, 40 or even more failed brute force attempts.
I want to limit resources spent on these password-guessers and would like to block the IP of anyone who fails to do a correct login on any WP-site on my VPS, after say 3 failed attempts.

Is this at all possible with CSF/LFD or customscripts for instance?

I've already added .htaccess files in most wp-admin directories that I control to limit login-attemps, but I don't have control over all the wordpress-websites.

I don't really want to install additional plugins in all the Wordpress-sites, as the work involved when it comes to updating these sites and plugins only becomes more and more.
 
Yes, I have that working, but while it does seem to work to a point, IMO it still is 'time-based' because of the periodical reading of the log-files.
A hacker can do many login-attempts in just 1, let alone 10 minutes.

BTW, the variable "brute_force_apache_log_list_update_interval=10" was not present in the DA-conf and had to be added manually.
I put it at 5 minutes, but I would think a realtime logscanner would be needed to block login-attempts in progress.

These are my settings;
Code: 
brute_force_apache_log_list_update_interval=5
brute_force_log_scanner=1
brute_force_scan_apache_logs=1
brute_force_time_limit=3600
brutecount=5
bruteforce=1
 
Although it might fill up your csf blacklist very fast, you might consider certain WP plugins to prevent attacks or allow ip-based access via .htaccess files. However if it's for your customers, you can't do much with that advise.

You can however use custom CSF regexp for this. Have a look at this thread:
http://forum.configserver.com/viewtopic.php?t=8886

From that thread there is a link to another thread which I did not read yet, but there is also an easy solution at the bottom of this thread, you could easily implement that in your CSF.
 
Hello,

To limit access to wp-login.php serverwide you can use:

1. Apache basic auth
Is very simple to get started with. Every user will be prompted to pass through username/password authorization before they will be allowed to view actual wp-login.php script.

2. (re)Catcha.
The same idea as with Apache basic auth, but instead of login form an user will be suggested to validate through a captcha. If to use Google's reCaptcha, the most server load will come on Google's servers. In order to utilize this solution, you will require additional knowledge and skills to write a script.

If you need help with any of the two feel free to contact me for a quote. The both are very familiar to me, and we've got them on servers under maintenance.
 
Richard G said:
Although it might fill up your csf blacklist very fast, you might consider certain WP plugins to prevent attacks or allow ip-based access via .htaccess files. However if it's for your customers, you can't do much with that advise.

You can however use custom CSF regexp for this. Have a look at this thread:
http://forum.configserver.com/viewtopic.php?t=8886
Click to expand...

For 95% of the websites running on my vps I'm pretty much the only one that maintains the Wordpress software updates. Also a lot of Wordpress sites are fairly static, so the .htaccess "Deny from all, except my IP" works fine here for most of them.
There are a few sites where the owner needs access to Wordpress at times.

Just so happens I found that topic on ConfigServer.com last week and implimented this friday.
Although at first I had CSF looking at the wrong logfiles and fixed that on saturday. Seems to have helped quite a bit as I'm only seeing 'single' attempts at wp-login.php in the logs.
No more 20 or more attempts in a row.

I also found a lot of BruteForce attempts directed at Wordpress' xmlrpc.php-file.
As a test, I've blocked access to any xmlrpc.php-file through httpd.conf

Today I've only had 1 BFM blockwarning, and that was an IP trying to gain access to an emailaccount.
So I think for now things are fine.
 
As a test, I've blocked access to any xmlrpc.php-file through httpd.conf
Click to expand...
I'm having the same issue with those attacks. It should be fixed in newer versions according to WP but still attacks go on.
Can you tell me how you fixed this in httpd.conf?
 
I found this very crude 'tip' online where to simply block anything accessing xmlrpc.php by putting a rule into httpd.conf;

Code: 
<FilesMatch "^(xmlrpc\.php)">
Order Deny,Allow
Deny from all
</FilesMatch>

or add the trackback.php-file as well;

Code: 
<FilesMatch "^(xmlrpc\.php|wp-trackback\.php)">
Order Deny,Allow
Deny from all
</FilesMatch>


I don't think I would to do this on a server where more clients do their own Wordpress-stuff and could depend on the functions that xmlrpc.php might provide.
 
Thanks for sharing!

As far as I understood, xmlrpc.php is only for iOS Apps and pingback and trackback's.
I think Wordpress should make a better solution. Attacking is not the issue, but it is when it can eat up apache resources.
Didn't have much of those after some forced WP updates on clients accounts, so I keep this solution as a backup if it happens again.
Thank you!
 
About the wp-login-attacks, although there are not as much attempts as before, I'm still getting a few persistent attackers coming through it seems at times;

Code: 
IP 2002:45c5:a9ce:0:0:0:45c5:a9ce has 201 failed login attempts: wordpress1=201
IP 69.197.169.202 has 363 failed login attempts: wordpress1=363

I might be looking into hardening the wordpress-installs a bit more it seems.
 
You must log in or register to reply here.
Back
Top