Input Hardening Plesk with AbuseIPDB

[iainh]

Server operating system version

AlmaLinux 9.7 (Moss Jungle Cat)

Plesk version and microupdate number

Plesk Obsidian 18.0.73 Update #5

I am looking to remove some of the noise and brute force attempt from the maillog and would appreciate people's thoughts and experience.

There seem to be three options:

1. The Plesk firewall
2. Fail2ban
3. AbuseIPDB

Plesk firewall
The firewall (iptables) allows me to be specific and so I have a:

1. 'Banned from IMAP and POP3' rule that denies access to TCP 25/993/110/995 for a list of both country codes and CIDR blocks
2. 'Banned from SMTP' rule that denies access to TCP 25/465/587

The first rule is fine for blocking attempts to log into mailboxes, but the second needs to be open to permit receipt of mail, but then seems to suffer from what I presume to be relay attempts, e.g.

Dec 8 03:47:06 mail postfix/smtpd[3287986]: warning: unknown[185.169.4.158]: SASL LOGIN authentication failed: authentication failure, sasl_username=scanner
Dec 8 04:21:43 mail postfix/smtpd[3296416]: warning: unknown[185.169.4.158]: SASL LOGIN authentication failed: authentication failure, sasl_username=backup
Dec 8 04:56:32 mail postfix/smtpd[3304545]: warning: unknown[185.169.4.158]: SASL LOGIN authentication failed: authentication failure, sasl_username=testuser
Dec 8 03:50:14 mail postfix/smtpd[3288748]: warning: unknown[62.60.131.40]: SASL LOGIN authentication failed: authentication failure, sasl_username=test@valid-domain
Dec 8 03:57:12 mail postfix/smtpd[3290201]: warning: unknown[62.60.131.40]: SASL LOGIN authentication failed: authentication failure, sasl_username=test@valid-domain
Dec 8 05:18:26 mail postfix/smtpd[3309486]: warning: unknown[62.60.131.40]: SASL LOGIN authentication failed: authentication failure, sasl_username=test@valid-domain

The first of these two examples (185.169.4.158) is a 100% abusive IP on AbuseIPDB with similar postfix/smtpd brute force attacks and is based in Vilnius, while the second IP (62.60.131.40) is again a 100% abusive IP with postfix/smtpd abuse based in the Netherlands. It's unlikely either of these machines would ever send legitimate Email, but I presume if they were blocked (added to the 'Banned from SMTP' rule), they could neither attempt to relay nor ever deliver mail to the server should they have legitimate mail to deliver. Correct?

In this respect, the (very nice) country blocking offered by the firewall can't be used for postfix/smtp, unless of course there is no desire to ever receive Email from RU/CN/IR/IN etc. Again, is this correct?

Fail2ban
Moving through the toolbag we have fail2ban. The 'plesk-dovecot' jail would seem to offer an alternatvie to the 'Banned from IMAP and POP3' f/w rule, although includes port 4190 (Plesk dovecot) ... although nmap reports 4190 isn't open on my box. So, question: Is using the 'plesk-dovecot' fail2ban jail a 'better' option than my 'Banned from IMAP and POP3' f/w rule?

And presumably, using the 'plesk-postfix' fail2ban jail will not only block relay attempts, it will also block legitimate mail delivery? Is there any advice/thoughts over using the 'plesk-postfix' fail2ban jail v my 'Banned from SMTP' f/w rule? Any benefit one way or the other?

AbuseIPDB
And then we come to AbuseIPDB. This rather wonderful service allows you to check on the reputation of an IP you find appearing repeately in your logs, and surprise surprise, most rank highly (typically 100%) on the abuse scale, which is why you are seeing them in your logs and making the check. I use this along with a net block check to determine whether to block the IP, the entire net block or let pass.

However, there are options to both contribute the results of your logs to the AbuseIPDB database and to use it's findings dynamically to block bad IPs. There is an integration between fail2ban and AbuseIPDB, and in researching ideas I see some nice scripts for integration in the Plesk Community, e.g. 'Plesk Fail2Ban: Integration for AbuseIPDB' (@brother4 and @LRob) and 'Integrating AbuseIPDB RealTime IP Check, possibly using ModSecurity and LUA' (@Ehud) , but these go back a few years and so I wonder, is there/will there be a Plesk option (or advice/KB article) on AbuseIPDB integration within a Plesk environment? I would love to both be able to contribute intelligence to AbuseIPDB for the benefit of all, and to also benefit from using it to block a lot of the noise without the need for repeated 'log crunching' and f/w (or fail2ban) updates.

Maybe there's a place for a Plesk server hardening KB article that could cover these and other points of advice? I know there is a 'Best practices to strengthen Plesk server security', but it is pretty high level and IMHO we could do with a: 'Things to do and how to do them' article suitable for everyone to follow (not just experiecned sysadms).

And finally
And finally, nmap reports 8880 is open which I see is "For accessing the Plesk console interface, especially when port 8443 is unavailable". I've no idea why 8443 would be unavailable and generally, unnecessary open ports only help the bad guys, so should 8880 be open, can I/should I close it (how?), or should I set a f/w rule to simply block? I can see it provides http (not https) access to the console ... so I'm thinking this is an immediate f/w rule to add if there is no way to disable this port!

Thanks for people's thoughts

 

[Kaspar]

I totally get your desire to reduce some of the "noise" in the maillog and limit brute force attempts. But I think it is important to understand that it's nearly impossible to completely prevent probe ("noise) and brute force attempts. But with use of the Plesk firewall and fail2ban you should be able to reduce the probe and brute force attempts at least somewhat.

For your post I get the feeling you're contemplating using the Plesk firewall OR fail2ban. There is no need to choose one over the other. They are actually best used together, but are suited for different roles.

