In a brute force dictionary attack, a remote host attempts to connect using common phrases for username and password, connecting and trying combinations as fast as possible, until either entry is achieved by a match, or the overload system experiences an overflow resulting in breach.
The most common brute force dictionary attack against Dovecot is continuous connections to port 25, the port responsible for listening to incoming mail, and connections from clients attempting to send mail.
messages
Feb 6 22:21:24 mailserver01 saslauthd[1150]: do_auth : auth failure: [user=summer] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Feb 6 22:21:24 mailserver01 saslauthd[1149]: do_auth : auth failure: [user=summer] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
secure
Feb 6 22:21:22 mailserver01 saslauthd[1150]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= Feb 6 22:21:22 mailserver01 saslauthd[1150]: pam_succeed_if(smtp:auth): error retrieving information about user summer Feb 6 22:21:22 mailserver01 saslauthd[1149]: pam_unix(smtp:auth): check pass; user unknown Feb 6 22:21:22 mailserver01 saslauthd[1149]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= Feb 6 22:21:22 mailserver01 saslauthd[1149]: pam_succeed_if(smtp:auth): error retrieving information about user summer
maillog
Feb 6 22:21:24 mailserver01 postfix/smtpd[16812]: warning: s15449723.onlinehome-server.com[74.208.17.177]: SASL LOGIN authentication failed: authentication failure Feb 6 22:21:24 mailserver01 postfix/smtpd[16814]: warning: s15449723.onlinehome-server.com[74.208.17.177]: SASL LOGIN authentication failed: authentication failure
It is a shortcoming of postfix/dovecot/sasl that the IP address of the attacker is not stored in the messages log or the secure log. Also, the only way to match entries from either of those two logs against the maillog is by the timestamp. This is problematic on a server with a great deal of mail activity.
It would be nice if the IP address was in the messages or secure log, or if there was a key value that could be used to match exactly with the correct entries in maillog.
mechanisms in play
- postfix - The mail transfer agent (MTA), the boss.
- dovecot - The IMAP and POP3 service, how you retrieve your mail. The Postfix mailer and Dovecot are a team for accepting and delivering email.
- pam (pam.d) - Linux Pluggable Authentication Modules (PAM) is what authenticates you when you try to login to get your mail from dovecot. PAM handles authentication.
- saslauthd (SASL) - This is what authenticates you when you try to send an email. Rather than managing a relay list, SASL requires authentication before permitting the sending of email.
The offending attacker connects to dovecot and issues several attempts to send messages as a number of different users. Dovecot only logs the initial connection, that process ID is tagged along with the IP address of the attacker. Then PAM gets the requests for all of the different login names being thrown at it. PAM has to work with SASL to check if the logins are valid. Each time a process ID is generated that tags both PAM and SASL with the same ID, however, the IP address is not captured here. It is not PAM's job to communicate with the system to capture IP addressing, as this would create unnecessary overhead for PAM and negatively impact an otherwise quick process. The problem is, other than a relative timestamp, the PID, or tagged id to the log entry only match the PAM to SASL communication, and cannot be matched up against Dovecot. This is fine for a small mail server with few users. However, when other user authentication requests are coming though on the same timestamp, it can be difficult to match up the log entries generated by pam in the messages and secure log against the offending postfix log entry in maillog, the only place the actual attacker IP address can be gleaned.
What can happen is there are so many saslauthd processes open that legitimate users are unable to login and authenticate.
prevention options
Blocking SMTP authentication brute force attacks using Fail2Ban
Fail2Ban can be used to block brute force attacks against your mail server. The attackers are blocked by their source IP using iptables. Although it doesn't block SMTP attacks by default, Fail2Ban can be configured to do so.
Fail2ban works by scanning log files to detect attacks such as log entries indicating multiple failed login attempts. It scans though the log, identifies an offending IP address, then creates an on-the-fly firewall rule to block it. It is typically configured to use iptables to accomplish this, however, it is not restricted to any one firwall, or using just firewall rules.
key words: saslauthd pam_unix smtp auth authentication failure