Loading ...
Sorry, an error occurred while loading the content.

295765Re: Postfix counters (was: limit and monitor too many sasl login from same user)

Expand Messages
  • Patrick Ben Koetter
    Oct 5, 2013
      * Patrick Ben Koetter <postfix-users@...>:
      > * Wietse Venema <postfix-users@...>:
      > > 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.


      [*] 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
    • Show all 13 messages in this topic