Date: Thu, 12 Feb 1998 23:06:06 -0600 (CST) From: Alex Nash <nash@mcs.net> To: freebsd-stable@FreeBSD.ORG Subject: ipfw users take note Message-ID: <199802130506.XAA13867@nash.pr.mcs.net>
index | next in thread | raw e-mail
Changes have been committed to -stable which fix ipfw's handling of
fragmented packets. An unfortunate side effect of the fix is that
fragmented packets which were previously denied/accepted may sometimes
have the opposite behavior.
A quick primer on the previous implementation: The last checks ipfw
performs to see if a packet matches a rule are against port numbers and
(if a TCP packet) TCP flags (syn, ack, etc.). For fragmented packets,
this information is available only in the first fragment (IP offset ==
0). As such, when ipfw saw one of these packets, it skipped the checks
for port number and TCP flags, and assumed a matched packet. This is
clearly wrong since the packet in question may not match the final
specifiers of the rule, such as the port number.
The new implementation takes this approach with fragments where the IP
offset is non-zero:
- Do not match fragmented packets if the rule specifies a port or
TCP flags
- Match fragmented packets if the rule does not specify a port and
TCP flags
In other words, match when we're sure the rule matches, but don't match
if we're unsure. Non-zero IP offset fragmented packets may be matched
explicitly with the 'frag' keyword.
There are a couple of problems to look out for. First, ipfw will now
reject rules which contain the frag keyword in conjunction with a port
specification or TCP flags. Second, services which commonly send
fragmented packets (NFS is a common example) may fail. This may be
indicative of fragmented packets being denied which were being passed in
the previous implementation. However, depending on your firewall
configuration, this may have the opposite effect -- i.e. NFS now works
where it didn't before (I happened to be puzzling over just one such
scenario recently). Note that if you have a allow rule which doesn't
contain port specifications between your NFS client and server, there
will not be any problems. A few quick examples:
1. Does not work:
allow tcp from any to any
allow udp from any to any 1-65535
deny all from any to any
NFS fails because the UDP fragments will not be passed by the
second rule.
2. Does work:
allow tcp from any to any
allow udp from any to any
deny all from any to any
Fragments are passed by the second rule because ports are not
specified.
3. Does work:
allow tcp from any to any
allow udp from any to any 1-65535
allow udp from any to any frag
deny all from any to any
Fragments are not passed by the second rule, but are passed by
the third.
Notes:
1. The above rules were for informational purposes only -- they aren't
very useful, nor do they make a lot of sense.
2. Fragments, as used above, does not include the first packet fragment
where IP offset == 0.
Alex
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802130506.XAA13867>