|WikiProject Computing / Networking / Security||(Rated Start-class, Low-importance)|
|WikiProject Internet||(Rated Start-class)|
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 220.127.116.11 (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. --18.104.22.168(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."