Eudemon 1000E安全策略配置不当导致GGSN业务高峰期丢包

发布时间:  2013-06-25 浏览次数:  381 下载次数:  0
问题描述
如图1所示,A和B的GGSN之间通过GRE隧道通信,业务高峰期时候,A的两套GGSN业务交替性丢包。
图1攻击防范配置不当导致GGSN业务高峰期丢包组网图

告警信息
原因一:中间设备链路存在问题。
原因二:两端的GGSN设备存在问题。
原因三:防火墙配置问题。
处理过程
步骤 1 在任意视图下执行命令display firewall defend flag,检查发现基于IP地址的攻击防范和ip-sweep攻击防范已启用,将基于IP地址的攻击防范和ip-sweep攻击防范去掉,再次测试,业务正常。
根因
1. 业务高峰期时,在GRE隧道中ping GGSN_1发现丢包,分别ping GGNS_2、GGSN_3和GGSN_4都不丢包。而且在公网中ping GGSN_1也不丢包,由于中间设备是无法检测到GRE隧道存在的,处理GRE报文与处理普通报文一样,因此可判断中间设备链路不存在问题,排除原因一。
2. 由于在业务高峰期,A的两套GGSN设备交替性丢包,而B的两套GGSN设备不丢包,可以判断所有GGSN端设备不存在问题,排除原因二。
3. 初步诊断为原因三,业务高峰期在A的主用Eudemon 1000E上下行接口抓包分析,发现Eudemon 1000E收到100个ICMP报文,但只转发出去92个ICMP报文,A的GGSN设备响应了92个ICMP请求包,B的GGSN设备也收到了92个ICMP应答包。因此判断是Eudemon 1000E丢弃了报文。
建议与总结
业务高峰期时,GRE报文比较多,且GRE报文的源地址和目的地址都是比较固定的几个地址,在这种情况下,Eudemon 1000E将GRE报文识别为IP扫描攻击的报文,将其丢弃。
图1组网中,B的某一个NE40E(比如NE40E_1)通过同一个源IP与A的两套GGSN建立GRE遂道,在Eudemon 1000E上的表现就是,同一个IP访问固定的几个IP地址。在流量大时,目的IP会不断发生变化(在固定的几个IP间发生变化),即会存在连续报文中源IP地址相同,但目的IP地址不同的情况,Eudemon 1000E会将此认为是攻击前奏,出现报文丢弃现象。
Eudemon 1000E的ip-sweep攻击防范实现原理:对固定IP地址的用户一秒内访问不同IP地址次数进行限制。如果大于配置的速率阀值(默认值为4000pps),则超过阀值的GRE报文将会被丢弃,如果同时开启了黑名单功能,则该用户将会被加入黑名单,一段时间内,这个源IP地址所有的报文都会防火墙丢弃。
在本案例中,从B发往不同GGSN隧道终端的GRE报文,源地址不变,目的地址却不相同,这些报文到达防火墙进行ip-sweep攻击防范检测时,如果不能满足配置的速率阀值,将会导致GRE报文被识别成ip-sweep攻击被丢弃,业务受影响。

END