I have finally set up a server with Debian Stretch rather than Jessie. The main 'you have to change everything' was around the move from PHP5 to PHP7. I still want to use the -fpm version of PHP because you don't need to load an entire PHP interpreter to serve JPEGs. I still want to stop bots trying to bruteforce WordPress logins. * Before (Jessie): Apache calls php-fpm via the fastcgi module in /etc/apache2/sites-available/example.com.conf - <IfModule mod_fastcgi.c> AddType application/x-httpd-fastphp5 .php Action application/x-httpd-fastphp5 /php5-fcgi Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi_examplesite FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi_examplesite -socket /var/run/php5-fpm_exampleuser.sock -pass-header Authorization </IfModule> and restricts access to wp-login.php in the site's .htaccess file - <Files "wp-login.php"> AuthName "Message that Firefox shows but Chromium no longer does!" AuthType Basic AuthUserFile /home/exampleuser/.htpasswd Require valid-user </Files> .. and it works! Anyone going to example.com/wp-login.php gets asked for a username and password by Apache before it will run it. * After (Stretch): Because of the changes between the two, Apache now calls php-fpm via the proxy-fcgi module in /etc/apache2/sites-available/example.com.conf - ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/php7.0-fpm_exampleuser.sock|fcgi://localhost/home/exampleuser/public_html/ and with the same .htaccess file, it *doesn't* trigger on access to wp-login.php because it's a .php file, ProxyPass gets there first and just runs it without checking anywhere else if it should. The method used on Jessie isn't particularly great, but because the enemy is dumb bots, it doesn't have to be! For the past few years, it's worked to dramatically reduce the impact of the endless attempts to bruteforce access to anything running WordPress - unlike the plugins that do something about the appalling security of a standard WordPress installation* it didn't need to run PHP or touch the database at all. I do also have fail2ban watching wp-login.php and blocking anyone who hammers it, but the next time there's a WordPress bot storm, it will affect the server because of all the PHP and database access. Any suggestions? I don't want to have to rename or move wp-login.php and I don't want to have compile PHP5.4 from source either... Ian * "Allowing infinite attempts to login without blocking the IP address after so many failures or even notifying the site's owner? What could /possibly/ be the problem with that?? In fact, let's make it even easier by allowing hundreds of attempts to be made at once!!!"