什么是SYN Flood攻击?_chenyulancn的专栏-CSDN博客

来自 : CSDN技术社区 发布时间：2021-03-25

SYN Flood (SYN洪水) 是种典型的DoS (Denial of Service 拒绝服务) 攻击。效果就是服务器TCP连接资源耗尽 停止响应正常的TCP连接请求。

说到原理 还得从TCP如何建立连接(Connection)讲起。通信的双方最少得经过3次成功的信息交换才能进入连接全开状态(Full-Open) 行话叫建立TCP连接的3次握手(TCP three-way handshake)。

本文假设连接发起方是A 连接接受方是B 即B在某个端口 Port 上监听A发出的连接请求。如下图所示 左边是A 右边是B。

A首先发送SYN Synchronization 消息给B 要求B做好接收数据的准备 B收到后反馈SYN-ACK Synchronization-Acknowledgement 消息给A 这个消息的目的有两个 (1) 向A确认已做好接收数据的准备 (2) 同时要求A也做好接收数据的准备 此时B已向A确认好接收状态 并等待A的确认 连接处于半开状态 Half-Open 顾名思义只开了一半 A收到后再次发送ACK(Acknowledgement)消息给B 向B确认也做好了接收数据的准备 至此三次握手完成 “连接”就建立了 实际上只是双方都按对方的要求进入了可以接收消息的状态。以上彼此要求对方确认的“状态”主要是双方将要使用的消息序号(SequenceNum) TCP为保证消息按发送顺序抵达接收方的上层应用 需要用消息序号来标记消息的发送先后顺序的。TCP是“双工”(Duplex)连接 同时支持双向通信 也就是双方同时可向对方发送消息 其中SYN和SYN-ACK消息开启了A→B的单向通信通道 B获知了A的消息序号 SYN-ACK和ACK消息开启了B→A单向通信通道 A获知了B的消息序号 。

以上讨论的是在双方诚实可信 网络正常的理想状况下建立连接。但实际情况是 网络可能不稳定会丢包 使握手消息不能抵达对方 也可能是对方故意不按规矩来 故意延迟或不发送握手确认消息。假设B通过某TCP端口提供服务 B在收到A的SYN消息时 积极的反馈了SYN-ACK消息 使连接进入半开状态 因为B不确定自己发给A的SYN-ACK消息或A反馈的ACK消息是否会丢在半路 所以会给每个待完成的半开连接都设一个Timer 如果超过时间还没有收到A的ACK消息 则重新发送一次SYN-ACK消息给A 直到重试超过一定次数时才会放弃。

做好人是要付出代价的 B为帮助A能顺利连接 需要分配内核资源维护半开连接 那么当B面临海量的大忽悠A时[1] 如上图所示 SYN Flood攻击就形成了。攻击方A可以控制肉鸡向B发送大量SYN消息但不响应ACK消息 或者干脆伪造SYN消息中的Source IP 使B反馈的SYN-ACK消息石沉大海[2] 导致B被大量注定不能完成的半开连接占据 直到资源耗尽 停止响应正常的连接请求[3]。

接下来说说应对思路。最简单粗暴的办法就是提高TCP端口连接容量的同时减少半开连接的资源占用时间。在Linux上可以修改以下配置提高TCP半开连接队列大小的上限

/proc/sys/net/ipv4/tcp_max_syn_backlog

可以减少半开状态下等待ACK消息的时间或者重试发送SYN-ACK消息的次数

/proc/sys/net/ipv4/tcp_synack_retries

抑或启用某种半开连接回收机制 使得当半开连接队列满了以后做“除旧迎新”操作 当然并不是所有系统都支持这种机制。

以上方法更像是权宜之计 只是缓解了被攻击时的系统压力 以及稍稍提高了些防御门槛 但也同时影响了部分正常的请求的建立 比如减少SYN-ACK重试次数 同样也会降低某些网络环境不好的正常用户的连接成功率 而且攻击者只要稍稍改变策略就可以提高攻击效果 比如当使用半开连接回收机制时 攻击者只需提高攻击频率就可使大部分正常的等待的半开连接 在ACK消息到来前就被踢出队列。

另一个思路是将攻击扼杀在摇篮 比如部署支持“IP防伪”的路由器 将伪造过IP地址的SYN消息过滤掉 或是提高网民防护意识减小肉鸡网络的规模等 但这都太过理想 有些时候攻击者都有高大上的背景 根本不需要攻击前先抓肉鸡 呵呵 你懂的☺。

以上两个思路都没有直击症结所在--任何一个SYN消息无论来源是谁 都会消耗B的一些资源保存半开状态 并逐渐达到“鸠占鹊巢”的效果。SYN Cache和SYN Cookies就是基于这个观察提出的两个方案。

SYN Cache的出发点主要是针对“鸠占鹊巢”问题 基本原理如下 构造一个全局的Hash Table 用来缓存系统当前所有的半开连接信息 连接成功则从Cache中清除相关信息 Hash Table中每个桶 bucket 的容量大小也有限制 当桶“满”时做除旧迎新操作。当B收到一个SYN消息后 会将半开连接信息加入到Hash Table中 其中key的生成很关键 既要用到SYN消息中包含的信息 如 Source IP Port等 又要做到很难被攻击者猜到 一般会通过一个秘密的函数生成 这样所有的半开连接无论好坏 都看似随机地被平均分配到了不同的“桶”中 使攻击难度大增 因为为达到DoS效果 攻击者需要使每个桶都达到填满状态 并且还要有足够快的“填桶”速度 使得正常的半开连接在还未完成建立前就被踢出桶 这样的攻击行为估计在达到目的前早就暴露了。

SYN Cookies着眼点主要是设法消除半开连接的资源消耗 原理与HTTP Cookies技术类似 B通过特定的算法把半开连接信息编码成“Cookie” 用作B给A的消息编号 SequenceNum 随SYN-ACK消息一同返回给连接发起方A 这样在连接完全建立前B不保存任何信息。如果A是正常用户 则会向B发送最后一次握手消息 ACK B收到后验证“Cookie”的内容并建立连接 如果A是攻击者 则不会向B反馈ACK消息 B也没任何损失 也就说是单纯的SYN攻击不会造成B的连接资源消耗。当然这种方案也有一定缺点 最明显的就是B不保存连接的半开状态 就丧失了重发SYN-ACK消息的能力 这一方面会降低正常用户的连接成功率 另一方面会导致某些情况下正常通信的双方会对连接是否成功打开产生误解 如A发给B的第三次握手消息(ACK)半路遗失 A认为连接成功了 B认为没收到ACK 连接没成功 这种情况就需要上层应用采取策略特别处理了。

当然 所有这些方案都不完美各有利弊 最终的策略可能是几种方案的结合使用 形成防御体系 将攻击提前化解在局部 不至于影响整个系统。

[1] 实际攻击时攻击方不太会暴力的发送大量SYN消息 这样反倒会提前暴露自己 而是先嗅探出被攻击对象的TCP配置参数 如半连接状态过期时间 队列上限等 掌握好节奏更量体裁衣的发送攻击消息 做到用最经济最不易被发现的方式鸠占鹊巢 占满半连接队列。
[2] 伪造Source IP IP Spoofing 有一定讲究 不能选一个真实的有TCP连接能力的主机 因为TCP协议要求在收到莫名其妙的SYN-ACK消息时 直接返回RST消息 这反倒提示被攻击的B可以提前中止假冒的半开连接 将其清理出队列。
[3] 这里指特定端口(Port)的连接资源被耗尽不能接受新连接请求 端口上已经建立的连接和其他未被攻击的端口不受影响。

本文原创 欢迎转载 但请注明出处