Portal Home > Knowledgebase > Articles Database > Server Level security against WordPress Brute Force Attacks


Server Level security against WordPress Brute Force Attacks




Posted by IT Tech, 08-25-2014, 02:51 PM
It seems that new WordPress sites are a hot target for hackers. I started noticing this about 18 months ago on an established website. I recently started a new WordPress site on a new host and within a day I began experiencing BFA attempts. Someone seemed to be pretty experienced and found out the non standard admin user ID that I used. I wasn't compromised but realized how vulnerable newbies could be. I'm using a plugin for protection but I guess the good providers offer some sort of server level protection. What is that protection? Some sort of mod_security? Evidently this is not standard with all providers? Anyone care to offer some insight on this? Thanks.

Posted by nixtree, 08-25-2014, 03:09 PM
Yes, there are mod_sec rule sets you can enable to alleviate WP bute force attacks. For eg: a sample solution is posted at http://kb.liquidweb.com/wordpress-modsecurity-rules/

Posted by IT Tech, 08-25-2014, 03:44 PM
That basically explains it, an application firewall. Without doing a BFA or asking the host is there a way to determine if they use mod-sec?

Posted by nixtree, 08-25-2014, 03:59 PM
No, asking your server admin/support is your best bet.

Posted by huck, 08-25-2014, 04:22 PM
Actually, enumerating users, plugins and themes on WP is trivial and requires little more expertise than installing any number of exploit scanning tools. So while changing your admin user is good, most brute force kits will enumerate your users before starting the attack. WP security basically boils down to trying to mitigate zero day attacks while keeping your site updated. To do this, I recommend a 4 point approach: Stay Informed Services like ManageWP.com keep tabs on updates for plugins and other items. InfiniteWP does something similar. Keeping your site up to date is critical for security. Block Malicious Requests To do this, you need a web app firewall. Mod Security, Incapsula, Cloudflare, and others provide this type of service. Basically you want to block malicious or suspect traffic before it hits your site. This can help protect you against common exploit techniques and allow trapping of zero-day exploits prior to updates being released. Malware Scanning Sucuri and others can scan your site for malware. While this is reactive, it can alert you to a security incident and hopefully limit the damage. Backups Maintain and monitor backups at a frequency that makes sense for your site. If your site is not very active, daily backups may be sufficient. If you post frequently, then hourly backups may be needed. You will want to keep some archives in case your monitoring or scanning misses something. Rolling back to known good code or comparing current files to backups is about the only way to be safe when cleaning up an exploited site. One last bonus tip -- if you are frequently changing your WP site, then use version control. Version control can be a great way to spot modified files after an attack and quickly revert them. There's a bunch of stuff you can do at the command line - like blocking PHP execution in upload directories, using http auth, etc -- that can help, but ultimately, you need to use a layered approach and put in place people and policies to keep things secure.

Posted by Kihi, 08-25-2014, 05:12 PM
Use a non-standard username. Only allow logins to /wp-login.php from particular IPs. Add iptables rules & fail2ban.

Posted by critihost, 08-25-2014, 05:32 PM
Mod-security, keep updates current and have a good password. If your password is good enough and you change it every once and a while the odds of a BFA cracking into your site are so so low. The majority of wordpress hacks come from three things: outdated install, plugins and a poor password.

Posted by IT Tech, 08-25-2014, 08:57 PM
I found that tactic far too restrictive, since sometimes I need access from different locations. If you really want to be secure then install a plugin with a 2 factor login authentication process. For many people 2 factor authentication is inconvenient especially when you want to login to make quick changes, though it is very secure.

Posted by IT Tech, 08-25-2014, 09:12 PM
In about 18 months of monitoring my sites I've never came across someone who tried a BFA with a user ID other than admin, until this last one. Also, the plugin that I'm using doesn't list any IP address for that hacker which at least to me, the person seems a little more advanced. I'm sure that if I investigated further I could track them down but I don't really have the time for that. Also no harm was done yet. Hopefully none will be done. Thanks for your quick guide!

Posted by khunj, 08-26-2014, 11:36 AM
It will only take a few minutes to get the list of all users. If you look at WordPress SVN repo, you will be amazed to see how many security plugins will rely on the user 'HTTP_X_FORWARDED_FOR', 'HTTP_CLIENT_IP' if they exist rather than the 'REMOTE_ADDR' variable (the only reliable IP). Hackers know about that

