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

Solution to SMTPAuth compromised accounts.

Expand Messages
  • Jorgen Lundman
    Hello all, Talking about the customer outgoing SMTP servers, where customers connect and are forced to SMTPAuth before they can send mail out to the Internet.
    Message 1 of 7 , Sep 12, 2013
    • 0 Attachment
      Hello all,

      Talking about the customer outgoing SMTP servers, where customers connect
      and are forced to SMTPAuth before they can send mail out to the Internet.
      We use LDAP for SMTPAuth verification.

      Occasionally, a customer account is compromised, and used for sending large
      volumes of spam.

      We have a system in place that detects this, and immediately sets the LDAP
      "accountStatus" to "disabled".

      However, quite often the 3rd party involved uses software that can use
      pipelining, and simply keeps sending mail, even though the SMTPAuth account
      has been stopped.

      Naturally, we can simply restart Postfix, thereby dropping all connections
      and forcing SMTPAuth again. But this is rather undesirable, and unattractive.

      Are there other solutions to consider?

      Can we add something similar to the "smtpd_client_restrictions" or
      "smtpd_recipient_restrictions", and adding a new rule-entry which would
      simply confirm that the "SMTPAuth LDAP 'user' used way back, is still
      accountStatus=enabled" ?

      Or, can we set a maximum limit on number of pipelining emails allowed, say,
      50, that at least we still have the spammers get cut off, but retain the
      efficiency of pipelining.

      Should we simply disable pipelining on the SMTP clusters? Customers
      "probably" are not negatively affected by this setting.



      --
      Jorgen Lundman | <lundman@...>
      Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
      Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
      Japan | +81 (0)3 -3375-1767 (home)
    • Viktor Dukhovni
      ... What you are calling pipelining is more properly called connection caching or message piggy-backing. A single SMTP connection is used to deliver
      Message 2 of 7 , Sep 12, 2013
      • 0 Attachment
        On Fri, Sep 13, 2013 at 11:45:54AM +0900, Jorgen Lundman wrote:

        > However, quite often the 3rd party involved uses software that can
        > use pipelining, and simply keeps sending mail, even though the
        > SMTPAuth account has been stopped.

        What you are calling "pipelining" is more properly called connection
        caching or message piggy-backing. A single SMTP connection is used
        to deliver multiple messages.

        > Naturally, we can simply restart Postfix, thereby dropping all
        > connections and forcing SMTPAuth again. But this is rather
        > undesirable, and unattractive.
        >
        > Are there other solutions to consider?

        With the default setting smtpd_delay_reject=yes each message is
        subject to the full set of smtpd restrictions.

        > Can we add something similar to the "smtpd_client_restrictions" or
        > "smtpd_recipient_restrictions", and adding a new rule-entry which
        > would simply confirm that the "SMTPAuth LDAP 'user' used way back,
        > is still accountStatus=enabled" ?

        The best approach for this is a policy service call before
        "permit_sasl_authenticated". The policy service can check wether
        the SASL username is still valid.

        Sadly Postfix does not have an access table keyed by the SASL login
        name. Perhaps we should bite the bullet, and add one, after defining
        a suitable encoding for any usernames that contain special or
        whitespace characters.

        --
        Viktor.
      • Stan Hoeppner
        ... It s not pipelining that enables this. It s the fact that, IIRC, Postfix smtpd allows a client to keep sending messages over an open connection for up to
        Message 3 of 7 , Sep 12, 2013
        • 0 Attachment
          On 9/12/2013 9:45 PM, Jorgen Lundman wrote:
          >
          > Hello all,
          >
          > Talking about the customer outgoing SMTP servers, where customers
          > connect and are forced to SMTPAuth before they can send mail out to the
          > Internet. We use LDAP for SMTPAuth verification.
          >
          > Occasionally, a customer account is compromised, and used for sending
          > large volumes of spam.
          >
          > We have a system in place that detects this, and immediately sets the
          > LDAP "accountStatus" to "disabled".
          >
          > However, quite often the 3rd party involved uses software that can use
          > pipelining, and simply keeps sending mail, even though the SMTPAuth
          > account has been stopped.

          It's not pipelining that enables this. It's the fact that, IIRC,
          Postfix smtpd allows a client to keep sending messages over an open
          connection for up to 300s by default.

          > Naturally, we can simply restart Postfix, thereby dropping all
          > connections and forcing SMTPAuth again. But this is rather undesirable,
          > and unattractive.

          Yes, obviously.

          > Are there other solutions to consider?

          The quickest and most thorough way to thwart this is to identify the ID
          of the smtpd process handling the connection, and kill it. I can't tell
          you how, but maybe Wietse or Viktor can.

          You might also try, in your working detection script, adding the
          hijacked account address to an access(5) table and using
          check_sender_access to reject subsequent submissions until smtpd times
          out. This would obviously also require an automated process to remove
          the entry from the access table once the password has been changed and
          the account re-enabled.

          There may already exist a policy daemon that might give most of what you
          seek. Check out postfwd: http://postfwd.org/ At the least it offers
          per sender rate limiting. You may be able to inject your disabled
          account address in real time and set the rate to 0.

          > Can we add something similar to the "smtpd_client_restrictions" or
          > "smtpd_recipient_restrictions", and adding a new rule-entry which would
          > simply confirm that the "SMTPAuth LDAP 'user' used way back, is still
          > accountStatus=enabled" ?
          >
          > Or, can we set a maximum limit on number of pipelining emails allowed,
          > say, 50, that at least we still have the spammers get cut off, but
          > retain the efficiency of pipelining.
          >
          > Should we simply disable pipelining on the SMTP clusters? Customers
          > "probably" are not negatively affected by this setting.

          Again, pipelining isn't your problem. It simply allows smtp commands to
          be grouped together instead of issued serially, but this works only per
          message, not across a large set of messages. See:
          http://tools.ietf.org/html/rfc2920#section-3.1

          What you seem to be asking for here is a way to limit total messages per
          session. I'm unable to locate such a restriction. The best I think you
          can do is limit message rate, which can be done with Postfix, or with
          postfwd.

          --
          Stan
        • lst_hoe02@...
          ... A workaround might be to force a mismatch with smtpd_sender_login_maps by removing the MAIL FROM -- Login-ID match in the table, no? But this only applies
          Message 4 of 7 , Sep 13, 2013
          • 0 Attachment
            Zitat von Viktor Dukhovni <postfix-users@...>:

            > On Fri, Sep 13, 2013 at 11:45:54AM +0900, Jorgen Lundman wrote:
            >
            >> However, quite often the 3rd party involved uses software that can
            >> use pipelining, and simply keeps sending mail, even though the
            >> SMTPAuth account has been stopped.
            >
            > What you are calling "pipelining" is more properly called connection
            > caching or message piggy-backing. A single SMTP connection is used
            > to deliver multiple messages.
            >
            >> Naturally, we can simply restart Postfix, thereby dropping all
            >> connections and forcing SMTPAuth again. But this is rather
            >> undesirable, and unattractive.
            >>
            >> Are there other solutions to consider?
            >
            > With the default setting smtpd_delay_reject=yes each message is
            > subject to the full set of smtpd restrictions.
            >
            >> Can we add something similar to the "smtpd_client_restrictions" or
            >> "smtpd_recipient_restrictions", and adding a new rule-entry which
            >> would simply confirm that the "SMTPAuth LDAP 'user' used way back,
            >> is still accountStatus=enabled" ?
            >
            > The best approach for this is a policy service call before
            > "permit_sasl_authenticated". The policy service can check wether
            > the SASL username is still valid.
            >
            > Sadly Postfix does not have an access table keyed by the SASL login
            > name. Perhaps we should bite the bullet, and add one, after defining
            > a suitable encoding for any usernames that contain special or
            > whitespace characters.

            A workaround might be to force a mismatch with smtpd_sender_login_maps
            by removing the MAIL FROM --> Login-ID match in the table, no? But
            this only applies if reject_sender_login_mismatch could/should be used
            of course.

            Regards

            Andreas
          • José Borges Ferreira
            ... On top of that, please consider use postfwd for rate limit. José Borges Ferreira
            Message 5 of 7 , Sep 13, 2013
            • 0 Attachment
              On 09/13/2013 08:47 AM, lst_hoe02@... wrote:
              > A workaround might be to force a mismatch with smtpd_sender_login_maps
              > by removing the MAIL FROM --> Login-ID match in the table, no? But
              > this only applies if reject_sender_login_mismatch could/should be used
              > of course.
              On top of that, please consider use postfwd for rate limit.

              José Borges Ferreira
            • Wietse Venema
              ... Built-in message rate limit: /etc/postfix/main.cf: smtpd_client_message_rate_limit = 10 External rate limit: use postfwd and the like. Wietse
              Message 6 of 7 , Sep 13, 2013
              • 0 Attachment
                Viktor Dukhovni:
                > > Can we add something similar to the "smtpd_client_restrictions" or
                > > "smtpd_recipient_restrictions", and adding a new rule-entry which
                > > would simply confirm that the "SMTPAuth LDAP 'user' used way back,
                > > is still accountStatus=enabled" ?

                Built-in message rate limit:

                /etc/postfix/main.cf:
                smtpd_client_message_rate_limit = 10

                External rate limit: use postfwd and the like.

                Wietse
              • /dev/rob0
                ... +1, a check_sasl_auth_access feature would be useful, despite the fact that other approaches can accomplish the same thing, as noted upthread by numerous
                Message 7 of 7 , Sep 13, 2013
                • 0 Attachment
                  On Fri, Sep 13, 2013 at 04:29:28AM +0000, Viktor Dukhovni wrote:
                  > Sadly Postfix does not have an access table keyed by the SASL
                  > login name. Perhaps we should bite the bullet, and add one,

                  +1, a check_sasl_auth_access feature would be useful, despite the
                  fact that other approaches can accomplish the same thing, as noted
                  upthread by numerous posters.

                  > after defining a suitable encoding for any usernames that
                  > contain special or whitespace characters.

                  Fortunately SASL usernames are typically something under site
                  administrators' control, so a partial solution might be to warn
                  against using special or whitespace characters in usernames. :)
                  --
                  http://rob0.nodns4.us/ -- system administration and consulting
                  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                Your message has been successfully submitted and would be delivered to recipients shortly.