In-House Honeypots

By Larry Seltzer  |  Posted 2007-10-14 Print this article Print

Opinion: Best defense is a strong offense: Use malware activity to track down bots and knock them out.

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—. 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.

FireEye uses a powerful appliance to block botnet activity in the enterprise. Click here to read more.

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. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzers blog Cheap Hack More from Larry Seltzer
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel