As I recall, when SYN floods were first becoming a hot topic on comp.protocols.tcpip, the general consensus was to implement Random Early Drop rather than an LRU queue for incomplete connections for precisely this reason. RED tends to drop malicious, rather than innocent, packets because they make up most of the packets in the queue. At the time, someone also pointed out that RED need not be implemented with any actual (pseudo-)randomness; just walking the queue with an appropriate step size and dropping each entry hit until the queue falls below the high water mark is sufficient. This was so widely discussed as a solution to SYN floods that I'm a bit surprised it hasn't popped up in this discussion. Does FW-1 use RED to handle SYN floods? Is there any reason why RED wouldn't work as well for the state table? (Someone earlier in this thread suggested that FTP relies on a one-hour timeout in the state table. I couldn't find anything to confirm that in RFC 959 or RFC 1123, but I'm not an FTP expert.) Michael Wojcik michael.wojcikat_private MERANT International Inc. Department of English, Miami University -----Original Message----- From: Victoria E. Lease [mailto:leaseat_private] Sent: Tuesday, August 03, 1999 8:52 AM To: BUGTRAQat_private Subject: Re: Simple DOS attack on FW-1 > On Fri, 30 Jul 1999, Jeff Roberson wrote: > > Also, if they implemented a circular buffer where connections that had > > been idle the longest were disconnected in favor of new connections their > > scalability might increase some. Wouldn't this allow DoS attackers to not only keep new connections from being established, but also to forcefully close already-established valid connections? Or am I missing something? I think it might work, though, if non-established, ie only two of three handshakes completed, connections were kept in a circular buffer. That way, the worst abuse that could happen would be for DoS'ers to incur a *chance* of established connections failing, and they wouldn't be able to affect already-established connections. They'd have to keep hammering at the unestablished-connection buffer, and very quickly, too, in order to keep valid connections from making it through.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:09 PDT