From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 29 16:02:58 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 72DC716A4CE for ; Sun, 29 Feb 2004 16:02:58 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 116B043D39 for ; Sun, 29 Feb 2004 16:02:58 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost [127.0.0.1]) by whizzo.transsys.com (8.12.10/8.12.10) with ESMTP id i2102v0R080613; Sun, 29 Feb 2004 19:02:57 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200403010002.i2102v0R080613@whizzo.transsys.com> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: "J.T. Davies" Organization: Serendipity Scheduling & Management X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" References: <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org> In-reply-to: Your message of "Sun, 29 Feb 2004 15:29:44 PST." <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Feb 2004 19:02:57 -0500 Sender: louie@TransSys.COM cc: freebsd-ipfw@freebsd.org 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: Mon, 01 Mar 2004 00:02:58 -0000 > > > I got to thinking -- I see (semi-frequently) in docs a rule at the top > > > of > > > the list much like: > > > > > > ipfw add 100 allow ip from any to any established > > > > > > ...and here's where the thinking part comes in... > > > > > > Is it possible to (spoof isn't the correct verbage) override the TCP > > > flags > > > on packets, thereby defeating the intent of the aforementioned rule? I > > > mean, if I had the knowledge (and the evil intent to do so) to create a > > > program that added the EST flag onto the TCP packets...rule 100 would > > > accept > > > the packet, thereby allowing access to anything behind the > > > firewall...no? > > > > > > Thoughts? Or is this a non-issue due to the stringent authoring of the > > > TCP/IP protocol? > > > > I'm not sure I follow your ideas. There is no 'EST' flag in a TCP > > packet. The "ESTABLISHED" state is kept at either end of the > > connection, not in the packets themselves. In addition, the two ends > > may not have the same state. > > > > Regards, > > > > Justin > > Ok, the Cliff Notes on TCP failed me...guess I gotta take TCP101 class > again. > > I re-read the man page for IPFW (and didn't blink this time). The > "established" rule matches on RST or ACK. > > 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")? [Or > am I just talking out my butt here] > > Or, to put the question more generally...could a "hacker" change the > flags/bits of the TCP packet at their whim? Sure, an attacker can generate spoofed packets with bogus source addresses to get through the filters. The intent of the established flag is to off-load policy of how connections get established somewhere else; like allowing outbound SYN segments from the "inside" to external destinations, but perhaps not the reverse. The exposure is an attacker injecting bogus data into the middle of an existing TCP connection, or "shooting down" an existing TCP connection by generating traffic with a RST (reset) bit. For either of these attacks to succeed, the attacker need to guess the source/destination IP addresses and source/destination TCP port numbers, and more difficultly, generate a packet with the TCP sequence number "in the window" of the TCP connection being attacked, The sequence number is 32 bits in size, so the attacker needs to guess a sequence number in the receive window, typically 32k in size out of a 32 bit numbered space. This is why you see things like randomizing the initial sequence numbers of connections to make it hard to predict sequence number that might be in use. Other approachs are to cryptographically protect the contents of the TCP and IP headers by using IPSEC with an authenticator to validate the packet header, or the TCP MD5 checksum option to protect TCP header fields. Both approachs typically require some sort of pre- arranged configuration between the two parties to the TCP connection, including sharing some sort of keying material. louie