公司网络堵塞案例
—IP fragment攻击,UDP flood攻击
1.故障描述:
周末休息,接到电话,某部门加班员工上网很卡,网速非常慢,几乎上不了网。
2.公司网络拓扑:
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath002.jpg)
一条50M光纤接入,带3百多台PC,十几台服务器。防火墙透明模式,过滤数据包作用,不做任何限制、限速。
3.初步判断:
按照以往经验,这次上网很卡,网络慢。估计就是局域网ARP病毒作祟或者有人在周末开机大肆BT下载导致,亦或者是出口路由器故障(此情况出现过一次,重启后恢复正常)。
4.具体情况分析:
登陆防火墙web界面,看到2个端口流量异常,不成比例,堵塞严重,看来某些数据包被拦截了。再telnet到出口路由器,看到CPU占用率几乎接近90%(平时网络最繁忙的时候,CPU占用率也才60%)。Ping 一下外网,延迟很大,丢包率严重。
重启路由器后,CPU占用率恢复正常,不过好景不长,几分钟后,CPU占用率重新达到80%多。(此时排除路由器故障)
拿一台笔记本(安装有抓包工具)到网络机房,接到核心交换机,做端口镜像。开始抓包,持续时间大概为40秒钟。
短短40秒钟,抓包保存的数据包就达到200多MB~~!!
5.开始分析数据包:
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath004.jpg)
【图1】
(1)图1能反映现在网络大体状况,网络带宽占用大概为50多Mbps;流量最大的3个IP远远比其他IP大,数据包最多的是2个协议HTTP和UDP。(ARP、TCP协议流量都很低,所以排除了ARP攻击、TCP泛洪攻击的可能)。
(2)点开“协议”一栏
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath006.jpg)
【图2】
(3)从图2看到2个协议流量最多,远远比其他多,一个是UDP,一个是IP fragment(IP分片)。先分析UDP协议,点开“UDP”。
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath008.jpg)
【图3】
(4)看到UDP的具体状况,点“UDP”下的“Other”一栏,看到“IP端点”中,10.X.X.2流量最多,远远比其他IP多。双击“other”,弹出一个“数据包分析工程”,通过分析,这IP数据包都正常,是在P2P下载,从“矩阵”图可以看出,10.X.X.2有195个IP会话。都符合P2P下载特性。
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath009.jpg)
【图4】
(5)双击【图3】的“HTTP”一栏,弹出数据包分析工程对话框,【图5】,看到所有数据包目的地址都是218.X.X.38,端口是80;date区都是无意义的AA填充,而checksum值是错误的,当这些数据包到达目标主机时,因为checksum错误会被拒绝,实际没有建立起来的连接被记录到连接状态表中,目标主机大量接收到这样数据包就导致连接状态表被填满,新的连接请求被拒绝。
另一个现象是,为什么在内网里,抓到这些包的源地址都是公网地址?我猜测是内网的肉鸡伪装仿冒的。(如有不对,请指正)
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath011.jpg)
【图5】
(6)双击【图2】的“IP fragment”栏,弹出数据包分析对话框;可以看到源地址是10.X.X.245,目标地址是218.X.X.38。这些IP分片很有规则,是通过精心构造的。MF标志为0,偏移却为370或者185(表明这个分片是整个数据包最后一个分片),但是查找完所有数据包,却没有找到MF标志为1,偏移为0的分片(数据包的第一个分片),这样目标主机收到大量的零碎分片,却无法重组数据包,导致占用过多资源,进而处理缓慢甚至宕机。
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath013.jpg)
【图6】
(7)接下来,看看218.X.X.38的矩阵图。可以看出有9527个连接。由此判断218.X.X.38是攻击目标。
![](file:///C:/Users/thin/AppData/Local/Temp/msohtmlclip1/01/clip_p_w_picpath015.jpg)
【图7】
6.故障排除:
(1)在核心交换机查找10.X.X.2的MAC地址,找到它所连接到的接入层交换机的端口,登陆到接入层交换机,把这个端口shutdown。
(2)同理,10.X.X.245也一样。这样,网络恢复正常。
注:10.X.X.245是一台服务器,由于是分公司的服务器,我没有权限,所以只能先关闭其端口使它不能危害整个内网,过后再通知分公司网管处理。这台服务器是由我协助上架的,但是还没上线运行,因为其业务系统还没调试完成(所以我才决定不事先通知分公司网管就断掉其网络)。
7.事后小结:
通过分析判断,内网10.X.X.2主机在P2P下载。而10.X.X.245被黑客攻击操控,成为肉鸡,对目标公网IP 218.X.X.38进行多种方式的攻击。
(1)由于对内网主机不做限制,导致某个别员工,肆无忌惮的下载,占用大量带宽,影响其他员工工作和业务开展。
(2)这台服务器系统是业务系统厂家安装的,为了方便其调试安装,所以开启了远程桌面,而做了NAT映射,但是没有更改默认3389端口(大意了),致使被黑客攻击,操控,使其成为了肉鸡。
8.事后思考:
(1)疑问,这些数据包分片是直接被路由器转发,还是等重组后再转发(是不是造成路由器CPU占用率过高的原因?)
(2)防火墙端口流量不一致,是不是因为攻击被阻拦,是IP 分片攻击被阻拦了,还是UDP 攻击被阻拦,亦或者2者都被阻拦了?
(3)UDP flood攻击中,抓包抓到的多个攻击源地址是公网IP,是不是10.X.X.245伪造的?最后我把10.X.X.245服务器网络断了之后,再进行抓包,没有发现这类数据包,所以证实,这些公网IP都是伪造的。
遗憾的是,我没有把监测电脑接到路由器出口端口和防火墙外网端口进行抓包分析,以证实我的猜想。
由于小弟知识浅薄,如有描述不对,谢谢指正,共同进步。