Date: Sun, 29 Feb 2004 19:02:57 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: "J.T. Davies" <jtd@hostthecoast.org> Cc: freebsd-ipfw@freebsd.org Subject: Re: TCP established flag & ipfw rule Message-ID: <200403010002.i2102v0R080613@whizzo.transsys.com> In-Reply-To: Your message of "Sun, 29 Feb 2004 15:29:44 PST." <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org> References: <CA1B3FE4-6B08-11D8-BD24-00306544D642@mac.com> <001c01c3ff1b$ea0d83e0$3301020a@hostthecaost.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403010002.i2102v0R080613>