• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Blocking Massive Connections / Attacks

Heppi75

Basic Pleskian
Hi,

I have some attacks from different IP Addresses like this:

Code:
postfix/smtpd[23192]: warning: ns502589.ip-192-99-8.net[192.99.8.171]: SASL LOGIN authentication failed: authentication failure
postfix/smtpd[23192]: lost connection after AUTH from ns502589.ip-192-99-8.net[192.99.8.171]
postfix/smtpd[23192]: disconnect from ns502589.ip-192-99-8.net[192.99.8.171]

Should the following fail2ban plesk postfix-sasl filter not block this? If I look on the regex it should match, also the fail2ban-regex shows the correct matches? But I had about 4000 attempts in a short time and nothing was blocked? Could someone explain me what I am doing wrong?

Code:
_daemon = postfix(-\w+)?/(?:submission/|smtps/)?smtp[ds]
failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL ((?i)LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(:[ A-Za-z0-9+/:]*={0,2})?\s*$
ignoreregex = authentication failed: Connection lost to authentication server$
 
Last edited:
@Heppi75

There are a number of possible explanations, the two most important of them are:

1 - Fail2Ban is overloading iptables and/or the firewall does not work properly: less likely root cause of the problem if you have a dedicated server, very likely root cause of the problem if you have a VPS or a cloud based VM,

2 - Fail2Ban is configured in such a way that

a - the default detection interval of 600 seconds is too high: a number of hack attempts (i.e. login attempts) will be occuring (but not succesful according to the logs) during a period of 600 seconds (10 minutes) in which period Fail2Ban will actuall do nothing, in order to detect the hack attempts afterwards and take appriopriate action by banning,

b - the scripted hack attempt is Fail2Ban proof: hack attempts are configured in such a way that detection intervals (and other Fail2Ban settings) are bypassed,

c - jails are not activated and/or configured properly: for instance, Fail2Ban detects the hack attempts, bans the bad IPs, but unbans the bad IPs too soon due to a too short ban period, being part of the settings of a particular jail,

and, in short, Fail2Ban can become quite ineffective with a bad configuration.

In summary, one should first check whether iptables works properly as a firewall and, afterwards, one should tweak Fail2Ban settings.

In general, it is good to activate the recidive jail: any IP that is banned multiple times by some Fail2Ban jail, will be banned by the recidive jail for a long time interval.

If you configure the recidive jail with

- logpath = /var/log/fail2ban.log
- maxretry = 2
- banperiod = 604800 (read: one week)

and a custom recidive filter with contents

[INCLUDES]
before = common.conf

[Definition]
_daemon = fail2ban\.actions\s*
_jailname = recidive
failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)NOTICE\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$
ignoreregex = ^.*\[postfix-anvil\].*$

[Init]
journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=5


then you are probably able to prevent a huge number of (retried) hack attempts (i.e. login attempts).

Some additional fine-tuning of Fail2Ban is probably desired, in order to make Fail2Ban really effective: for instance, one could make Fail2Ban write to /etc/hosts.deny file AND (at the same time) write bad IPs to a Nginx based block file, hence making the entire Fail2Ban setup a bit more savvy.

However, Fail2Ban tuning is a specialist job, so if you want to improve Fail2Ban without complex customizations, just increase the ban periode to the equivalen of a year!

Hope the above helps a bit!

Regards.........
 
Back
Top