Posted by VaultnetworksSFL, 08-26-2014, 11:43 AM
I agree, it's better to not do guess work in this case.

Posted by damoncloudflare, 08-26-2014, 06:09 PM
What is that protection? Some sort of mod_security? Evidently this is not standard with all providers? Anyone care to offer some insight on this? Thanks." I've heard good things about BruteProtect (plugin recently acquired by Automattic) and Clef (getclef.com) about protecting against Brute Force attacks. A good Web Application Firewall would also probably help as well.

Posted by LivingTheDream, 09-18-2014, 08:40 AM
There's a long debate (23 pages and counting ) on this on this thread http://www.webhostingtalk.com/showth...ss+brute+force (this post contains some mod sec rules) http://www.webhostingtalk.com/showpo...&postcount=315 Brute Protect plugin is highly recommended, however, it appears it will soon no longer be a standalone product unfortunately will be in Jetpack.

Posted by FRH Lisa, 09-18-2014, 12:44 PM
I thought the mod_sec rules had stopped working due to the way WordPress returns successful / failed logons. Adding multi-factor and additional prompts is nice, as it will stop a successful attack dead in its tracks. The issue for us is the server resources that attacks consume. When you repeatedly nail wp-login.php as fast as possible, it drives up CPU usage. Even with tools like CloudLinux, this can quickly consume an entire server. Plugins like WordFence can help, but that's still an application-side solution, and needs to be manually installed on each WP installation. The root issue is that WordPress's security is weak. Until they move their wp-admin URL and implement even the most basic brute-force protection, this will continue to be an issue.

Posted by K&T Host - Tim, 09-18-2014, 01:42 PM
We have had success using Nginx as a reverse proxy for this type of issue. One part of the solution is to rate limit the amount of traffic that can go to the login pages at once. For example, limiting requests to wp-login.php down to one request per second slows down the brute force attack. It also keeps most of the resource usage away from the back-end application. If you can do something similar to this, it might help. #Nginx.conf #Request Limiting limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; limit_req_status 444; #Put this bit in your website definition file. #Set request limit to 1 per second on wp-login.php page for WordPress location /wp-login.php { limit_req zone=one burst=5; proxy_pass h ttp://yourbackendserver; proxy_redirect off; } location ~ ^/(wp-config\.php) { deny all; }

Posted by LivingTheDream, 09-18-2014, 08:20 PM
I have had great success in using mod sec rules. The only issue I encounter is how to prevent legit users from getting blocked. It is a pain trying to get a user's IP address to then unblock it. Most legit users who get blocked don't even know why / care and probably this results in lost business. The best solution would be if WordPress could implement a rate limiter / DDOS trap on the login page.... but don't hold your breathe. I have tried many plugins and they are all useless as a large attack quickly overwhelms the server resources, even with Cloud Linux engaged. However, that said, I did find Brute Protect to be very good - the problem is it seems it will soon be discontinued as a standlone plugin which is a pity. I have also used the Limit Login Attempts plugin, however, this is now quite old and it is uncertain if it is being updated. Personally, I feel much happier targeting this issue at the server level and not relying on plugins.

Posted by nixtree, 09-19-2014, 09:09 AM
We have added the option to alleviate wordpress/Joomla brute-force attacks via mod_sec ( + CSF or iptables to block source IP address ) in recent version of our exploit scanner ntServerGuard. So far it is working good for us. Though we received few clients blocked on some shared servers, they were actually crossed failed login threshold in the specific period; so it is expected.

Posted by FRH Lisa, 10-10-2014, 05:47 PM
Agreed. Thus far, however, the general response from WordPress has been that it's Somebody Else's Problem. After all, it's your host's fault if your site is being attacked. WordFence does a decent job, but we're seeing attackers rapidly cycling through forged IP addresses smartly. Fire off logon attempts from an IP twice, cycle to unused IP, try again twice ... wash, rinse, repeat. What's hilarious is that there's one simple and highly effective way to stop these attacks: randomizing the name of /wp-admin or wp-login.php. It's been brought up a few times in their forums, but the responses have been fairly silly and dismissive (I think at least one user said something like "the hackers will just guess at the URL instead so this doesn't help at all").



Was this answer helpful?

Add to Favourites Add to Favourites    Print this Article Print this Article

Also Read
WAMP server suggestion (Views: 613)