I’m looking after a full roots stack server, and its periodically being bombarded with bruteforce attempts on the wp-login page.
I was wondering how others have been mitigating this. Do people go with a plugin solution or perhaps with fail2ban?
fail2ban would probably be a good bet, but I have no idea how to configure it with ansible roles rather than directly. The plugin WP fail2ban contains a config file I can use, but I need to figure out how to include that jail and add a fail2ban service to the existing ssh one without breaking everything!
Thanks @strarsis, the thing is that I’m reasonably comfortable with the security of the login form - we use complex passwords and have a reCAPTCHA on that form.
The thing that is bothering me most is that when attacks happen we get this sort of thing:
There is a corresponding spike in CPU and these requests come from the same group of IPs repeatedly for a few hours at a time.
It just seems like fail2ban would be a better suited tool to recognise repeated bad login attempts and block those IPs at a firewall level.
I’m going to dig into this further and will report back with any findings. Any guidance is more than welcome!
Trellis does install Fail2ban. /trellis/roles/fail2ban
Maybe it is only a question of adapting the config files / adding a config file? /trellis/roles/fail2ban/templates
I do not know Fail2ban precisely, but I think this would be the starting point.
Thanks @Dinghy, I got as far as trying to figure out how to automate adding a custom filter to /etc/fail2ban/filter.d/ at deployment.
I’m thinking of using a filter from the WP fail2ban plugin, but it still applies if I were to write my own.
As far as I can see, it doesn’t look like I can add the filter through the fail2ban role, so does anyone know of an appropriate place within the Trellis setup to run some sort of copy command or at least shell script to copy the file over so that fail2ban can use it?
It has a wealth of security and firewall rules and they can be customized. You might need the $20 month plan to unlock some of the better features though.
Two other reason I prefer Cloudflare for.security. One is that brute force attacks are all Wordpress hits. Even with a plugin it’s still a Wordpress hit. Every hit on the server adds to the apache queue. An overloaded queue will result in 50x errors to visitors and admins. By having Cloudflare field the hits Wordpress is protected.
In addition, our host charges by the humber of hits. Too many hits and we jump up a pricing tier. So Cloudflare also saves us hosting fees.
