Building a TCP Honeypot
Notes from designing a small service that watches hostile network behavior without trusting it.
A honeypot is a strange kind of server. Its job is not to serve legitimate users quickly. Its job is to look ordinary enough to invite interaction, then record that interaction without giving the attacker a useful foothold.
The first constraint is isolation. Every parser, timeout, banner, and log path needs to be built with the assumption that the remote peer is trying to learn something or trigger a mistake. Boring defensive code is the feature.
The second constraint is measurement. Raw connection counts are easy to collect and easy to misunderstand. The useful signal is in timing, command sequences, repeated fingerprints, and how behavior changes when the service responds differently.