syn flood洪水攻击
这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。
方式
客户端大量发送半连接后断开
为什么服务端消耗资源?
服务端有个SYN Timeout(大概30秒-2分),在超时期限到之前如果存在一个很大的半连接列表:
- 会再次发送SYN+ACK给客户端
- 保存与遍历也会消耗大量资源
防御
- 缩短
SYN Timeout时间(只适合攻击频度不高的情况) - 设置
SYN Cookie(就是给每一个请求连接的IP地址分配一个Cookie,如果短时间内连续受到某个IP的重复SYN报文,就认定是受到了攻击,以后从这个IP地址来的包会被丢弃.)(只适合对方使用真实IP的情况) - 延缓TCB分配(消耗服务器资源主要是因为当SYN数据报文一到达,系统立即分配TCB,从而占用了资源.因此,当正常连接建立起来后再分配TCB可以有效减轻服务器资源消耗,常见的方法是使用
Syn Cache和Syn Cookie技术) - 使用SYN Proxy防火墙
- TCP Safe Reset
相关技术
Syn Cache
这种技术是在收到SYN数据报文时不急于去分配TCB，而是先回应一个SYN ACK报文，并在一个专用HASH表（Cache）中保存这种半开连接信息，直到收到正确的回应ACK报文再分配TCB。在FreeBSD系统中这种Cache每个半开连接只需使用160字节，远小于TCB所需的736个字节。在发送的SYN ACK中需要使用一个己方的Sequence Number，这个数字不能被对方猜到，否则对于某些稍微智能一点的Syn Flood攻击软件来说，它们在发送Syn报文后会发送一个ACK报文，如果己方的Sequence Number被对方猜测到，则会被其建立起真正的连接。因此一般采用一些加密算法生成难于预测的Sequence Number。
Syn Cookie
对于SYN攻击，Syn Cache虽然不分配TCB，但是为了判断后续对方发来的ACK报文中的Sequence Number的正确性，还是需要使用一些空间去保存己方生成的Sequence Number等信息，也造成了一些资源的浪费。 Syn Cookie技术则完全不使用任何存储资源，这种方法比较巧妙，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。