处理syn半连接DDOS攻击

为什么80%的码农都做不了架构师？>>>   

       公司的网络环境是电信和联通双出口，电信二台nginx，联通二台nginx，以反向代理的方式提供负载均衡，同时nginx前通过lvs DR模式负载均衡，通过dns视图给二个出口分流，系统全部是centos 6系统。

        现象，联通二台nginx网口口突然流量降到0（接近0），持续时间20分钟，电信出口正常。事后请求日志里无信息，系统日志无异常信息。二台联通的nginx请求降到0。

        故障发生时，没有第一时间上线查看，事后第一感觉要么是上联可能出现问题，二台nginx同时出现这样的问题，类似域名备案之类的原因，出口被运营商限制了。要么是lvs出了问题，流量入口从lvs出现在问题，如内网某台服务器成为肉鸡，发了arp欺骗的攻击，使得网关的lvs mac错误等。还有一种可能是syn攻击，但这种攻击可能性最小，系统日志无syn攻击的日志，lvs上做了源ip会话保持，服务器也开启了tcp_syncookies，如果是sync攻击，使二台同时耗尽半连接，要么是分布式的DDOS，有大量的源ip，这样的攻击需要大量的肉鸡，不是一般人可以做到，另一种可能就是基于源ip欺骗的syn攻击，伪造源ip，这样的攻击很难到，运营商路由会检查源ip，伪造的源ip通常很难通过公网到达服务器，如果是源ip欺骗的syn，内网有肉难的可能性比较大，只有内网的伪造源ip发大量的syn到服务器耗尽半连接。

        怀疑是怀疑，要证实怀疑，就得在监控上下手，部署arpwatch，监视内网的Arp变动情况，添加tcp状态监控。次日早晨，攻击再现，通过监控，立马定位syn DDOS攻击。如图：

nginx的请求量：

系统的tcp连接状态机：

        在下图，tcp状态机，故障时间点，基本都是SYN_RECV状态，数量刚好接近somaxconn（我的环境是128）的近二倍。

      处理措施：调大somaxconn的值，调大tcp_max_syn_backlog，增大tcp半连接队列的长度，降低tcp_synack_retries的值，可以设成0，使得半连接可以快速的释放。开启防火墙，限制单ip的syn包的频率。如单个ip 3s内最多发送60个syn包。如下：

       iptables -I INPUT 1 -i em2 -p tcp --syn --dport 80 -m state --state NEW -m recent --set --name HTTPFLOOD

        iptables -I INPUT 2 -i em2 -p tcp --syn --dport 80 -m state --state NEW -m recent --update --name HTTPFLOOD --seconds 3 --hitcount 60 -j  DROP

        这里使用到iptables recent模块，系统默认的单表ip列表的长度是100,单个ip记录20次，需要适当的调大。

      rmmod xt_recent.so

      modprobe xt_recent ip_list_tot=2000 ip_pkt_list_tot=60

        网上有通过limit 模块来限制syn包的速率，如这样iptables -A INPUT -m limit --limit 10/s --limit-burst 30 -j

DROP为种方式，不过个人觉得这种方式存在一个问题，没有对单个ip做限制，如果单个ip每秒发送超过40个包，就会使得正常的syn丢弃，所以个人觉得这不是一个好的idea。

        当然要彻底去解决syn DDOS攻击，靠修改服务器的几个配置，效果达到多少，我不敢发表意见，最靠谱的还是专业的syn防火墙，原理上能简单，服务器的系统资源有限，专业的syn防火墙防止syn攻击的原理是，syn包先到防火墙，防火墙不直接把包交给服务器，而是自己发过一个syn ack包应答，如果一定时间内没有收到Ack应答包，防火墙就认为是一个syn攻击包，直接丢弃，这样syn攻击包就不会到达服务器。另一种方式是，防火墙收到syn包，直接交给服务器，服务器应答syn ack包，如果一定时间内，没有ack应答，防火墙将自己发送一个rst包给服务器，使服务器快速释放半连接。而且防火墙基于硬件，从原理上，我觉得比改服务器更靠谱的。        

转载于:https://my.oschina.net/beiyou/blog/194947