公司网络堵塞案例

—IP fragment***,UDP flood***
1.故障描述:
周末休息,接到电话,某部门加班员工上网很卡,网速非常慢,几乎上不了网。
2.公司网络拓扑:

一条50M 光纤接入,带3 百多台PC ,十几台服务器。防火墙透明模式,过滤数据包作用,不做任何限制、限速。
3.初步判断:
按照以往经验,这次上网很卡,网络慢。估计就是局域网ARP病毒作祟或者有人在周末开机大肆BT下载导致,亦或者是出口路由器故障(此情况出现过一次,重启后恢复正常)。
4.具体情况分析:
登陆防火墙web界面,看到2个端口流量异常,不成比例,堵塞严重,看来某些数据包被拦截了。再telnet到出口路由器,看到CPU占用率几乎接近90%(平时网络最繁忙的时候,CPU占用率也才60%)。Ping 一下外网,延迟很大,丢包率严重。
 
重启路由器后,CPU占用率恢复正常,不过好景不长,几分钟后,CPU占用率重新达到80%多。(此时排除路由器故障)
 
拿一台笔记本(安装有抓包工具)到网络机房,接到核心交换机,做端口镜像。开始抓包,持续时间大概为40秒钟。
 
短短40秒钟,抓包保存的数据包就达到200多MB~~!!
5.开始分析数据包:

【图 1
 
 
(1)图1能反映现在网络大体状况,网络带宽占用大概为50多Mbps;流量最大的3个IP远远比其他IP大,数据包最多的是2个协议HTTP和UDP。(ARP、TCP协议流量都很低,所以排除了ARP***、TCP泛洪***的可能)。
 
(2)点开“协议”一栏
 

【图 2
 

(3)从图2看到2个协议流量最多,远远比其他多,一个是UDP,一个是IP fragment(IP分片)。先分析UDP协议,点开“UDP”。

 
 

【图 3
 
(4)看到UDP的具体状况,点“UDP”下的“Other”一栏,看到“IP端点”中,10.X.X.2流量最多,远远比其他IP多。双击“other”,弹出一个“数据包分析工程”,通过分析,这IP数据包都正常,是在P2P下载,从“矩阵”图可以看出,10.X.X.2有195个IP会话。都符合P2P下载特性。
 
 
 

【图 4
 
 
 
(5)双击【图3】的“HTTP”一栏,弹出数据包分析工程对话框,【图5】,看到所有数据包目的地址都是218.X.X.38,端口是80;date区都是无意义的AA填充,而checksum值是错误的, 当这些数据包到达目标主机时,因为 checksum 错误会被拒绝,实际没有建立起来的连接被记录到连接状态表中,目标主机大量接收到这样数据包就导致连接状态表被填满,新的连接请求被拒绝。
 
另一个现象是,为什么在内网里,抓到这些包的源地址都是公网地址?我猜测是内网的肉鸡伪装仿冒的。(如有不对,请指正)
 
 

【图 5
(6)双击【图2】的“IP fragment”栏,弹出数据包分析对话框;可以看到源地址是10.X.X.245,目标地址是218.X.X.38。 这些 IP 分片很有规则,是通过精心构造的。 MF 标志为 0 ,偏移却为 370 或者 185 (表明这个分片是整个数据包最后一个分片),但是查找完所有数据包,却没有找到 MF 标志为 1 ,偏移为 0 的分片(数据包的第一个分片),这样目标主机收到大量的零碎分片,却无法重组数据包,导致占用过多资源,进而处理缓慢甚至宕机。
 

【图 6
 
(7)接下来,看看218.X.X.38的矩阵图。可以看出有9527个连接。由此判断218.X.X.38是***目标。
 

【图 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 都是伪造的。
 
遗憾的是,我没有把监测电脑接到 路由器出口端口 防火墙外网端口 进行抓包分析,以证实我的猜想。
 
 
 
由于小弟知识浅薄,如有描述不对,谢谢指正,共同进步。