Comment on Beware New WordPress Security Theat: The WordPress Misinformation Virus by Neil Beattie.
Hi Mike, sorry haven’t been here for a while and just thought I would catchup with latest comments. You are getting a very common brute force login, noting that they are not even bothering to provide a referer to the POST.
A simple .htaccess rule can block these (check if path is wp-login, check if has referer, return a 403/404 if not), although some attackers do use refers so this rule does not work for them.
The problem with these attacks is that because they pass through the WP framework and any security plugins, they can cause extreme server loading. In fact, I did some tests on a colleagues server comparing various security plugins that they use and nearly all the sites with security plugins had higher loadings than the sites without plugins, even if the wp-login.php was renamed and didn’t exist.
The problem was particularly bad with attacks that sent multiple requests at the same time. I’m not sure if WordPress Simple Security was one of the installed plugins, but WordFence was and that was by far the worst loading from an attack.
That is why we decided against using plugins; it was essential for us that no request would even get to the site framework. Some plugins are very active on stopping brute force logins, but with secure passwords the login wouldn’t ever succeed anyway. For us, it was more important to reduce the server loading with these brute force attempts, so our firewall rules use various mechanisms to stop the login request before it even hits WP.
Interestingly, what we’ve found is that by robustly blocking these brute force attempts, including intelligent throttling & rate limiting, over time we get significantly less attacks. Our servers are just not very tempting for attackers to go for. On colleague servers without our firewall but which do have WP security plugins, the attacks continuously occur often with many an hour every hour and at times their server loadings are significant even from just a single site attack.
We are considering releasing our SiteSentinel firewall to market. It is a more complex product to install than a plugin, although once running there is almost zero management required and no site changes are required.
I do still recommend plugins like WordPress Simple Security, they can provide useful framework level security, but I believe they should be fronted by a server level firewall, be that on the server itself or through a CDN or similar.
Neil Beattie Also Commented
Beware New WordPress Security Theat: The WordPress Misinformation Virus
I have myself over designed & coded a web application firewall. It is not a WordPress plugin; it is server level and protects any sort of PHP web site using a framework aware rule based system. It does not use blacklisting and I agree that shared distributed IP address blacklists are not good; at least in my own experience.
My firewall blocks based on its own experience of remote systems making undesirable requests. Being server level, it shares knowledge between sites. A block on one site can instantly block to all sites on the same server (even multiple servers), either temporarily or permanently. We often see attackers try a combination of apparently innocuous things such as probes, as well as clearly malicious things. By blocking sooner, we potentially stop them being successful with an infiltration that we might not have otherwise detected, maybe because we have not seen such an attack before. The only unique bit of information that can achieve that with is the IP address.
After millions of requests on multiple servers with a huge variety of site frameworks (WordPress, Magento, Drupal, Joomla, Larvel, Yii, Symfony, etc), it works very well. Our server loading has dropped considerably, from our logs we know that we are not incorrectly blocking anyone.
Blocking by IP address also does not have to be slow if it is done in a way that leverages database & memory caching technologies. With some task off-loading it is possible to build a profile of ‘bad’ IP addresses, such as those from bad crawlers.
Currently our servers check most requests within 10ms including processing all the rules and complete with database persistence & logging.
Blocking by IP address for at least a period of time is extremely beneficial. Many of the attackers & bad crawlers we see *are* repeat offenders from the same IP addresses, rarely using proxy services, and often repeating over many months. Over a period of a few hours we will often see the same remote IP address repetitively try the same attack on the same (yes, same attack and same site!) and on multiple sites, but we already blocked them with their initial requests on first site. Then later on they often try a different attack but they are still blocked.
Within that 10ms we also do some blocking using GeoIP and our logs contain the data to prove it is useful. Sure, some sites can leverage GeoIP blocking better than others. We block China from most sites because of the huge crawling activity from there, but we do allow China to access some sites that want that.
We stop blocked requests getting to the framework, so we find a huge reduction in loading by blocking requests earlier. Previously when using security plugins we still had heavy loading from the framework run-up. We no longer see any loading from brute force attacks and have to check our firewall logs to spot them. Our firewall will catch *any* PHP request before it gets to any script execution within the site, which is a failing of most if not all security plugins.
I do think security plugins such as WordPress Simple Firewall provide very useful features and I encourage WordPress site owners to install a good plugin, but site owners shouldn’t be fooled into thinking a framework specific firewall plugin is capable of blocking all possible attacks, because that is not the case.
