Re: Firewall Primitives

[Devdas Bhagat <dvb () users sourceforge net>]

On 06/11/02 08:48 -0500, Marcus J. Ranum wrote:
<snip>
> 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.
IMHO, most organizations should not care about packet filtering
firewalls dropping packets on the edge in accordance with policy.
The only place where you want to collect information is a honeypot,
which is a different kettle of fish.

> 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
Thats as far as simple packet filters go.

> doing app-level processing and signature checking against the
> incoming (or optionally outgoing) stream to check for misuse or
This would be a matter for an application layer gateway. I don't know
about others, but I certainly count application layer gateways/proxies in
my firewall architecture.
<repeat rant>
Older systems were not fast enough to check all network traffic for
malicious behaviour. Modern systems are fast enough to do protocol
validation for most speeds
</repeat rant>

> 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.
Shouldn't the default posture be to run untrusted traffic through a
validating proxy anyway? The additional complexity of switching modes
based on content inspection is too high as compared to the cost of
another box as an application proxy.

> 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.
An old line of thinking which should be dropped, just like
telnet/ftp/r*.
My personal preference is:
Hostile network -> SPF -> ALG -> Audited application.

NIDS may be present, but I would recommend a HIDS on all boxes.

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