Just to throw in my $0.02 (some readers might want to skip this message: it's content
might lower their faith in firewalls): This whole discussion reheats the old question
about what to call an application layer proxy and what not.
First of all, I think Paul is on the right track. But I think the situation is worse.
[Paul Cardon wrote]
> If you reread the last paragraph of the stateful inspection section of
> Mikael's post you can see the key difference: "This all assumes that the
> firewall isn't completely reassembling the stream, but rather looking at
> the contents of individual packets."
Reassembling the stream is not enough. Period. Any proxy which calls itself
"Application Level" is required to get the whole picture. It has to know what is going
on, why it is doing this or that, and what the security implication of it's doing are.
This will never be 100%, but an "Application Level" proxy has to be very -- VERY --
close to 100%.
#dream on
An WWW Application proxy should be able to see the page which it is about to deliver
to the client. It should be able to strip any, all, and everything which could harm
the client application.
#dream off
An FTP Application proxy must be able to convert passive FTP to active FTP and vice
versa. If the client wants to get a file, the proxy must get the file and serve it to
the client. There must not be any interaction between the protocol logic of the server
and the logic of the client. The client asks for a file, the proxy gets the idea, the
proxy speaks to the server, receives the file, and finally sends it to the client. Any
interaction between the client and the server which goes beyond the fact that the
server sent a file and the client received a file would make the proxy a "non
application level" proxy.
> Checkpoint's patch "fixes" the problem by requiring responses from the
> server to be terminated by a newline and fit in a single packet. This
> improves the situation at the expense of blocking some potentially valid
> traffic. Unfortunately, it is still possible to exploit the real
> problem by playing within FW-1's new rules.
Pardon me, but: A fix which only makes it harder to exploit the flaw should not be
called a fix. It's like "our marketing people said that the average script kid is able
to jump over a 3 feet fence. Take this 3.5 feet fence. It should make you feel good.".
They've done something: They gave the people a good feeling but left the problem. They
made it worse.
(and I've not even started to talk about the phrase "don't use passive FTP")
> That is why one of the
> alternatives would be to use their "ftp security server" (clever name to
> avoid the word proxy) which presumably does reassemble the entire
> control stream. Perhaps they even did it right.
If ressembling the stream would be enough.
Or does it more than this? Has anyone any hard facts?
Trying to sell transport layer proxys by the name of application layer proxys might be
more common than most people think. I can't prove it right here, but I have this
feeling. I have this dream...
andreas.
[DISCLAIMER: I speak for myself only.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
