Re: Two minor IPFW-related questions
On Mon, 28 Jul 2008 20:48:09 -0700, "Ronald F. Guilmette" <[EMAIL PROTECTED]>
wrote:
>On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" <[EMAIL PROTECTED]>
>wrote:
>> 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?
>
> First, on one particular machine of mine, I'm seeing a fair number...
> many dozens or so per hour... of /var/log/security logfile entries for
> ipfw-rejected packet fragments. This is on a machine that has a very
> busy name server. [...] The majority of the rejected "frag" packets
> are UDP packets, and I've just now determined that many/most/all of
> those are coming from actual name servers elsewhere.
It's fairly non-trivial to make TCP fragments (TCP tries its best to
avoid fragmentation and it splits traffic to 'segments' using its own
logic, not how many bytes the user application wrote). So it's "normal"
to see mostly UDP fragments.
> In short, I do believe that these packet fragments are mostly (or
> entirely) perfectly legitimate packet fragments... probably partial
> answers to DNS queries that the nameserver on this machine sent out.
DNS will fallback to TCP when UDP fails (i.e. when an answer datagram is
too large for UDP to deliver). So I might consider dropping them anyway.
> So now, given that I understand (or believe I do, anyway) everything
> that you, Giorgos, said about the possibility of a DoS attack based on
> packet fragmentation, and given that I _do not_ believe that anybody
> has it in mind to do a DoS against me at the present time (either
> using packet fragements or any other sort of DoS technique) is it
> really wise for me to be dropping all of these DNS response packet
> fragments? Wouldn't I be better off letting them in?
It depends on why/when the fragmentation occured. If a name server is
sitting behind a link with a small MTU or a link with a bit of data
loss, losing one fragment means that *all* fragments must be transmitted
again. In those cases relying on the capability of DNS to fallback on
TCP may be a slightly better choice.
> I'm most particularly concerned about the possibility that... because
> I have ipfw dropping all fragments... I may be completely losing some
> DNS responses that I actually do want
No that's fine. You may get a delayed response, when DNS decides to
switch to TCP, or a timeout if the whole "try UDP, fail, try TCP, fail"
dance takes too long. But in that case plain UDP would have failed
anyway, so you are just given an extra chance with TCP queries.
> OK, one last question. I've just read the helpful little brief tutorial
> about path MTU discovery... which Google helped me to find:
>
> http://www.netheaven.com/pmtu.html
>
> This is kinda sorta enlightening about why most of the fragments that
> my ipfw is currently rejecting are either at offset 1472 or at offset
> 1480... but not quite. What's the significance of these specific
> offset numbers (1472 and 1480)? Is there some particular kind of
> hardware or well-known- phenomenon (like the one described in the
> document above) that commonly produces fragments with those specific
> offsets, i.e. 1472 and 1480?
The two "standard" Ethernet encapsulation formats ("IEEE 802.2/802.3"
vs. "RFC 894") specify how data is laid out in an Ethernet 'frame'. The
encapsulated data areas in the two frame formats can hold:
IEEE 802.2/802.338-1492 bytes of data
RFC 894 46-1500 bytes of data
The numbers you are seeing are 20 bytes less than the maximum, because
they account for the minimum IP header of 20 bytes. With a minimal IP
header of 20 bytes, without any IP options, the two Ethernet frame
formats can hold 1472 and 1480 bytes of IP-encapsulated data. That's
the "magic" reason for the fragment sizes you see.
In reality the full-path MTU may be even smaller for a variety of
reasons, but that's another thing :)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Two minor IPFW-related questions
In message <[EMAIL PROTECTED]>, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: >On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" <[EMAIL PROTECTED] >om> 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? First let me send a big THANK YOU to Giorgos Keramidas for providing such timely and detailed replies to my IPFW questions. Much appreciated. Now that I've got that out of the way, let me say a couple of things. First, on one particular machine of mine, I'm seeing a fair number... many dozens or so per hour... of /var/log/security logfile entries for ipfw-rejected packet fragments. This is on a machine that has a very busy name server. The nameserver in question was recently upgraded to bind 9.5.0-P1 (so I'm not worred that there is any kind of attack going on here) _and_ also the ipfw ruleset recently had this added: deny any to any in frag The majority of the rejected "frag" packets are UDP packets, and I've just now determined that many/most/all of those are coming from actual name servers elsewhere. In short, I do believe that these packet fragments are mostly (or entirely) perfectly legitimate packet fragments... probably partial answers to DNS queries that the nameserver on this machine sent out. So now, given that I understand (or believe I do, anyway) everything that you, Giorgos, said about the possibility of a DoS attack based on packet fragmentation, and given that I _do not_ believe that anybody has it in mind to do a DoS against me at the present time (either using packet fragements or any other sort of DoS technique) is it really wise for me to be dropping all of these DNS response packet fragments? Wouldn't I be better off letting them in? I'm most particularly concerned about the possibility that... because I have ipfw dropping all fragments... I may be completely losing some DNS responses that I actually do want, and for which there are no other DNS servers that will give me unfragmented answers. Is this a reasonable concern? Might it be wise, in my case, to remove the rule that's killing all of the packet fragments from my ipfw rule set... and then just put it back if I ever seem to be undergoing a DoS? OK, one last question. I've just read the helpful little brief tutorial about path MTU discovery... which Google helped me to find: http://www.netheaven.com/pmtu.html This is kinda sorta enlightening about why most of the fragments that my ipfw is currently rejecting are either at offset 1472 or at offset 1480... but not quite. What's the significance of these specific offset numbers (1472 and 1480)? Is there some particular kind of hardware or well-known- phenomenon (like the one described in the document above) that commonly produces fragments with those specific offsets, i.e. 1472 and 1480? Just curious. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Two minor IPFW-related questions
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 192.228.91.19 > 66.60.171.112 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Two minor IPFW-related questions
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? 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:[EMAIL PROTECTED]) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
