WordPress 5.2: Mitigating Supply-Chain Attacks

Everything you put on the Internet gets daily attempted attacks. The issue is... nobody should care about attempted attacks. Of course people will try to bruteforce your passwords. If you have any kind of software that warns you about these attacking attempts that's not helpful at all. What you want is to make these attacks do nothing. In case of bruteforce attempts it's clear how to do that: don't use insecure or reused passwords.

When a Wordpress install has write access to its own PHP files, then a vulnerability can do more harm obviously since it can modify the Wordpress install itself and thus more easily "infect" the installation. Denying write access cuts off many attacks from doing significant harm. BTW WP-CLI can also do checksums of your install.

I wouldn't fret too much about seeing attempted hack attempts. If you have enough logging turned on for a public web server, you'll see a constant stream of hack attempts for all types of languages / frameworks. I did this the other day and saw what I recognized as a variety of different attacks targeted at PHP, Rails, and Java.

Regarding usernames: note that Wordpress will, by default, expose those usernames in things like posts (author's username is revealed). I had to modify my theme to make that stop, and even then I'm not 100% sure it's not leaking somewhere I missed. Maybe you want to do all content editing with a user that has reduced privileges and only use your admin user when necessary.

It's important to remember a large set of un-updated nodes will remain. Not that anyone can do much, but equally not that the entire surface of bad Wordpress will go away. I would be interested how big the long tail is. one third? more?

It is also worth thinking about the code signing problem firefox just had, and reflecting on the possibility of the hack in the head still taking place: either a denial-of-service or a bad code intrusion risk remains.

Its far far less likely, and it can be mitigated, but this is the reality of distributed systems: You can only do the best you can, nothing is guaranteed. (even TMR units fail)

The best thing to do after that is to set up an .htaccess rule to return a 401 Forbidden error for /wp-login.php, because even with the plugin above the request is processed by PHP, which can still slow things down depending on the intensity of the attack.

This is obviously just security through obscurity, and you need other security measures in place too. Having said that, I find plugins like WordFence are overkill and often confusing, although we build WP sites from scratch so we control a lot of that side of things ourselves, and use a WP-focused hosting service which takes care of the other things like server-level security.