Differences in packet headers allow tools like nmap to fingerprint operating systems. My new approach to packet normalization removes these header differences. Starting TTL, TCP Options used, and TCP Option order, after normalization, are the same from one packet to the next no matter which operating system sends it. If we normalized the packets transiting our network, could we keep nmap, and tools like it from remotely fingerprinting hosts? It turns out that we can, and we can for most hosts on our network.
The proof of concept that I developed (idguard) does just that. A Linux Kernel module, it will be installed as part of the embedded firmware of a Linux-based router, and placed on the local network. Idguard will then give all the packets flowing through the router the same starting TTL, the same selection of TCP options, and the same TCP option order, causing nmap to fail in its attempt to fingerprint hosts on the network.
In this session, we'll review packet normalization techniques and how they can be applied to the traffic flowing through our switches to make hosts that they support resistant to fingerprinting, even by nmap. We’ll walk through the process from start to finish, from the selection and design of the transformations (some old, some new), to the development of the proof of concept, and finally to the demonstration of idguard itself on a RouterBoard model RB450 router. Followed up by a discussion of the issues involved, the challenges to overcome, and the obstacles to deploying this in a production environment.
While ultimately something for the network switch, idguard is suitable for any Linux based router capable of loading and using kernel modules, and will be available for you to take home when we are done so that you can try it for yourself. It uses the packet normalization techniques that I developed, and it is more than enough to show you that while it is not currently an existing feature of switches like DHCP and IGMP snooping, it should be.