httplistenerexception:不能访问网络位置_「实战」给客户公司提交的一份网络故障分析报告...

1、故障描述及部署位置

周五上午去用户处了解故障现象，并询问网络基本情况，了解情况如下：

如上图，用户网络出口带宽为 20M，两台交换机下联 30 多个用户主机与服务器。从本周一开始出现网内用户访问互联网时出现时断时续的状态，打开页面速度非常缓慢，而且经常存在不能打开网页的情况。

于交换机 1 和交换机 2 分别配置镜像端口，部署科来网络分析系统，抓取上联接口的流量进行分析。

2、故障分析

交换机 1：在交换机 1 抓取了二十分钟，并未发现异常情况与流量突发，所以怀疑本次问题可能是由于交换机 2 下联主机存在问题所致。

交换机 2：抓取 10:55:28-10:55:38 的数据包，短短十秒钟我们就发现了网络中存在的问题，如下图：

不难看出，短短十秒钟的总流量达到了 272MB ，基本全部是 512-1023字节的数据包，并且 TCP 同步包达到了 50 余万个，没有收到任何的 TCP 同步确认包，存在明显的异常情况。

查看TC 会话，发现所有的TCP会话行为一致，全部是111.xx.xx.xx 向183.xx.xx.xx 的 80 端口发送TCP 数据包。

SYN数据包是 TCP/IP 建立连接时使用的握手请求数据包，不应存在任何应用层数据，但是在上图中看到该数据包中还有512字节的 HTTP 数据，并且数据内容全部为0，该数据包为明显的伪造数据包。

因为伪造数据包为互联网地址，所以会通过互联网出口向外发送。由于本网络互联网出口为 20Mbps ，而伪造数据包却达到了 261Mbps ，明显超过了最大处理能力，此时内网主机在访问互联网时就会出现连接十分缓慢，甚至不能访问互联网的情况。

3、故障定位

如上图，通过查看MAC地址我们得知发送大量数据包的MAC地址为XX:XX:XX:XX:11:57，掌握了发起攻击的MAC 地址后，通过查看交换机MAC 地址表，找到相应端口，如下图：

该 MAC 地址对应的交换机 2 端口为 G1/0/18 口，通过断掉该接口的方式来排查，断掉该端口后网络恢复正常，能够正常流畅的浏览网页。

4、总结

通过排查发现交换机 2 的 G1/0/18 接口发送大量互联网地址伪造数据报，通过大量发送此类数据包拥塞网络的互联网出口，达到 DOS 攻击作用。通过排查发现 G1/0/18 口为邮件网关连接端口，建议用户联系邮件网关设备厂商，对设备进行问题排查。

欢迎关注我的头条号，私信交流，学习更多网络技术！