On Thu, 18 May 2000 [EMAIL PROTECTED] wrote:
> Perhaps, but it does so at the expense of higher layer processing and OS
> overhead, while a stateful inspection engine hits it below the Kernel below the
>
> network layer analyzing every packet before it hits the network driver.
If a firewall were to examine packets "below the network driver layer",
it'd have to institute its own network driver layer. There's not a
commercial firewall out there that hasn't had bugs, serious
security-related bugs. So, yes, there is overhead with an ALG, but it's
that overhead that provides us with transport layer protection for the
"protected" nodes as well as the ability to protect from things in the
data stream.
> > Well....not always. Cisco IOS FW and PIX do some application level
> > inspection and they don't use any third party hooks to do it.
>
> Please - do not confuse the PIX product with that of a compliant stateful
> inspection device...
Compliant with what? There's not a "standard" for firewall construction.
> > They are,
> > however, affected by a problem that is endemic to this kind of firewall -
> > you can trick them. Say you want to mount an SMTP attack using a bogus
> > command...normally the firewall would see the command and block the traffic.
> > If you break the data up into lots of packets, however, you can extend the
> > delivery of the command outside the window of data reassembly that is
> > possible in the box - net effect, command gets through. This is not a Cisco
> > problem - it's a problem with this _kind_ of firewall. Because they are only
> > passing the data through they can only look at a certain "window" of the
> > stream - after that they have to pass it through or they will run out of
> > time/space/storage.
>
> Hence, supports my point "not application aware and require 3rd party
> filtration or services for protocol stream level scrutiny."
To do it correctly requires either significant buffering (enough to cause
the same sort of latency issues that are harped about application
gateways) and either the rejection of out of order fragments, or an
attempt at fragment reassembly that mimics an ever-changing set of
"protected" nodes. Now you're throwing in "services" that generally
include a TCP/IP stack of their own to worry about (first or 3rd party)-
negating all that "benifit" you keep trying to show.
> Intrinsic to the ALG is the layer where it sits - hence as I'm sitting above
> the kernel/OS/ layer 3 + I'm
> subseptible to all attacks thereof.
This isn't true. It's *possible* that the ALG itself is susceptible to
attacks which it is vulnerable to (if you've done your research correctly,
that's a heck of a lot smaller of a set of issues than you propose.) In
the meantime, all the clients *aren't* susceptible to attacks below the
application layer. With any sort of packet filter, stateful or not,
inspecting or not, the author of the filter has to know about the attack
*before* it can be blocked (MSG_OOB being my favorite example of such) or
_all the "protected" nodes are potentially vulnerable_ and out of order
fragments must always be rejected or buffered and reordered subjecting
more firewall code to potentially hostile Denial of Service attacks or
clients to service outages.
It's also possible to pipe raw sockets to an ALG if you're so inclined to
write your proxies that way. You end up having to recreate enough of the
IP stack that it's probably not attractive under most circumstances versus
auditing the stack itself. As more and more people get redundant
load-sharing connections, out of order packet and fragment reassmebly may
become more of an issue.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
