如何防御SYN攻击

• LINUX内核版本不一样，计算半连接最大和全连接最大值不一样，要根据自己的内核版本进行调整
• 增大半连接队列
  • 要想增大半连接队列，不能只单纯增大tcp_max_xyn_backlog的值，还需一同增大somaxconn和backlog，也就是增大全连接队列，否则，只单纯增大tcp_max_syn_back_log是无效的。
  • 增大tcp_max_syn_backlog
    • echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
  • 增大somaxconn
    
    • 　　echo 1024 > /proc/sysc/net/core/somaxconn
  • 增大backlog
    
    • 　　nginx server {listen 80 backlog=1024}
• 开启tcp_syncookies功能
  • 　　echo 1 > /proc/sys/net/ipv4/tcp_syncookies 仅当 SYN 半连接队列放不下时，再启用它   0 关闭  2 无条件开启
  •  syncookies=1时，半连接队列满后，后续的请求就不会存放到半连接队列了，而是在第二次握手的时候，服务端会计算一个cookie值，放入到SYN + ACK 包中的序列号发给客户端，客户端收到后并回ack,服务端就会校验连接是否合法，合法就直接把连接放入到全连接队列
• 减少SYN+ACK重传次数
  • 　　echo 1 > /proc/sys/net/ipv4/tcp_synack_retries SYN + ACK 重传次数上限设置为1次
    
    
    

 

以下是针对TCP各个阶段的一些优化：

• TCP三次握手优化
  • 客户端 SYN_SENT优化 做为发起方，当发起SYN包时，就会处于SYN-SEND状态，等待ACK回复，如果长时间没有收到则会重发 有tcp_syn_retries 参数控制，默认为5次，每次重发时间为 1 2 4 8 16 重传，可以根据服务器繁忙程度设置重传次数
  • 服务端 SYN_RECV优化 收到SYN包时，服务端回得SYN+ACK包，处于 SYN_RECV状态 如果没有收到客户端回应的ACK包，也会有tcp_synack_retries重传次数 也是 1 2 4 8 16 32重传时间。可以设置tcp_abort_on_overflow来控制一直没收到ack的行为，设置为0：如果accept队列满了，那么server扔掉client发过来的ack 设置为1：如果accept队列满了，server发送一个RST包给client,表示废掉这个握手过程和这个连接

  • 

• TCP四次挥手优化
  • 四次挥⼿过程只涉及了两种报⽂，分别是 FIN 和 ACK：
    FIN 就是结束连接的意思，谁发出 FIN 报⽂，就表示它将不会再发送任何数据，关闭这⼀⽅向上的传输通
    道；
    ACK 就是确认的意思，⽤来通知对⽅：你⽅的发送通道已经关闭；
  • 四次挥⼿的过程:
    当主动⽅关闭连接时，会发送 FIN 报⽂，此时发送⽅的 TCP 连接将从 ESTABLISHED 变成 FIN_WAIT1。
    当被动⽅收到 FIN 报⽂后，内核会⾃动回复 ACK 报⽂，连接状态将从 ESTABLISHED 变成 CLOSE_WAIT，
    表示被动⽅在等待进程调⽤ close 函数关闭连接。当主动⽅收到这个 ACK 后，连接状态由 FIN_WAIT1 变为 FIN_WAIT2，也就是表示主动⽅的发送通道就关闭
    了。
    当被动⽅进⼊ CLOSE_WAIT 时，被动⽅还会继续处理数据，等到进程的 read 函数返回 0 后，应⽤程序就会
    调⽤ close 函数，进⽽触发内核发送 FIN 报⽂，此时被动⽅的连接状态变为 LAST_ACK。
    当主动⽅收到这个 FIN 报⽂后，内核会回复 ACK 报⽂给被动⽅，同时主动⽅的连接状态由 FIN_WAIT2 变为
    TIME_WAIT，在 Linux 系统下⼤约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。
    当被动⽅收到最后的 ACK 报⽂后，被动⽅的连接就会关闭。
  • 主动方的优化
    • FIN_WAIT1状态的优化 主动方发送FIN报文后，处于FIN_WAIT1状态，如果及时收到ACK，则很快变为FIN_WAIT2状态，如果收不到ACK时，内核会重发FIN报文，重发次数有tcp_orphan_retries控制，如果FIN_WAIT1状态过多，就要适当降低这个值
    • FIN_WAIT2状态的优化 主动方收到ACK报文后，会处于FIN_WAIT2状态，如果连接是⽤ shutdown 函数关闭的，连接可以⼀直处于 FIN_WAIT2 状态，因为它可能还可以发送或接收数据。但对于 close 函数关闭的孤⼉连接，由于⽆法再发送和接收数据，所以这个状态不可以持续太久，⽽tcp_fin_timeout 控制了这个状态下连接的持续时⻓，默认值是 60 秒
    • TIME_WAIT状态的优化 TIME_WAIT 状态的连接，在主动⽅看来确实快已经关闭了。然后，被动⽅没有收到 ACK 报⽂前，还是处于LAST_ACK 状态。如果这个 ACK 报⽂没有到达被动⽅，被动⽅就会᯿发 FIN 报⽂。᯿发次数仍然由前⾯介绍过的
      tcp_orphan_retries 参数控制。TIME-WAIT 的状态尤其᯿要，主要是两个原因：防⽌具有相同「四元组」的「旧」数据包被收到；保证「被动关闭连接」的⼀⽅能被正确的关闭，即保证最后的 ACK 能让被动关闭⽅接收，从⽽帮助其正常关

      闭；为什么 TIME_WAIT 状态要保持 60 秒呢？这与孤⼉连接 FIN_WAIT2 状态默认保留 60 秒的原理是⼀样的，因为这两个状态都需要保持 2MSL 时⻓。MSL 全称是 Maximum Segment Lifetime，它定义了⼀个报⽂在⽹络中的最⻓⽣存时间。v>

      Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT ⽽直接关闭。开记tcp_tw_reuse 和 tcp_timestamps 可以打开复用time_wait状态的端口（创建时间超过1秒才可以复用）
• TCP传输数据优化