|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SYN floods continue (fwd)
Is this practical on a global scale? ---------- Forwarded message ---------- Date: Wed, 11 Sep 96 14:06:05 CDT From: Andrew Molitor <[email protected]> To: [email protected], [email protected] Subject: Re: SYN floods continue (fwd) With fine NSC routers all over the place, one could insert a RR option into all the SYN packets flowing through them. The enclosed filter fragment will insert a RR option capable of recording the first 7 routers after this one that the packet goes through. It won't work on all our stuff, and (realistically) is enclosed for reference only. I can dream, though, eh? A little additional checking could be added to make it hard or impossible to spoof this by inserting your own RR option at the source. Basically, if you're deploying this, you strip out options on packets arriving from 'little leaf nodes that might be bad guys' before you add yours in. It would be relatively trivial to add this to, say, the freely available IP filtering in Linux. The performance hit in the core routers would only be taken for SYN packets, which are some modest percentage (less that 10?) of all packets. They'd feel it, but would probably not topple right over. With this option present, the problem or tracing it back to the source begins to look like backtracing usenet headers -- it's not easy, but it often/usually provides some useful information. It also would require lots of co-operation among ISPs. Andrew filter syn_tracking not ip_protocol in (6) break; # Get outta here if it's not TCP not ip_fo in (0) break; # or if the header's not here not tl_byte (13) mask 0x02 in (0x02) break; # if SYN not set, get out ip_option_present 0x07 break; # Get out if RR option already here # Otherwise insert a 7 hop RR option. stamp_option 0x071f0400000000000000000000000000000000000000000000000000000000; end - - - - - - - - - - - - - - - - -
|