Robert--
>
> please excuse my lack of research on the overall subject of SYN.
>
> where do we go to get "educated" besides here. www or list?
Comer: "Internetworking w/ TCP/IP"
>
> 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"?
>
I believe it was stated that this SYN flood came from IP packets with
the "Source Route" option set. There should be a packet filter routine
which will drop ALL packets with *any* options triggered. Since,
typically speaking, the only reason that the IP options are used are
to debug or cause trouble, this might be the safest approach for a
firewall.
> in this syn function, what is so "necessary" about it that a machine must
> "answer" to it good or bad?
>
It is necessary...if you want TCP to work. When TCP is passed a segment
to "carry", it (TCP on host a) establishes a connection with the other
(host b) host's transport layer using a "three-way handshake". A SYN
is sent over the connection to synchronize sequence numbers (x), which
is replied to by hostb with it's own SYN, call it SYN-b, which contains
another sequence number as well as host a's sequence number+1
(SYN-b = y, x+1) which initiates an ACK from host a as well as the
begining of the data stream.
I agree with Andrew regarding the needed cooperation from other ISPs
in debugging this one. My advice for step 1 is to get the last hop
from a lower layer and contact the administrator for that domain.
Hasta,
--Todd
_____________________________________________________________________________
R. Todd Truitt Todd .
Truitt @
evolving .
com
Evolving Systems, Inc.
_____________________________________________________________________________
R. Todd Truitt Todd .
Truitt @
evolving .
com
Evolving Systems, Inc.
Follow-Ups:
-
Re: SYN floods
From: "Simon J. Gerraty" <sjg @
zen .
quick .
com .
au>
|
|
