Talk:SYN flood

mitigation
Article says SYN flood can be mitigated by "limiting the number of new connections from a source per timeframe"

This assumes that flooder is actually using their own IP address in the source fields -- not really a requirement. The source IP address can be spoofed on the SYN packet.

The article claims that SYN floods don't work on modern networks, which is absolute crap. It's actually quite rare for a website to be able to handle a large SYN flood. —Preceding unsigned comment added by 80.254.74.34 (talk) 05:53, 30 October 2010 (UTC)
 * That's only due to wrong strategies and configs...you need to handle TCP flooding in the app servers, not in the firewall, otherwise it becomes a 1-point-of-failure (or you need batteries of firewalls for nothing...allright: I'm talking about a load-balanced dedicated server system and not some cheap virtual hosting where you may be on the same server like the attacked page: then your hoster needs batteries of firewalls to protect 1 tiny server ;). And a huge backlog plus a lot of RAM each server is necessary, too, but if you have it together with a 9 sec SYN-TTL I really see no problems, sry. --178.197.236.114(talk) 22:47, 28 December 2013 (UTC)

implementations mitigating and not solving the problem
The article states: "but because modern TCP/IP stacks do not have the above mentioned bottleneck, there should be little or no difference between a SYN flood and any other channel capacity-based attack" There is no source for this opinion, and the only actual reference (RFC 4987), published in August 2007, is far from making such a strong assertion, especially since many solutions involve routers and firewalls and not the TCP/IP stack implementation. In fact, it only states that (section 2.1, History): "The community quickly developed many widely differing techniques for  preventing or limiting the impact of SYN flooding attacks.  Many of   these have been deployed to varying degrees on the Internet, in both   end hosts and intervening routers.  Some of these techniques have   become important pieces of the TCP implementations in certain   operating systems, although some significantly diverge from the TCP   specification and none of these techniques have yet been standardized   or sanctioned by the IETF process."

So I suggest to remove the statement or else to provide some verifiable source —Preceding unsigned comment added by 88.149.250.237 (talk) 12:54, 19 November 2008 (UTC)

connection should be described as embryonic, not half-open
See other Wikipedia pages on this distinction: TCP half-open and Embryonic connection. —Preceding unsigned comment added by 67.107.141.2 (talk) 01:53, 8 May 2009 (UTC)

Links and references needed
There should be some links that provide information on how to migrate the attack.

Any links to an open-source example would be appreciated.(on both the attack and how to migrate it.)(SourceForge.net or GitHub link would be nice.)

FockeWulf FW 190 (talk) 17:24, 14 March 2016 (UTC)