核心S7706交换机遭到内网服务器流量攻击导致端口拥塞,网速变慢

发布时间:  2014-09-07 浏览次数:  835 下载次数:  0
问题描述
组网图如下所示,网络中有多个园区,园区A不仅作为本园区的Internet出口,同时也是其他园区的Internet出口,核心交换机和出口AR路由器运行OSPF协议,不同园区AR之间也运行OSPF,所有运行ospf协议的设备都在AREA0区域。某天园区A的网速变的非常慢,园区间的IP电话几乎听不到对方的声音。

告警信息
园区A的核心交换机和AR之间的ospf协议时断时续,而且有错误包告警。如下面信息所示。 通过查看AR上的日志,发现不同园区AR之间的ospf协议也在发生震荡。
<S7706-01>display ospf error

         OSPF Process 100 with Router ID 10.1.1.2
                 OSPF error statistics

General packet errors:
0     : IP: received my own packet     123   : Bad packet
0     : Bad version                    0     : Bad checksum
0     : Bad area id                    0     : Drop on unnumbered interface
0     : Bad virtual link               0     : Bad authentication type
0     : Bad authentication key         0     : Packet too small
0     : Packet size > ip length        0     : Transmit error
2     : Interface down                 123   : Unknown neighbor
0     : Bad net segment                0     : Extern option mismatch
0     : Router id confusion

HELLO packet errors:
0     : Netmask mismatch               0     : Hello timer mismatch
0     : Dead timer mismatch            0     : Virtual neighbor unknown
0     : NBMA neighbor unknown          0     : Invalid Source Address

DD packet errors:
0     : Neighbor state low             0     : Unknown LSA type
0     : MTU option mismatch

LS ACK packet errors:
0     : Neighbor state low             0     : Unknown LSA type

LS REQ packet errors:
0     : Neighbor state low             0     : Empty request
0     : Bad request

LS UPD packet errors:
0     : Neighbor state low             0     : Newer self-generate LSA
0     : LSA checksum bad               206   : Received less recent LSA
0     : Unknown LSA type

Opaque errors:
0     : 9-out of flooding scope        0     : 10-out of flooding scope
0     : 11-out of flooding scope       0     : Unkown TLV type

Retransmission for packet over Limitation errors:
0     : Number for DD Packet           0     : Number for Update Packet
0     : Number for Request Packet

Receive Grace LSA errors:
0     : Number of invalid LSAs         0     : Number of policy failed LSAs
0     : Number of wrong period LSAs

Configuration errors:
0     : Tunnel cost mistake

处理过程
一 . 初步定位:
1. 由于所有园区的上网和VOIP业务都受到影响,所以首先怀疑园区A的AR遭到攻击或出现问题,AR上防火墙功能正常开启,没有发现攻击记录。查看AR的logbuffer,发现不同园区AR之间,以及园区A的AR和核心交换机之间的OSPF协议经常发生震荡,而且有很多ospf错误包;从AR上ping Google公网地址没有丢包记录,由此初步判断问题应该还在内网。园区A作为所有园区的Internet出口,首先排查园区A。

二、. 详细排查:
1.  在园区A内用PC尝试无线上网,发现获取IP 和DNS都是正常的,从PC ping  AC6605上的网关地址没有出现丢包,从PC ping S7706的地址也没有丢包,从PC ping AR的地址出现间歇性丢包,所以判断园区A的S7706和AR之间网络有问题;接下来需要判断是S7706没有上送报文给AR,还是AR没有回应报文,于是通过流量统计,用测试PC 不停的ping AR的地址,通过ACL匹配测试PC的ip地址分别在S7706的入、出两个方向,以及AR的入方向进行流量统计。发现S7706上能正常收到PC的ping报文,但只有PC能ping通AR时,S7706出方向以及AR上入方向才显示有来自PC ping报文的流量统计数据。由于判断S7706没有上送测试PC所有的报文。

2. 在S7706上查看与AR互联接口详细信息,发现S7706上行到AR方向每300ms的报文数量非常大,比下行数量还要大,这是不合常理的。于是用display interface brief命令,查看S7706的哪些端口使用率比较高,通过对比发现eth-trunk 15上送到S77的报文数量远远高于其他端口;

3.通过在S7706上镜像eth-trunk15的流量,查看上送到S7706的报文类型,发现测试PC每次PING失败时,S7706都从eth-trunk15收到大量TCP SYN报文,且源地址均为AR上Nat地址池中的某一公网地址,载S77上出现以公网地址为源地址的报文,可以判定为攻击,在S77上将以该地址为源地址的报文禁掉以后,所有园区网络业务恢复正常;

三、确定攻击源:
1.同样通过在连接服务器的S5700上使用display interface brief(找收报文明显偏高的端口)和端口镜像(确定攻击报文类型与S77上镜像的一致),确定所有数据报文来自于内网的一台服务器,由此确定了攻击源;
根因
核心S7706交换机下挂的某台服务器中毒,间歇性瞬间突发大量的流量,导致园区A中核心S7706和AR之间的百兆端口被拥塞,大量正常报文被丢弃。
解决方案
1. 由于攻击源使用的源地址是固定的,在S7706上Acl deny动作匹配攻击流,流分类匹配ACL, 将流策略应用在S7706的下行接口的入方向;
2. 找出攻击源后,进行服务器设置修改和病毒查杀,清除攻击源;
建议与总结
一. 网速慢是因为网络中出现了流量瓶颈,所以首先可以尝试通过ping大包找出瓶颈的位置;
二. 判断瓶颈的原因:
    1. 首先是查看是否对用户进行了限速,然后再看运营商处申请带宽的使用是否已经达到上限;
    2. 查看瓶颈设备的端口带宽使用率,判断是否为带宽限制;
    3. 查看瓶颈设备上上下行接口是否有错误包,协商方式和速率是否正确;
    4. 通过命令display qos queue statistics查看各优先级队列报文统计信息,查看哪种报文量最大,是否合理;
    5. 查看瓶颈设备处是否有QOS配置,参数设备是否有问题;
   

END