Bugtraq mailing list archives

Re: FW-1 DOS attack: PART II


From: avalon () COOMBS ANU EDU AU (Darren Reed)
Date: Fri, 6 Aug 1999 00:02:42 +1000


In some mail from Paul Boyer, sie said:
[...]
The need is to remember some (relatively small) state information about
a connection, while a DoS attack consist in flooding with irrelevant
packets requiring that same amount of information.

The problem here, isn't so much setting up new information but keeping
information around.  The problem was originally brought to life using
a port scanner, using real addreses, whereas the synflood problem is
most commonly associated with fake source/destination IP addresses.
Whilst synflooding was a per-host problem, with the firewall, it is
magnified as it must moderate all connections going through.  So if
n hosts on the inside are talking to m hosts on the outside, there's
the potential for n*m pieces of state information.

In the case of FW-1, I'm not sure what they can do w.r.t. ACK's and
resuming connections apart from throwing that nasty feature out.
Possibly have an accelerated timeout (a few seconds).

In a carefully configured firewall using IP Filter, denial of service
problems are more likely to hit the application (servers) before the
state tables, etc, assuming your attacks are sourced externally and
you have controlled internal endpoints.  My own firewall lets in mail
connections and that's it. The box will probably croak due to excessive
mail processes running before the state table gets filled.  If I wanted,
I could easily cause a DoS problem for myself with it - just send 10,000
`fake' SYN packets through to some host which I know will never respond.

For just holding state information about current connections, you could
probably implement something along the lines of pass the SYN's through
and enable state on SYN-ACK's in response, although that really requires
two rules per port.

That doesn't work, for NAT, as you need to know how to translate the packet
(both of them, to match and in both directions) and in addition, you need to
be sure that your translation isn't going to collide with a previous packet's
translation that you may now know nothing about.

Darren


Current thread: