RE: Active response... some thoughts.

        ...and this would solve the problem, sort of. For all practical purposes you're entering a "packet race" when you use this technique. You're trying to get the resets to either endpoint of the connection before the real packet gets there, thus making sure sequence numbers are correct so the machines at both ends don't know anything funny is going on and reject the subsequent "real" packets like you're trying to make them do. When you only send resets to one end of the connection you're technically cutting your chances of this succeeding in half, the way I see it (which very well may be wrong). The more resets you send out on the wire as fast as you can, the better the chance of one of those getting there before the real packet does and closing the connection before any damage can be done. This is why Marty spent a considerable amount of time manipulating the FelxResp code in Snort a year or so ago to setup precaching of IP and UDP/TCP headers used in the response packets... the less time you spend generating these headers on the fly, the more of them you can send out at a higher rate of speed.

        FWIW, we found that during the original Code Red outbreak, we saw a 90% success rate when using FlexResp to snipe sessions from infected hosts. This, of course, means that 10% of all of those forged reset packets didn't make it to either end of the connection in time... this was before the days in Snort where the precaching I mentioned above was implemented. I haven't been lucky (?) enough to be in a situation again where I've needed to test this ability in a high-volume production environment.

Thanks,
Abe

--
Abe L. Getchell
Security Engineer
abegetchell@qx.net

> -----Original Message-----