Fri, 02 Jul 2010
New Firewall
In the last few months, I have totally rewritten the faculty network packet filter configuration. In the past we had several problems with it:
- Its 1600+ rules took more than half a minute to load (more on a machine
with more CPUs because of greater cost of locking), which caused a significant
disruption in our network service. I have invented a solution where
each chain is loaded with one of two suffixes (say
-aor-b. When reloading the configuration, we decide which suffix is in use (let it be the-asuffix), delete all rules with the other suffix (-b, for example), load the new configuration into chains in the-bsuffix, and then prepend the jump from bothINPUTandFORWARDchains to our top-level chains (input-bandforward-b). This is the "atomic commit", and later we can delete all the now unused-achains. So we can reload the entire firewall configuration with no service disruption at all. - Its structure was maybe 10 years old, from the time when connection tracking was either not present in the kernel, or (later) was not fast enough on our hardware. Now we have connection tracking support. Its final bit - conntrackd - has been put in place today. Moving to connection tracking has reduced the configuration size to about 1100 rules.
- The rules are generated from the common set of per-chain files, which may contain either L3 protocol-agnostic rules (like "allow SSH from everywhere") or L3 protocol specific rules (like "allow SSH from such and such IPv4 host"). This allows us to maintain the common configuration for both IPv4 and IPv6, and to be specific only when it does matter (IPv4 addresses, ICMP versus ICMPv6, etc.). So now the path for deploying IPv6 to end users is open (more on it in another post).
Now we have to solve more interesting problems. For example IPv6 best practices, or logging all packet flows using conntrack-tools somehow.