Follow Up: Closed Relay – SMTP Auth Attack

On Monday, I posted a blog post related to an increase in SMTP Auth Attacks. Frank posted an interesting comment with a question which I thought was worth discussing:

Good posting. I haven’t seen very strong support by MTAs to identify SMTP AUTH brute force attacks. Any comments on what vendors are doing, between Exchange (using AD on the backend), LDAP-based auth, and native system AUTH?

Of course the best way to mitigate exposure to a SMTP Auth Attack is to disable the feature. If it really is necessary to use it, it could be limited to specific IP addresses or subnets that are trusted such as a VPN, rather than allowing anyone in the world to authenticate. However, the comment obviously relates to a situation where SMTP Auth must be supported and the connection IP address of clients could come from anywhere.

In the case of an Exchange server mentioned above, it’s not usually recommended to have the server in the DMZ from a security viewpoint. Instead, a SMTP proxy (which could be software/appliance/hosted) sitting in front of the MTA could be used to detect these attacks rather than relying on Exchange or the back end authentication mechanism to detect them.

Does Exchange actually have any features to combat an attack? To be perfectly honest I wasn’t sure so I did a little digging. I was already aware of the tarpit feature in Exchange 2003 dicussed in this Knowledge Base article. As the tarpit feature is bypassed for authenticated sessions it’s not clear if it would help prevent a SMTP Auth attack by tarpitting it due to failed authentication attempts. However, I did find a MS Exchange tutorial claiming that it did. I wanted to confirm this so I contacted our friend, Terry Zink, the product manager for Exchange Hosted Services to pass my query on to a relevant contact. He was kind enough to oblige and confirmed that Exchange 2007 does tarpit failed authentication attempts and was pretty sure that 2003 did likewise.

While I was writing this follow up to the original blog post, Frank also commented on the ability of other MTA’s to prevent these attacks:

Incidentally, a vendor who has customized qmail (among other things) mentioned to me that they have rate-limiters per IP and username for just that aspect.

That’s a typical way to mitigate this type of attack. Rather than allowing an attacker to hammer a mail server all day the authentication failures per ip or user can be used to detect it. It’s quite similar to a SSH Brute Force attack and there’s a unix solution, Fail2Ban, that can detect failed smtp authentications and create rules to temporarily ban the originating IP addresses.

If any of you are worried that you might be vulnerable to such an attack and are not even sure if this feature is enabled, you can check by telnet-ing directly to port 25, issuing a ehlo/helo and looking at the capabilities reported by the MTA to see if AUTH is listed. You could also check your outbound mail servers IP address against multiple blacklists using this tool multiple blacklists. It’s also a good idea to monitor SMTP AUTH traffic at a perimeter firewall or SMTP Proxy to see any failures.