14 Apr
2018
14 Apr
'18
8:37 p.m.
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!!!"