Roger A. Grimes wrote recently about using a honeypot in the internal network to catch maldoers (am I alone in feeling a bit naughty after seeing the pic of Roger and honey?). I think this approach is a little heavy-handed, even for a throw-away machine. A full-blown honeypot is a bit of an interesting approach to the problem of detecting intrusion. If staff cannot detect intrusions on their real systems or on the network, they’re not going to wield a honeypot correctly. And if they do catch someone probing the honeypot, they are already beyond having a problem.

Now, that’s not to say I discredit this approach. I’m all for multiple barriers, detections, defenses, and using spare time and resources (even throw-away junk) for any little bit that can help. In fact, in a previous job I had a really old workstation that I opened a share on and configured a few port listeners on. This box was a crude honeypot/detection box that could alert me if something was scanning certain ports (namely 1434) or something was depositing malicious files on the open share (we had a couple of these outbreaks when I first joined up). Not really a honeypot, but it was a box meant to simply trigger an alarm in an environment that was cash-strapped from a back room standpoint. Honeypots seem more geared towards human attackers, as opposed to automata which is more often the culprit.

So, I’m not disagreeing with the approach in total, but I would caution that honeypots internal will indicate something bigger is happening, and there really should (if you can get the budget for it) be other measures in place on the network and real systems to detect intrusions or naughty activity, even if they are just little tripwires or detectors.

The article also gives some nice tools, and I’ve already picked up that book mentioned and hope to get started on it in the coming months.