Re: [fw-wiz] Firewall Primitives

From: Devdas Bhagat (dvb@users.sourceforge.net)
Date: 11/06/02


From: Devdas Bhagat <dvb@users.sourceforge.net>
To: firewall-wizards@honor.icsalabs.com
Date: Wed Nov  6 15:58:01 2002

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



Relevant Pages

  • Re: AS4.2/WM5/OUTLOOK2K3 suddenly not syncing, please help
    ... there is a connection EXIST between the device because I ... connection on port 26675 but on the PPC the port number keeps ... Outlook, countless times of reinstalling Activesync, removing Windows ... Firewall set to NO). ...
    (microsoft.public.pocketpc.activesync)
  • Re: port 80 is open
    ... The firewall drops all packets initiated ... > the packet sender an ICMP host unreachable message. ... the ICMP host unreachable message is sent if the ISP router cannot see ... and then close the connection as your IP is seen as not connected. ...
    (comp.security.firewalls)
  • Re: port scan to juniper fw
    ... If the packet with SRC-IP a.b.c.d ... enters firewall via interface 'X' and the route on the firewall for ... the below default behavior of Juniper SSG for a port scan. ... Information Assurance Certification Review ...
    (Pen-Test)
  • RE: FTP Window of opportunity?
    ... target on the line when in reality it was just a firewall lying to them. ... The connection connects and then immediately ... Subject: FTP Window of opportunity? ... the FTP port shows up. ...
    (Pen-Test)
  • RE: Strange replies on closed port
    ... port should be a RST - not dropping the packet. ... receiving an UDP datagram to a non 'listening' port. ... that message isn't generated by the end host, ... Connecting to a closed Port w/o Firewall: ...
    (Pen-Test)