Fighting Back Spammers
In the last weeks, Fred and I have discussed and tried out various approaches to get the spam problem on one of our customers' servers under control.
I’ll give some hints on how you might be able to improve your mail server setup. Be aware: we’re rather strict on that server. When a message looks too much like spam it is dropped immediately and maybe lost forever in outer space. Our customer is OK with that procedure. I don’t know if you are, too. Nevertheless, we found a combination of the following methods to be quite helpful:
Disable catch-all for your domains. Well, it was fun while it lasted to have e-mail addresses like [email protected] – with catch-all you just had so set up your server to accept any localpart of your domain and deliver it to your inbox. Now that spammers try various methods to form localparts that might exist on your system (and, in fact, do not, such as applebaumlongleyi@, cremeansfeofilaktumarcoux@, deangeliskennedy@, …), it is best for your mental sanity to restrict your server to the addresses (personal and role accounts) you really use.
Use fail2ban to drop SMTP connections from a certain host if they fails to behave when talking to the SMTP server. This rule is taken into account if there are more than n failures in a specific time slot, e.g., when being misconfigured or not waiting for the server greeting and trying to send their junk immediately. And while you’re at it, see if you like to activate fail2ban for your SSH daemon and other services, too.
Check the SMTP connection against a blacklist. There are some well-administered blacklists like the one from Heise/iX. Use them. To cut a long story short: hosts that used to deliver spam to other providers in the past 72 hours are kicked from here, too. That DNSBL is fed by some important German Mail providers, e.g., GMX or Web.de.
Check DATA using SpamAssassin. If the mail passed the previous tests, it is filtered through SpamAssassin. We use some of the tests provided with the SpamAssassin installation as well as our own customized ones. Mails are also checked for known malware/virus infections (ClamAV and others) during SMTP connections. In addition, the SaneSecurity plugin for ClamAV catches some more phishing/malware mails. Action taken here: if a message fails more than n tests, i.e., gets a high SpamAssassin score, it is dropped. Be careful when choosing the spam score limit – if it’s too high, it might be useless, if it’s too low that might result in losing legitimate mail which got a high spam score for whatever reason.
Our setup is OK so far, but we’re still seeing some ten thousands SMTP connections in the log files that have to be evaluated and are eventually being dropped by one of the test engines for various reasons. If we could also eliminate some more of these, we’d be good.
The final and most restrictive rule might be somehow considered politically incorrect. So let me explain the problem first and than you decide if this rule is OK for you.
Our customer does not expect e-mails from Eastern European or Asian countries, e.g., from Russia, Ukraine, Turkey, or Korea. Just to name a few. Setting up a general iptables filter rule for all (or even only one) of these countries is not an option as we would exclude people from these countries from getting information from sources in the rest of the world. That’s not what we want to achieve here. Access to information on the net should not be restricted.
But… Let’s look at the problem from a different point of view. Most zombie bot Windows machines that have been hijacked and is being used for spreading worms and spam mails use their own local SMTP engine. That’s to create a distributed net of mail-sending machines which is much harder to detect and block as one single host. A “regular” user1 does IMHO not have a legitimate reason to directly2 __connect from their host to our customers' server by SMTP.
Let’s say someone from Mumbai is trying to send an e-mail to me. If they’re using some web mail provider, e.g., Google Mail, their e-mail is sent through and from Google servers, not from their own dial-up host. They have to authenticate with the Google servers and if they’re sending spam, I can file a complaint report to Google and they can take action. Even, if it takes long and the spammer has since set up ten new accounts for delivering his highly appreciated information mails offering me bigger… breasts. Sorry, dude, I’m comfortable with my chest. I don’t think hooters would look good there. But, anyway. Using an external web server the spammer is forced to comply to rules made by someone else. If they’re sending too many messages, they might be excluded from the service for a few minutes. And an alarm might go off somewhere, so the case is being investigated, read: shut down if detected.
If spammers are using their own domain set-up, they usually use a rented or hijacked server to send their message to mine. That’ll be only one host someone at their hosting company will have to take down to (temporarily) solve the problem. If they’re refusing to take action, again, you only have to block one host and not a whole bot-net distributed over various providers, nets, or even countries.
In other words, my experience shows that legitimate e-mails do not [directly] have origin from dial-up hosts. Never. Therefore, I started to block SMTP traffic from certain dial-up networks.3 And you know what? The amount of incoming SMTP connections delivering spam or malware dropped by 80%! I think that’s enough justification for this method. In case you’re interested, these were the top spam-sending networks in the last weeks:
- Moscow Local Telephone Network (OAO MGTS), 79.139.128.0/18
- Korea Telecom, 59.0.0.0/11
- Far East Telecommunications Company, 77.34.0.0/15
- Promira Network (Russia), 79.120.64.0/18
- BORANET (South Korea), 118.128.0.0/14
- TurkTelekom (definitely the winner!), 85.105.208.0/20 and 85.105.224.0/19 and 88.230.128.0/18
- UKRTELECOM, 92.112.0.0/15
So, what are your experiences fighting spam? Do you use a different setup? Do you think one of the methods presented here is prone to error and will result in many false positives? Feel free to give feedback using the comment function below.