Patrick Ben Koetter: > * Wietse Venema <postfix-users@postfix.org>: > > 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 > intervenes?
My idea: if Postfix can count something, then applications will 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 have > 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? I suppose SMTP-related counters would be driven by smtpd(8), and Postfix still uses the same program for both MUA and MTA traffic. > If a regular client ended after x attempts within y time, should > any further attempt lead to a ban, because it identifies an irregular > client that keeps on failing? I hope that simple counters and limits can deal with this. If not, 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 submitted > password in <https://leakdb.abusix.com/info.html> and use the fact > that there are matches to come to a decision. Grabbing SASL password information with smtpd(8) would require more duplication of SASL inside smtpd(8). Wietse
