Has anyone tried to fail2ban wordpress

I recently came across a few tutorials about using fail2ban to protect WordPress login from forced attacks.

One of the tutorials.
https://graspingtech.com/using-fail2ban-protect-wordpress-blog-brute-force-attacks/

I am wondering if anyone here has had experience of using fail2ban to protect WordPress?

There is a plugin but that would take resources and using it directly would save resources instead of having another plugin to load.

1 Like

Not really tried, usualy I install wordfence on top of wordpress. But you can try it out, hestia installs the “default” stack of fail2ban, there is nothing special so the tutorial should work aswell.

2 Likes

I am trying different things but I am still not satisfied with the outcomes. I have not had the time though.

To configure the jails, the logfiles are:

/var/log/apache2/domains/*.log
/var/log/nginx/domains/*.log

Filter example:
[Definition]
failregex = ^<HOST> .* "POST .*wp-login.php
^<HOST> .* "POST .*xmlrpc.php
ignoreregex =

You can find a more comprehensive filter here:

There is also one filter that I am trying: Ban bots and DDOS

This jail needs to be adapted to look into the nginx logs.
Jail:

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/apache*/*access.log
maxretry = 300
findtime = 300
bantime = 600
action = iptables[name=HTTP, port=http, protocol=tcp]

Filter: http-get-dos.conf
Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.
You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.

[Definition]
failregex = ^<HOST> -.*(GET|POST|HEAD).*
#ignoreregex = ^<HOST> -.*"GET.*HTTP.*Googlebot/2\.1.*"$
ignoreregex =

Set up multiple recidive rules in cascade
https://www.burlutsky.su/security/fail2ban-re-ban-hackers/

1 Like

Thanks guys, will have a look at it on the test server when I get a chance (probably next week sometime).

I have jetpack on top of wordpress at the moment but would rather look into other options.

I will let you know the results.

UPdate

made a filter:

[Definition]
failregex = ^<HOST> .* "POST .*wp-login.php HTTP.* 200

ignoreregex =

in jail.local

[wordpress]
enabled = true
port = http,https
filter = wordpress
action = iptables-multiport[name=wordpress, port="http,https", protocol=tcp]
logpath = /var/log/apache2/domains/*.log
maxretry = 5
findtime = 300
bantime = 300

Seems to work ok…
Should save resources from having to have yet another plugin.

if your cleaver you could do something like this to redirect to another server to say why there blocked.

Maybe you should have fail2ban look also into the nginx logs.

The log is empty that’s why I didn’t do it, all the domains in domain directory are mail.(domain).com and the email is already setup.

If nginx + apache2 is used only /var/log/apache2 is used.

1 Like

Awesome thank you…
Didn’t know that…

You might be better off using one of the WP plugin firewalls, which are quite configurable. Ninja firewall and All In One Security seem OK. Depends what you’re after really.

And there’s the htaccess-based one which is also interesting.
https://perishablepress.com/7g-firewall/

I already have alias of plugin’s installed and am looking at ways to avoid more of them.

I am quite happy the way it works with fail2ban at the moment, it works so that’s good enough for now …
Thank you for the info.

Next to stop all SSH apart from my IP since I am the only one that is going to use it

@pluto for the fail2ban wp. I would avoid plugins as much as I can that’s why this solution is best. PHP is inherently inefficient, and therefore I will avoid it and plugins are not executed if the web is cached so… when nginx is serving cached versions of the web, the attacks will not be stopped.

EDIT: I have read the plugin’s documentation and this one doesn’t consume CPU since it blocks traffic with apache2 .htaccess and nginx directives.

If you have several domains under the same machine, the fail2ban approach will ban offending IPs for all domains at once.

@liamgibbins to protect SSH you may:

  • If you have a static IP address you may make a firewall rule to allow only connections from that IP
  • Otherwise, add an IPset rule only to allow SSH connections from your country.
  • Have 1 server with open SSH and connect the rest of your servers from that machine only so that you have only one machine exposed.
  • Put 0 retries on fail2ban with very long ban periods and have a whitelisting mechanism in fail2ban such as the dovecot whitelist I suggested for hestia.
  • Disallow root login and change SSH port
  • Don’t use passwords. Use keyfiles instead.
  • Disallow root login and change SSH port
  • Don’t use passwords. Use keyfiles instead.

And you have most of the noise.

Please note that Hestia uses ssh connection for filemanager and as the default sftp method…

Personally I would prefer let connect clients to sftp then ftp as it is more secure. SSH isn’t evil / bad it is just more secure. The only thing it can be more easily abused for evil things…

I totally agree with your statement, I don’t understand what people get out of hacking a server I really don’t…

I intend on ignoring my static IP and 127.0.0.1 on SSH the rest can just be blocked.

I don’t use the file manager as I just get errors so that’s turned off.

I would also stay away from banning with a negative number or with 0 as it can get resource intensive, I am planning on chaining jail’s so the ban time increases, this will keep the search of the logfiles to a minimum, when the maximum ban time is reached to fire me an email then I will manually ban that ip in the firewall, I don’t mind doing it this way.

This is a fair point. And I also agree that the extra processing power required for plugins might not be acceptable to everyone, although as you noticed the .htaccess one quite cleverly avoids that.

I guess what I was saying with my plugins post is that different approaches will suit different people. If you don’t want to spend the time writing regexes for your fail2ban rules, then there are plugins which have done the work for you. I guess I could also mention mod_security! Each to their own!

This is why I like Hestia. You use it as a base to modify to your taste.

If we could as a community reach an agreement on which jails and filters would be good to have, maybe those regex would be incorporated into Hestia.

Don’t know if there I a method in f2b if you can load additional configuration rules by just create an file and reload it will load extra rules it will allow creation of extra rules and don’t load every rule on default if you don’t use such rule it makes no sense

I think we should be able to integrate:

Drop down / List of filters:

  • Wordpress
  • Whitelist Dovecote
  • And continue and give users the option to enable disable configs on “demand”
2 Likes

We have several options here.

  1. copy wpf2b.conf to jail.d directory so it gets read by fail2ban
  2. just search and replace enabled and disabled switch in the same file
  3. have a bigger jail.local with all optional configurations disabled (this requires no interface and could be easily updated)

We could have the [DEFAULT] + ignorip in a different textbox and we could potentially repeat that config in the firewall rules so that people trying to whitelist their IPs understand that the way to go is to whitelist them in fail2ban.

As for the rules I would add

  • SSH ban login attempts with the user “root” (since it is frequent to ban logins from user root)
  • DOS attacks (jail to block IP if you get more than 300 http requests in 300 seconds +ignoreregex for googlebot)
  • Badbots
  • hestia login
  • roundcube login
  • Whitelisting
  • Wordpress and other cms
  • Common exploits
  • phpmyadmin
  • smtp
  • imap / pop
  • sftp
  • ssh
  • recidive rule

For wordpress and other CMS would it be better to do a redirect to a page on a different port that basically says “your banned for repeated login attempts, contact you system admin” rather than dropping the IP address and users having no idea what’s going on and thinking there site is down.

Or maybe giving the option as a radio button (one or the other). When they select WordPress etc.

Just a thought

The other option is to put it in the documentation so they have a how to if they want it or not