Click the comments link on any story to see comments or add your own.
Subscribe to this blog
08 Jul 2008
A member of one of the mailing lists I read wrote in saying that one of his client's computers was on the CBL, a well known an extremely reliable list of zombie-controlled computers that send spam. He assumed it was due to bounce blowback, and was asking for copies of the messages that caused the listing. Even though the computer in question was a Windows box running Exchange that was also a NAT gateway to a local network, the Exchange logs didn't show anything, and he didn't believe the problem was zombie, He didn't get a lot of sympathy.
Late in the conversation, Steven Champeon of hesketh.com, who heads the Enemieslist anti-spam project, sent a fine summary explaining what you do when you show up on the CBL. It's adapted here with his permission.
Your local MTA logs, spam headers and samples are useless for securing your network against modern bots. Once you've been told your NAT is allowing spew, and so it is infected (somehow; either directly or by association due to poor policing of outbound traffic), it seems like maybe the first, and immediate, thing to do is to secure the NAT against outbound SMTP / port 25 traffic from unauthorized hosts, and log all attempts in order to discover the miscreants.
For a single host (not behind a NAT) the best thing to do is sniff the local network traffic and look for odd patterns in the outbound SMTP. Especially, say, if it's not running any apparent mail client software ;)
You're not trying to discover and secure an open relay, like you might have ten years ago.
You're trying to determine which, and how many, of your local assets are now pwnd by the RBN or whoever.
As spamming is what the majority of what such assets are used for, and since spam is sent via outbound 25 connections to lots of places that happen to be MXen, it seems that a good step in such a case would be to look for that sort of traffic in places it shouldn't be. I'm not up on whether the latest bots actually use DNS lookups for getting their MX lists or not (I suspect not) but that might be another thing to look for. Also, as you mentioned, P2P - if you can identify it. Also IRC, if you can identify it.
For webhosts and non-Windows folks, where the exploits aren't as universal as the bots, it's a little more difficult, but can be addressed in similar fashion by requiring all outbound SMTP go through choke points that are logging traffic, or through transparent redirection to your MTA (or a MTA set up specifically for that purpose, if you'd rather not risk your reputation on less secure assets).
In other words, maybe it would be worth investing in proactive security based on structural characteristics of what you're trying to prevent from exploiting your network.
Without passing judgement on you or your client, several things in your replies made me wonder how seriously you're taking this.
I'm not trying to call you out here, necessarily, just trying to make sure that the good lessons from the conversation are summarized. Maybe it's just that most of my antispam filters are based on structural, rather than content-oriented, characteristics, and so what CBL management says about the way the CBL works makes more sense to me, but it must be intensely frustrating for the CBL volunteers and others to have to explain the basics of modern bot behaviors to people over and over again. Especially when much of what they have to say is already on their site, etc.
Maybe the CBL just needs to preface all lookup results with a few paragraphs to the effect of "these are not your father's spambots, the world has changed since 1998"? :)
For all instances of "you" above, feel free to insert "your client", etc.
Anyway, back to the popcorn.
My other sites
© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.