Battling the bots

We found our clients getting attacked by bots trying to login. This was tedious, so we looked for ways to discourage these bots.

Our first attempt was to limit their access to our usernames. To accomplish this we added the following to our /server/tenseg.conf file in each available site (we should figure out how to not use the explicit URL):

if ($arg_author) {
  return 301 $scheme://ggp.tenseg.net;
}

This didn’t stop them from trying, though. So we also added the following to this main site’s /before/tenseg-limits.conf file. Note, we can only add this once, so we do not add it to any of the other available servers.

limit_req_zone $binary_remote_addr zone=WPLIMIT:10m rate=15r/m;
limit_req_status 429;

This creates an Nginx rate limit named WPLIMIT that allows sites to only access something 15 times per minute and uses 10MB of space holding the addresses of those making attempts. Once this limit is created we can add the following to each available server’s /server/tenseg.conf file:

location = /wp-login.php {
    limit_req zone=WPLIMIT burst=5 nodelay;
    include fastcgi.conf;
    fastcgi_pass unix:/run/php/php7.3-ggp.sock;
}

location = /xmlrpc.php {
    limit_req zone=WPLIMIT burst=5 nodelay;
    include fastcgi.conf;
    fastcgi_pass unix:/run/php/php7.3-ggp.sock;
}

Note the inclusion of the FastCGI stuff in these entries. Without this, the php file does not function as a PHP file at all. We learn the values to use in each site by checking the values used in that site’s sites-available configuration file.

The burst=5 nodelay on these limit_req settings ensures that the normal human login experience is still satisfactory. We have found that if a person is using a password manager they could well exceed the one-request-per-four-seconds (15r/m) rate just by having the password manager enter their credentials and one-time token. Allowing an undelayed burst makes regular logins flow smoothly.

After making these changes, the best way to restart Nginx is to use sudo nginx -s reload because this will report syntax errors and not actually restart the server if the configuration files are flawed.

In addition to this, we also learned to use ufw (the “uncomplicated firewall” that SpinupWP has included) to block certain bad actors.

sudo ufw insert 1 deny from 23.100.85.179 to any

This should block a site at a level below Nginx. We include insert 1 to make this the first rule, it has to come before we allow in web traffic. You can view all the settings with sudo ufw status numbered.

We’ll see how this goes.