On Wed, 11 Sep 1996, Robert Hanson wrote:
> please excuse my lack of research on the overall subject of SYN.
>
> where do we go to get "educated" besides here. www or list?
For this particular issue, comp.protocols.tcp-ip would probably be
the most appropriate venue.
>
> 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"?
No. You can detect that you've been flooded, and are being flooded, but
you can't really stop a malicious flood without dropping the ability for
users to connect. You can reduce timeouts for sockets in SYN_RCVD state,
make your buffers very large, increase SO_MAXCONN, and listen queues to
very, very large values, and you may be able to make the resources
necessary to SYN flood you some, but you can't stop it. I've also seen
programs to kill SYN_RCVD sockets for SunOS and/or Solaris somewhere. If
you drop the values too low, you will deny service to legitimate users on
slow lines.
IF ISPs and NSPs would disallow traffic that doesn't originate on their
networks from their gateways, this would be almost a moot issue.
>
> in this syn function, what is so "necessary" about it that a machine must
> "answer" to it good or bad?
It initiates a TCP connection. If you block it, you block connections.
If you don't know how TCP works, I'd recommend W. Richard Stevens'
TCP/IP Illustrated Volume 1.
>
> 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
> >
>
>
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts @
clark .
net which may have no basis whatsoever in fact."
PSB#9280
References:
|
|
