On Tue, 17 Sep 1996, Curtis Villamizar wrote:
In message <v03007814ae643a8d0173@[198.68.110.3]>, "Erik E. Fair" writes:
Your suggestion has two flaws:
1. missed SYN ACKs due to asymmetric routing.
On the order of 1,000 pps worth?
The other option here is to log SYNS and ACK's (both going in the same direction) - They will definately BOTH been seen at the same interface - regardless of routing topology, unless you are talking about some form of load balancing where packets are spewed down somewhat random paths. This doesn't account for "null0" routes and attempted connections to down machines, but.... What we're watching for is 1000 pps of excessive SYNS with no ACKS. Even if you set the trigger level at 500 SYN/NO ACK per sec, you'd catch an interface where you've got an excessive level of these going on. The real drawback, which I meant to mention in my original post (but didn't) and has been mentioned by a cisco person here, is that this requires going a little deeper into the packets than normal - For those routers which switching is implemented in silicon, this might be a problem. It also increases CPU load. I also want to make it clear that in my opinion, where possible, EVERYONE should be doing filtering on their customer-facing interfaces. (yes, all my PPP customers have a filter which permits stuff from THEIR IP and only THEIR IP.) However, in a situation where you have downstreams which are running dynamic (BGP4) routing, filtering may not be practical. This would provide an additional tool to determine if these attacks are occuring, and to track them to the source. -forrestc@imach.com