On Wed, 8 Mar 2000, John Adams wrote:
> > You want the truth? I caught one major firewall vendor in a big lie over
> > this one. Their so called proxy was nothing more than a transparent
> > connection, yet when I asked them if I put a telnet daemon on another
>
> Very few firewalls actually check that the protocol travelling over a
> particular port -really is- what the port is supposed to be used for.
By definition, an application layer gateway speaks the application
protocol. That doesn't prevent higher-layer tunneling inside valid
application layer data, but does prevent simply relaying or passing the
data at the transport or link layer.
> Anyhow, I see this as an easily spoofable scenario, and building a
> firewall to do protocol analysis would also have to support resetting the
> connection if the protocol should ever deviate from the established norm.
> It seems like this would be an incredible amount of work for the firewall
> to do on each packet, as it would now have to maintain state for each
> conversation (per protocol).
Or it would have to act as a server and then make its own client
connection.
> Consider this, an inside employee sets up an ftp server on port 80 of
> their home machine, and you don't want anyone using ftp because they might
> ftp out your super seekrit widget plans. You say that outbound port 80
> should only be web, but I blast a bunch of packets before my ftp
> connection setup to fool the firewall (even better, I just forget the
"Bunch of packets" won't work with an application proxy, tunneling over
HTTP will, hence the current push to tunnel everything and its mother over
HTTP.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
