Description of problem:
By default, sendmail uses saslauthd for SMTP AUTH; saslauthd uses PAM for authentication. However, log entries do not contain the remote host IP/hostname or requested login, even though this capability is built into PAM and other daemons who use PAM (e.g. sshd, imapd, etc.) do properly record both the rhost and requested login.
For example, when saslauthd experiences an auth failure, it logs to /var/log/secure:
Mar 9 06:56:41 hostname saslauthd: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
When sshd logs a similar failure, it logs:
Mar 8 14:02:26 hostname sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=someuser
Note that sshd's log entry includes both the remote host (rhost) and the requested login (user); saslauthd does not include either one (the requested login is neither in "logname" nor "ruser").
As such, saslauthd's PAM log entries are of very limited utility, and are useless for brute force detection utilities (e.g. BFD or fail2ban).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fail an SMTP AUTH
2. Check and view the corresponding entry in /var/log/secure
3. Compare with a failed ssh login - note the missing rhost and user fields.
saslauthd-generated PAM log entry is missing rhost= and user= fields.
Entry should have proper values for rhost= and user=, just like sshd- and imapd-generated PAM logs do.
The underlying problem is that in saslauthd/auth_pam.c, the auth_pam() function does not include an argument for the remote host, nor a means of determining it within the code. The requested login name _is_ passed but is not recorded in the log. Thus, saslauthd throws away the remote host information before even checking PAM, and also fails to set the appropriate PAM property to record the requested login name.
It should be quite possible to modify auth_pam to determine the remote host (using sasl_getprop, perhaps) and then to set the appropriate PAM parameters (via pam_set_item, perhaps). See last year's discussion on the Cyrus SASL mailing list:
A patch to do this in a _very_ old version of Cyrus SASL is available (http://www.uklinux.net/software/cyrus-sasl-1.5.24-pam-rhost.patch), from when this code used to be in lib/checkpw.c... I am not entirely sure if this patch can be forward-ported to the v2.x (with the code now in saslauthd/auth_pam.c), but hopefully it can be.
(Additionally, the code should also be patched to pass the requested login (variable "login" within auth_pam()) to the _correct_ user= field of the pam data variable, so that it will be properly converted by pam_strerror() and thus properly logged, as well.)
I don't believe there is upstream intent to implement this, so it would be great if it could be implemented as an RHEL-specific patch, or perhaps RHEL devs could provide additional impetus to upstream devs to implement this. (In principle, this is a security issue - the lack of information makes these log entries useless for preventing brute force SMTP AUTH attacks.)
A patch for 2.1.23 and 2.1.24 has been proposed upstream; RHEL uses 2.1.22, so I am unsure if either of these patches can be backported, but if so, I recommend inclusion of such a patch. This can definitely help to increase security.
(I couldn't add this to the external links, above, since Cyrus IMAP isn't in the list of external bug trackers!)
The patch author indicates that the 2.1.23 patch applies cleanly to 2.1.22, and the patched version works well. It should be suitable for backporting into the RHEL distribution.
I would be grateful if it could be considered for inclusion. This would enhance security by allowing firewalling of dictionary attacks against sendmail.
Created attachment 500652 [details]
remote-host logging patch for saslauthd
Patch for v2.1.23 of cyrus-sasl; applies cleanly to 2.1.22.
to add this functionality to RHEL, please contact RH support
I thought enhancement/feature requests came through here, as well. Oops. I guess you wouldn't consider this a bug or security concern, technically? (It is the latter, though not an actual exploit.)
Is there a way to forward this thread easily to RH support?
The upstream bug report at andrew.cmu.edu is also welcomed.
Jan, I am not a RedHat customer... my employer purchases RedHat, and I generally use CentOS. CentOS won't implement this change since it's downstream. Not sure if/when CyrusSASL will implement it.
Unless I'm mistaken, it appears I can't submit a support ticket (to request this functionality) without being a paid customer. Any other way to get this patch incorporated into RHEL 5? I think it could fall under a security concern, since it's an enhancement that brings SASL's PAM logging into compliance with other PAM clients (like ssh, etc.).
Just wondering if there's any way to get this incorporated as a backport, as I can't open a support ticket without being a paid customer...
Mentioned patch breaks testsaslauthd utility  and it's possible that also something else so it needs more testing and probably should be reworked.
Petr, the linked bug 759334 says that a new version in FC16 fixes this issue. Will this new version be pushed to RHEL5 (and hopefully be picked up downstream by CentOS 5) at any point?
The patch brakes compatibility with several clients not only testsaslauthd so it was removed from Fedora and can't be included in RHEL-5 until it's changed in order not to change api or brake compatibility.
I use syslog and some custom daemons to identify and ban ip addresses with iptables that fail to authenticate more than x times in y minutes.
Banning based on failed smtp auth attempts is a valid reason, but if rhost isn't supplied, then it is as useful as a chocolate fireguard.
This is a failed authentication example:
Mar 12 05:43:56 zeus saslauthd: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=exampleuser
Mar 12 05:43:54 zeus sendmail: STARTTLS=server, relay=201-68-4-113.dsl.telesp.net.br [184.108.40.206], version=TLSv1/SSLv3, verify=NO, cipher=RC4-MD5, bits=128/128
Mar 12 05:43:58 zeus sendmail: q2C4hmmH008887: 201-68-4-113.dsl.telesp.net.br [220.127.116.11] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA
The maillog doesn't show failed auth attempts, just a dropped connection.
There are valid reasons for not banning addresses based on "did not issue", unless excessive.
Fuzzy cross-referencing the secure and mail logs for the ip address would be a really painful option.
How could a log entry in the secure log break compatibility with other clients?
What are the specifics?
Could this be fixed in such a way that it can be customizable with an option in /etc/sasl2/Sendmail.conf?
This is an information hole that still needs to be filled and standardized for other services too - (eg. vsftp logs resolved addresses)
(In reply to comment #13)
> How could a log entry in the secure log break compatibility with other
> What are the specifics?
THe problem is not log entry but the protocol change provided by this patch. saslauthd listens on an unix socket and reads 4 items - user_id, password, service and realm. If you add another item host then saslauthd will block reading until client sends it. It might be ok for clients using cyrus-sasl library but there are several clients like exim which communicates directly to saslauthd socket and they are not aware of fifth item. I can't change the default protocol.
Might it be possible to encode the host name as a transparent extension of the service or realm strings (maybe suffix them with @IP.ADD.RE.SS)?
(In reply to comment #13)
> Mar 12 05:43:54 zeus sendmail: STARTTLS=server,
> relay=201-68-4-113.dsl.telesp.net.br [18.104.22.168], version=TLSv1/SSLv3,
> verify=NO, cipher=RC4-MD5, bits=128/128
> Mar 12 05:43:58 zeus sendmail: q2C4hmmH008887:
> 201-68-4-113.dsl.telesp.net.br [22.214.171.124] did not issue
> MAIL/EXPN/VRFY/ETRN during connection to MSA
> The maillog doesn't show failed auth attempts, just a dropped connection.
> There are valid reasons for not banning addresses based on "did not issue",
> unless excessive.
> Fuzzy cross-referencing the secure and mail logs for the ip address would be
> a really painful option.
Try to increase sendmail loglevel to e.g. 10 or more:
# grep LogLevel /etc/mail/sendmail.cf
# tail -2 /var/log/maillog
Oct 4 10:30:02 dhcp-lab-249 sendmail: q948Tobf028306: AUTH failure (plain): authentication failure (-13) SASL(-13): authentication failure: Password verification failed, relay=localhost.localdomain [127.0.0.1]
Oct 4 10:30:04 dhcp-lab-249 sendmail: q948Tobf028306: localhost.localdomain [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
It may resolve your problem, but it doesn't resolve the $SUBJ of this BZ.
I believe that this has to be fixed/changed on a cyrus-sasl client side.
The client linked to cyrus-sasl library can use
int sasl_getprop(sasl_conn_t *conn, SASL_IPREMOTEPORT, const void ** pvalue);
to get its client's address and then log attempts itself.
Even the patch attached to this bug doesn't solve the log issue with the
auth_krb5. It adjusts only the auth_pam method.
Let's say I use cyrus-imapd. There is a line of code in imapd.c:
syslog(LOG_NOTICE, "badlogin: %s plaintext %s %s",
imapd_clienthost, canon_user, sasl_errdetail(imapd_saslconn));
so I need to catch notice messages in syslog:
# echo '*.=notice /var/log/cyrus.log' >> /etc/rsyslog.conf
and after restart rsyslog I can see following messages in the /var/log/cyrus.log:
Oct 8 16:47:32 rhel-6-openssh imap: starttls: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits new) no authentication
Oct 8 16:47:40 rhel-6-openssh imap: badlogin: master.virt [192.168.122.1] LOGIN [SASL(-4): no mechanism available: Couldn't find mech LOGIN]
Oct 8 16:47:49 rhel-6-openssh imap: badlogin: master.virt [192.168.122.1] plaintext root SASL(-1): generic failure: checkpass failed
note: this is log from rhel-6 but I believe that this would work same on a rhel-5 box