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

using/logging client addr as part of SASL auth

Expand Messages
  • Ricardo Signes
    Hello! I m looking for a way to detect and distinguish different kinds of auth failures. Right now, I m feeling a bit stuck by my inability to get all the
    Message 1 of 7 , May 27, 2014
    • 0 Attachment
      Hello!

      I'm looking for a way to detect and distinguish different kinds of auth
      failures. Right now, I'm feeling a bit stuck by my inability to get all the
      data I'd like in one place at the same time.

      Right now, we're using SASL authentication with pwcheck. pwcheck, of course,
      only gets two data: username and password. It can't take any action based on
      the IP address of the remote.

      Meanwhile, postfix's logs on failure don't appear to show me the username on
      failed AUTH attempts.

      I'd like to be able to distinguish the cases resulting from the intersections
      of (one password over and over / many different passwords), (one username /
      many usernames), (one IP address, many IP addresses). With these data, I can
      take better action to detect, classify, and react to bad actors.

      I'm happy (I guess) to end up having to write code to make this happen, but I'm
      not sure where I could do it.

      --
      rjbs
    • lists@rhsoft.net
      ... the problem ist that postfix has no idea of the SASL internals and should not need to - in case of dovecot i asked a few days ago to log the username
      Message 2 of 7 , May 27, 2014
      • 0 Attachment
        Am 27.05.2014 22:45, schrieb Ricardo Signes:
        > I'm looking for a way to detect and distinguish different kinds of auth
        > failures. Right now, I'm feeling a bit stuck by my inability to get all the
        > data I'd like in one place at the same time.
        >
        > Right now, we're using SASL authentication with pwcheck. pwcheck, of course,
        > only gets two data: username and password. It can't take any action based on
        > the IP address of the remote.
        >
        > Meanwhile, postfix's logs on failure don't appear to show me the username on
        > failed AUTH attempts.
        >
        > I'd like to be able to distinguish the cases resulting from the intersections
        > of (one password over and over / many different passwords), (one username /
        > many usernames), (one IP address, many IP addresses). With these data, I can
        > take better action to detect, classify, and react to bad actors.
        >
        > I'm happy (I guess) to end up having to write code to make this happen, but I'm
        > not sure where I could do it

        the problem ist that postfix has no idea of the SASL internals and should
        not need to - in case of dovecot i asked a few days ago to log the username
        because in case of using dovecot as SASL provider that's the only instance
        which decodes the input and verify it against the user-db

        sadly until now nobody cares except hints "turn debug on" which is no
        solution in production to help users in case of password changesn and
        forgot 2 out of 6 clients, especially for Apple users since that
        crap needs to seperatly change the password for the outgoing server
        while even MS Outlook 10 years ago offered a checkbox at setup
        "use the same credentials as for POP3/IMAP"
      • Wietse Venema
        ... Would not it be sufficient to trigger on repeated authentication failures, regardless of the login name? As Reindl observed, Postfix does not decode SASL
        Message 3 of 7 , May 27, 2014
        • 0 Attachment
          lists@...:
          > the problem ist that postfix has no idea of the SASL internals and should
          > not need to - in case of dovecot i asked a few days ago to log the username
          > because in case of using dovecot as SASL provider that's the only instance
          > which decodes the input and verify it against the user-db

          Would not it be sufficient to trigger on repeated authentication
          failures, regardless of the login name?

          As Reindl observed, Postfix does not decode SASL protocols, it just
          passes strings between the remote SMTP client and the local Dovecot
          server or SASL implementation.

          Wietse
        • lists@rhsoft.net
          ... no - the problem is that i wanto to *help* users failing again and again to send mail from mobile devices without realize that the change of the POP3/IMAP
          Message 4 of 7 , May 27, 2014
          • 0 Attachment
            Am 27.05.2014 23:04, schrieb Wietse Venema:
            > lists@...:
            >> the problem ist that postfix has no idea of the SASL internals and should
            >> not need to - in case of dovecot i asked a few days ago to log the username
            >> because in case of using dovecot as SASL provider that's the only instance
            >> which decodes the input and verify it against the user-db
            >
            > Would not it be sufficient to trigger on repeated authentication
            > failures, regardless of the login name?

            no - the problem is that i wanto to *help* users failing again and
            again to send mail from mobile devices without realize that the
            change of the POP3/IMAP password was not enough and need to do the
            same for the outgoing server

            in days of a lot of devices and carrier grade NAT filter the logs
            for successful IMAP/POP3 logins from the same IP is just blind
            guessinf

            one may say it's the users problem - well i faced users clients
            to send the same message again and agin every 5 minutes until
            that damned iphone got stolen and so the log flood ended :-(


            > As Reindl observed, Postfix does not decode SASL protocols, it just
            > passes strings between the remote SMTP client and the local Dovecot
            > server or SASL implementation.

            sadly yes - *dovecot* should log that
          • Ricardo Signes
            * Wietse Venema [2014-05-27T17:04:32] ... It s not ideal. Here are some scenarios: a. one IP, the same username, many different
            Message 5 of 7 , May 27, 2014
            • 0 Attachment
              * Wietse Venema <wietse@...> [2014-05-27T17:04:32]
              > lists@...:
              > > the problem ist that postfix has no idea of the SASL internals and should
              > > not need to - in case of dovecot i asked a few days ago to log the username
              > > because in case of using dovecot as SASL provider that's the only instance
              > > which decodes the input and verify it against the user-db
              >
              > Would not it be sufficient to trigger on repeated authentication
              > failures, regardless of the login name?

              It's not ideal. Here are some scenarios:

              a. one IP, the same username, many different passwords
              b. one IP, different usernames, many different passwords
              c. many IPs, the same username, many different passwords
              d. one IP, the same username, the same (wrong) password repeatedly

              Scenarios a,b,c are much more likely to be attacks than (d), which looks like
              somebody just turned on their old laptop without fixing its fetchmail job.

              Scenario a and b are single-IP bad actors trying to perform a dictionary
              attack, targeted or not.

              Scenario c is potentially someone with a botnet trying to get a single target.

              Taking action based on "repeatedly failed auth from ip X" is a start, but it's
              not great.

              I definitely understand the point about not wanting to deal with the SASL
              internals. Putting aside that question, do you have any suggestions or
              thoughts about improving the way in which potential attacks could be classified
              with currently available data?

              --
              rjbs
            • Wietse Venema
              ... I suppose that one would log a password hhas, just to be sure. ... It is not practical to implement every SASL protocol in Postfix. Also, the more secure
              Message 6 of 7 , May 27, 2014
              • 0 Attachment
                Ricardo Signes:
                > a. one IP, the same username, many different passwords
                > d. one IP, the same username, the same (wrong) password repeatedly

                I suppose that one would log a password hhas, just to be sure.

                > I definitely understand the point about not wanting to deal with the SASL
                > internals.

                It is not practical to implement every SASL protocol in Postfix.
                Also, the more secure SASL protocols don't send a fixed password,
                instead they use challenge-response. In that case there is no way
                to find out whether you are looking at (a.) or (d.).

                Postfix could log the base64 blobs that the client sends. Even
                without decoding base64, this may be sufficient to see that someone
                is using the same username and password repeatedly with AUTH PLAIN
                or AUTH LOGIN, and you can base64 decode the blob to find out what
                username may be involved. But this effectively logs many plaintext
                passwords to file.

                > Putting aside that question, do you have any suggestions or thoughts
                > about improving the way in which potential attacks could be
                > classified with currently available data?

                The general solution requires support in the authentication back-end,
                be it Dovecot or the SASL library.

                Wietse
              • Ricardo Signes
                * Wietse Venema [2014-05-27T17:48:03] ... Yes, something like a truncated hash of the password salted with something changed frequently
                Message 7 of 7 , May 27, 2014
                • 0 Attachment
                  * Wietse Venema <wietse@...> [2014-05-27T17:48:03]
                  > Ricardo Signes:
                  > > a. one IP, the same username, many different passwords
                  > > d. one IP, the same username, the same (wrong) password repeatedly
                  >
                  > I suppose that one would log a password hhas, just to be sure.

                  Yes, something like a truncated hash of the password salted with something
                  changed frequently and never stored. <hand wave> It only needs to detect
                  close-in-time "same password" with very low false positives.

                  > It is not practical to implement every SASL protocol in Postfix.
                  > Also, the more secure SASL protocols don't send a fixed password,
                  > instead they use challenge-response. In that case there is no way
                  > to find out whether you are looking at (a.) or (d.).

                  Indeed. Fortunately (?) for me, I don't need to worry about that at this
                  point.

                  > Postfix could log the base64 blobs that the client sends.

                  Yes, I think that, as you suggest, this leads to a scary place.

                  > The general solution requires support in the authentication back-end,
                  > be it Dovecot or the SASL library.

                  I see now that libsasl v2's sasl_server_new takes a string in the form
                  "ipaddr:port" and that postfix's smtpd_sasl_activate seems to pass along the
                  actual remote client IP. (Please tell me if I've grossly misread; I am not
                  familiar with Postfix's source.) As long as we don't put an SMTP proxy in the
                  way, this suggests to me that I can probably do something *fairly* simple with
                  libsasl to get all the relevant data in one place. I see a horrible, useful
                  hack in my future.

                  Thanks for your help.

                  --
                  rjbs
                Your message has been successfully submitted and would be delivered to recipients shortly.