TCP洪水攻击(SYN Flood)的诊断和处理

SYN Flood介绍

前段时间网站被攻击多次,其中最猛烈的就是TCP洪水攻击,即SYN Flood。

SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一,这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,常用假冒的IP或IP号段发来海量的请求连接的第一个握手包(SYN包),被攻击服务器回应第二个握手包(SYN+ACK包),因为对方是假冒IP,对方永远收不到包且不会回应第三个握手包。导致被攻击服务器保持大量SYN_RECV状态的“半连接”,并且会重试默认5次回应第二个握手包,塞满TCP等待连接队列,资源耗尽(CPU满负荷或内存不足),让正常的业务请求连接不进来。

详细的原理,网上有很多介绍,应对办法也很多,但大部分没什么效果,这里介绍我们是如何诊断和应对的。

诊断

我们看到业务曲线大跌时,检查机器和DNS,发现只是对外的web机响应慢、CPU负载高、ssh登陆慢甚至有些机器登陆不上,检查系统syslog:

# tail -f /var/log/messages
Apr 18 11:21:56 web5 kernel: possible SYN flooding on port 80. Sending cookies.

检查连接数增多,并且SYN_RECV 连接特别多:

# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 
TIME_WAIT 16855
CLOSE_WAIT 21
SYN_SENT 99
FIN_WAIT1 229
FIN_WAIT2 113
ESTABLISHED 8358
SYN_RECV 48965
CLOSING 3
LAST_ACK 313

根据经验,正常时检查连接数如下:

# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 
TIME_WAIT 42349
CLOSE_WAIT 1
SYN_SENT 4
FIN_WAIT1 298
FIN_WAIT2 33
ESTABLISHED 12775
SYN_RECV 259
CLOSING 6
LAST_ACK 432

以上就是TCP洪水攻击的两大特征。执行netstat -na>指定文件,保留罪证。

应急处理

根据netstat查看到的对方IP特征:

# netstat -na |grep SYN_RECV|more

利用iptables临时封掉最大嫌疑攻击的IP或IP号段,例如对方假冒173.*.*.*号段来攻击,短期禁用173.*.*.*这个大号段(要确认小心不要封掉自己的本地IP了!)

# iptables -A INPUT -s  173.0.0.0/8  -p tcp  –dport 80 -j DROP

再分析刚才保留的罪证,分析业务,用iptables解封正常173.*.*.*号段内正常的ip和子网段。这样应急处理很容易误伤,甚至可能因为封错了导致ssh登陆不了服务器,并不是理想方式。

使用F5挡攻击

应急处理毕竟太被动,因为本机房的F5比较空闲,运维利用F5来挡攻击,采用方式:让客户端先和F5三次握手,连接建立之后F5才转发到后端业务服务器。后来被攻击时F5上看到的现象:

  • 1、连接数比平时多了500万,攻击停止后恢复。
  • 2、修改F5上我们业务的VS模式后,F5的CPU消耗比平时多7%,攻击停止后恢复。
  • 3、用F5挡效果明显,后来因攻击无效后,用户很少来攻击了,毕竟攻击也是有成本的。

调整系统参数挡攻击

没有F5这种高级且昂贵的设备怎么办?我测试过以下参数组合能明显减小影响,准备以后不用F5抗攻击。

第一个参数tcp_synack_retries = 0是关键,表示回应第二个握手包(SYN+ACK包)给客户端IP后,如果收不到第三次握手包(ACK包)后,不进行重试,加快回收“半连接”,不要耗光资源。

不修改这个参数,模拟攻击,10秒后被攻击的80端口即无法服务,机器难以ssh登录; 用命令netstat -na |grep SYN_RECV检测“半连接”hold住180秒;

修改这个参数为0,再模拟攻击,持续10分钟后被攻击的80端口都可以服务,响应稍慢些而已,只是ssh有时也登录不上;检测“半连接”只hold住3秒即释放掉。

修改这个参数为0的副作用:网络状况很差时,如果对方没收到第二个握手包,可能连接服务器失败,但对于一般网站,用户刷新一次页面即可。这些可以在高峰期或网络状况不好时tcpdump抓包验证下。

根据以前的抓包经验,这种情况很少,但为了保险起见,可以只在被tcp洪水攻击时临时启用这个参数。

tcp_synack_retries默认为5,表示重发5次,每次等待30~40秒,即“半连接”默认hold住大约180秒。详细解释:

The tcp_synack_retries setting tells the kernel how many times to retransmit the SYN,ACK reply to an SYN request. In other words, this tells the system how many times to try to establish a passive TCP connection that was started by another host. This variable takes an integer value, but should under no circumstances be larger than 255 for the same reasons as for the tcp_syn_retries variable. Each retransmission will take aproximately 30-40 seconds. The default value of the tcp_synack_retries variable is 5, and hence the default timeout of passive TCP connections is aproximately 180 seconds.

