Failure to report rhosts

Hi James,
thank your for your report and your help to make Ubuntu better.
These are essentially two issues in one.

For the first being "fail sasl+pam" - would you have some steps to reproduce the issue.
At least I must admit I never set them up, and others coming by to help might as well.
So if you'd have a bit of a guide how to trigger the issue that would be great.
It might also help other users with the same issue to find more easily if they are facing the same that you report.

For the second issue about ip restrictions based on past login attempts I'd ask you to open up a new bug for it. Essentially as I read it that is a feature request against the upstream projects more than anything else - we should keep it separate from your issue #1 to avoid people being distracted between the two.

Hi, Thanks for the reply.

First of I will say that everything to reproduce this is a default configuration for saslauthd. You simply have to install it. The next part would be to install any of the other default like imapd(no configuration required) or sendmail(which does need configured). Or any other client that is capable of using saslauthd

Mayby this isn't understood well or I have come across badly. The problem here in ubuntu is that the saslauthd version in ubuntu doesn't support passing the rhost (the remote ip address) from its front end service to the pam authentication lib's at all.

This make logging, blocking of remote ip addresses which are constantly trying usernames / passwords on mail servers via smtp, pop3, imap impossible to monitor, log and block as pam.d authfailure will fail to log any actionable information.

Here is more information on the same bug from redhat. https://bugzilla.redhat.com/show_bug.cgi?id=683797

The 2nd issue isn't so much of a feature request as it is actually the same functionality. You cannot have a pam module installed/configured in the system which can lookup say a dns blacklist or database of blocked ip addresses and block access though stand pam configuration that saslauthd uses by default. This makes all pam authentication configuration / logging based on the back of saslauthd that involves an ip address useless / redundant / non functional.

This isn't a new problem with saslauthd its just never been fixed.. It dates back to 2011. Across multiple systems and use this package.

https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2011-March/002218.html

@James, big thanks for the information I think your clarity about the logging of the rhost and the redhat bug helped a bit.

To help get work completed on this bug I tried to reproduce this by setting up a mail server using sasl using these steps [1]. I was then able to telnet to it from a remote host and attempt to login. In mail.log I got the following messages:

Jan 25 16:55:58 uvt-yakkety postfix/smtpd[3313]: connect from unknown[192.168.122.1]
Jan 25 16:56:13 uvt-yakkety postfix/smtpd[3313]: warning: unknown[192.168.122.1]: SASL login authentication failed: authentication failure

which show the remote host IP, however in auth.log I see:

Jan 25 16:56:12 uvt-yakkety saslauthd[3020]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=powersj
Jan 25 16:56:13 uvt-yakkety saslauthd[3020]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
Jan 25 16:56:13 uvt-yakkety saslauthd[3020]: do_auth : auth failure: [user=powersj] [service=smtp] [realm=uvt-yakkety] [mech=pam] [reason=PAM auth error]

I believe this replicated the issue, can you confirm?

[1] https://wiki.debian.org/PostfixAndSASL

Yes that is the correct issue occurring effectively pam never sees the rhost data from sendmail which can be seen in the auth log.

Jan 25 16:56:12 uvt-yakkety saslauthd[3020]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=powersj

I did some more investigating into this issue. From what I can tell the saslauthd client never sends the rhost to the saslauthd process and it isn't supported in the client/server protocol. So this is somewhat of a problem because of the design of the protocol and maintaining backwards compatibility with existing clients.

Is this log line enough for fail2ban purposes?

Jan 25 16:56:13 uvt-yakkety postfix/smtpd[3313]: warning: unknown[192.168.122.1]: SASL login authentication failed: authentication failure

You have:
- the service (smtpd)
- the ip (192.168.122.1)
- the failure reason ("authentication failure")

Upstream issue: https://github.com/cyrusimap/cyrus-sasl/issues/346

I think we should defer to upstream on this one.

A patch was proposed (and merged) in the linked upstream bug:

https://github.com/cyrusimap/cyrus-sasl/pull/6

This seems to be marked for the 2.2.0 release.

The next steps here would be to backport and verify the fix.