* Patrick Ben Koetter <postfix-users@postfix.org>: > * 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? > > 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? > > 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? > > 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.
Geolocation + day + x failed logins = attacker? IIRC you showed during the inital postscreen development that you were able to correlate spambots with geolocation. The reason there were so many connections from spambots was it was day in these geolocations and people were up and had turned their compromised machines on. One could also track behaviour and build an IP reputation for login/password combinations. Connections from unusal IPs + repeated login failures could be a good reason to ban the IP. You could go fancy and use REPUTE <https://datatracker.ietf.org/wg/repute/> to store/retrieve reputation information. Finding connections from a banned IP in a database shared between different services (SMTP/POP/IMAP) might be useful for all participating services. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
