Last weekend I downloaded and ran Fred Cohen's Deception Toolkit for the first time.
DTK is, as far as I am aware, the first publicly available honeypot. The premise is simple to state and immense in its implications: instead of just trying to keep attackers out, deliberately make some of your services look vulnerable, to attract attackers, to waste their time, and to learn what they do.
I want to talk about what DTK actually is, and what it is making me think.
What it is, mechanically
DTK is a collection of small Perl scripts that emulate, on TCP ports of your choosing, the behaviour of well-known services with well-known vulnerabilities. There is a fake Sendmail that pretends to have an old version's bugs. There is a fake FTP. There is a fake PHF, which is the CGI script that has been the subject of so many remote-compromise stories this year.
When an attacker probes one of these ports, the DTK script answers. It looks plausible. It even hands back a fake password file, with fake hashes, if you ask nicely. None of it is real.
Meanwhile, every interaction is logged.
What it changes about how I think
Until last weekend my mental model of network defence was simple: a perimeter, with services on the inside, and rules on the outside that decide who can talk to what. The whole apparatus is reactive. The attacker takes an action; the firewall and the host either let it through or do not.
DTK proposes something different. It says: you can also lie. You can present a network surface to attackers that is not your real network surface, and you can use the gap between the lie and the truth to learn things — about who is probing you, and how, and when, and with what tools.
This is the sort of thing the academic literature has been getting at for a while. Fred Cohen wrote about deception in computer security at length. The Cliff Stoll story in The Cuckoo's Egg is the same idea applied to a single fake account. DTK is the first time I have been able to install the idea on my own box and watch it work.
What I actually saw
I ran DTK on a small subset of the usual suspect ports — 21, 25, 79, 110 — for about three days, on a box exposed directly to the internet via PPP. I had no traffic on those ports under normal use, so anything DTK saw was, by definition, not me.
In three days the logs caught:
- Roughly thirty connection attempts to port 25, almost all from automated scanners looking for open SMTP relays.
- A handful of probes that did the PHF request to port 80, which I had also configured DTK to fake — none of them seemed to read the page they got back, which was suggestive.
- Two interactive sessions on port 21, where an actual human appears to have driven the FTP for several minutes, looking for writeable directories, before giving up.
None of this is a serious threat. All of it is data. Nothing else I have ever installed has produced this kind of data.
The argument against
The obvious argument against running a honeypot is that you are inviting trouble. If you put a fake vulnerable service on the network, the attacker will probe it. They will probe whatever else you have, too.
In practice this is less of a worry than it sounds. The internet is already full of attackers probing your services constantly. A honeypot is not bringing you new attention; it is recording the attention you already get. The marginal risk is small. The marginal data is large.
What I am going to do next
I am going to leave DTK running. I am going to start writing up what I see in the logs over time. I am also going to start watching for the appearance of similar work — there are murmurings of an upcoming open-source intrusion detection system called Snort, by Martin Roesch. The two ideas — deception, and pattern-matching for known attacks — feel like they belong in the same conversation.
A weekend well spent. Possibly more than a weekend, if I am honest.