The Plesk firewall is static. Meaning that you need to manage any firewall rule manually. If you want to block every abusive IP you encounter with the firewall, it will probably soon become a full time job. Especially if you're hosting many domains. That's not to say the Plesk firewall isn't useful. On the contrary. It's very well suited to block IP ranges/subnets (and very specific IP's if you must). Being able to geo-block countries is a great bonus. Although it's not completely accurate and geo-blocking countries has a limited impact to begin with.

Fail2ban on the other hand is dynamic. It searches through logs for abusive behavior and temporarily blocks IP's accordingly. One of fail2ban's limitations is that it only keeps track of individual IP's, not subnets. I also feel that the default ban time and detection interval of fail2ban are way too low to be very effective. I recommend increasing these substantially. Fail2ban has many more (advanced) options that are not available from within, but can be managed via command line. Which might be worth checking out if you like to dive into the power of fail2ban a little bit deeper.

I also recommend regularly checking the list banned IP on fail2ban to see if there many domains within a single subnet are blocked. If they are, you can check their reputation on the AbuseIPDB. If the reputation is bad (which it most likely is) you can consider manually blocking the subnet on the Plesk firewall (or even on the fail2ban permanent jail). I shared a shell script here that can help you automate this.

You always run the risk of blocking legitimate servers this way. Personally I feel it's a pretty small risk on which the benefits outweigh the risk. But this might be different for you of course.

As for AbuseIPDB, it is a great source to check on the reputations of IP's. Newer fail2ban versions are shipped with an optional action to report banned IP to AbuseIPDB directly. The action configuration can be downloaded/copied from the fail2ban repo on Github here. Some additional instructions are available here. I prefer this method to report IP's to AbuseIPDB over the other methods shared on the forum you linked to.

That's for reporting only. Using abuseipdb to also (preemptively) block abuse IP's is a bit of a challenge. I haven't found any suitable solution worth integrating on any of my servers yet. One of the challenges is that the blocklist contains almost 80 thousand IP's with a confidence level of 100%. And nearly 120 thousand IP'sif you reduce confidence level to 75%. If you're not careful you will choke your server trying to block all of those IP's.

Hope this helps. I tried to answer your specific questions with the above information in mind.

[...] It's unlikely either of these machines would ever send legitimate Email, but I presume if they were blocked (added to the 'Banned from SMTP' rule), they could neither attempt to relay nor ever deliver mail to the server should they have legitimate mail to deliver. Correct?

Yes, correct. Any mail traffic from those IP's are blocked entirely.

In this respect, the (very nice) country blocking offered by the firewall can't be used for postfix/smtp, unless of course there is no desire to ever receive Email from RU/CN/IR/IN etc. Again, is this correct?

Yes, correct again.

[...] So, question: Is using the 'plesk-dovecot' fail2ban jail a 'better' option than my 'Banned from IMAP and POP3' f/w rule?

Not better (or worse). Just different. Your firewall rule is static, the dovecot fail2ban jail is dynamic.

[...] And presumably, using the 'plesk-postfix' fail2ban jail will not only block relay attempts, it will also block legitimate mail delivery?

It blocks any mail traffic from the banned IP, which could include legitimate mail.

[...] Is there any advice/thoughts over using the 'plesk-postfix' fail2ban jail v my 'Banned from SMTP' f/w rule? Any benefit one way or the other?

If used right, these could complement each other. As the firewall rule is static and the fail2ban jail dynamic.

[...] And finally, nmap reports 8880 is open which I see is "For accessing the Plesk console interface, especially when port 8443 is unavailable". I've no idea why 8443 would be unavailable and generally, unnecessary open ports only help the bad guys, so should 8880 be open, can I/should I close it (how?), or should I set a f/w rule to simply block? I can see it provides http (not https) access to the console ... so I'm thinking this is an immediate f/w rule to add if there is no way to disable this port!

I think port 8880 is a legacy port from back in the days when Plesk could still be accessed via an insecure connection (http). As far as I know it doesn't serve much of purpose, but is still available for legacy and compatibility reasons. You can block the port on a firewall without having to worry about it having any negative impact on your Plesk usage.

 

[iainh]

Many thanks @Kaspar for your time, thoughts and advice

Yes, I get that fail2ban is dynamic and have that locked down (maxretry = 3) to help limit things, but there is also the fail2ban 'plesk-permanent-ban' jail, although that is an all ports, TCP and UDP total ban, but you could create (say) a 'plesk-permanent-dovecot-ban' or postfox jail. I suppose a benefit of that route would be the easy transfer of an IP out of a dynamic to a permanent ban jail.

Ultimately, my understanding is both the Pesk f/w and fail2ban are manipulating iptables and so I'm presuming are simply two means to the same end?

Yes, IP geolocation has quaite a few vagaries, but if you want to block RU or IR, they are a whole lot simpler than multiplc CIDR blocks and 'good enough' as a starting point.

As you point out, the implication of vaste iptable lists on performance need to be considered, but I'm tending to go for the IPs and CIDRs recording hundreds or thousands of probes and so these two have an impact. I'm find a lot of bad IPs are from 'Cheapy hosts' or some other similar type of name. India is a big source and so I have some large CIDR blocks in place now. Traffic is regional and so some of these places are unlikely to ever have legitimate interest in anything ... but of course, there's always the opportunity to block something legit.

I had a read of the AbuseIPDB info and will have a further look on Github. While it may be possible to craft something it would also be nice for Plesk to consider something ... maybe I need to transfer this to a Plesk product request. The more of us that conribute the better intel we'll alll have, although I guess we get into your point about: Are you really going to block 80K IPs?

I guess what woild be good is something that analysed your own logs and picked out repeat high volume offenders. Then you don't need to worry about 80K IPs, just the one endless probing your server...