浅析SYN FLOOD攻击原理

最新推荐文章于 2025-06-23 11:01:34 发布

翻译最新推荐文章于 2025-06-23 11:01:34 发布 · 1.3w 阅读

文章标签：

#tcp

TCP/IP 专栏收录该内容

1 篇文章

订阅专栏

浅析SYN FLOOD攻击

概述

SYN（synchronous）是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN+ACK应答表示接收到了这个消息，最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。
一：介绍SYN
二：什么是SYN洪水攻击
三：什么是SYN cookie
四：什么是SYN cookie防火墙

C=client(客户器)
S=Server(服务器)
FW=Firewall(防火墙)

一：介绍SYN
SYN cookie是一个防止SYN洪水攻击技术。现在SYN cookie已经是linux内核的一部分了（默认的stat是no）,但是在linux系统的执行过程中它只保护linux系统。如果创建一个linux防火墙，他可以为整个网络和所有的网络操作系统提供SYN COOKIE保护你可以用这个防火墙来阻断半开放式tcp连接，所以这个受保护的系统不会进入半开放状态(TCP_SYN_RECV)。当连接完全建立的时候，客户机到服务器的连接要通过防火墙来中转完成。

二：什么是SYN洪水攻击？
当一个客户端尝试和一个服务器建立TCP连接，客户端和服务端会交换一系列报文。这种连接技术广泛的应用在各种TCP连接中，例如telnet,Web,email,等等。
首先是客户端发送一个SYN报文给服务端，然后这个服务端发送一个SYN-ACK包以回应客户端，接着，客户端就返回一个ACK包来实现一次完整的TCP连接。在服务端返回一个确认的SYN-ACK包的时候有个潜在的弊端，他可能不会接到客户端回应的ACK包。这个也就是所谓的半开放连接，服务端需要耗费一定的数量的系统内存来等待这个未决的连接，虽然这个数量是受限的，但是恶意者可以通过创建很多的半开放式连接来发动SYN洪水攻击。
通过ip欺骗可以很容易的实现半开放连接。攻击者发送SYN包给服务端系统，这个看起来是合法的，但事实上所谓的客户端根本不会回应这个。SYN-ACK报文，这意味着服务端将永远不会接到ACK报文。而此时，半开放连接将最终耗用受害者所有的系统资源，受害者将不能再接收任何其他的请求。通常等待ACK返回包有超时限制，所以半开放。
连接将最终超时，而受害者系统也会自动修复。虽然这样，但是在受害者系统修复之前，攻击者可以很容易的一直发送虚假的SYN请求包来持续攻击。在大多数情况下，受害者几乎不能接受任何其他的请求，但是这种攻击不会影响到已经存在的进站或者是出站连接。虽然这样，受害者系统还是可能耗尽系统资源，以导致其他种种问题。
攻击系统的位置几乎是不可确认的，因为SYN包中的源地址多数都是虚假的。当SYN包到达受害者系统的时候，没有办法找到他的真实地址，因为在基于源地址的数据包传输中，源ip过滤是唯一可以验证数据包源的方法。

三：什么是SYN cookie？
SYN cookie就是用一个cookie来响应TCP SYN请求的TCP实现，根据上面的描述，在正常的TCP实现中，当服务端接收到一个SYN数据包，他返回一个SYN-ACK包来应答，然后进入TCP-SYN-RECV（半开放连接）状态来等待最后返回的ACK包。服务端用一个数据空间来描述所有未决的连接，然而这个数据空间的大小是有限的，所以攻击者将塞满这个空间。在TCP SYN COOKIE的执行过程中，当服务端接收到一个SYN包的时候，他返回一个SYN-ACK包，这个数据包的ACK序列号是经过加密的，也就是说，它由源地址，端口源次序，目标地址，目标端口和一个加密种子计算得出。然后服务端释放所有的状态。如果一个ACK包从客户端返回，服务端将重新计算它来判断它是不是上个SYN-ACK的返回包。如果这样，服务端就可以直接进入TCP连接状态并打开连接。从而使服务端避免守侯半开放连接。
以上只是SYN COOKIE的基本思路，它在应用过程中仍然有许多技巧。

四，什么是SYN COOKIE 防火墙
SYN COOKIE 防火墙是SYN cookie的一个扩展，SYN cookie是建立在TCP堆栈上的，他为linux操作系统提供保护。SYN cookie防火墙是linux的一大特色，你可以使用一个防火墙来保护你的网络以避免遭受SYN洪水攻击。
下面是SYN cookie防火墙的原理
client firewall server
------ ---------- ------
1. SYN----------- - - - - - - - - - ->
2. <------------SYN-ACK(cookie)
3. ACK----------- - - - - - - - - - ->
4. - - - - - - -SYN--------------->
5. <- - - - - - - - - ------------SYN-ACK
6. - - - - - - -ACK--------------->
7. -----------> relay the ------->
<----------- connection <-------
1:一个SYN包从客户端发送到服务端。
2：防火墙在这里扮演了服务端的角色来回应一个带SYN cookie的SYN-ACK包给客户端。
3：客户端发送ACK包，接着防火墙和客户端的连接就建立了。
4：防火墙这个时候再扮演客户端的角色发送一个SYN给服务端。

5：服务端返回一个SYN给客户端。
6：防火墙扮演客户端发送一个ACK确认包给服务端，这个时候防火墙和服务端的连接也就建立了。
7：防火墙转发客户端和服务端之间的数据。
如果系统遭受SYN Flood，那么第三步就不会有，而且无论在防火墙还是服务端都不会收到相应在第一步的SYN包，所以我们就击退了这次SYN洪水攻击。