search

YunoHost / issues

General issue tracker for the YunoHost project
72 stars 8 forks source link

fail2ban doesn't ban on failed smtp auth attempts #2254

Open chri2 opened 1 year ago

chri2 commented 1 year ago

It seems that fail2ban doesn't ban on failed smtp auth attempts.

alexAubin commented 1 year ago

It's supposed to be handled by fail2ban's default postfix jail which is enabled in YunoHost : https://github.com/YunoHost/yunohost/blob/dev/conf/fail2ban/yunohost-jails.conf#L8

Can you elaborate on what kind of log line exactly is not caught by fail2ban ?

alexAubin commented 1 year ago

(Hm I realize there's also https://github.com/YunoHost/yunohost/blob/dev/conf/fail2ban/postfix-sasl.conf though)

chri2 commented 1 year ago

It's supposed to be handled by fail2ban's default postfix jail which is enabled in YunoHost : https://github.com/YunoHost/yunohost/blob/dev/conf/fail2ban/yunohost-jails.conf#L8

Can you elaborate on what kind of log line exactly is not caught by fail2ban ?

# grep '^Sep 30.*SASL LOGIN authentication failed' mail.warn | cut -d']' -f2- | sort | uniq -c | sort -n
     83 : warning: unknown[45.129.14.17]: SASL LOGIN authentication failed: Connection lost to authentication server
    126 : warning: unknown[45.129.14.17]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
# date
Sa 30. Sep 08:21:47 CEST 2023

If I'd search backwards I'd probably find more extreme examples (posted one on the matrix channel I remember).

chri2 commented 12 months ago

I just checked again and found that fail2ban recognizes the dovecot journal messages related to authentication failures.

But it doesn't help agains e.g. this:

# journalctl -u dovecot.service | grep 'rip=124.106.147.42' | cut -d',' -f1
Nov 19 12:30:45 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 12:57:56 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:05:19 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:09:27 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:15:34 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:18:30 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:24:41 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:26:40 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:35:00 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 13:48:12 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 15:06:49 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed
Nov 19 16:00:35 link-goe.de dovecot[908054]: imap-login: Disconnected (auth failed

All from the same IP which is still constantly trying.

My line of thinking now is that the ratings should be different than 10 failures in 10 minutes.

I'd think somethink like this would be very helpful:

To each IP there's a bucket of x failures available. If the failure bucket is empty we put for that IP a time penalty in its penalty register and it is blocked for that time. Every x seconds we give the IP one failure back to its failure bucket which it than could use. Every time the failure bucket gets emptied again we add another time penalty to the penalty register of the IP and it is blocked for that ever increasing time. Once an IP that has already a penalty register logs in successfully the penalty register and the failure bucket get reset to their initial values and a warning message for the admin including the details about the IPs status when reset.

This would eventually allow wrongly configured clients to recover with the admin being notified about a potentially guessed password. On the other hand it would block out long and slow running attacks as the one I'm seeing right now.

I didn't get into fail2ban deep enough to see whether it would be possible to configure a scheme like described above or something similar. Anybody knows already?

alexAubin commented 12 months ago

I didn't get into fail2ban deep enough to see whether it would be possible to configure a scheme like described above or something similar. Anybody knows already?

There is the recidive jails which works in a similar fashion and is automatically enabled on YunoHost

chri2 commented 12 months ago

Thanks! I'll look into that to find why it doesn't hit that client I pasted part of the log for.

chri2 commented 12 months ago

It looks to me that the long running attack I have doesn't trigger a ban at all. The recidive would only work to block that IP for a longer period if it would get blocked a few times.

The approach doesn't help against attacks that are below the attacks/time-interval trigger. But that is what I've been looking for.

An approach using recidive could be to alter the configuration like this:

But there'd still the issue that if the individual rules are multiplied to a large number of systems an attacker just needs to know the treshold to stay below it to attack all of theses similar configured systems without triggering a ban.

alexAubin commented 4 months ago

Re-having a quick look at this, it seems it may be related to the fact that we have an postfix-sasl filter/regex but the one enabled is just postfix ... Though I don't know what the postfix does and why we have to ship something specific for postfix-sasl ?