Firewalls @
GreatCircle .
COM writes:
> Yes, they basically are, in general. The biggest
>difference between the two is one of perception.
I see your case now: It is possible to either implement an
application level gateway that handles a protocol or to tap an
incoming connection and attach a state machine (or some other
mechanism) to this connection that tracks the protocol on this
connection at an arbitrary level of detail.
Still there is a greater difference than just perception.
A packet filter still deals with its information on a packet
level. It gets a new packet from the incoming port, advances all
its state machines and passes the packet on (or drops it and all
packets related to this transaction that might be received in
the future). Sometimes the connection is cut somewhere in the
middle of a transaction. An incoming FTP connection might be
snooped at the content level and the filter does know about the
file. From the connection it has learned that it is an ARJ
compressed exe file for MS-DOS and that it contains well known
viral code. The connection to the target FTP server that is to
be protected is cut at this point by the filter, but a partial
update has been done, leaving dangling connections and a partial
file around.
An proper application level gateway would perhaps perform the
upload into a quarantine area, apply standard tools to the
suspicious file and either let it through in its entirety or
drop it completely.
Of course the packet filter has enough state information to undo
the transaction (if at all possible): It could emit abort and
deletion commands and close the connection, but this would add
even more complexity to the filter. The application level
gateway has an advantage: Both know about higher level
transactions, but the gateway can act on the level of this
transactions dealing with entities of this level while the
packet filter acts on packet level.
If you do security checks, you do them on a certain layer of the
stack. The result of this check is applied to some transaction
on this layer. If implemented properly, the complete
transaction should never happen, if the check fails somehow.
>There's no
>inherent superiority of either application level gateways
>or dynamic packet filters. The superiority comes from
>whether or not there is adequate security-related processing
>for the protocols you want to run through the firewall.
I agree with you that any filter that is going to track a
connection at application level has to be just as complex as
the corresponding application level gateway.
I just think that it might be easier to write and verify such
application specific code for applications (much of this code
already exists) than for something that has to perform such
checks on the fly while it is wading knee deep through partially
received data.
And it might be easier to withold a certain transaction within
an application level gateway until it is proven to be harmless
than to undo a partially committed transaction that became
harmful in the middle of being executed.
Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
"Ivanova is always right. I will listen to Ivanova.
I will not ignore Ivanova's recomendations. Ivanova is GOD.
And, if this ever happens again, Ivanova will personally RIP YOUR LUNGS OUT!"
--The Babylon 5 Mantra
|
|
