CISCO路由器封锁QQ客户端-quansheng

1、正常情况下，QQ可以顺利的登录：

这时通过抓包可以发现，QQ协议的数据包，正常情况下（后面有不正常的情况），都是通过udp协议传送的。在udp的数据载荷中，可以看到QQ对应用层数据做的封装格式。其中有一个叫做“命令”的字段（这个名字是科来给起的，真实名称估计是没有），这一字段在数据包所处位置固定、长度固定，通过分析登录过程中的一系列数据包，我大概可以断定这个“命令”字段就是QQ用来识别每一个数据包的作用和包含内容的（比如有请求登录、发送消息、接受消息、加个好友什么的）。正好科来在概要中有描述：其中有一个命令就是“请求登录令牌”，这个数据包听上去在登录过程中比较关键，所以我想测试一下，如果阻止这个数据包发送，能不能就阻断掉QQ登录。在包结构中看到，这个命令字段距离3层头开始的位置有31个字节，大小为2字节，它的值是“00BA”（注意是16进制数值）。

于是在路由器中定义一个class来匹配“请求登录令牌”这个数据包：

class-map type access-control match-any qq_udp

match start l3-start offset 31 size 2 eq 0xBA

然后通过policy将这个数据包记录下来并drop掉：

policy-map type access-control qq_udp

class qq_udp

log

drop

2、第一次测试结果：

在科来的抓包和路由器的日志中可以看到，路由器将“请求登录令牌”丢弃掉后，QQ客户端在不断的重新发送这个数据包，这一点可以证明这个数据包的作用还是很大的，送不出去，它是不会罢休的。

过了很久很久（大约1、2分钟后），我估计QQ是觉得通过udp发送是没戏了，这时它突然开始通过HTTP登录，并且很快就登上去了。这时再通过科来分析这些HTTP数据包，发现在HTTP数据载荷中都是无法识别的2进制数据，我估计它可能是把登陆数据加密后通过HTTP传输了：

但是继续分析多个HTTP数据后可以看出：

在这些封装在HTTP中的2进制数据，第3、4个字节的值都是0x02和0x16，根据这个规律，再做一个class匹配所有符合这样特征的数据包，执行drop：

class-map type access-control match-any qq_tcp

match start l3-start offset 42 size 2 eq 0x216

policy-map type access-control qq_tcp

class qq_tcp

log

drop

最后再测试一次：

路由器上显示，先把QQ客户端的udp请求给drop了，一会又把它的tcp请求给drop了。这回QQ没招了，给出了“超时”提示！

通过对数据包的深层识别，就能够阻止QQ利用80、443这些必开端口进行登录的诡异行为。

最后介绍一下这个feature：12.4（15）T里面就有了，从18到72都带！