From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 1 18:29:43 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46DD616A4CE for ; Mon, 1 Mar 2004 18:29:43 -0800 (PST) Received: from bsd1.hostthecoast.org (dsl-230-142.ipns.com [209.210.230.142]) by mx1.FreeBSD.org (Postfix) with SMTP id A6CAA43D2D for ; Mon, 1 Mar 2004 18:29:42 -0800 (PST) (envelope-from jtd@hostthecoast.org) Received: (qmail 27498 invoked from network); 2 Mar 2004 02:30:40 -0000 Received: from unknown (HELO host1) (10.2.1.51) by bsd1.hostthecoast.org with SMTP; 2 Mar 2004 02:30:40 -0000 Message-ID: <001a01c3fffe$93257ef0$3301020a@hostthecaost.org> From: "J.T. Davies" To: References: <200403020118.MAA18408@lightning.itga.com.au> Date: Mon, 1 Mar 2004 18:32:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: TCP established flag & ipfw rule X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 02:29:43 -0000 > jtd@hostthecoast.org said: > > To clarify, instead of "EST" in my original post, replace with "ACK". > > Could some unscrupulous person add the "ACK" flag to the TCP packets > > and be accepted by this rule (even though they may not technically be > > "ACK")? > > > They could. But this is not as damaging as you think, because once the > malicious packet is passed by ipfw and gets to the destination machine, the > dest machine will try and look up the internal state (i.e. seq numbers, window > sizes, RTT estimates etc) for this supposed TCP connection. It will > presumably not have a TCP connection with the matching ip address/portnumbers, > so all this will do is cause the "attacked" machine to send an RST and discard > the malicious packet. It won't magically make a connection appear in the > target machine. The only way to initiate a TCP connection is with a SYN > packet, and they don't get passed by the "established" rule. > > So this is a possible denial-of-service (forcing the internal machine to > consider and RST random attacking packets), but not a security failure as > such. > Excellent! Thank you all who responded!