On Fri, 30 Jul 1999, Matt wrote: > A FireWall-1 NT denial of service was actually discovered/discussed on > bugtraq in February using similar methodologies to those described by > Lance Spitzner in his recent mail. This is one of the public posts, > but there was quite a bit of discussion in private mail as well. > > To summarize: Someone was claiming that this problem was not in > FireWall-1 NT, but NT's IP stack that was causing the crash. I was fairly > certain this was not the case, as I had just done quite a bit of testing against NT 4.0 > SP4 at the time with nmap. I had followed up by testing FireWall-1 NT > v4.1, and it did crash (the NT service shot up to 100% CPU usage) when > several spoofed SYN scans were run against it's untrusted interface. The > difference between this attack and the one Lance has described is that > this attack appeared to work against both the trusted and untrusted > interfaces, and can be performed over multiple hops. I am the person who had stated the problem was in NT's stack. The FW1 state tables do not get created when a packet is denied. Also, in the default config (with a cleanup rule), there are only 9 or so ports open. If this was FW1 related, it's probably related more to something internal in NT freaking out and thereby causing FW1 to freak as well. This problem seems as if it could be fixed by NOT building the state tables for a connection unless it recieves the SYN/ACK from the destination host. Just counting a SYN alone is useless, you have no idea whether or not the connection *can* be established yet. Perhaps to go even deeper, why not flag that SYN as it's coming in/going outbound with a timeout value to wait for a SYN/ACK response? If FW1 recieves the SYN/ACK it's has flagged then it should create the necessary state table. Otherwise, it should log & discard the flag appropriately. That would also allow for reasonable connection timeout values (for connections that we know exist). This could however, have it's drawbacks. If FW1 does not keep it's state tables when reloading the policy (or other things), all current connections would be lost. Not too bad considering we at least know that the connections have been established and registered with FW1 in a more orderly fashion. Jason Ihde
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:54:46 PDT