On Jun 5, 2:11pm, Cy Ardoin wrote:
} Subject: Re: PIX and FW-1 (packet filter Question)
} On Thu, 5 Jun 1997, Jonathan M. Bresler wrote:
}
} >
} > >I don't think there is anything an application firewall can
} > >do that can't also be done by a "packet filter" firewall. The
} >
} > trivial example:
} > a smtp application level proxy can disable the "debug" command
} > for every sendmail behind that firewall.
}
} Finding and removing the "debug" command from smtp connections at the
} packet layer isn't much different than finding and altering the PORT and
} PASV part of the FTP command and all the NAT style packet filters
} modify the FTP commands. It's not something packet filters do, but
} it is no more difficult than many of the things they already do.
What if each character in "debug" is sent in a separate TCP segment?
What if the segments are sent out of order? What if "debug" is part
of one TCP segment that is fragmented with overlapping fragments such
that you don't see "debug" until the fragments are reassembled in a
certain way? And don't forget, you need to keep track of the entire
state of the SMTP connection, so that you don't drop the connection
because "debug" is in the text of the message. The reassmbly and
reordering is done by the TCP stack in an application proxy firewall,
so the application proxy and the destination mail server will see the
same cleaned-up datastream.
I seem to recall that the FW-1 ftp command stream rewriting broke
if the packet boundaries happened to occur in inconvenient places
(I believe they fixed this a while ago). If you're just relying
on your firewall to rewrite your ftp commands, then about the worst
thing a hostile ftp client could do is just not work. If you're
relying on your firewall to sanitize incoming data streams, then
any failures to accurately track the connection state could result
in a security breach.
In principle, a stateful packet filter and an application proxy can
do the same thing, but it would take a very large number of states
to duplicate what the network stack does with input packets. Even
if your packet filter implements an equivalent state machine, there
is the danger that the destination host works in an unexpected way that
still leaves it vulnerable. Probably the easiest and safest thing
for the packet filter can do is to throw away fragmented packets and
out of order TCP segments, but I suspect that violates some of the
"should" and "must" clauses in the RFCs.
--- Truck
|
|
