什么是SYN flood
- 攻击者伪装大量的IP地址给服务器发送SYN报文，由于伪造的IP地址几乎不可能存在，也就几乎没有设备会给服务器返回任何应答了。因此，服务器将会维持一个庞大的等待列表，不停地重试发送SYN+ACK报文，同时占用着大量的资源无法释放。更为关键的是，被攻击服务器的SYN_RECV队列被恶意的数据包占满，不再接受新的SYN请求，合法用户无法完成三次握手建立起TCP连接。也就是说，这个服务器被SYN Flood拒绝服务了。
如何预防？
- SYN Flood攻击大量消耗服务器的CPU、内存资源，并占满SYN等待队列。相应的，我们修改内核参数即可有效缓解。
- 主要参数如下：
1、 net.ipv4.tcp_syncookies=1；
2、 net.ipv4.tcp_max_syn_backlog=8192；
3、 net.ipv4.tcp_synack_retries=2；
4、 分别为启用SYNCookie、设置SYN最大队列长度以及设置SYN+ACK最大重试次数；
- SYN Cookie的作用是缓解服务器资源压力。启用之前，服务器在接到SYN数据包后，立即分配存储空间，并随机化一个数字作为SYN号发送SYN+ACK数据包。然后保存连接的状态信息等待客户端确认。启用SYN Cookie之后，服务器不再分配存储空间，而且通过基于时间种子的随机数算法设置一个SYN号，替代完全随机的SYN号。发送完SYN+ACK确认报文之后，清空资源不保存任何状态信息。直到服务器接到客户端的最终ACK包，通过Cookie检验算法鉴定是否与发出去的SYN+ACK报文序列号匹配，匹配则通过完成握手，失败则丢弃。
- SYN Proxy则是管家式的防御，它站在攻击者和目标服务器之间，伪装成目标服务器对所有的SYN报文进行应答，包括攻击者在内。当三次握手正确的建立起来后，就伪装成客户端IP地址与后端的目标服务器建立三次握手，然后转发数据，需要注意的是，TCP三次握手在这里变成了6次握手，而且两个握手内的ACK号肯定不一致，需要做一个修正。
SYN Cookie可以和SYN Proxy无缝集成，协同工作，提供更好的防御服务，基本上100%无误杀。那么使用这种防御手段，付出的代价是什么？ - 我们可以看到，SYN Cookie和SYN Proxy对每一个SYN包都会进行答复，如果攻击者发送1Gbps的报文过来，防御方会发送1Gbps的报文回去。10Gbps就10Gbps，100Gbps就100Gbps。问题是，企业网络禁得起这种折腾么？基本上，攻击流量达到一定程度，网络不攻自溃
- tcp_max_syn_backlog则是使用服务器的内存资源，换取更大的等待队列长度，让攻击数据包不至于占满所有连接而导致正常用户无法完成握手。
- net.ipv4.tcp_synack_retries是降低服务器SYN+ACK报文重试次数，尽快释放等待资源。
版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: