A security experiment with Fail2Ban, Syslog and Honeypot

Every site has a lot of weekly / daily attempts to abuse your forms to submit their bad content, create users, login... Here we will try to ban some of those IPs directly in the server firewall, so they can't even reach Drupal.

At first, this method might not be applicable for you. If you have a professional hosting / PaaS, your provider could (should ?) already take care of this. At least globally, maybe not specifically for Drupal attacks. For this method, you must have be able to log on your server with a user that has admin rights. This post is especially written for Debian Buster, but it should be more or less the same for other Debian versions. For other distributions, you might have to tweak some things.

Then, as you will see in the conclusion, I tend to think that this method is not sustainable in the long term. This really has to be taken as an experiment.

I also want to mention that this blog post is heavily inspired by Integrate Honeypot with Fail2ban. Basically it was my starting point and I'm mostly complementing it here.

Step 1: Drupal configuration

Let's start on the Drupal side of things. You will need to enable the Syslog module (Core). Like the name suggests, this module will write the Drupal system logs into the linux syslog. In Debian, this log is /var/log/syslog. Now, among other logs, each time a login attempt fails, it will be recorded in the syslog.

Then, if you want you can also protect the login form with Honeypot as well. You can also protect other forms such as the user registration form and the global contact form. The important part is to be sure to have the option Log blocked form submissions checked on Honeypot configuration.

Step 2: Fail2Ban configuration on your server

Fail2Ban is available in the Debian repositories:

It's advised to never edit the Debian configuration files, so we will create only .local files. Let's start with the global jails configuration:

Replace 1.2.3.4 by your own IP(s) before anything else! Otherwise you could loose access to your remote server.

Then you can set global variables that will override the too low default values.

• findtime (in seconds) will parse the logs for the last specified seconds. Do not enter a huge value here because this could impact the server performance.
• bantime (in seconds) is the time for which the IPs will be banned. Don't hesitate here to have a big number. Here it's 1 year.
• maxretry is the number of times an attempt can be retried.

Now let's define a configuration for Drupal jails:

The first jail and filter, drupal-auth, already exists by default in Debian when installing Fail2Ban. However, I found that the regex was not working for me everytime. I still enabled it in the beginning. I added a custom version that works better, drupal-auth-custom, and I deactivated the first one. Finally I added 2 jails and filters with Honeypot.

Finally, we have to create the filters that we declared in those jails. The first filter also exists after Fail2Ban installation, so let's create the 3 others:

Notice that in /etc/fail2ban/filter.d/drupal-honeypot-auth.local, I had to use the french translation of the message because that's how Honeypot logs it for me. Also, you might have another form ID in /etc/fail2ban/filter.d/drupal-honeypot-contact.local

At last, restart the Fail2Ban service:

Testing it

Careful if you try to pretend to be a hacker to see if your configuration works, you could be banned from your own server! I would just recommend to wait a little bit for real cases.

See if the jails are all active (you should have 5 with the default sshd jail):

See the status of a jail and if it has banned IPs:

Test a jail filter:

One last word: when you test fail2ban-regex, if you find matches, those will not be banned. Same thing when you restart the server: already processed logs will not be taken into account. One would have to reset Fail2Ban's database or do other hacky things but it's not really worth it. After all, you've lived with those unbanned IPs for a while now, right ?

Results after 48 hours

After 48 hours I have:

• 3 IPs banned by drupal-auth
• 9 IPs banned by drupal-auth-custom which include the 3 above. That's why I deactivated drupal-auth and use only the custom version.
• 0 IPs banned by drupal-honeypot-auth (I will have to check that it works).
• 10 IPs banned by drupal-honeypot-contact

So a total of 19 IPs and they are all different.

Conclusion

For now I'm happy with this method but it should not be sustainable in the long term. With already 19 different IPs in 48 hours, if it goes on at the same rate for 1 year I will have around 3500 Iptables rules. This without counting the bans with the standard sshd jail. This should slow down too much my server.

Most importantly, I'm only banning on the basis of 3 Drupal specific rules, which miss the huge part of other attack attempts.

I'll keep the experiment going on for some time, just to see. In the end, I think that it might not be worth the effort. Configuring a more robust system would probably imply to use IPset which can handle large amounts of IPs. Also, it might be interesting to import or sync IP blacklists collected by a service and to contribute to this service data with your Fail2Ban. At this point, work is starting to add up and either you are really passionate about this, or you just take a very good hosting provider.

Update 2020-08-25: now 258 banned IPs for drupal-honeypot-contact, 199 for drupal-auth-custom and the rest is negligible. I've set up 1 year bans. Seems pretty much sustainable form my website, finally.