之所以可以把tcp_synack_retries改为0,因为客户端还有tcp_syn_retries参数,默认是5,即使服务器端没有重发SYN+ACK包,客户端也会重发SYN握手包。详细解释:

The tcp_syn_retries variable tells the kernel how many times to try to retransmit the initial SYN packet for an active TCP connection attempt. This variable takes an integer value, but should not be set higher than 255 since each retransmission will consume huge amounts of time as well as some amounts of bandwidth. Each connection retransmission takes aproximately 30-40 seconds. The default setting is 5, which would lead to an aproximate of 180 seconds delay before the connection times out.

第二个参数net.ipv4.tcp_max_syn_backlog = 200000也重要,具体多少数值受限于内存。

以下配置,第一段参数是最重要的,第二段参数是辅助的,其余参数是其他作用的:

# vi /etc/sysctl.conf

使配置生效:

# sysctl -p

注意,以下参数面对外网时,不要打开。因为副作用很明显,具体原因请google,如果已打开请显式改为0,然后执行sysctl -p关闭。因为经过试验,大量TIME_WAIT状态的连接对系统没太大影响:

为了处理大量连接,还需改大另一个参数:

# vi /etc/security/limits.conf

在底下添加一行表示允许每个用户都最大可打开409600个文件句柄(包括连接):

*                –       nofile          409600

参考资料

  • 文件句柄不要超过系统限制/usr/include/linux/fs.h,相关链接:http://blog.yufeng.info/archives/1380
#define NR_OPEN (1024*1024)     /* Absolute upper limit on fd num */
  • 内核参数详细解释:http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html

结束语

TCP洪水攻击还没完美解决方案,希望本文对您有所帮助,让您快速了解。

原文链接:http://tech.uc.cn/?p=1790

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2016-05-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏开发与安全

集线器,二层交换机,路由器与三层交换机

集线器:以前10M共享式以太网专用,现在用得比较少,只工作在物理层,端口与主机之间使用半双工通信,一般来说无论物理连接是总线型还是星型,它的逻辑连接都是总线型的...

27870
来自专栏程序猿

OSI与TCP/IP各层的结构与功能,都有哪些协议

在实际的开发中,网络编程占据很大一部分。从基本的应用与服务之间的数据传输,到性能优化;在从那些代理应用,路由跟踪,到匿名网络。无不应用到网络中的...

41850
来自专栏Golang语言社区

TCP/IP通信架构

1 .计算机网络的体系结构 计算机网络是一个非常复杂的系统,将整个网络的传输功能进行分层设计的网络结构层次模型及各层协议的集合称为计算机网络的体系结构。为了解决...

34250
来自专栏java思维导图

理解TCP/IP三次握手与四次挥手的正确姿势

背景 和女朋友异地恋一年多,为了保持感情我提议每天晚上视频聊天一次。 从好上开始,到现在,一年多也算坚持下来了。 问题 有时候聊天的过程中,我的网络或者她的网络...

29470
来自专栏运维小白

TCP/IP三次握手四次挥手

背景 和女朋友异地恋一年多,为了保持感情我提议每天晚上视频聊天一次。 从好上开始,到现在,一年多也算坚持下来了。 问题 有时候聊天的过程中,我的网络或者她的网...

27950
来自专栏用户画像

路由协议

OSPF是基于链路状态的自治系统内部路由协议,链路状态路由协议使用dijkstra的最短路径优先算法计算和选择路由。这类路由协议关心网络中链路和接口的状态(UP...

8320
来自专栏Java进阶架构师

【网络协议】专题总结以及网络协议高频面试题汇总(8篇)

初次接触,可能对所谓三次握手四次挥手理解过于抽象?没关系,来看动态图版本的文章,让你从抽象到具象:

33720
来自专栏JetpropelledSnake

Python Web学习笔记之TCP/IP协议原理与介绍

HTTP、FTP、SMTP、Telnet等等协议,哦!那个HTTP协议啊就是访问网页用的那个协议啊然后那个······其实······你懂得,我们应该从实际来了...

658100
来自专栏散尽浮华

梳理Linux下OSI七层网络与TCP/IP五层网络架构

作为一个合格的运维人员,一定要熟悉掌握OSI七层网络和TCP/IP五层网络结构知识。 废话不多说!下面就逐一展开对这两个网络架构知识的说明: ---------...

326100
来自专栏逸鹏说道

探索ASP.NET MVC5系列之~~~4.模型篇---包含模型常用特性和过度提交防御

其实任何资料里面的任何知识点都无所谓,都是不重要的,重要的是学习方法,自行摸索的过程(不妥之处欢迎指正) 汇总:http://www.cnblogs.com/d...

37680

扫码关注云+社区

领取腾讯云代金券