295766Re: Postfix counters (was: limit and monitor too many sasl login from same user)
- Oct 5, 2013Patrick Ben Koetter:
> * Wietse Venema <postfix-users@...>:My idea: if Postfix can count something, then applications will
> > Viktor Dukhovni:
> > > On Sat, Oct 05, 2013 at 09:59:23AM -0400, Wietse Venema wrote:
> > >
> > > > It should be easy enough to count per "login name" instead of per
> > > > "SMTP client" (after all, those labels are just simple strings that
> > > > select a hash-table entry).
> > > >
> > > > However it should not be too easy to exhaust server memory.
> > > >
> > > > In particular, Postfix must not try to maintain huge numbers of
> > > > counters when some spammer tries a huge number of different login
> > > > names in a short time.
> > >
> > > Which requires a large number of concurrently compromised accounts.
> > > In most cases a spammer will have compromised a modest number of
> > No. Think "brute force account guessing attack". For example, a
> > spammer tries (a long list of usernames) x (a long list of passwords)
> > distributed over multiple compromised clients.
> > Regardless of whether this is a common mode of operation, Postfix
> > must not run out of memory when it happens.
> How would you detect such an attack? A pattern of connection/login
> failures? A regular client should try x attempts within y and then
> give up, shouldn't it? Or do they try until someone manually
follow. Whether it is counting login names, sender addresses,
recipient addresses or something that I haven't thought of yet.
> Can we assume such a feature would only be used on ports that haveI suppose SMTP-related counters would be driven by smtpd(8), and
> MUA to MTA traffic? On such a port could we separate spammer clients
> from regular clients? Do regular clients have behaviours that make
> them distinguishable from irregular (spammers) ones?
Postfix still uses the same program for both MUA and MTA traffic.
> If a regular client ended after x attempts within y time, shouldI hope that simple counters and limits can deal with this. If not,
> any further attempt lead to a ban, because it identifies an irregular
> client that keeps on failing?
then making counters available via memcached would allow other
programs to make more complex inferences.
Unfortunately, digging up the login name (without waiting for a
successful login) requires that Postfix implements parts of the
SASL protocol itself. So that is not a very good application of
counters for failed login attempts on known names, or login attempts
on non-existent names.
> Also: A deep inspection (time consuming) could lookup the submittedGrabbing SASL password information with smtpd(8) would require more
> password in <https://leakdb.abusix.com/info.html> and use the fact
> that there are matches to come to a decision.
duplication of SASL inside smtpd(8).
- << Previous post in topic Next post in topic >>