Hi,
> 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:
SYN is the first packet received from the remote host if he wants to
establish a TCP connection. You normally answer with an ACKnowledgeemnt.
This Acknowledgement needs to be Acknowledged again to consider the
connection established. As long as the second ACK isnt received the kernel
has to wait for it. f you dont get an ACK you can't distinguish a SYN Bomb
from a slow elayed ack. Therefore you cant expire pending SYNs too fast,
cause that would block Connections from slow networks. You cant block SYN
requests by source, cause the source is fakeable without problem. And you
cant block too much syn requests, cause you are unable to tell which syn
request is a valid connection and which not.
The only chance you have in SYN flooding is, that an existing host will send
a RST packet if it receives an ACK for a not estalished connection. This RST
will clean the pending socket before the Timeout occur and will free
Resources on the Attackt Host faster.
> in this syn function, what is so "necessary" about it that a machine must
> "answer" to it good or bad?
If you dont answer you wont get any connections. This is exactly the damage
the offending sender wants to achief.
Greetings
Bernd
Follow-Ups:
References:
|
|
