Talk:SYN flood

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking / Security (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Low-importance).
Taskforce icon
This article is supported by WikiProject Computer Security (marked as Mid-importance).
 
WikiProject Internet (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

mitigation[edit]

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[edit]

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[edit]

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)