Facebook
Twitter- 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:
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
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:
- '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
- 'Banned from SMTP' rule that denies access to TCP 25/465/587
Dec 8 03:47:06 mail postfix/smtpd[3287986]: warning: unknown[185.169.4.158]: SASL LOGIN authentication failed: authentication failure, sasl_username=scannerDec 8 04:21:43 mail postfix/smtpd[3296416]: warning: unknown[185.169.4.158]: SASL LOGIN authentication failed: authentication failure, sasl_username=backupDec 8 04:56:32 mail postfix/smtpd[3304545]: warning: unknown[185.169.4.158]: SASL LOGIN authentication failed: authentication failure, sasl_username=testuserDec 8 03:50:14 mail postfix/smtpd[3288748]: warning: unknown[62.60.131.40]: SASL LOGIN authentication failed: authentication failure, sasl_username=test@valid-domainDec 8 03:57:12 mail postfix/smtpd[3290201]: warning: unknown[62.60.131.40]: SASL LOGIN authentication failed: authentication failure, sasl_username=test@valid-domainDec 8 05:18:26 mail postfix/smtpd[3309486]: warning: unknown[62.60.131.40]: SASL LOGIN authentication failed: authentication failure, sasl_username=test@valid-domainThe 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
