Chris Linfoot | How to prevent SMTP AUTH abuse

Friday, 25. February 2005

How to prevent SMTP AUTH abuse

Loads of hits here recently looking for this information:

The use of brute force attacks against SMTP AUTH to obtain valid username/password pairs and thus relay privileges is now well documented. I am posting this to help administrators identify whether they are at risk and to offer some solutions.

How to tell if you are a potential target

Use a telnet client to connect to port 25 of your SMTP server and issue an EHLO. For example:

$ Telnet mysmtp 25
220 mysmtp ready at Fri, 25 Feb 2005 09:13:08 +0000
ehlo test
The SMTP server will return a few lines like these:

250-mysmtp Hello test ([10.0.0.1]), pleased to meet you
250-AUTH LOGIN
250 SIZE
If 250 AUTH LOGIN is listed, you are a potential target.

What NOT to do

Do NOT attempt to fix this by defeating ESMTP.

RFC2821 says:

Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO.

The most common way ESMTP is defeated is with firewall "fixup" protocols, such as that found in Cisco Pix. These intercept EHLO and substitute XXXX, causing your SMTP to return a 5xx error response to EHLO. Do not interfere with ESMTP in this way - it is not necessary.

Solution 1

Many sites do not need SMTP authentication at all. If you are not actually using it to authenticate your own users, turn it off.

How you do this will vary depending on which SMTP server software you are using.

In Domino, look in either the Ports, Internet Ports, Mail tab of the server document or if you are using an Internet Site document for the server in question, look in that document on the Security tab.

Solution 2

If you are using SMTP AUTH (and the main reason for doing this is to identify your own users and grant them relay privileges), then:

Enforce a strong password policy for every user in your directory. Passwords should be at least 8-10 characters long and mix upper and lower case alpha characters, numeric characters and symbols. Passwords such as "password", "qwertyuiop" and so on should be strictly prohibited.
Do not have obvious generic usernames in your directory such as backup, root or web. If you must have these types of role accounts, give them less obvious names or at the very least give them very strong passwords.

A final thought

Keep an eye on your logs for signs of failed SMTP authentication. Attacks usually happen over a short period and involve attempts on a large number of username/password permutations so they will be obvious.

Depending on the source, you should either complain to abuse@ for the owner of that source (and send a log excerpt to back up the complaint), or consider firewalling the entire source network.

At the time of writing we have a small number of large networks, mainly in China and all of which have been used in SMTP AUTH attacks against our systems, included in a deny access group at the firewall.

Category: SMTP AUTH
Technorati: SMTP AUTH

Comments :

1. Amy Blumenfield25/02/2005 16:13:18
Homepage: http://www.cnsla.com

Chris- thanks, but my Internet Sites doc list security settings for HTTP and SSL - no setting for SMTP. What am I missing here? TIA.

2. Chris Linfoot25/02/2005 16:17:27

You need an SMTP inbound site document. If you don't have one, create one - although, if the server document is set to use the Internet site document and there is no inbound SMTP site document, the SMTP service should not accept any inbound connections anyway.

3. Amy Blumenfield25/02/2005 16:24:44
Homepage: http://www.cnsla.com

I have one. That's what I was referring to - there is no authentication options for SMTP - only HTTP and SSL. I checked on client's NABs and theirs is the same. Running D6.5.3.

4. Chris Linfoot25/02/2005 16:29:59

You should see this on the security tab of the SMTP inbound site.

SMTP AUTH

Set the circled item to no.

5. Amy Blumenfield25/02/2005 16:32:18
Homepage: http://www.cnsla.com

aaahhhh...so it's not listed as SMTP authentication options! That's what threw me - it says HTTP Authentication. But am I then disabling the ability for folks to authenticate to access db's via a browser?

6. 25/02/2005 16:34:06

IT says TCP authentication. Sorry, it's early. But will that affect HTTP authentication?

7. Chris Linfoot25/02/2005 16:37:57

Not on an SMTP inbound site document. All it does is turn off 250-AUTH LOGIN in response to EHLO whatever at your inbound SMTP server.

Those fields are not helpfully named, are they?

8. 25/02/2005 16:50:47

Great! Thanks - it's a tad confusing! Have a great weekend.

9. Mark Barton28/02/2005 13:50:14

Chris,

Thanks for this. I had something similar and I wondered if its the same thing. I use a port redirection service from http://www.no-ip.com as my ISP doesnt support Port 25 which was working great but unfortuanly after a while I got a lot of log messages stating SMTP Authentication not enabled.

This actually prevented the messages being delivered (I can see the status of the message stack on the no-ip.com site. If I restarted the SMTP task and or server it would deliver 1 or 2 then the error mesages would start again.

Eventually I dumped W2K3 and reinstalled windows XPPro and it seems the error message has gone away - no changes to the SMTP Internet Site document. Any thoughts ? Was the server under attack (would they be able to see it as it doesnt run on port 25 and the firewall prevents port scans.

Mark

10. Chris Linfoot28/02/2005 14:04:19

Domino throws that "SMTP Authentication not enabled" message in circumstances unrelated to SMTP AUTH.

For example, if you have a Domino server using an Internet site document for Internet site settings, and the inbound SMTP site document either does not exist, or does not nominate a particular server as a valid server for that SMTP inbound site, then when a remote user connects Domino will send 421 service unavailable, but the console log says "SMTP Authentication not enabled".

In fact, it does not say "SMTP Authentication not enabled" when any attempt (successful or otherwise) is made to use SMTP AUTH, so I have no idea what it really means.

I should say you probably weren't under attack, but there is some incompatibility with W2K3 and a non-MS SMTP service running on the "wrong" port. Another half baked MS security kludge, I would guess.

Stick with W2K if you can or (dare I suggest) a non-MS platform for the server.

11. Marcel28/06/2005 12:14:54
Homepage: http://wwww.ineco.nl

Thanks a lot for this! I have posted this problem twice in the R7 forum on notes.net without any luck!