please excuse my lack of research on the overall subject of SYN.
where do we go to get "educated" besides here. www or list?
now...
logically speaking... isnt there some integral part of a syn flood or syn
this or that that is "detectable" and therefor "blockable" or that it will
allow some "logic" to be coded to prevent full scale "bombing"?
in this syn function, what is so "necessary" about it that a machine must
"answer" to it good or bad?
please help us all understand.. i know it happens to me... i see it
happen, and i think ive effectively traced it... yet i dont know what ive
found...
know what i mean? aka im trying to discover the properties of what i have
"accidentally" stumbled upon...
thank you.
--->
Robert H. Hanson LAN/WAN Consultant - Internet Service Provider
Otis Orchards, Wa. Cutting Edge Communications www.cet.com
(509) 927-9541 finger: info @
cet .
com or email: roberth @
cet .
com
On Wed, 11 Sep 1996, Andrew Molitor wrote:
> 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
>
Follow-Ups:
References:
|
|
