eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I was very impressed with a recent story in the venerable Virus Bulletin by a couple of McAfee research engineers. The authors, Vinoo Thomas and Nitin Jyoti, argue for in-house honeypots and other techniques to trap in-house bots.
Dont get carried away; honeypots are an old idea. But its still a good one to run them in-house, in your DMZ, in order to gather intelligence on attacks, and I bet there are very few large networks bothering to do it.
I keep hearing from vendors that there are plenty of bots inside corporate networks. One of the major things that bots do is to send spam, and this is done out TCP port 25. (Thomas and Jyoti also claim that some malware uses the alternate SMTP submission port 587, but it was my impression that all submissions on this port had to be authenticated, making it useless to malware. After getting a more detailed explanation from them, I dont think you need to worry about port 587 at all. The problem is all on port 25.) In order to block unauthorized e-mail submissions, many enterprises block port 25 outbound at the firewall. Thomas and Jyoti say simply blocking port 25 is the wrong way to go. Far better to redirect all that port 25 traffic to a honeypot.
The honeypot chosen by McAfee is MailPot by VeriSigns iDefense. This tool is designed specifically for this purpose, to capture e-mail sent out by bots, trojan horses and the rest of the cast of malware infections. MailPot is licensed under GPL 2 and (obviously) comes with source code. They tested it on a client network that they knew had bots on it.
MailPot can be configured to take e-mail from a variety of client submission configurations, from Outlook to open relay. As the instructions say, if the mail clients (i.e. the bots) do MX lookups on the target domains, which is not uncommon, you may need to take other measures. The McAfee engineers did this by using iptables to set a firewall rule redirecting *all* outbound port 25 traffic to the honeypot system.
MailPot gathers lots of information about the sending system from the message it traps, including the IP address. Even with DHCP in place, the address will immediately identify the system. It has some handy options like doing a whois on a domain listed in the headers.
McAfees experience is that the large majority of the messages trapped in the honeypot will be spam (see the paper for details), and this makes sense. The remainder are mostly copies of the malware sent out in an effort to spread, and a few are passwords and other information stolen from the client system.
The authors also have an interesting alternative suggestion for identifying compromised systems, but it would only work for networks with well-organized and administered system image management. As part of the standard system image you could include a file that contains an e-mail address—imagine gone2pot@eweek.com—. Dont use that address for anything, but monitor the inbox. If you receive mail at that address it must mean that some software on the system has crawled the hard disk, found the file and added it to its mailing list.
Done in this simple way its useful, but there is a better way which the authors also suggest. If your image management permits it, make the address unique for each system, perhaps by appending the machine name. A single address can leak out, perhaps by a bot reporting it up the C&C. A unique address is easily replaced. But the management overhead is increased; you dont really want to have all those mailboxes, so you should probably have them all forward to one and use rules to track what the actual target address of the message was.
Blocking port 25 is better than not blocking it. Setting up a honeypot or some other tracking system lets you use botnet activity to track and remove the bots shortly after they come to life. The best botnet defense is a strong offense, so go after them.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer