ipt_scrub: scrubbing for Netfilter

scrubbing is the action of normalizing packets. The goal is to not be able to determine the operating system of clients behind a gateway. Normalized trafic offers the following possibilities :

• Just before an IDS, we can make its work easier by feeding it normalized trafic : there is no TTL trick used to escape detection anymore.
• Minimize OS fingerprinting, Even through the "Application Layer" will give hints to an attacker (User-Agent in HTTP header or mail enveloppe), not every protocol has this "flaw" : DNS, IKE, SMTP, etc. Furthermore, there is not only the fingerprinting issue : an administrator can wish to hide the fact he is running a farm of DNATed servers.
• Misshapen trafic can be discarded, the time of "Ping of death" is not over! Last year, there were (simple) major vulnerabilities in missshapen packets : the IPv6 routing header issues, old school flaws in pre-beta of Microsoft Windows Vista.
• Protection, or interface with embedded equipment : some legacy equipment in end of life could still have TCP ISN vulnerability without any update possible.
• A similar framework is implemented in OpenBSD (pf) but there was no scrubbing support into the Linux kernel.

A merge was tried with upstream, but the developpers will not integrate it, mainly for philosophical issues (we shall stop to break the end-to-end principle, we saw the result with NAT).

It's sad to not be merge because that means that I must maintain my patches along the kernel. Unfortunately, I don't have much time to follow the kernel releases.

• The Netfilter patch
• The IPtables patch

Performing normalization should be harmless as long as we stick to two rules :

• Stay RFC compliant
• Keep in mind the consequences of a change : we can lower a TTL but never rise it!

So the answer is no, scrubbing will not eat babies.

The current patch achieves the following transformations :

• IPv4
  • Random IP ID
  • Zeroify ToS
  • TTL normalization
• TCP
  • Random TCP Sequence
  • TCP Options
  • Random Timestamp
  • Sanity checks on MSS
  • TTL seal : The TTL cannot be modified within a TCP connection It means that you must make sure there is only one only route to the destination (there cannot be two paths with different distances). This feature is disabled by default because of this issue.

There isn't any IPv6 transformations yet but there should be more if the development restarts…