[ZT]（哎，为什么总是Cisco？）未知二层协议报文导致C6500E脱管

djsoft

C6500E未知二层协议报文攻击导致脱管
震惊，思科高端交换机C6500E竟被中毒PC击败！前段时间，楼主企业网络出了点神奇的事情，企业部分的PC重启后无法上网，Ping网关出现了丢包，楼主登录到C6500E进行分析，发现远程连接不上，后通过管理数据口查看CPU使用率竟持续100%：

于是楼主开始对网络的流量进行分析，楼主发现在二层网络上存在大量的二层未知协议数据包，仔细分析报文，其目的MAC为二层网关地址（即C6500E设备本身的MAC地址），与设备上显示的自身MAC地址一致：

各种攻击报文抓包结果如下：

其特点为，目的MAC为C65E设备本身的MAC，但是以太类型字段全部为未知协议，如0x1234，0x7999，0x9111等等。

楼主尝试了如下方法对这些攻击报文进行防御：

1） 采用编号为200-299的Protocol type-code access list进行防御；

该方法首先创建access-list 200，并指定未知协议号0x1234，动作为deny；

创建policy-map和class-map绑定access-list 200；

policy-map下没有deny的选项，于是将该策略动作设置为空；

最后将该策略下发在端口入方向：

结果：无效，无法防止未知协议攻击，CPU冲高，设备脱管；

2） 采用IP access-list进行防御：

查看思科支撑的access-list，如下：

如果采用IP access-list，则deny选项里没有针对未知协议的防御功能：

因此IP access-list无法防御未知协议攻击；

3)采用48-bitMAC address access list进行防御：

发现不能指定某个未知协议，不能区分未知协议报文与正常报文。如果采用48-bit MAC address accesslist针对设备本身的MAC地址进行deny，那么连发送到设备的合法报文也会被deny，因此该方法行不通。

4） 采用MAC access-list进行防御,

在全局下创建MAC access-list，把某种未知协议例如0x1234的报文deny掉，目的MAC地址配置为本机MAC，

然后在接口下直接应用该MAC access-list，

这时设备CPU使用率很低，未知协议0x1234的攻击被拦截：

该方法虽能防御未知协议攻击，但弊端不少：

1、 只能在端口下直接应用Mac access-list，配置成policy-map之后在全局下应用无效；

2、 以太协议类型字段值范围为0x0000~0xFFFF，未知协议可能有60K之多，那么要屏蔽所有未知协议攻击，那么MAC access-list下将要配置60K以上的rule，大量消耗系统access-list资源；

各位网友是否遇到此类事情，欢迎共同探讨!