Problem solve Get help with specific problems with your technologies, process and projects.

Fun with mail servers

Well, maybe not fun. This tip takes a look at all the ways Spammers will try to attack your mail servers.

The really annoying thing about spam for an admin isn't receiving it, it's trying to keep spammers from using your mail server as a relay. This is really a critical job too, because aside from using up costly bandwidth, lagging your server and weighing on your conscious, you can also quickly wind up on everyone's "blacklist". When that happens, your users will experience intermittent delivery and you can count on spending a lot of time you don't have trying to get your system squared away and get off the banned lists.

Of course, almost every network administrator is familiar with the concept of an "open relay" and why that's bad, and the typical solutions, like restricting relay service to certain IP addresses or requiring authentication. But many network admins might not realize that spammers are a little more sophisticated these days.

As an exercise, I set up several mail servers this week and last, using both MS Exchange and a few freeware SMTP/POP3 servers, and set up my protocol analyzer (ClearSight) so that I could watch what happened. I must admit, I was fairly shocked.

As you might imagine, it wasn't long before they found my servers. And even though I was requiring authentication for relaying, I quickly began to see thousands of e-mails with bogus source addresses streaming from my Exchange server, even though I wasn't seeing any e-mail come in. It turns out that they exploited a bug (which may have been related to SQL Server) to cause my server to generate the mail automatically... no relaying required.

So I ditched that and started up some of the freeware servers. Watching this was even more interesting, and I was amazed at the variety of attacks. Although relay attempts were initially met with "503 – This mail server requires authentication" by my server, I again quickly saw spam spewing forth. They had guessed the "postmaster" account password and were sending mail as the postmaster.

After I disabled the postmaster account, I witnessed lots of attempts at bogus SMTP commands, and bad source e-mail addresses, and things like sending several RSET commands in a session. (Many servers let you disable use of some commands.) At this point, I realized this must be why my server had a feature that drops the connection after reaching a given number of failed commands, so I set that quite low.

I also noticed that most of the attempts to relay were coming from the same IP address, so I blocked that address in my firewall. Within minutes, I was getting the same spam from a different address on a different continent. Again, I blocked it, and again it arrived from a 3rd source. Curiously, as long as they were getting connected, they seemed content to receive authentication failure notices, but as soon as they couldn't establish a TCP connection to port 25, they would switch source addresses.

One interesting side-effect that I found was the option to reject mail from invalid domains. This seemed like a good idea to me, as much of the spam has a source mail address filled with ASCII trash. However, what I found was that even though my requirement for authentication blocked the relay attempt, my server would still send a DNS query for the sender's domain. The result was thousands of DNS requests. Worse, they would trickle in for hours, and then suddenly send thousands of requests per minute that nearly DoS'd my DNS servers. I disabled this option after watching the traffic.

If you're responsible for a mail server, I urge you to periodically spend a few minutes with a sniffer and make sure your server isn't possessed. I'd also encourage you to keep the system patched, rename or disable any standard accounts and generally familiarize yourself with all the security features your server supports. As the spammers become more sophisticated, we'll have to become more educated. Don't rely on authentication or IP addressing alone.


Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.


Dig Deeper on Network Infrastructure

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close