On Sun, Jan 28, 2001 at 11:45:03AM -0800, Jason Legate wrote:

...

I would add careful use of some rate-limiting functionality, (already mentioned in Richard Steenbergen's http://www.e-gerbil.net/ras/dos.txt) so you can rate-limit things like icmp and acks numbered 0 and anything else that show themselves to be obvious candidates over time.

In actuality, in a TCP SYN packet, an ack of 0 is very common. If you view legitimate syn's generated by real stacks, you will see at dword offset 7: 0x00000000.

Last time I checked, this was a 0 for all intents and purposes. By rate-limiting acks of 0, you are rate-limiting most syn packets, which I don't think is the ultimate goal.

Jason don't be silly, obviously if the SYN bit is set its not an ACK flood. This is just an example of predictable misbehavior which can usually be identified in any kiddie attack (TH_ACK and ack field 0 in the case of stream). But you should know this... :P An attacker can always change their tactics and manage to throw out packets which can slip past a filter ruleset. Rate-limits are only useful for a) protecting the surrounding network not necessarily the target, b) when the traffic you are rate-limiting is desired but not absolutily necessary under attack conditions (ex: icmp echo-replies are valued but during a smurf you can live without them), or c) when you have carefully engineered seperate rate-limit buckets so that an attacker targetting one service may not disturb another. Other steps must be taken in conjunction, and rate-limiting is only one small tool in the arsenal. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)