--On Monday, January 28, 2002 08:20:52 PM +0100 Harald Welte
> 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)
tag in HTML was splitted between two TCP packets.
Therefore I think *all* "looking for interesting text in TCP streams"
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.