While catching up on my podcasts, I was listening to PaulDotCom Security Weekly Episode 220. During the news stories they talked about an article in Network World regarding the effectiveness of honeypots in the Enterprise and how they were the best thing since sliced bread. Everyone agreed with the article and sung the praises of honeypots and how they almost always were great indicators of issues on the network and almost always caught malware propagating across their networks.
Honestly, this left me scratching my head. I have been running honeypots in an enterprise environment for over two years and they have been little more then novelties.
Now, don’t get me wrong: I love me some honeypots. When I first found out about honeyd back around 2002 or so I fell in love. I coded up an entire suite of scripts to mimic default installs of various Linux distributions. I used it in my university’s CTF competition to light up the /22 they gave us with over 700 decoy computers. I bought an extra IP for my DSL connection at my home solely for running it. I presented on it at The Last HOPE. It’s an amazing tool. When I got the green light at my work to set it up on the LAN for monitoring I was pumped! When running it at home I received an amazing amount of attacks! Surely the network, which was still thought to resemble the wild west would give us an amazing picture to how bad things are. The office had informal bets to see how long the box would last before it was exploited.
Well, that was over two years ago. We’re still waiting.
Honeypots are a double edged sword detection wise. When positioning them, a lot of folks place them in a DMZ open to the wild of the Internet. While this allows you to see exactly what is being flung at your network, most people don’t realize the amount of shit that gets rained down on your servers. In an average day one can see attacks from upwards of 20-30 hosts. This is wonderful, but correlating these to attacks on your infrastructure can be insanely time consuming. For each attack you need to ask:
- What was the attack?
- Do I have hosts vulnerable to that particular attack?
- Did this malicious host launch that attack against those servers?
- Was that attack successful?
While important questions, these alerts pile up. It’s very easy to end up chasing your tail and quickly become overwhelmed.
The flip side of this is positioning them inside your network. While you (hopefully) won't be overwhelmed with attacks, you'll run start running into the opposite where you'll be wondering if you'll be seeing any events. If you don't have some kind of automating alerting system, you may start not notice if and when an attack happens. Whoops.
Honeypots provide great information for network based attacks. For the scenarios described in the Network World article and above they function admirably. However, I feel comfortable in saying that over 95% of attacks coming into most networks are web based attacks that come in via one path: Users’ web browsers. Trojans like Zeus, Gozi, Sasfis, Koobface, and Conficker thrive in most modern enterprise environments. Recently there was a great post on the RSA weblog by Uri Rivner comparing the amount of data stolen by the Zeus Trojan and Wikileaks (Zeus wins. Handily). What do these crimeware kits have in common? They don’t probe other computers, they don’t scan, they just phone home to their C2 infrastructure. Honeypots are as useful in detecting and preventing these situations as a bowl of Tapioca pudding would be.
Like all security devices, honeypots have their place. Having nodes reporting into existing alerting structure (SIEMs) as tripwires and “patient zeros” are a good idea. However, with some of the price tags on these pieces of software one has to do a cost benefit analysis regarding their existing infrastructure. Would you be better served by a honeypot or hardware for an IDS system, another firewall, a SIEM, a log server, vulnerability scanner, or some other piece of security infrastructure? While they can and will catch certain attacks, however, they are one small piece in what you should be deploying and they should be one of the last pieces of your puzzle rather then your first.