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
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
- 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 (c) 2001 Kurt J. Lidl. All rights reserved.
Redistributions of this information must retain the above copyright
$Date: 2003/04/19 16:11:03 $