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

Disabling SMTP Auth per user

Expand Messages
  • List
    We are currently using dovecot for smtp auth, and due to an increase in spammers abusing smtp auth we setup dovecot to return an invalid login for user s that
    Message 1 of 7 , Oct 2, 2013
    • 0 Attachment
      We are currently using dovecot for smtp auth, and due to an increase in
      spammers abusing smtp auth we setup dovecot to return an invalid login
      for user's that have been set to "disabled" in our provisioning system.
      This seemed to work for a while (preventing spammers that are using
      auth), but we are finding that a number of spammers are somehow keeping
      their smtp connection open after we have "disabled" smtp auth and
      continuing to send messages even though the authentication should be
      failing. We are not sure why this is the behavior or even what we
      should be looking for to determine how they are circumventing the
      authentication.

      postconf -n:

      alias_database = hash:/etc/aliases
      alias_maps = hash:/etc/aliases
      broken_sasl_auth_clients = yes
      command_directory = /usr/sbin
      config_directory = /etc/postfix
      daemon_directory = /usr/libexec/postfix
      data_directory = /var/lib/postfix
      debug_peer_level = 2
      default_destination_recipient_limit = 1000
      default_process_limit = 1000
      header_checks = regexp:/etc/postfix/header_checks
      html_directory = no
      inet_interfaces = all
      inet_protocols = all
      mail_owner = postfix
      mailbox_size_limit = 52224000
      mailq_path = /usr/bin/mailq.postfix
      manpage_directory = /usr/share/man
      message_size_limit = 52224000
      mydestination = $myhostname, localhost.$mydomain, localhost
      myhostname = server.domain.tld
      mynetworks = $config_directory/mynetworks
      newaliases_path = /usr/bin/newaliases.postfix
      queue_directory = /var/spool/postfix
      readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
      recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
      relayhost = relay.domain.tld
      sample_directory = /usr/share/doc/postfix-2.6.6/samples
      sendmail_path = /usr/sbin/sendmail.postfix
      setgid_group = postdrop
      smtp_data_done_timeout = 900s
      smtp_data_init_timeout = 900s
      smtp_data_xfer_timeout = 900s
      smtp_helo_timeout = 900s
      smtp_mail_timeout = 900s
      smtp_tls_note_starttls_offer = yes
      smtpd_client_event_limit_exceptions = static:all
      smtpd_helo_required = yes
      smtpd_recipient_restrictions = permit_mynetworks, check_client_access
      mysql:/etc/postfix/authb4smtp.cf, check_client_access
      cidr:/etc/postfix/access permit_sasl_authenticated,
      reject_unauth_destination
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_path = private/auth
      smtpd_sasl_security_options = noanonymous
      smtpd_sasl_type = dovecot
      smtpd_sender_restrictions = reject_unknown_sender_domain,
      reject_non_fqdn_sender, permit
      smtpd_tls_CAfile = /etc/postfix/tls.ca.crt
      smtpd_tls_auth_only = no
      smtpd_tls_cert_file = /etc/postfix/tls.crt
      smtpd_tls_key_file = /etc/postfix/tls.key
      smtpd_tls_loglevel = 1
      smtpd_tls_received_header = yes
      smtpd_tls_security_level = may
      smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_cache
      smtpd_tls_session_cache_timeout = 3600s
      tls_random_source = dev:/dev/urandom
      unknown_local_recipient_reject_code = 550
    • Viktor Dukhovni
      ... The full story is in your logs. Find a message sent by a disabled user after the account was disabled. Find the associated stmpd(8) connect and
      Message 2 of 7 , Oct 2, 2013
      • 0 Attachment
        On Wed, Oct 02, 2013 at 10:17:16AM -0500, List wrote:

        > We are currently using dovecot for smtp auth, and due to an increase
        > in spammers abusing smtp auth we setup dovecot to return an invalid
        > login for user's that have been set to "disabled" in our
        > provisioning system. This seemed to work for a while (preventing
        > spammers that are using auth), but we are finding that a number of
        > spammers are somehow keeping their smtp connection open after we
        > have "disabled" smtp auth and continuing to send messages even
        > though the authentication should be failing. We are not sure why
        > this is the behavior or even what we should be looking for to
        > determine how they are circumventing the authentication.

        The full story is in your logs. Find a message sent by a disabled
        user after the account was disabled. Find the associated stmpd(8)
        connect and disconnect log entries. If a single connection continues
        to generate messages long after the account is disabled, then indeed
        your description is correct.

        Regardless of whether you've disabled an account or not, you should
        probably use a policy service that limits the message rate from a
        a given SASL user account (returning a 421 error code when the rate
        is exceeded). The policy service can also check whether the account
        has been disabled. This check will not be cached (unlike the SASL
        login status of the SMTP connection).

        --
        Viktor.
      • List
        ... Indeed, we are actually writing a policy service now to deal with rate limits and blacklisting/whitelisting SASL. One thing I noticed in the documentation
        Message 3 of 7 , Oct 2, 2013
        • 0 Attachment
          On 10/2/13 10:32 AM, Viktor Dukhovni wrote:
          On Wed, Oct 02, 2013 at 10:17:16AM -0500, List wrote:
          
          
          We are currently using dovecot for smtp auth, and due to an increase
          in spammers abusing smtp auth we setup dovecot to return an invalid
          login for user's that have been set to "disabled" in our
          provisioning system.  This seemed to work for a while (preventing
          spammers that are using auth), but we are finding that a number of
          spammers are somehow keeping their smtp connection open after we
          have "disabled" smtp auth and continuing to send messages even
          though the authentication should be failing.  We are not sure why
          this is the behavior or even what we should be looking for to
          determine how they are circumventing the authentication.
          
          The full story is in your logs.  Find a message sent by a disabled
          user after the account was disabled.  Find the associated stmpd(8)
          connect and disconnect log entries.  If a single connection continues
          to generate messages long after the account is disabled, then indeed
          your description is correct.
          
          Regardless of whether you've disabled an account or not,  you should
          probably use a policy service that limits the message rate from a
          a given SASL user account (returning a 421 error code when the rate
          is exceeded).  The policy service can also check whether the account
          has been disabled.  This check will not be cached (unlike the SASL
          login status of the SMTP connection).
          
          
          Indeed, we are actually writing a policy service now to deal with rate limits and blacklisting/whitelisting SASL.  One thing I noticed in the documentation regarding smtpd_recipient_restrictions (under " Dangerous use of smtpd_recipient_restrictions") is that recipient restrictions can result in too permissive access.  I wonder if moving the check_client_access and permit_sasl_authenticated below reject_unauth_destination would help?

          smtpd_recipient_restrictions =
                     #### Permit networks defined in /etc/postfix/mynetworks
                     permit_mynetworks
                     reject_unauth_destination
                     #### POP/IMAP before SMTP
                     check_client_access mysql:/etc/postfix/authb4smtp.cf
                     check_client_access cidr:/etc/postfix/access
                     #### Permit SASL authenticated
                     permit_sasl_authenticated

          Also I understand that smtp_client_restrictions is the first to be evaluated, would it make sense to move the permit_sasl_authenticated into this access restriction or not so much?

           
        • Viktor Dukhovni
          ... Don t. ... Too late, their outbound mail has already been rejected. ... No. Take time to understand how Postfix restrictions work. With Postfix 2.10 or
          Message 4 of 7 , Oct 2, 2013
          • 0 Attachment
            On Wed, Oct 02, 2013 at 10:46:12AM -0500, List wrote:

            > One thing I noticed
            > in the documentation regarding smtpd_recipient_restrictions (under "
            > Dangerous use of smtpd_recipient_restrictions") is that recipient
            > restrictions can result in too permissive access. I wonder if
            > moving the check_client_access and permit_sasl_authenticated below
            > reject_unauth_destination would help?

            Don't.

            >
            > smtpd_recipient_restrictions =
            > #### Permit networks defined in /etc/postfix/mynetworks
            > permit_mynetworks
            > reject_unauth_destination
            > #### POP/IMAP before SMTP
            > check_client_access mysql:/etc/postfix/authb4smtp.cf
            > check_client_access cidr:/etc/postfix/access
            > #### Permit SASL authenticated
            > permit_sasl_authenticated

            Too late, their outbound mail has already been rejected.

            > Also I understand that smtp_client_restrictions is the first to be
            > evaluated, would it make sense to move the permit_sasl_authenticated
            > into this access restriction or not so much?

            No. Take time to understand how Postfix restrictions work.

            With Postfix 2.10 or later you can use "smtpd_relay_restrictions"
            to avoid being an open relay, and do anti-spam control in the
            various other restriction classes. Some duplication of permissive
            controls is then inevitable, but you're no longer at risk of becoming
            an open relay due to ordering problems.

            --
            Viktor.
          • Manuel Bieling
            ... Moving check_client_access below reject_unauth_destination prevents you from wildcards in check_client_access which can make you an open relay. Just
            Message 5 of 7 , Oct 2, 2013
            • 0 Attachment
              On 10/02/2013 05:46 PM, List wrote:
              > I wonder if moving the
              > check_client_access and permit_sasl_authenticated below
              > reject_unauth_destination would help?

              Moving 'check_client_access' below 'reject_unauth_destination'
              prevents you from wildcards in 'check_client_access' which can make you
              an open relay. Just best practice and not a must.

              > smtpd_recipient_restrictions =
              > #### Permit networks defined in /etc/postfix/mynetworks
              > permit_mynetworks
              > reject_unauth_destination
              > #### POP/IMAP before SMTP
              > check_client_access mysql:/etc/postfix/authb4smtp.cf
              > check_client_access cidr:/etc/postfix/access
              > #### Permit SASL authenticated
              > permit_sasl_authenticated

              I'm wondering what 'permit_sasl_authenticated' effects? If you have
              already rejected unauth destination. Keep in mind "Restrictions are
              applied in the order as specified; the first restriction that matches wins".

              > Also I understand that smtp_client_restrictions is the first to be
              > evaluated, would it make sense to move the permit_sasl_authenticated
              > into this access restriction or not so much?

              Do you mean 'smtpd_client_restrictions'?

              Since 'reject_unauth_destination' is not allowed in
              'smtpd_client_restrictions' you will need 'permit_sasl_authenticated' in
              'smtpd_recipient_restrictions' too.

              In general 'smtpd_client_restrictions' is not want you want. You don't
              want client side authentication. You want authentication for sending
              mails, I think.

              Finally authenticated users via 'permit_sasl_authenticated' can avoid
              'spam checking', 'policy, gray listing' as early as it is checked. But
              that is only relevant for 'smtpd_relay_restrictions'

              http://www.postfix.org/SMTPD_ACCESS_README.html


              Manuel Bieling
            • Viktor Dukhovni
              ... No, it simply breaks POP before SMTP. So the original order is correct. However, now that we see that the OP is using POP before SMTP, it is quite likely
              Message 6 of 7 , Oct 2, 2013
              • 0 Attachment
                On Wed, Oct 02, 2013 at 07:08:48PM +0200, Manuel Bieling wrote:

                > >I wonder if moving the
                > >check_client_access and permit_sasl_authenticated below
                > >reject_unauth_destination would help?
                >
                > Moving 'check_client_access' below 'reject_unauth_destination'
                > prevents you from wildcards in 'check_client_access' which can make
                > you an open relay. Just best practice and not a must.

                No, it simply breaks POP before SMTP. So the original order is
                correct.

                However, now that we see that the OP is using POP before SMTP, it
                is quite likely the POP before SMTP cache, rather than SMTP auth
                that is at issue with the spammers in question. Once SASL is up
                and running, it is wise to stop supporting the POP before SMTP
                crutch.

                --
                Viktor.
              • Manuel Bieling
                ... Aha I see, interesting relict Manuel Bieling
                Message 7 of 7 , Oct 2, 2013
                • 0 Attachment
                  On 10/02/2013 07:12 PM, Viktor Dukhovni wrote:
                  > However, now that we see that the OP is using POP before SMTP

                  Aha I see, interesting relict


                  Manuel Bieling
                Your message has been successfully submitted and would be delivered to recipients shortly.