Two minor IPFW-related questions

[Giorgos Keramidas]

On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" <rfg at tristatelogic.com> 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 192.228.91.19 66.60.171.112 in via rl0 (frag 60396:368 at 1480)

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:1480 at 0+)

    # 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:1480 at 5920+)

    # 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:19 at 1480)

    # 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