How is sendmail SMTP authentication logging controlled?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP

up vote
1
down vote

favorite

I get a ton of failed SMTP login attempts. I’d really like to defend against it, but the logging of those attempts is poor.

I’m using sendmail 8.15, cyrus-sasl 2.1.26. The SASL setup is the simplest way, defaults all around, authenticating with pam_unix.

I get log messages like this a lot:

saslauthd[8292]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[8292]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[8292]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[8292]: do_auth         : auth failure: [user=colby] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

This means that while I know bogus attempts to login are happening, I can’t really do anything about it, like have fail2ban jail them.

I can’t really tell if the problem is that Sendmail is telling pam_unix things, and it’s dumping them, or if sendmail isn’t telling pam about where the attempt is being made.

What I want is for auth attempts to be logged with the ip address where it came from, so if there are a lot of failures, fail2ban can jail the IP.

share|improve this question

    up vote
    1
    down vote

    favorite

    I get a ton of failed SMTP login attempts. I’d really like to defend against it, but the logging of those attempts is poor.

    I’m using sendmail 8.15, cyrus-sasl 2.1.26. The SASL setup is the simplest way, defaults all around, authenticating with pam_unix.

    I get log messages like this a lot:

    saslauthd[8292]: pam_unix(smtp:auth): check pass; user unknown
    saslauthd[8292]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
    saslauthd[8292]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
    saslauthd[8292]: do_auth         : auth failure: [user=colby] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
    

    This means that while I know bogus attempts to login are happening, I can’t really do anything about it, like have fail2ban jail them.

    I can’t really tell if the problem is that Sendmail is telling pam_unix things, and it’s dumping them, or if sendmail isn’t telling pam about where the attempt is being made.

    What I want is for auth attempts to be logged with the ip address where it came from, so if there are a lot of failures, fail2ban can jail the IP.

    share|improve this question

      up vote
      1
      down vote

      favorite

      up vote
      1
      down vote

      favorite

      I get a ton of failed SMTP login attempts. I’d really like to defend against it, but the logging of those attempts is poor.

      I’m using sendmail 8.15, cyrus-sasl 2.1.26. The SASL setup is the simplest way, defaults all around, authenticating with pam_unix.

      I get log messages like this a lot:

      saslauthd[8292]: pam_unix(smtp:auth): check pass; user unknown
      saslauthd[8292]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
      saslauthd[8292]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
      saslauthd[8292]: do_auth         : auth failure: [user=colby] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
      

      This means that while I know bogus attempts to login are happening, I can’t really do anything about it, like have fail2ban jail them.

      I can’t really tell if the problem is that Sendmail is telling pam_unix things, and it’s dumping them, or if sendmail isn’t telling pam about where the attempt is being made.

      What I want is for auth attempts to be logged with the ip address where it came from, so if there are a lot of failures, fail2ban can jail the IP.

      share|improve this question

      I get a ton of failed SMTP login attempts. I’d really like to defend against it, but the logging of those attempts is poor.

      I’m using sendmail 8.15, cyrus-sasl 2.1.26. The SASL setup is the simplest way, defaults all around, authenticating with pam_unix.

      I get log messages like this a lot:

      saslauthd[8292]: pam_unix(smtp:auth): check pass; user unknown
      saslauthd[8292]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
      saslauthd[8292]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
      saslauthd[8292]: do_auth         : auth failure: [user=colby] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
      

      This means that while I know bogus attempts to login are happening, I can’t really do anything about it, like have fail2ban jail them.

      I can’t really tell if the problem is that Sendmail is telling pam_unix things, and it’s dumping them, or if sendmail isn’t telling pam about where the attempt is being made.

      What I want is for auth attempts to be logged with the ip address where it came from, so if there are a lot of failures, fail2ban can jail the IP.

      pam sendmail sasl

      share|improve this question

      share|improve this question

      share|improve this question

      share|improve this question

      edited 20 hours ago

      asked Nov 5 at 22:43

      Hack Saw

      654310

      654310

          2 Answers
          2

          active

          oldest

          votes

          up vote
          1
          down vote

          The session here is split out between the mail transport agent and also saslauthd:

          testhost saslauthd[17177]: do_auth         : auth failure:
            [user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
            [reason=PAM auth error]
          

          A complete log of what you want may not be available by default or will require reconstruction under some log aggregation service. (The logging is also bad under Postfix when using saslauthd; some of the logs end up in the mail logs, and others elsewhere.) Sendmail does support custom syslog rules; however, if a client only issues EHLO nurse, AUTH LOGIN, QXp1cmVEaWFtb25k, SHVudGVyMg== and then fails (with a quit or by simply dropping the connection) that may not give any of the usual ruleset hooks a chance to run.

          With the LogLevel turned up to 11 (or higher) there is a log on failure that does include the relay address:

          testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
            (LOGIN): authentication failure (-13) SASL(-13):
            authentication failure: checkpass failed,
            relay=localhost [127.0.0.1]
          

          This comes from sendmail/srvrsmtp.c and happens when LogLevel > 9. Or you could patch that file to avoid increasing the LogLevel, but that may introduce different problems.

          Other methods to limit SMTP AUTH follow.

          pam limit to a particular group

          Adjust the PAM configuration and disallow SMTP AUTH unless the user belongs to a particular group; this will prevent mosts password guessing attacks though is viable if only a small and predictable subset of your users need to use SMTP AUTH:

          account     required      pam_access.so accessfile=/etc/security/smtp_access.conf
          

          and then in /etc/security/smtp_access.conf

          + : ok-sasl : ALL
          - : ALL : ALL
          

          and then put the users into the ok-sasl group.

          hide the SMTP AUTH service

          Another option would be to put a VPN or something in front of SMTP so that service is simply not available to the Internet; this should cut down on the spray of log noise a public-facing service receives these days.

          pam_tally

          I’ve also tried pam_tally2 but that was very good at locking out accounts, including legitimate accounts who had logged in without any apparent errors…maybe it will work better for you?

          share|improve this answer

          • Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
            – Hack Saw
            Nov 5 at 23:59

          • I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
            – Hack Saw
            Nov 6 at 14:59

          up vote
          0
          down vote

          accepted

          Sadly, the answer seems to be that with sendmail and cyrus-sasl, there is no control. Sendmail seems to send the info to sasl, and cyrus-sasl does nothing with it, and equally sendmail does nothing after the authentication fails.

          Thrig’s answers above may prove useful to others, and perhaps one day someone will see this, and provide a better answer.

          share|improve this answer

            Your Answer

            StackExchange.ready(function() {
            var channelOptions = {
            tags: “”.split(” “),
            id: “106”
            };
            initTagRenderer(“”.split(” “), “”.split(” “), channelOptions);

            StackExchange.using(“externalEditor”, function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using(“snippets”, function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: ‘answer’,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: “”,
            imageUploader: {
            brandingHtml: “Powered by u003ca class=”icon-imgur-white” href=”https://imgur.com/”u003eu003c/au003e”,
            contentPolicyHtml: “User contributions licensed under u003ca href=”https://creativecommons.org/licenses/by-sa/3.0/”u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href=”https://stackoverflow.com/legal/content-policy”u003e(content policy)u003c/au003e”,
            allowUrls: true
            },
            onDemand: true,
            discardSelector: “.discard-answer”
            ,immediatelyShowMarkdownHelp:true
            });

            }
            });

             
            draft saved
            draft discarded

            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2funix.stackexchange.com%2fquestions%2f480000%2fhow-is-sendmail-smtp-authentication-logging-controlled%23new-answer’, ‘question_page’);
            }
            );

            Post as a guest

            2 Answers
            2

            active

            oldest

            votes

            2 Answers
            2

            active

            oldest

            votes

            active

            oldest

            votes

            active

            oldest

            votes

            up vote
            1
            down vote

            The session here is split out between the mail transport agent and also saslauthd:

            testhost saslauthd[17177]: do_auth         : auth failure:
              [user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
              [reason=PAM auth error]
            

            A complete log of what you want may not be available by default or will require reconstruction under some log aggregation service. (The logging is also bad under Postfix when using saslauthd; some of the logs end up in the mail logs, and others elsewhere.) Sendmail does support custom syslog rules; however, if a client only issues EHLO nurse, AUTH LOGIN, QXp1cmVEaWFtb25k, SHVudGVyMg== and then fails (with a quit or by simply dropping the connection) that may not give any of the usual ruleset hooks a chance to run.

            With the LogLevel turned up to 11 (or higher) there is a log on failure that does include the relay address:

            testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
              (LOGIN): authentication failure (-13) SASL(-13):
              authentication failure: checkpass failed,
              relay=localhost [127.0.0.1]
            

            This comes from sendmail/srvrsmtp.c and happens when LogLevel > 9. Or you could patch that file to avoid increasing the LogLevel, but that may introduce different problems.

            Other methods to limit SMTP AUTH follow.

            pam limit to a particular group

            Adjust the PAM configuration and disallow SMTP AUTH unless the user belongs to a particular group; this will prevent mosts password guessing attacks though is viable if only a small and predictable subset of your users need to use SMTP AUTH:

            account     required      pam_access.so accessfile=/etc/security/smtp_access.conf
            

            and then in /etc/security/smtp_access.conf

            + : ok-sasl : ALL
            - : ALL : ALL
            

            and then put the users into the ok-sasl group.

            hide the SMTP AUTH service

            Another option would be to put a VPN or something in front of SMTP so that service is simply not available to the Internet; this should cut down on the spray of log noise a public-facing service receives these days.

            pam_tally

            I’ve also tried pam_tally2 but that was very good at locking out accounts, including legitimate accounts who had logged in without any apparent errors…maybe it will work better for you?

            share|improve this answer

            • Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
              – Hack Saw
              Nov 5 at 23:59

            • I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
              – Hack Saw
              Nov 6 at 14:59

            up vote
            1
            down vote

            The session here is split out between the mail transport agent and also saslauthd:

            testhost saslauthd[17177]: do_auth         : auth failure:
              [user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
              [reason=PAM auth error]
            

            A complete log of what you want may not be available by default or will require reconstruction under some log aggregation service. (The logging is also bad under Postfix when using saslauthd; some of the logs end up in the mail logs, and others elsewhere.) Sendmail does support custom syslog rules; however, if a client only issues EHLO nurse, AUTH LOGIN, QXp1cmVEaWFtb25k, SHVudGVyMg== and then fails (with a quit or by simply dropping the connection) that may not give any of the usual ruleset hooks a chance to run.

            With the LogLevel turned up to 11 (or higher) there is a log on failure that does include the relay address:

            testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
              (LOGIN): authentication failure (-13) SASL(-13):
              authentication failure: checkpass failed,
              relay=localhost [127.0.0.1]
            

            This comes from sendmail/srvrsmtp.c and happens when LogLevel > 9. Or you could patch that file to avoid increasing the LogLevel, but that may introduce different problems.

            Other methods to limit SMTP AUTH follow.

            pam limit to a particular group

            Adjust the PAM configuration and disallow SMTP AUTH unless the user belongs to a particular group; this will prevent mosts password guessing attacks though is viable if only a small and predictable subset of your users need to use SMTP AUTH:

            account     required      pam_access.so accessfile=/etc/security/smtp_access.conf
            

            and then in /etc/security/smtp_access.conf

            + : ok-sasl : ALL
            - : ALL : ALL
            

            and then put the users into the ok-sasl group.

            hide the SMTP AUTH service

            Another option would be to put a VPN or something in front of SMTP so that service is simply not available to the Internet; this should cut down on the spray of log noise a public-facing service receives these days.

            pam_tally

            I’ve also tried pam_tally2 but that was very good at locking out accounts, including legitimate accounts who had logged in without any apparent errors…maybe it will work better for you?

            share|improve this answer

            • Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
              – Hack Saw
              Nov 5 at 23:59

            • I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
              – Hack Saw
              Nov 6 at 14:59

            up vote
            1
            down vote

            up vote
            1
            down vote

            The session here is split out between the mail transport agent and also saslauthd:

            testhost saslauthd[17177]: do_auth         : auth failure:
              [user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
              [reason=PAM auth error]
            

            A complete log of what you want may not be available by default or will require reconstruction under some log aggregation service. (The logging is also bad under Postfix when using saslauthd; some of the logs end up in the mail logs, and others elsewhere.) Sendmail does support custom syslog rules; however, if a client only issues EHLO nurse, AUTH LOGIN, QXp1cmVEaWFtb25k, SHVudGVyMg== and then fails (with a quit or by simply dropping the connection) that may not give any of the usual ruleset hooks a chance to run.

            With the LogLevel turned up to 11 (or higher) there is a log on failure that does include the relay address:

            testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
              (LOGIN): authentication failure (-13) SASL(-13):
              authentication failure: checkpass failed,
              relay=localhost [127.0.0.1]
            

            This comes from sendmail/srvrsmtp.c and happens when LogLevel > 9. Or you could patch that file to avoid increasing the LogLevel, but that may introduce different problems.

            Other methods to limit SMTP AUTH follow.

            pam limit to a particular group

            Adjust the PAM configuration and disallow SMTP AUTH unless the user belongs to a particular group; this will prevent mosts password guessing attacks though is viable if only a small and predictable subset of your users need to use SMTP AUTH:

            account     required      pam_access.so accessfile=/etc/security/smtp_access.conf
            

            and then in /etc/security/smtp_access.conf

            + : ok-sasl : ALL
            - : ALL : ALL
            

            and then put the users into the ok-sasl group.

            hide the SMTP AUTH service

            Another option would be to put a VPN or something in front of SMTP so that service is simply not available to the Internet; this should cut down on the spray of log noise a public-facing service receives these days.

            pam_tally

            I’ve also tried pam_tally2 but that was very good at locking out accounts, including legitimate accounts who had logged in without any apparent errors…maybe it will work better for you?

            share|improve this answer

            The session here is split out between the mail transport agent and also saslauthd:

            testhost saslauthd[17177]: do_auth         : auth failure:
              [user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
              [reason=PAM auth error]
            

            A complete log of what you want may not be available by default or will require reconstruction under some log aggregation service. (The logging is also bad under Postfix when using saslauthd; some of the logs end up in the mail logs, and others elsewhere.) Sendmail does support custom syslog rules; however, if a client only issues EHLO nurse, AUTH LOGIN, QXp1cmVEaWFtb25k, SHVudGVyMg== and then fails (with a quit or by simply dropping the connection) that may not give any of the usual ruleset hooks a chance to run.

            With the LogLevel turned up to 11 (or higher) there is a log on failure that does include the relay address:

            testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
              (LOGIN): authentication failure (-13) SASL(-13):
              authentication failure: checkpass failed,
              relay=localhost [127.0.0.1]
            

            This comes from sendmail/srvrsmtp.c and happens when LogLevel > 9. Or you could patch that file to avoid increasing the LogLevel, but that may introduce different problems.

            Other methods to limit SMTP AUTH follow.

            pam limit to a particular group

            Adjust the PAM configuration and disallow SMTP AUTH unless the user belongs to a particular group; this will prevent mosts password guessing attacks though is viable if only a small and predictable subset of your users need to use SMTP AUTH:

            account     required      pam_access.so accessfile=/etc/security/smtp_access.conf
            

            and then in /etc/security/smtp_access.conf

            + : ok-sasl : ALL
            - : ALL : ALL
            

            and then put the users into the ok-sasl group.

            hide the SMTP AUTH service

            Another option would be to put a VPN or something in front of SMTP so that service is simply not available to the Internet; this should cut down on the spray of log noise a public-facing service receives these days.

            pam_tally

            I’ve also tried pam_tally2 but that was very good at locking out accounts, including legitimate accounts who had logged in without any apparent errors…maybe it will work better for you?

            share|improve this answer

            share|improve this answer

            share|improve this answer

            edited Nov 6 at 21:02

            answered Nov 5 at 23:12

            thrig

            23.4k12955

            23.4k12955

            • Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
              – Hack Saw
              Nov 5 at 23:59

            • I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
              – Hack Saw
              Nov 6 at 14:59

            • Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
              – Hack Saw
              Nov 5 at 23:59

            • I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
              – Hack Saw
              Nov 6 at 14:59

            Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
            – Hack Saw
            Nov 5 at 23:59

            Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time.
            – Hack Saw
            Nov 5 at 23:59

            I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
            – Hack Saw
            Nov 6 at 14:59

            I’m now looking at source code, and being reminded why I have a liking for functional programming. The logging around the sasl auth attempt seems to be devoid of logging hooks, instead preferring to allow sasl to give the details. From what I see, sasl has the info (maybe), but doesn’t bother to put it in the error output.
            – Hack Saw
            Nov 6 at 14:59

            up vote
            0
            down vote

            accepted

            Sadly, the answer seems to be that with sendmail and cyrus-sasl, there is no control. Sendmail seems to send the info to sasl, and cyrus-sasl does nothing with it, and equally sendmail does nothing after the authentication fails.

            Thrig’s answers above may prove useful to others, and perhaps one day someone will see this, and provide a better answer.

            share|improve this answer

              up vote
              0
              down vote

              accepted

              Sadly, the answer seems to be that with sendmail and cyrus-sasl, there is no control. Sendmail seems to send the info to sasl, and cyrus-sasl does nothing with it, and equally sendmail does nothing after the authentication fails.

              Thrig’s answers above may prove useful to others, and perhaps one day someone will see this, and provide a better answer.

              share|improve this answer

                up vote
                0
                down vote

                accepted

                up vote
                0
                down vote

                accepted

                Sadly, the answer seems to be that with sendmail and cyrus-sasl, there is no control. Sendmail seems to send the info to sasl, and cyrus-sasl does nothing with it, and equally sendmail does nothing after the authentication fails.

                Thrig’s answers above may prove useful to others, and perhaps one day someone will see this, and provide a better answer.

                share|improve this answer

                Sadly, the answer seems to be that with sendmail and cyrus-sasl, there is no control. Sendmail seems to send the info to sasl, and cyrus-sasl does nothing with it, and equally sendmail does nothing after the authentication fails.

                Thrig’s answers above may prove useful to others, and perhaps one day someone will see this, and provide a better answer.

                share|improve this answer

                share|improve this answer

                share|improve this answer

                answered 20 hours ago

                Hack Saw

                654310

                654310

                     
                    draft saved
                    draft discarded

                     

                    draft saved

                    draft discarded

                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2funix.stackexchange.com%2fquestions%2f480000%2fhow-is-sendmail-smtp-authentication-logging-controlled%23new-answer’, ‘question_page’);
                    }
                    );

                    Post as a guest

                    Related Post

                    Leave a Reply

                    Your email address will not be published. Required fields are marked *