From owner-freebsd-security Tue May 22 17:53:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id D37C037B43C for ; Tue, 22 May 2001 17:53:16 -0700 (PDT) (envelope-from crist.clark@globalstar.com) Received: from globalstar.com ([207.88.153.184]) by nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with ESMTP id GDRJS500.M5N; Tue, 22 May 2001 17:52:53 -0700 Message-ID: <3B0B09F9.1825BEC4@globalstar.com> Date: Tue, 22 May 2001 17:53:13 -0700 From: "Crist Clark" Organization: Globalstar LP X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lowell Gilbert Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPFW Rule -1 Always = Attack? References: <44y9rtf9ox.fsf@lowellg.ne.mediaone.net> <44ae4669z0.fsf@lowellg.ne.mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lowell Gilbert wrote: > > diman@asd-g.com (diman) writes: > > > On 19 May 2001, Lowell Gilbert wrote: > > > > > dwplists@loop.com (D. W. Piper) writes: > > > > > > > If I understand things correctly from the archives and the IPFW man > > > > page, IPFW rule -1 is built into the firewall, and only applies to > > > > rejecting IP fragments with a fragment offset of one. The man page > > > > further states, "This is a valid packet, but it only has one use, to try > > > > to circumvent firewalls." > > > > > > > > Does that mean that every packet dropped by rule -1 indicates a > > > > deliberate attempt to circumvent the firewall, and should be reported to > > > > the appropriate network administrator for the source IP address? > > > > > > It's *possible* that the rule could be triggered by something that > > > wasn't an attack. Thinking about it briefly, it seems slightly more > > > likely that it's part of a probe, rather than an actual attack > > > However, reporting to the network administrator for that address is > > > almost certainly useless in any case, because an attacker would > > > probably have spoofed that address anyway. [An attacker wouldn't ever > > > get any response from that packet in any case.] > > > > Attacker can get answer from a destination host. It's a ipfw between > > if he willn't. Easy rule :) > > This is incorrect. The attacker can't get an answer in either case. > > The destination host won't reply unless the packet with the fragment > offset of zero *also* got through to that destination host, in which > case this rule doesn't matter. Huh? It sure does. If the first packet gets through, the second one is stopped, thus preventing all pieces from reaching the destination host and being reassembled. > If it isn't the case, the destination > host will never get a whole packet, and will never respond. > > The "rule -1" situation is only useful (to attackers) as part of a > traffic analysis scheme, and not terribly even for that. However, > there's no downside to dropping these packets, so we do. No, the use of these packets is to try to slip datagrams past a firewall. If a datagram containing a TCP segment is fragmented with an offset of 1 (8 bytes), the source and destination ports and the sequence number are in the first fragment, but the TCP flags will end up in the second fragment. This could potentially confuse a firewall that does not reassemble fragments (like ipfw(8)). The firewall has no TCP flags to check on that first fragment, so what does it do? In a stateless packet filter, how can you tell if a packet is part of an established connection without checking the flags? Well, ipfw(8) has been designed to not be concerned since it just drops that second fragment. See RFC1858 for a more complete discussion. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message