• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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