Brute Force Dictionary Attack on Dovecot
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.
Contents
mechanisms in play
- postfix - The mail transfer agent (MTA).
- 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.
Postfix mailer and Dovecot handles email accepting and delivery for messages to local users and from local users to remote destinations. The attacker connects to dovecot and issues several attempts to send messages as a number of different users. The attacker doesn't know actual system usernames, so the attacker uses a dictionary list of common names and hopes to try name after name until there's a match.
Dovecot only logs the initial connection, that process ID is tagged along with the IP address of the attacker; that is logged in log/maillog . PAM then gets the requests for all of the different login names being thrown at it. PAM has to work with SASL to check if the login names are valid. Each time a process ID is generated that tags both PAM and SASL with the same ID. Log entries are generated in two places, log/messages and log/secure .
The problem with the entries in the messages and secure log is that no IP address is captured. It is not PAM's job to communicate with the system to capture IP addressing, as this would create excess overhead for PAM. Matching these entries with the maillog is difficult. 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. In data center (A) a mail server was so overloaded with saslauthd processes, the system admin couldn't even connect directly to the system to perform an emergency shutdown of dovecot.
prevention options
Block SMTP Authentication Attacks With Fail2Ban
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.
obtain and install
First, you need to install Fail2Ban. For Redhat/Fedora use yum.
yum install fail2ban
CentOS: fail2ban is not available from CentOS. It will have to be manually downloaded. You can get it from EPEL, the Fedora repository.
wget http://mirror.pnl.gov/epel//6/i386/fail2ban-0.8.11-2.el6.noarch.rpm rpm -ih --percent fail2ban-0.8.11-2.el6.noarch.rpm
You might have some dependencies to install, like
yum install gamin-python wget http://mirror.pnl.gov/epel//6/i386/python-inotify-0.9.1-1.el6.noarch.rpm rpm -ih --percent python-inotify-0.9.1-1.el6.noarch.rpm
These are the most common 2 needed for CentOS users. Get them and any others possibly needed then try to install fail2ban again. Additional help is available for RPM Commands.
ALL LINUX DISTRIBUTIONS - Fail2ban is written in Python, thus no compilation is required. You can even run Fail2ban without installing it. It can always be obtained directly from http://www.fail2ban.org
configure
Configuration for Fail2ban on a Redhat/Fedora/CentOS style distribution. This is using fail2ban with dovecot 2.x (versions 2 and above) - filtering and pattern matching.
- configuration files: ./fail2ban
- regex filters: ./fail2ban/filter.d
- action file (do/block): ./fail2ban/action.d
First edit the dovecot.conf filter file.
vi ./fail2ban/filter.d
Next edit the postfix-sasl.conf and iptables-multiport-tcp.conf action files.
vi ./fail2ban/filter.d/postfix-sasl.conf vi ./fail2ban/action.d/iptables-multiport-tcp.conf
Do not directly edit jail.conf. Comments in jail.conf clearly warn against modifications in jail.conf. Put your customizations in a jail.local file or a jail.d/customisation.local
cp ./fail2ban/jail.conf ./fail2ban/jail.local vi ./fail2ban/jail.local
Important Configuration Parameters:
- ignoreip: This is a space-separated list of IP addresses that cannot be blocked by fail2ban.
- bantime: Time in seconds that a host is blocked if it was caught by fail2ban (600 seconds = 10 minutes).
- maxretry: Max. number of failed login attempts before a host is blocked by fail2ban.
- filter: Refers to the appropriate filter file in "./fail2ban/filter.d".
- logpath: The log file that fail2ban checks for failed login attempts.
ignoreip = 127.0.0.1 192.168.254.0/24
Set the IP addresses of trusted hosts for fail2ban to ignore. Replace the 192x non-routable with the address of your machine or network. You can also add other trusted networks. Put your mom's IP address in there because sometimes she gets her password wrong more than 3 times in a row!
monitoring
It is a fact that today most mail servers are frequently scanned for username and password combinations. These dictionary attacks against mail servers seems to be all the rage since about 2010, hitting an all time high in 2014. Most attacks from from the APNIC IP blocks, however, compromised systems in your own area might be under the control of someone doing system scanning on your machine. Blindly blocking foreign subnets isn't enough.
Closely monitoring the log file:
tail -f /var/log/secure
provides a very clear view of the user and pass being tried. Several combinations are attempted per connection. For each one line of failed authentication in the maillog there may be a dozen or more lines of user/pass combinations being tried visible in the secure log. The number depends on your dovecot configuration limits. It is interesting to see the "common" usernames being attempted. The attacker is typically running a script that automates the attack. Sometimes an improperly configured script being ran by the attacking script-kiddie will hammer dovecot with a username like 'null' repeatably for hours. The entertainment value in that is that it is a waste of the attackers time. The sad part is that it is also a waste of your system and network resources.
Once you have fail2ban properly configured, you can monitor it with a high debug level to see how well it is performing. A debug level of "4" is the most verbose. Use this for a short duration while you are working out the glitches and fine tuning. A debug level of "2" or "1" is appropriate for continued use.
tail -f /var/log/fail2ban-test.log
Although you can configure fail2ban to add log entries to the syslog, it is recommended you have it log to its own file while debugging. With a debug level of 4 a lot of entries are added to the log. Plus it is easier to monitor fail2ban when it has a dedicated log file. Once you have it running smoothly you may opt to configure it to log to the syslog, or continue to log to a unique file. This setting is in the fail2ban.local configuration file.
logtarget = /var/log/fail2ban-test.log
When you see iptables rules being added by fail2ban, they will be in chains labeled "fail2ban-postfix" (depending on your own customized configuration). Here is an example of an attacker being blocked by an iptables rule generated by fail2ban:
iptables -I fail2ban-postfix 1 -s 105.237.97.175 -j DROP
If your system has very few static iptables rules, then you can view what is going on with a simple
iptables -L
However, for systems with 1000s of iptables rules, it is more useful to list only those created by fail2ban
iptables -L fail2ban-postfix
Now we see all firewall rules generated by fail2ban for postfix.
Lastly, a most useful feature of fail2ban is the ability to send you reports by email. You can configure fail2ban to send you email notifications when it bans a host. By default fail2ban is configured not to send any mails. You will have to make modifications to enable it. Edit jail.local to set up email notifications. Email notification is sent as an "action" and in the case of notifications for these smpt auth attacks, is under the label [sasl-iptables]
Using action.d/mail.conf to email you a notification on common activities such as: fail2ban service start, banning and unbanning an address.
vi ./fail2ban/jail.local
Find the line in the enabled action. An action can have multiple lines. Add a line under action =
mail[name=postfix-sasl, dest=yourmailbox, sender=fail2ban@localhost, sendername="Fail2Ban SASL"]
In this example, actions adding iptables rules for smtp attack will result in an email sent to yourmailbox.
key words: saslauthd pam_unix smtp auth authentication failure
