On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote: > Just a couple of questions about IPFW-related things: > > 1) Somewhere the other day I read a recommendation... which looked > rather official to me that the time... that all fragments should be > firwalled out, e.g. thusly: > > deny any to any in frag > > Is that actually a Good Thing To Do? Are there really no legitimate > packate fragments out there on the Internet?
Yes, they may be legitimate packet fragments. Normally, the path MTU discovery algorithm should kick in most of the time. It is turned on by default # pwd /usr/src/sys/netinet # fgrep path_mtu_discovery tcp_output.c int path_mtu_discovery = 1; SYSCTL_INT(_net_inet_tcp, OID_AUTO, path_mtu_discovery, CTLFLAG_RW, &path_mtu_discovery, 1, "Enable Path MTU Discovery"); if (path_mtu_discovery) # But there may be routes between your FreeBSD box and the two endpoints of a connection that do not have this option, or have it disabled. This means that if you are not absolutely sure that all hosts 'inside' and 'outside' the firewall support path MTU discovery *and* have it turned on, it's still possible to get fragmented datagrams. The reason why fragments may be prudent to drop in a firewall is that non-initial fragments don't contain enough information to be classified on a port-by-port basis. Fragmentation requires that each fragment should contain a data portion that is a multiple of 8 bytes (except for the last fragment of a datagram), so the first fragment will generally contain useful bits (i.e. UDP source port, and UDP destination port), but this means that a 'malicious' user may use *non* initial fragments to generate artificial load on your firewall. A router that accepts fragments and isn't configured to drop them may have to keep non-initial fragments for a certain amount of time, hoping that the first fragment of the datagram will arrive soon, and the datagram will be reconstructed before forwarding it. If your firewall keeps around non-initial fragments and a malicious user sends thousands or even millions of non-initial fragments for seemingly legitimate connections, then your firewall may run out of useful resources. FWIW, you can find a lot of information about this sort of attack by searching the net for "fragment DoS attack". > 2) What is the significance of the last three numbers in the following > log line? What exactly does each one of them represent? > > Jul 28 00:00:13 segfault kernel: ipfw: 250 Deny UDP 22.214.171.124 > 126.96.36.199 in via rl0 (frag 60396:[EMAIL PROTECTED]) The three numbers are: * IP Identification Number, of the datagram. This is the copied straight out of the IP header's ip.ip_id field. * The number of data bytes in the data portion of this fragment (the size of the full IP fragment excluding the size of the IP header itself). * The offset of this fragment from the start of the full datagram. This is useful when trying to reconstruct the initial, full IP datagram, after all its fragments have been received. Non-final fragments also have the 'more fragments' flag set in their IP header, and then the three numbers are followed by "+", i.e.: (frag 60396:[EMAIL PROTECTED]) # Initial fragment, because the fragment offset is zero. There are # more fragments (the '+' flag is printed). It's sort of expected # that the _initial_ fragment will always have the '+' flag set. # After all that's the whole point of fragmenting the original IP # datagram :) (frag 60417:[EMAIL PROTECTED]) # Probably the fifth fragment of a relatively large IP datagram # (5920 = 1480 * 4). I'm saying `probably' because the mechanism # of fragmentation permits fragmenting a fragment _again_ while it # passes through routers. There are more fragments (presence of the # '+' flag indicates 'more fragments'). (frag 17234:[EMAIL PROTECTED]) # Probably the second and last fragment of an IP datagram with IP.Id # = 17234. There are 19 data bytes in the datagram, it is probably # the second datagram if we assume an MTU of 1480 (usually typical # in Ethernet interfaces). This particular way of presenting fragment size, offset and flags is also used in tcpdump output, so if you learn to read fragment info this way it will be useful if you have to look at tcpdump traces too :-) HTH, Giorgos _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"