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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:06 PDT