hmmmm....
i know this code and functionality has been here for years... so it is
modifiable or "fixable" based upon scenario...
im not as "quick" a hack as i used to be yet i was always able to brute
force an algo and then refine.
so... and not that this hasnt been thought of before...
how do we fix zillions of machines from a "red flag" situation. or at
least the ones we care about... is this not "logical"...
im not so stupid that i dont understand what you just wrote... im just
ignorant to that "facts" as to what has been done previously to mentor a
solution to what appears to me as a "boundary value problem"...
too much is typically bad and is at an outer boundary... ie not within
normal levels based upon performance of a machine with multiple
services being offered....
how much does bandwidth affect SYN attacks... quite a bit im guessing...
--->
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 Thu, 12 Sep 1996, Bernd Eckenfels wrote:
> 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:
|
|
