Failure to report rhosts

Bug #1657897 reported by James Stevenson on 2017-01-19
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cyrus-sasl2
New
Unknown
cyrus-sasl2 (Ubuntu)
Wishlist
Unassigned

Bug Description

When using sasl2-bin and saslauthd it will fail to work correctly with pam.

The first major problem is that that it will fail to report the rhost address in the log which means auth failures cannot be policed and no useful data (the ip address) is reported to the log file. Example below during a password brute force attempt.

Jan 19 21:57:16 mail saslauthd[1534]: pam_unix(smtp:auth): check pass; user unknown
Jan 19 21:57:16 mail saslauthd[1534]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=

The other issue is that it would be great to be able to ip restrict logins based on pam module configuration. Based on previous reading and as far as I can tell the remote ip address is not supported between the imap/pop/smtp process and sasl2 is it possible to add support for this?

Technically this is a long standing security issue because fail2ban cannot be used to process the syslog file and auto block the host during brute force password attempts.

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.

Changed in cyrus-sasl2 (Ubuntu):
status: New → Incomplete
James Stevenson (ja7es) wrote :

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

Joshua Powers (powersj) wrote :

@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

James Stevenson (ja7es) wrote :

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.

Changed in cyrus-sasl2 (Ubuntu):
status: Incomplete → Confirmed
Andreas Hasenack (ahasenack) wrote :

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")

Andreas Hasenack (ahasenack) wrote :

I think we should defer to upstream on this one.

Changed in cyrus-sasl2 (Ubuntu):
importance: Undecided → Critical
importance: Critical → Wishlist
status: Confirmed → Triaged
Changed in cyrus-sasl2:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.