Re: Firewall Primitives

["Marcus J. Ranum" <mjr () ranum com>]

George Capehart wrote:
> It really did seem that he was suggesting that the firewall actually
> actively route, as opposed to "look at the packet and drop it if it doesn't
> like it . . ." ;-]  So, I really meant to use the term router.  

I guess I was thinking like an IDS guy - one of the big problems of
a firewall is that it inherently interferes with the telemetry that
you might want to collect from an IDS. (Then again, you might NOT
want to collect it, and that should be OK, too...)   This applies
at both the packet level and at the app level - but if you can
provide the necessary semantics at the app level, the packet level
must (by definition) be a given. Consider two current cases:

A firewall gets a SYN packet aimed at port 23 on a machine behind
the firewall. The firewall looks in its policy table and drops the
packet (or sends a reset) to the client, and logs a refused connection.
What does an IDS see? Nothing (if it's inside the firewall) or
nothing (if it's outside the firewall) except a rejected connection.
Was it a probe or attack? We'll never know because it never got far
enough to even matter. Maybe we don't care but maybe we'd have
wanted the firewall to do something like hand-off the connection
to an internal routine that tarpitted the connect, or gave a
login: prompt, or whatever. Just for information collection. It'd
be an interesting option, anyhow.

The next case is more complex and really points out (to me) a lot
of the flaws in firewalls today. Consider a firewall gets a connection
on port 80 inbound to a webserver. It checks policy and sees it
should be allowed. It logs the connect and begins shuttling packets.
That's as far as most firewalls go. BUT the firewall _should_ be
doing app-level processing and signature checking against the
incoming (or optionally outgoing) stream to check for misuse or
intrusions. Suppose it finds an incoming URL that looks like a
buffer overrun. At that point, it might make sense to hand the
traffic off (simulating a session start-up internally or setting
one up with an external machine and switching into proxy/NAT
on that session) to something that might perform more detailed
analysis, packet capture, IDS, or honeypotting.

About a month ago(?) I posted a flowchart for the whole
IDS/firewall/antivirus/content inspection/honeypot/VPN/NAT
gamut, which are all really aspects of the same thing: security
oriented boundary traffic management. Traffic management
can't be just packet-level because there are non-packet-level
attacks that we should be worried about. Most firewalls are
packet-oriented but that's only because the customers and
equity markets have rewarded speed over security in such
products.

mjr.
---
Marcus J. Ranum                         http://www.ranum.com
Computer and Communications Security    mjr () ranum com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards