netdev
[Top] [All Lists]

Re: [PATCH] Make netfilter handle .. perhaps offtopic

To: Harald Welte <laforge@xxxxxxxxxxxx>, kuznet@xxxxxxxxxxxxx
Subject: Re: [PATCH] Make netfilter handle .. perhaps offtopic
From: Peter Bieringer <pb@xxxxxxxxxxxx>
Date: Mon, 28 Jan 2002 23:29:58 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20020128202052.W26676@xxxxxxxxxxxxxxxxxxxxxxx>
References: <20020128191923.V26676@xxxxxxxxxxxxxxxxxxxxxxx> <200201281902.WAA01789@xxxxxxxxxxxxx> <20020128202052.W26676@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

--On Monday, January 28, 2002 08:20:52 PM +0100 Harald Welte
<laforge@xxxxxxxxxxxx> wrote:

> It's difficult in the case where we have a PORT command (or
> similar) split over two packets all the time.  Not talking about
> retransmissions. W'd have something like
> 
> tcp packet one: "PORT 192,16"
> packet two: "8,1,1,12,34\r"
> 
> (or even more packets).  How would we reliably match against the
> command? Where do you draw the line? what is about each character
> in one packet?
> 
> To cover this (other) case, we would need to remember a certain
> amount of payload of every ftp connection. to be precise:
> strlen(MAX_PORTCMD_LEN-1)  bytes.  We would need to keep this like
> a ringbuffer.

Don't know if it's still the case, but some time ago (~ 2 years)
reading Cisco doc of PIX firewall and their Javascript filter, they
mentioned also that this isn't (wasn't) detected if the Javascript
tag in HTML was splitted between two TCP packets.

Therefore I think *all* "looking for interesting text in TCP streams"
(FTP "PORT", Javascript tag, or something else which is interesting
or important) should take care about that this string can be splitted
between 2 packets. Otherwise the probability of "not hit because of
splitted" will be not zero.

And this is imho a security issue. Think about e.g. (don't know, if
ever possible, but) a special modified web server, which checks MTU
and split candidates for filtering to do unwanted things...

mho: netfilter is (or should/will be hopefully) a stateful inspection
engine comparable to (or better: superseed) the current market leader
of commercial firewalls...therefore splitting of text between TCP
packets should always be catched and no issue for perhaps later
possibilities of upcoming security issues.

Comments?

        Peter

<Prev in Thread] Current Thread [Next in Thread>