On Wed, 21 Apr 2004, Don Lewis wrote: > On 21 Apr, Mike Silbersack wrote: > > Would it be feasible for us to create a four to five element array to > > track "resettable" sequence numbers? This could hold the sequence numbers > > of the last few packets transmitted, and account for that edge case as > > well. I'm very uneasy with the IETF step C - sending more packets out > > into the network sounds like a new type of amplification attack. > > I'd be concerned about the extra memory, especially in cases where we > want to support very large numbers of connections. I don't think the memory would be prohibitive, but upon further thought I don't think the idea is advantageous. > As far as amplification, step C has a gain of less than one, since > packets are only transmitted if the incoming packet hits the window, and > they will be the same or smaller in size than the incoming packets. I > don't know if it would be valid to rate limit them ... Good point, I had forgotten about that. However, I'm still worried that sending those acks could have a downside. With all the tcp stacks out there, it seems probable that something will go wrong. > If this is the only edge case that we have to worry about, we might be > able change the test to: > > if (th->th_seq == tp->last_ack_sent || > th->th_seq == tp->last_ack_sent + tp->rcv_wnd - 1) { Ok, what if we do something like this: 1. Accept all RSTs meeting the criteria you just listed above. 2. Keep a global counter of all out of window RSTs that were received which corresponded to legitimate connections. (Don't track _all_ RSTs, or backscatter from scanners / etc will falsely be detected as an attack.) If we're over a certain threshold, set the "under attack" flag. 2a. This counter could also be per-socket, with a very low threshold. (I think I like this better, actually.) 3. If a RST arrives within the window, check the under attack flag; if we're under attack, drop it. If we're not under attack, accept it. Add to a counter tracking how many of these we received and what we did with them. With this setup, any attempt to run the brute-force RST attack *should* fail, unless the attack gets lucky enough to have one of his first few packets land in the window. However, it should still let oddball TCP stacks RST connections, because they're presumably going to land within the window on the first packet. This would also be easy to implement. :) Thoughts? Mike "Silby" Silbersack _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"