In some mail from Jean-Christophe Touvet, sie said:
>
> As far as I know, this is a Firewall-1 bug. The reason is that Gauntlet used
> to split its PORT commands in two packets (two write() system calls). Since
> Firewall-1's filtering code works only with one packet at once, it fails. TIS
> guys wrote some patches to solve this problem (contact your Gauntlet
> reseller),
> but IMHO that's really a packet filtering design problem: how do you inspect
> data when it doesn't fit in the same packet ? Of course, you could keep data
> in your sate machine, but in that case you've just written a proxy. Any
> comments ?
This isn't a bug in Gauntlet.
The Gauntlet proxy has no say in how TCP packets are actually sent, that's
all handled by the kernel. It could buffer the two writes, split the two
up into 4, etc. The Gauntlet proxy can "suggest" that the kernel write
it all out at once, but what happens if your FTP control connection is
over a busy line, window drops to (say) 16 and you then issue a "PORT"
command. Firewall-1 is, if the above description is correct, going to
fail. Same problem is found in the Linux `ip_masq' code. Broken
solution, IMHO. Pester the Firewall-1 people for a real transparent proxy
that works all the time.
This highlights a problem with "advanced" packet filtering: it can (or
attempt to) modify or leave untouched data about which it has insufficient
knowledge about to make any sort of decision. The problem here is that
Firewall-1 is modifying application layer data from its position, in the
network layer.
Packet filtering should be limited to making filter decisions based on the
data in the network and transport headers unless some sort of reassembly
and sequencing is done to correctly piece together higher layer data.
This may actually amount to proxies being required/used :)
Hmmm, wonder if FW-1 is bug compatible with Linux :-)
Darren
Follow-Ups:
References:
|
|
