under another kind of attack

[Joseph Tam]

Olaf Hopp <Olaf.Hopp at kit.edu> writes:

> I have dovecot shielded by fail2ban which works fine.  But since a few
> days I see many many IPs per day knocking on my doors with wron
> password and/or users.  But the rate at which they are knocking is very
> very low.  So fail2ban will never catch them.

Slow roll distributed attacks.  Really hard to stop.

> And I see many many distinct IPs per day (a few hundred) trying many
> many existing and non-existings accounts.  As you see in the timestamps
> in my examples, this can not be handled by fail2ban without affecting
> regular users with typos.  Is anybody observing something similar ?

All the time, and to many services.  If you need to be fault tolerant,
you'll either have to set tolerant limits (allow reasonable number of
failures), or timeout features.  You could also track successful
logins as whitelisting entries for future logins.

> Anybody an idea against this ? Many of these observed IPs are chinese
> mobile IPs, if this matters.  But we have also chinese students and
> researchers all abroad.

Nearly an intractable problem, especially since your users are embedded
in a notoriously infested network (as someone quipped, "like picking
marshmallows out from a pile of sh*t").

Some ideas:

 	- pre-emption (using third party RBLs that targets BFD)
 	- immediate blacklisting of known bad users/passwords
 		(e.g. "admin", "support", extinct users, etc.)
 	- persistent tracking storage: tracking in SQL, or
 		or large LRU list that can reach far enough back
 		in time.

(I think Aki mentioned weakforced which you can use instead if fail2ban
to implement some of these things.)

There are other solutions like alternate ports, port knocking, certificate
authentication, or VPN, but they are hard/impossible to do with a large
userbase, or have high setup/amortization costs.

If you have a enforced strong password policy, these brute forcers have
little chance of succeeding, so maybe the easiest cheapest policy is to
ignore it.

Joseph Tam <jtam.home at gmail.com>