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

Methods to limit spam sent through compromised account?

Expand Messages
  • D G Teed
    Today a user s account was compromised (likely phished) and their credentials used to send email over our main outbound SMTP with TLS and SASL auth. When we
    Message 1 of 11 , Mar 31, 2011
    • 0 Attachment

      Today a user's account was compromised (likely phished) and their
      credentials used to send email over our main outbound SMTP
      with TLS and SASL auth.

      When we learned of it, the PAM smtp configuration was set up to
      block the user account authenticating and the account was soon disabled.

      In the meantime, thousands of spam had gone out, as it happened
      before we get to work.

      Are there any suggestions on how to tune postfix to limit the spam throughput?
      There are also legitimate users who have bulk email to send, so
      limiting by recipient quantity (as we do on our webmail) wouldn't be desirable.

      I've seen http://www.postfix.org/TUNING_README.html
      and we are now using:

      smtpd_client_connection_count_limit = 2
      smtpd_client_connection_rate_limit = 10
      smtpd_client_event_limit_exceptions = 127.0.0.0/8, xxx.xxx.xxx.xxx/21
      smtpd_client_message_rate_limit = 10
      smtpd_client_new_tls_session_rate_limit = 10
      smtpd_data_restrictions = reject_unauth_pipelining
      smtpd_delay_reject = yes
      anvil_rate_time_unit = 60s
      anvil_status_update_time = 600s

      Most of the client limits had previously been at 50 or 60.  The exceptions
      line includes our servers subnet.

      I'd like some idea of what real world values would be useful, or additional suggestions
      on how to make the performance less attractive to users of compromised accounts.

      I know spammers refuse to send through our webmail (another dedicated SMTP server for that)
      as they won't put up with a limit of 10 recipients.

      --Donald

    • Stan Hoeppner
      ... When you find a reasonable and effective solution to the phishing problem please share it with the rest of us. The only sure fire solution I m currently
      Message 2 of 11 , Mar 31, 2011
      • 0 Attachment
        D G Teed put forth on 3/31/2011 10:21 AM:

        > I'd like some idea of what real world values would be useful, or additional
        > suggestions
        > on how to make the performance less attractive to users of compromised
        > accounts.

        When you find a reasonable and effective solution to the phishing
        problem please share it with the rest of us.

        The only sure fire solution I'm currently aware of is mass executions of
        stupid and/or ignorant people who have no business using a computer or
        email. The obvious problem with this solution is it requires
        exterminating well over half the human race, including many/most of my
        family members. Not an appealing solution.

        --
        Stan
      • Victor Duchovni
        ... A good solution for large providers with many users some of whom may have compromised accounts is per-user rate limiting, which is possible via many of the
        Message 3 of 11 , Mar 31, 2011
        • 0 Attachment
          On Thu, Mar 31, 2011 at 11:41:19AM -0500, Stan Hoeppner wrote:

          > D G Teed put forth on 3/31/2011 10:21 AM:
          >
          > > I'd like some idea of what real world values would be useful, or additional
          > > suggestions
          > > on how to make the performance less attractive to users of compromised
          > > accounts.
          >
          > When you find a reasonable and effective solution to the phishing
          > problem please share it with the rest of us.

          A good solution for large providers with many users some of whom may
          have compromised accounts is per-user rate limiting, which is possible
          via many of the more popular policy plugins.

          --
          Viktor.
        • Robert Schetterer
          ... using clamav-milter with sanessecurity antipish should stop allready known spam, for sure not new ones -- Best Regards MfG Robert Schetterer
          Message 4 of 11 , Mar 31, 2011
          • 0 Attachment
            Am 31.03.2011 18:41, schrieb Stan Hoeppner:
            > D G Teed put forth on 3/31/2011 10:21 AM:
            >
            >> I'd like some idea of what real world values would be useful, or additional
            >> suggestions
            >> on how to make the performance less attractive to users of compromised
            >> accounts.
            >
            > When you find a reasonable and effective solution to the phishing
            > problem please share it with the rest of us.
            >
            > The only sure fire solution I'm currently aware of is mass executions of
            > stupid and/or ignorant people who have no business using a computer or
            > email. The obvious problem with this solution is it requires
            > exterminating well over half the human race, including many/most of my
            > family members. Not an appealing solution.
            >

            using clamav-milter with sanessecurity antipish should stop
            allready known spam, for sure not new ones

            --
            Best Regards

            MfG Robert Schetterer

            Germany/Munich/Bavaria
          • Ralf Hildebrandt
            ... Well, that happens to us as well. ... You probably need a policy server which limits the sender to a certain amount of mails per time unit. If that limit
            Message 5 of 11 , Mar 31, 2011
            • 0 Attachment
              * D G Teed <donald.teed@...>:
              > Today a user's account was compromised (likely phished) and their
              > credentials used to send email over our main outbound SMTP
              > with TLS and SASL auth.
              >
              > When we learned of it, the PAM smtp configuration was set up to
              > block the user account authenticating and the account was soon disabled.
              >
              > In the meantime, thousands of spam had gone out, as it happened
              > before we get to work.

              Well, that happens to us as well.

              > Are there any suggestions on how to tune postfix to limit the spam
              > throughput?
              > There are also legitimate users who have bulk email to send, so
              > limiting by recipient quantity (as we do on our webmail) wouldn't be
              > desirable.

              You probably need a policy server which limits the sender to a certain
              amount of mails per time unit. If that limit is being exceeded, you
              could either tempfail the mails until some human admin lifts the ban
              OR put the mails on hold.

              --
              Ralf Hildebrandt
              Geschäftsbereich IT | Abteilung Netzwerk
              Charité - Universitätsmedizin Berlin
              Campus Benjamin Franklin
              Hindenburgdamm 30 | D-12203 Berlin
              Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
              ralf.hildebrandt@... | http://www.charite.de
            • pf at alt-ctrl-del.org
              Stan Hoeppner March 31, 2011 12:41 PM ... You can use policyd v2 to throttle users to X mails over Y time span.
              Message 6 of 11 , Mar 31, 2011
              • 0 Attachment
                "Stan Hoeppner" March 31, 2011 12:41 PM


                >D G Teed put forth on 3/31/2011 10:21 AM:
                >
                >> I'd like some idea of what real world values would be useful, or additional
                >> suggestions
                >> on how to make the performance less attractive to users of compromised
                >> accounts.
                >
                > When you find a reasonable and effective solution to the phishing
                > problem please share it with the rest of us.
                >

                You can use policyd v2 to throttle users to X mails over Y time span.
              • D G Teed
                ... I think you misunderstood what I wrote. I listed actual postfix variables, looking for input on practical values. This isn t unreasonable to expect.
                Message 7 of 11 , Mar 31, 2011
                • 0 Attachment
                  On Thu, Mar 31, 2011 at 1:41 PM, Stan Hoeppner <stan@...> wrote:
                  D G Teed put forth on 3/31/2011 10:21 AM:

                  > I'd like some idea of what real world values would be useful, or additional
                  > suggestions
                  > on how to make the performance less attractive to users of compromised
                  > accounts.

                  When you find a reasonable and effective solution to the phishing
                  problem please share it with the rest of us.

                  The only sure fire solution I'm currently aware of is mass executions of
                  stupid and/or ignorant people who have no business using a computer or
                  email.  The obvious problem with this solution is it requires
                  exterminating well over half the human race, including many/most of my
                  family members.  Not an appealing solution.

                  I think you misunderstood what I wrote.  I listed actual postfix
                  variables, looking for input on practical values.  This isn't unreasonable
                  to expect.  I've implemented restrictions on our webmail's SMTP
                  to the point that spammers login, send a few emails, find it doesn't work
                  for large number of recipients and then logout.  It works and I'm not dreaming.
                  Horde developers have also set up limits which greatly discourage
                  spamming.  The only problem is we can't choke the number of
                  recipients on our general SMTP.

                  I was hoping for angles on rate limiting which normal users could live with but would be useless for spam.  In the couple of responses so far, it seems it requires
                  something external - too bad it requires more layers - I hoped it was within
                  the capabilities of anvil and such.

                  Actually, this conversation has me thinking, maybe we should have a dedicated
                  SMTP just for external SMTP + TLS + SASL.  That way I can do the same
                  recipient limit throttling and tell people not to expect it will work for mass
                  mail outs.

                  --Donald

                • D G Teed
                  On Thu, Mar 31, 2011 at 3:34 PM, pf at alt-ctrl-del.org
                  Message 8 of 11 , Mar 31, 2011
                  • 0 Attachment
                    On Thu, Mar 31, 2011 at 3:34 PM, pf at alt-ctrl-del.org <pf@...> wrote:

                    "Stan Hoeppner" March 31, 2011 12:41 PM

                    D G Teed put forth on 3/31/2011 10:21 AM:

                    I'd like some idea of what real world values would be useful, or additional
                    suggestions
                    on how to make the performance less attractive to users of compromised
                    accounts.

                    When you find a reasonable and effective solution to the phishing
                    problem please share it with the rest of us.


                    You can use policyd v2 to throttle users to X mails over Y time span.


                    Thanks.  This might be the way to go as it also would address
                    the case of local users if their system is compromised.

                    Would you happen to know how it behaves when the SQL backend
                    isn't available?  I know sqlgrey keeps working OK if the DB is
                    unreachable.

                    --Donald

                  • Jeroen Geilman
                    ... That depends way too much on your particular setup. ... For such scenarios, even tighter restrictions (enforced by methods external to postfix) would seem
                    Message 9 of 11 , Mar 31, 2011
                    • 0 Attachment
                      On 03/31/2011 08:36 PM, D G Teed wrote:

                      On Thu, Mar 31, 2011 at 1:41 PM, Stan Hoeppner <stan@...> wrote:
                      D G Teed put forth on 3/31/2011 10:21 AM:

                      > I'd like some idea of what real world values would be useful, or additional
                      > suggestions
                      > on how to make the performance less attractive to users of compromised
                      > accounts.

                      When you find a reasonable and effective solution to the phishing
                      problem please share it with the rest of us.

                      The only sure fire solution I'm currently aware of is mass executions of
                      stupid and/or ignorant people who have no business using a computer or
                      email.  The obvious problem with this solution is it requires
                      exterminating well over half the human race, including many/most of my
                      family members.  Not an appealing solution.

                      I think you misunderstood what I wrote.  I listed actual postfix
                      variables, looking for input on practical values.

                      That depends way too much on your particular setup.

                      This isn't unreasonable
                      to expect.  I've implemented restrictions on our webmail's SMTP
                      to the point that spammers login, send a few emails, find it doesn't work
                      for large number of recipients and then logout.

                      For such scenarios, even tighter restrictions (enforced by methods external to postfix) would seem appropriate: simply record the number of failed deliveries or spamassassin hits per web user, and disable the account if this exceeds some threshold.
                      Rest assured that the big webmail providers use quite advanced methods to detect hacked mail accounts that try to send spam - and they don't depend solely on the MTA to provide this protection.

                      It works and I'm not dreaming.
                      Horde developers have also set up limits which greatly discourage
                      spamming.  The only problem is we can't choke the number of
                      recipients on our general SMTP.
                      I was hoping for angles on rate limiting which normal users could live with but would be useless for spam.  In the couple of responses so far, it seems it requires
                      something external - too bad it requires more layers - I hoped it was within
                      the capabilities of anvil and such.

                      Rate limiting is certainly within anvil's capabilities, but you don't want to constrain this on your external smtpd(8) listener.
                      Use submission instead.

                      Submission cleanly separates incoming mail from the Internet from submissions by your own users, with no chance of the two types of traffic mingling.
                      A separate smtpd(8) listener purely for webmail is also a good idea - this doesn't even have to listen on the network.

                      All of these can have distinct restrictions placed on the traffic they accept.

                      Actually, this conversation has me thinking, maybe we should have a dedicated
                      SMTP just for external SMTP + TLS + SASL.  That way I can do the same
                      recipient limit throttling and tell people not to expect it will work for mass
                      mail outs.

                      Yes: it's called "submission"; it runs on port 587 by default and was invented for this purpose.
                      You could also provide the people that need mass mailing with "special" accounts that have less strict limits.

                      -- 
                      J.
                      
                    • lst_hoe02@kwsoft.de
                      ... If you don t like rate-limits you might go with content-filter on *outgoing* mail and instead of inserting headers or dropping the mail put mail on hold
                      Message 10 of 11 , Mar 31, 2011
                      • 0 Attachment
                        Zitat von D G Teed <donald.teed@...>:

                        > On Thu, Mar 31, 2011 at 1:41 PM, Stan Hoeppner <stan@...>wrote:
                        >
                        >> D G Teed put forth on 3/31/2011 10:21 AM:
                        >>
                        >> > I'd like some idea of what real world values would be useful, or
                        >> additional
                        >> > suggestions
                        >> > on how to make the performance less attractive to users of compromised
                        >> > accounts.
                        >>
                        >> When you find a reasonable and effective solution to the phishing
                        >> problem please share it with the rest of us.
                        >>
                        >> The only sure fire solution I'm currently aware of is mass executions of
                        >> stupid and/or ignorant people who have no business using a computer or
                        >> email. The obvious problem with this solution is it requires
                        >> exterminating well over half the human race, including many/most of my
                        >> family members. Not an appealing solution.
                        >>
                        >
                        > I think you misunderstood what I wrote. I listed actual postfix
                        > variables, looking for input on practical values. This isn't unreasonable
                        > to expect. I've implemented restrictions on our webmail's SMTP
                        > to the point that spammers login, send a few emails, find it doesn't work
                        > for large number of recipients and then logout. It works and I'm not
                        > dreaming.
                        > Horde developers have also set up limits which greatly discourage
                        > spamming. The only problem is we can't choke the number of
                        > recipients on our general SMTP.
                        >
                        > I was hoping for angles on rate limiting which normal users could live with
                        > but would be useless for spam. In the couple of responses so far, it seems
                        > it requires
                        > something external - too bad it requires more layers - I hoped it was within
                        > the capabilities of anvil and such.
                        >
                        > Actually, this conversation has me thinking, maybe we should have a
                        > dedicated
                        > SMTP just for external SMTP + TLS + SASL. That way I can do the same
                        > recipient limit throttling and tell people not to expect it will work for
                        > mass
                        > mail outs.

                        If you don't like rate-limits you might go with content-filter on
                        *outgoing* mail and instead of inserting headers or dropping the mail
                        put mail on hold and disable the account in question if some
                        "spaminess" limit is reached. This no easy lightwight/solution either
                        but you can get away without rate-limits.

                        Regards

                        Andreas
                      • Gábor Lénárt
                        ... Sounds reasonable, we have something like +200K mail accounts, and really, only something like a dozen user told us they want to send mass-mail (well, not
                        Message 11 of 11 , Apr 3, 2011
                        • 0 Attachment
                          On Thu, Mar 31, 2011 at 07:51:43PM +0200, Ralf Hildebrandt wrote:
                          > > Are there any suggestions on how to tune postfix to limit the spam
                          > > throughput?
                          > > There are also legitimate users who have bulk email to send, so
                          > > limiting by recipient quantity (as we do on our webmail) wouldn't be
                          > > desirable.
                          >
                          > You probably need a policy server which limits the sender to a certain
                          > amount of mails per time unit. If that limit is being exceeded, you
                          > could either tempfail the mails until some human admin lifts the ban
                          > OR put the mails on hold.

                          Sounds reasonable, we have something like +200K mail accounts, and really,
                          only something like a dozen user told us they want to send mass-mail (well,
                          not spam but "legitime" one), all the others seems to be sending "some"
                          mails sometimes. So it can be a good rule, that most people won't send even
                          100 mails per hour "by hand", and if this limit is exceeded then it can be
                          some kind of non-reported mass mail sending (we can ask our customers to
                          tell us if they want to send more mails, so the limit for a user can be set
                          to a higher value), or some compromised account. Especially, I found it
                          useful to check the IP of the peer, if its not own IP address space, and not
                          even some other big ISPs nearby it's almost always spam. It's quite rare
                          that compromised user accounts are used to send spam from our IP pool (it's
                          another story that some customers have MTAs using us as relay, but they
                          forget their MTAs as open relay .........)

                          - Gábor
                        Your message has been successfully submitted and would be delivered to recipients shortly.