Stopping dictionary attacks on wp-login.php with a couple of lines of nginx configuration<\/h2>\n
One downside of using a popular content management system like WordPress is that many script kiddies like to perform automated attacks on it, looking for people who’ve chosen poor usernames and passwords to edit their content. Unfortunately, that sort of attack causes web servers to get very busy, using up power and generally slowing things down for people trying to do real work. One such attack is illustrated in the chart below, showing my server’s CPU activity over 24 hours from a week or two ago. The data came from sar’s standard logs.<\/p>\n
![\"A](\"http:\/\/davstott.me.uk\/wordpress\/wp-content\/uploads\/2014\/03\/cpuChart13-1024x526.png\")
<\/a>A chart of my server’s CPU activity, the % in use<\/p><\/div>\n
What could cause such a big plateau of busywork, I hear you ask? It turned out to be a couple of IP addresses with very dodgy DNS names blatting away at my wp-login.php several times a second for hours on end.<\/p>\n
I made this traffic go away with a couple of simple nginx configuration<\/a> directives that made the attacking script believe that my website had gone away after a handful of failed log in attempts. <\/p>\n It’s split into two sections, the first is to add this to nginx.conf\u00e2\u20ac\u2122s http{} section. This creates a bucket named \u00e2\u20ac\u02dcmyZone\u00e2\u20ac\u2122, with a rule that says any content locations mapped to that bucket should not average more than one request per second from a given remote IP address:<\/p>\n Adding this next stansa into your virtual host\u00e2\u20ac\u2122s server{} section (sorry for using the ~ operator, lazy Dav was lazy) maps any URLs containing the string \u00e2\u20ac\u02dcwp-login.php\u00e2\u20ac\u2122 into that bucket. The \u00e2\u20ac\u0153burst=3\u00e2\u20ac\u009d parameter allows me to retry a failed login a couple of times without locking me out of my own website, and consigning error logging to \/dev\/null means that I don\u00e2\u20ac\u2122t waste disk space or webstats on looking at the banned login requests, although there are some downsides to doing that :<\/p>\n Whilst this deflects a simple attack from a small number of IP addresses, it wouldn\u00e2\u20ac\u2122t help so much if my server was that target of a distributed attack from a large number of IP addresses. This is where cloud-based services such as Brute Protect<\/a> come into play, letting server administrators share data on failed login attempts into a coordinated pool to try to protect everybody. This plugin runs in PHP, so isn\u00e2\u20ac\u2122t as efficient as blocking the unwanted traffic in the web server or firewall, but it\u00e2\u20ac\u2122s still useful and doesn\u00e2\u20ac\u2122t take much time at all to set up.<\/p>\n If you haven\u00e2\u20ac\u2122t heard about op-code caches before, I recommend that you read EngineYard\u00e2\u20ac\u2122s excellent explanation of PHP Opcode Caches<\/a>, which includes any amount of detail.<\/p>\n From what I remember of @julienPauli<\/a>\u00e2\u20ac\u2122s excellent talk on OpCache internals<\/a> at this year<\/a>‘s PHP London conference<\/a>, the recently open-sourced opcache works wonders when using frameworks that compile a large number of classes that aren’t used all that often. Rather like my WordPress site.<\/p>\n Unlike APC, Opcache doesn\u00e2\u20ac\u2122t just cache the results of compiling your PHP code, it also includes some optimisations, such as replacing i++ with ++i to avoid having to allocate a temporary variable that is never referenced to store the results of the increment. Taken together, these optimisations become significant.<\/p>\n To look at the impact of upgrading to php5.5 and switching on opcache, I\u00e2\u20ac\u2122ve charted the difference in the time taken to draw the front page of my blog:<\/p>\n limit_req_zone $binary_remote_addr zone=myZone:2m rate=1r\/s;<\/code><\/p>\n location ~ wp-login.php {
\n \tlimit_req zone=myZone burst=3;
\n \tfastcgi_pass php;
\n \tinclude fastcgi_params;
\n \terror_log \/dev\/null;
\n }<\/code><\/p>\nUpgrade your PHP and use Zend\u00e2\u20ac\u2122s opcache<\/h2>\n