1

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.

1

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?

  • Yeah, my main goal is to ban IPs which repeatedly try and fail, but for a limited time. – Hack Saw Nov 5 '18 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 '18 at 14:59
0

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.

0

I have a solution which helps somewhat. The messages you list look like the ones that come from /var/log/secure (at least on RedHat/Centos).

As you noticed, there is no IP, so you can't do much with those entries.

However, take a look in /var/log/maillog and you will find entries looking like:

Apr 11 13:58:48 alpha sendmail[23712]: x3BKwjij023712: [118.24.45.165] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

These are connections which attempt an AUTH (or two), fail and disconnect. There is almost a 100% correlation between these and the pam messages in /var/log/secure.

I use these as input to a fail2ban jail. A single occurrence wins a ban, because a lot of the automated systems probing use a full class C (or /24 if you prefer) address space and it's quite a long time before you see that address again.

I currently have someone/thing that seems to be using a botnet, with IPs scattered all over. They seem to only repeat after days, sometimes never. You do end up with a LOT of fail2ban entries. But its better than doing nothing.

  • Ooooo, promising! – Hack Saw Apr 13 at 5:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.