From owner-freebsd-questions@FreeBSD.ORG Tue Jul 29 03:48:10 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1C10106566C for ; Tue, 29 Jul 2008 03:48:10 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-outgoing-helo.tristatelogic.com (112.171-60-66-fuji-dsl.static.surewest.net [66.60.171.112]) by mx1.freebsd.org (Postfix) with ESMTP id 89D718FC29 for ; Tue, 29 Jul 2008 03:48:10 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id F3D9711423 for ; Mon, 28 Jul 2008 20:48:09 -0700 (PDT) To: freebsd-questions@freebsd.org In-reply-to: Your message of Tue, 29 Jul 2008 05:27:05 +0300. <878wvlv30m.fsf@kobe.laptop> Date: Mon, 28 Jul 2008 20:48:09 -0700 Message-ID: <84492.1217303289@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Re: Two minor IPFW-related questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 03:48:10 -0000 In message <878wvlv30m.fsf@kobe.laptop>, Giorgos Keramidas wrote: >On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" 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.