Re: [fw-wiz] CERT vulnerability note VU# 539363

From: Paul D. Robertson (proberts@patriot.net)
Date: 10/16/02 

From: "Paul D. Robertson" <proberts@patriot.net>
To: Daniel Hartmeier <daniel@benzedrine.cx>
Date: Wed Oct 16 10:20:02 2002

On Wed, 16 Oct 2002, Daniel Hartmeier wrote:

> On Wed, Oct 16, 2002 at 09:36:06AM -0400, Paul D. Robertson wrote:
>
> > If you're hosting public resources behind the same firewall that's
> > protecting everything else in your enterprise, you've probably made a
> > questionable architectural decision. If you're keeping state on say
> > inbound SMTP traffic, the question is "Why?" If the 'Net as a whole can
> > connect to something, the state itself isn't going to do much good. If
> > you're trying to rewrite sequence numbers because of a host that talks to
> > the public with high predeictability, again you're probably made a
> > questionable architectural decision.
>
> Keeping state can have performance benefits. Depending on your rule set,
> associating a packet with a state entry is cheaper than evaluating the
> rules. Keeping state does not 'just' increase the quality of filter
> decisions.

Ok, I can see that if you're handling less stateful entries than you have
rules, but with good rule ordering, or a busy site, I'm not sure it's a
gimme. Do you have any way to measure which is better, or threashold
information?

> > Public-talking hosts should be protectable with simple non-stateful packet
> > filtering rules- *especially* those which allow the untrusted side to
> > initiate connections.
>
> In my experience, allowing to specify a maximum for the number of states
> created by a filter rule is very useful in this case (if you want to
> keep state on all connections, and everything passes through the same
> firewall). While an attacker can exhaust the individual maxima for
> incoming connections to different services, other kinds of connections
> (like outgoing connections, or connections the attacker can't establish)
> are not affected.

If you can limit the connection rate- I've never been in a position where
that was overly necessary- I kept Web servers away from firewalls behind
screening routers, and tuned the stack of my SMTP gateway to handle
whatever it could without dropping legitimate connections- you could rate
limit services with QoS as well- that just moves the issue from the
stateful filter and its buffers to the router's buffers though. Unless
you can just reject the traffic.

Rate limiting is an interesting application of a state engine though, and
certainly one I hadn't thought about much. The issue here however is that
rate limiting creates a DoS window.

How likely is an exhaustion attack which doesn't turn into a complete
flood which brings down the other services?

I think for non-malicious stuff, rate limiting by state may be
interesting, but I think in the face of a malicious attack, it's probably
ultimately less useful than it seems on the surface (assuming a
relatively normal architecture, and not a hydra of connections and
address spaces.)

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts@patriot.net which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation

Relevant Pages

  • Re: Virus/trojan tunnel out from behind firewall?
    ... >> David Carmean wrote: ... >>> behind a firewall and thus providing an attacker a way into the ... > give an attacker a wormhole into the center of a corporate network. ... that allowed incoming connections to privileged ports). ...
    (Incidents)
  • Re: Can firewall help?
    ... Don't know about the firewall issue, ... would like to know why the connections are happening. ... including what ports an attacker can "see". ...
    (comp.security.firewalls)
  • Re: What is the Pattern here ?
    ... These are all Dialup Connections that I had no connection with at the time. ... It's obviously an enormous security hole, ... > and a real firewall box. ...
    (comp.security.firewalls)
  • Re: Black Ice confesses faulty program!!!
    ... > outgoing connections or traffic except in cases where these connections ... > "dangerous/suspicious" traffic by the BlackICE program. ... > get into your machine then even a PC *without* a firewall is completely ... If you don't think "Spyware" is a problem for computer ...
    (comp.security.firewalls)
  • Re: Port 135
    ... The patch doesn't disable DCOM / RPC, so connections can still be made. ... That's why you need a firewall. ... the patch is not the thing to control ... control over your TCP/IP ports and services, ...
    (microsoft.public.security)