On 6/27/05, Marius Mertens <marius.mertens@xxxxxx> wrote: > If you are afraid of somebody trying to DOS you, the recent match with the > added TTL check might be an even better choice. I've been wondering about recent's TTL check and its ability to prevent or even reduce DOSing. To test if the TTL option is used, the attacker can send regular (nonspoofed) ssh requests until they start becoming unresponsive (call this number n), then try sending another request with a different TTL. If that request returns, TTL match is being used so simply send n-1 requests with different TTLs and the spoofed address. Unless the route from the attacker to the sshd is longer than the route from the spoofed client IP to the sshd and the client uses a TTL of 255 (or something similarly high), the legitimate client will still be DOSed. Knowledge of the client system's OS or TCP stack is also reasonably easy to acquire, and can help narrow down the TTLs that need to be sent. Or the attacker can be lazy and send 250 or so SYN packets with different TTLs and the spoofed IP. In short, if an attacker know's you're using recent to track ssh requests, and is not so clueless that he doesn't know about the TTL option to recent, you're dead whether or not you use the TTL option. On a related note, I really hope ISPs are doing some egress filtering to prevent these packets with source IPs not on the expected subnet from getting out. I wonder how many do...
