You come into the office in the morning, login to your computer to check mail and find that the mail server is really slow or not responding at all. So you remote in to the box and find that your mail servers outgoing queue is full of messages destine for domains you never send to and from senders not from your domain. "What the heck's going on?" Have you been a victim of spam relaying? Very possibly, yes, here's a few tips on how to diagnose this problem and how to prevent future spam relays.
Topic of discussion:
- What is relaying?
- How spammers are able to relay, what methods are used?
- How to determine if relaying is occurring.
- SMTP log details of spammer relaying mail.
- How to secure relaying attempts and prevent future relay attempts.
When a mail server receives an incoming message and it's recipient address is to a local domain defined by your mail server it is considered local mail and placed in the local POP3/IMAP account. If the recipient is to a remote address (to a domain that is not defined by your mail server) this is considered relaying. The mail server should perform several checks on the connecting IP to ensure that it is trusted. The connected IP is typically trusted using one of three relay checks:
- Is a predefined trusted IP. Usually your private network.
- POP3 before send. The IP must have authenticated to POP3 or IMAP before sending.
- SMTP Authentication. Can be used by the connecting IP and is part of the ESMTP protocol.
Use private network. Most mail servers are configured to only allow relaying from the local private network and spammers are less likely to find ways to send spam via your private network, unless they find a way into your network using a virus or some other means. In my experience spammers are lazy and will first attempt to use automated ways to find weak passwords on your mail server so they can relay, however, when troubleshooting relaying issues never count out the possibility that your local network has been compromised, virus or otherwise.
Authenticate to mail server. POP3 before send or SMTP authentication can be used to relay mail, but how do spammers find your username and password allowing them to authentication? One common method used is POP3 harvesting attacks. What happens is the harvester connects to your POP3 server and sends a common username and password, if it fails they send another username and password until they find a valid username / password combination. I've come across this issue 100's of times and it's unbelievable how many usernames and passwords are the same, typically email users change their password to match their alias making it easier to remember, which opens a huge security hole in your mail server.
How to determine if relaying is occurring:
Stop the SMTP service and clean out the outgoing queue. If a spammer (this is usually an automated process running on a zombie computer) is activity relaying mail through your mail server you need to stop your SMTP service immediately. If not, you might find your mail servers IP being added to black list servers. Removing your IP from black list servers can be just as time consuming as cleaning up spam relaying issues. Most mail servers provide you with the ability to delete messages in the outgoing queue, simply delete what's obviously spam and check the following to determine what happened.
Check the POP3 logs for harvest attempts, and note the connecting IP. Here's an example.
+OK test.com Mail Server v1 POP3
user sales
+OK sales
pass sales
-ERR Unknown user or incorrect password
user info
+OK info
pass info
-ERR Unknown user or incorrect password
user test
+OK test
pass test
+OK 0 messages (0) octets
quit
+OK test.com closing connection
POP3 Logs. Your POP3 logs will show the username but not the password so you will need to look for reoccurring attempts where a valid username/password was found, look for the +OK after the pass command. Once you know the username you can reset that accounts password. Another tip is to look for the largest sized log, this is likely when the harvest started. Also search your SMTP logs for the same IP address. If you find the IP, and your mail server allows POP3 before send, this will allow that IP to relay.
SMTP Logs. A more common scenario is that the newly discovered open relay is posted to the big cloud in the sky and zombie spamming computers will use SMTP authentication to relay spam through your mail server.
Encoded username and password. Successful SMTP authentication.
>>> 250-host-name Hello remote-client [1.1.1.1].This is only a partial log showing successful authentication. This is what you will see in the SMTP log to determine what account was used for relaying. Search the logs for 'AUTH LOGIN', without the single quotes. The username and password are base64 encoded and can be decoded from the following site. For example, the username above is dGVzdA. The password is cGFzcw. Copy the data and paste into the site below to decode.
<<< AUTH LOGIN
>>> 334 VXNlcm5hbWU6
<<< dGVzdA==
>>> 334 UGFzc3dvcmQ6
<<< cGFzcw==
>>> 235 2.0.0 Authentication successful
Base64 Decoding
Decoded username and password. Here's an example of the data decoded.
>>> 250-host-name Hello remote-client [1.1.1.1].Once successfully authenticated you should see the session continue with delivery to 100's if not 1000's of remote recipients. Once you know which account was used to relay you can change the password. In our example above it was account test. Keep in mind that more than one account may have been compromised. Continue to search the logs for other login attempts.
<<< AUTH LOGIN
>>> 334 Username:
<<< test
>>> 334 Password:
<<< pass
>>> 235 2.0.0 Authentication successful
How to secure relaying attempts and prevent future relaying attempts:
- AUTH policies. Most mail servers allow all authentication types for SMTP. This is best practice so your mail server supports the widest range of connecting clients. For example, AUTH CRAM-MD5, PLAIN, LOGIN, and DIGEST-MD5 are defaults. If you change the AUTH defaults you may encounter problems where some clients (Outlook only supports AUTH LOGIN) can not authentication. This will result in a 'We do not relay' error. The logs will report some type of AUTH exchange to be considered trusted.
- Restrict failed login attempts. Set POP3 login failures to 5 to slow down POP3 harvesting.
- Trusted IP addresses. Know which IP addresses are trusted on your network and when possible trust only private IP addresses.
- Password policies. Create password policies that force mail users to change passwords often. Passwords should also contain alpha-numeric and non alpha-numeric characters.
- Limit recipient deliveries. Limit the amount of recipients your mail server will accept in a single SMTP session. This will slow down the spammer.
