利用FMP封QQ

QM-network 清默网络-于康 原创 CISCO路由器利用 FPMFPMFPMFPM封锁 QQQQQQQQ客户端 1、 正常情况下，QQ可以顺利的登录： 我们使用科来网络分析系统抓取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 QM-network 清默网络-于康 原创 然后通过policy将这个数据包记录下来并drop掉： policy-map type access-control drop_qq class qq_udp log drop interface FastEthernet0/0 service-policy type access-control output drop_qq 第一次测试结果： 在科来的抓包和路由器的日志中可以看到，路由器将“请求登录令牌”丢弃掉后，QQ客户端 在不断的重新发送这个数据包，这一点可以证明这个数据包的作用还是很大的，送不出去， 它是不会罢休的。 过了很久很久（大约 1、2 分钟后），我估计 QQ是觉得通过 udp 发送是没戏了，这时它突然 开始通过 HTTP 登录，并且很快就登上去了。这时再通过科来分析这些 HTTP 数据包，发现 在 HTTP 数据载荷中都是无法识别的 2 进制数据，我估计它可能是把登陆数据加密后通过 QM-network 清默网络-于康 原创 HTTP 传输了： 但是继续分析多个 HTTP 数据后可以看出 在这些封装在HTTP中的2进制数据，第3、4个字节的值都是0x02和0x21，根据这个规律，再 做一个class匹配所有符合这样特征的数据包，执行drop： class-map type access-control match-any qq_tcp match start l3-start offset 42 size 2 eq 0x221 policy-map type access-control drop_qq QM-network 清默网络-于康 原创 class qq_tcp log drop 最后再测试一次： 路由器上显示，先把QQ客户端的udp请求给drop了，一会又把它的tcp请求给drop了。这回 QQ没招了，给出了“超时”提示！ 通过对数据包的深层识别，就能够阻止QQ利用80、443这些必开端口进行登录的诡异行为。 最后介绍一下这个feature：12.4（15）T里面就有了，从18到72都带！ 此实验仅是一个小测试，在实际环境中一般不使用此技术，不方便去管理，实际环境中使用 七层设备就很容易解决，如深信服、网康、或者使用微软的 ISA等等，此实验对对路由器的 处理性能有一定影响。