IPFW Improvements for BSD/OS

During the development of a IPFW filter that would disrupt communications with machines running Microsoft software infected by the NIMDA worm, I encountered several shortcomings of the existing IPFW system. Here are my notes about the what could be changed to make the IPFW system less limited.

Add a tcpdata[X:Y] command

The tcpdata command would allow for looking at offset X bytes into the tcp data of a packet and examine Y (Y in 1,2,4) bytes of data. This would have to take into account IP options and TCP options, of course. It is incredibly hard to do this with the existing ipfwcmd syntax (read impossible), without falling back to BPF assembly. Getting to avoid having to fall back to the BPF assembler is why this would be useful!

Add a tcpstream[X:Y] command

This command, when used with a circuit cache, could look starting at byte X of the total tcp stream. This is pretty hard to do -- since multi-byte sequences might run off the end of the packet! Also, there would be a need to make this work for both directions of the TCP stream. Given the data offset for the TCP flow is tracked in the circuit cache, it should just be a matter of choosing a nice programming interface to all it to happen. This would need to be flexible enough to make sure the programmer can specify the tcpstream location for the data flow in each direction.

Add the ability to specify strings instead of constants in IPFW programs

This would simplify the filter writer's task of matching a given string ``fingerprint'' or ``signature'' in an IPFW filter. This is really just syntacic sugar, but a sweet feature to have!

Add a "tcp_reset" callable filter

This would also require adding an explicit "reassemble" filter. Change the existing "rewrite" filter to be synonyms for those two filters, depending on what flags where passed, rather than having an overloaded name and flags that tell it to do multiple (unrelated) actions. The "tcp_reset" filter should take a flag specifying which side (or both) of the connection should get the RST packet sent to it. Maybe a bitfield: 1 -> sender, 2 -> dest (and 3 -> both).

Change the "ipfwrewrite" command

Make it be more of a driver program that can deal with enabling the various callable filters that will ship with the system:
ipfwcall [ -T tag ] reassemble
ipfwcall [ -T tag ] tcp_reset
ipfwcall [ -T tag ] some_future_filter


Make it so packets can be modified at the foward filtering point

Currently packets may only be modified at the pre-input and pre-output filtering points in the kernel. Since packets hitting the forward filtering point are known not to interact with the TCP stack, this is also a safe place to modify packets.

Getting even more ready for IPv6

While much support for IPv6 filters exist in the IPFW framework, other changes would be desirable. Hook it back into the KAME IPv6 stack that BSD/OS is currently shipping. Figure out a way to allow for next-hop routing by IPv6 Addresses (currently impossible in IPv6, but possible for IPv4).

Copyright

lidl@pix.net
$Date: 2003/04/19 16:11:03 $