{"id":2596,"date":"2013-05-23T14:44:39","date_gmt":"2013-05-23T13:44:39","guid":{"rendered":"http:\/\/blog.ed.gs\/?p=2596"},"modified":"2013-05-23T14:44:39","modified_gmt":"2013-05-23T13:44:39","slug":"wordpress-brute-force-protection-hack","status":"publish","type":"post","link":"https:\/\/ed.gs\/2013\/05\/23\/wordpress-brute-force-protection-hack\/","title":{"rendered":"WordPress Brute Force Protection Hack"},"content":{"rendered":"
The current “WordPress Brute Force Attack” has been targeting a lot of our blogs on PrimaryBlogger<\/a>. We have nearly 10,000 blogs, so you can imagine how many requests we’re getting for wp-login.php. For some reason the attacks seem to be more prolific in the 7am-11am GMT time period. We’d been woken up on numerous mornings now over the previous weeks and were getting quite annoyed with it, so we decided to look into permanently protecting ourselves from brute force attacks.<\/p>\n The main signature of the attack is a POST request to wp-login.php with the usernames admin, adminadmin and administrator. We don’t allow any of those usernames on PrimaryBlogger<\/a>, so initially we used Fail2Ban<\/a> to block any requests coming from those usernames.<\/p>\n This worked for a short time, but it still allowed the users to load the entire WordPress instance until they’re blocked by iptables. That meant if we had 10,000 Fail2Ban<\/a> blocked users in iptables and we blocked after two attempts, then it’s loaded at least 20,000 instances of the page. The wp-login page would directly hit our Nginx\/PHP-FPM stack on each request too, blocking other users in the mean time. On one occasion the load of one of our servers was at 130, quite high to say we usually run around 0.5. <\/p>\nSo, what next?<\/h2>\n