作者：李晨光
本文由技术专家李晨光投稿。如需转载，请联系本公众号获取授权！

1.概况

安全员林峰为保证会议的无线网络顺畅，架设了Radius无线认证系统，可是会议进行没多久，无线局域网就出现了意外，无线网网络时断时续，会场里到处是抱怨声，IT人员压力山大… …下文就记录了他通过使用各种监控软件收集日志，分析和处理问题的全过程。

注意：阅读本文之前，请大家先了解802.11 帧格式及类型的相关知识。

2.故事人物

在本案例中的参与者有三位，他们的角色分别是：

林峰 (管理员) ：

Mark (演讲者)：

姜华（安全主管）：

3.事件背景

某日林峰来到会议中心，开始了一天新的工作。他是全球云计算大会会场的IT技术支持。TVM将它的安全季度会议安排在北京某国际会议中心。

快到9:15了，可是主讲人Mark不知什么原因还没到场,今天的主题是“云计算与云存储”，在这个领域他是专家，现在来自全国各个行业的近千名IT工程师和经理们正在大会议室不耐烦地等待，林峰独自拿着演讲稿在一旁等候主讲人Mark的到来。

我们把事件还原到2小时前，林峰7点就来到了1～3号会议室开始了紧张的准备工作，他多次测试了会场的802.1x无线网络，以确保网络正常运行。拓扑如图1 所示，用多个AP做接入点，它们被布置到会场的各个角落，以达到信号全覆盖，然后将其接入到一个Cisco 3550交换机上，利用一个20M的端口上连到互联网。为了便于维护，林峰将各个 AP信息（编号、MAC地址、IP地址等）进行了详细记录。

图1 会场布置

这次会议的会议室由一个主会场大厅和三个分会场会议室组成，这四间大厅都通过AP与一台交换机相连接。

林峰深知传统的基于主机的用户认证方式，会出现用户口令被截获与仿冒等缺陷，而且静态WEP也存在严重安全问题，于是他决定搭建一个Radius认证服务器进行认证，已确保仅允许注册的参会人员上网。

Radius认证系统后台采用MySQL数据库，编程语言采用PHP，其运行平台为Apache+PHP架构，利用该方案实现一个“基于MAC地址的认证” 的系统，本以为这种基于MAC地址的Radius认证技术，优点在于用户访问网络资源时，必须要先进行Radius认证，从而提高网络的安全性，这次安全会议没有较大的安全风险，好不容易构筑好的安全防线却像诺曼底防线一样不堪一击，意想不到的事情发生了。

林峰观察到了四周的很多人拿着手机、iPad和笔记本正在浏览网页。

半个小时后，Mark进入会场，这时候林峰心中的石头才终于落地。当Mark准备他的笔记本和报告材料并连接到无线网时，林峰上台做了一个简短的介绍，然后很快坐在前排位置上，打开他的无线网络，包括一些网络测试工具和监听工具，同时测量网络的连通性。

他执行了一次对入口点的连通性检测：

# ping wirelessgateway.com

PING wirelessgateway.com (192.168.0.20):56 data bytes

64 bytes from 192.168.0.20: icmp_seq=0 ttl=225 time=1.033 ms

64 bytes from 192.168.0.20: icmp_seq=1 ttl=225 time=0.791 ms

64 bytes from 192.168.0.20: icmp_seq=2 ttl=225 time=0.811 ms

64 bytes from 192.168.0.20: icmp_seq=3 ttl=225 time=0.913 ms

--- wirelessgateway.com ping statistics ---

4 packets transmitted. 4 packets received. 0% packet loss

round-trip min/avg/max/std-dev=0.791/0.892/1.013/0.117 ms

然后，他决定用一个无线监听软件，来抓一个正常时的网络快照(Wireshark工具同样适合用来监听)。捕获到的数据包如下：

①09:31:32.579031 00:0d:29:57:96:bf 01:40:96:00:00:00 00:0d:29:57:96:bf 11 68 802.11 WEP Data

②09:31:36.134696 00:40:96:44:17:DF 00:07:50:57:E4:7B 00:0d:29:57:96:bf 11 101 802.11 WEP Data

③09:31:36.134819 00:07:50:57:E4:7B 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 406 802.11 WEP Data

④09:31:36.163505 00:0d:29:57:96:DF 11 14 802.11 Ack

⑤09:31:36.170863 00:40:96:44:17:DF 00:07:50:57:E4:7B 00:0d:29:57:96:bf 11 92 802.11 WEP Data

⑥09:31:36.274095 00:07:50:57:84:78 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 92 802.11 WEP Data

⑦09:31:36.274217 00:0d:29:57:96:bf 11 14 802.11 Ack

⑧09:31:36.274767 00:40:96:44:17:DF 00:07:50:57:84:78 00:0d:29:57:96:bf 11 90 802.11 WEP Data

⑨09:31:36.276131 00:40:96:44:17:DF 00:07:50:57:84:78 00:0d:29:57:96:bf 11 535 802.11 WEP Data

看到了结果，这些参数一切看上去都很正常，他心里很高心。

Mark继续着精彩演讲，把参会者带到了一个技术的殿堂，可能是早上起来太早的原因，时间一长林峰听得也有点犯困，渐渐得他睡着了。报告大约进行了半小时，有人突然叫醒了林峰，并告诉他网络连接出现了状况。这时林峰立即查看了网络状况，看看到底发生了什么情况。

# ping wirelessgateway.com

PING wirelessgateway.com (192.168.0.20):56 data bytes

64 bytes from 192.168.0.20: icmp_seq=0 ttl=225 time=0.913 ms

64 bytes from 192.168.0.20: icmp_seq=1 ttl=225 time=0.989 ms

64 bytes from 192.168.0.20: icmp_seq=2 ttl=225 time=0.919 ms

64 bytes from 192.168.0.20: icmp_seq=3 ttl=225 time=0.943 ms

64 bytes from 192.168.0.20: icmp_seq=6 ttl=225 time=0.231 ms

64 bytes from 192.168.0.20: icmp_seq=7 ttl=225 time=0.912 ms

64 bytes from 192.168.0.20: icmp_seq=8 ttl=225 time=0.423 ms

--- wirelessgateway.com ping statistics ---

9 packets transmitted. 7 packets received. 21% packet loss

round-trip min/avg/max/std-dev=0.923/2.911/4.241/1.354 ms

很显然网络出现了丢包，延迟比较大，看到这一情况，他有些不安。这时林峰环顾会场四周，发现有几个参会者的电脑也出现了不同程度的网络问题。Mark又继续讲了半小时，这时候网络再次出现问题，然而这次故障变得更加严重。林峰这回又仔细检查了入口点AP的连通性：

# ping wirelessgateway.com

PING wirelessgateway.com (192.168.0.20):56 data bytes

--- wirelessgateway.com ping statistics ---

19 packets transmitted. O packets received. 100% packet loss

… … （后续包省略）

糟糕，网络已全部停止，四周抱怨再次传来，林峰非常着急，而且他发现有两个AP相继掉线了。这时，他又启动了无线监听软件，查看到底发生了什么。

#wdump -n ether host 00:40:96:44:17:DF or ether host 00:40:96:54:56:33

很显然，会场很多人无法上无线网，一些人偶尔也能连接成功。这种时断时续的现象，到底是由什么原因引起？

4.故障排除过程

网络可能会出现各种形式的故障，当网络中某节点出现故障，它可能会彻底断掉，也可能时断时续，这种情况产生的原因可能是配置问题，或是硬件问题，也可能是受到恶意攻击。

正当林峰一筹莫展时，某公司安全主管姜华来到会场。他提出要看看林峰的流量日志，希望能帮助林峰搞清楚到底发生了什么，林峰这时也觉得无计可施了，只好将存有日志的笔记本交给负责安全的主管姜华。

下面的原始日志文件的摘要突出了姜华所发现的内容：

1 10:14:47.994746 00:40:96:44:17:DF 00:0d:29:57:96:bf 00:0d:29:57:96:bf 11 535 802.11 WEP Data

4 10:14:47.997262 00:0d:29:57:96:DF 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 30 802.11 Disassoc

… …

通过上面的内容分析，我认为是802.11 Disassociate Flood攻击。

从第4帧开始出现了解除连接帧（disassociation frame）。这是发给Mark笔记本电脑的，它伪装成发自入口点。“Disassociation frame”这个信息通告了他的笔记本无线网卡断开状态表中所有已经与入口点建立连接的记录。Disassociation frame是用来从无线网络中删除节点的，在正常的无线网络很少出现。姜华马上觉察到这一现象非常可疑。

18 10:14:48.125766 00:40:96:44:17:DF FF:FF:FF: FF:FF:FF FF:FF:FF: FF:FF:FF 11 47 802.11 Probe Req

Mark的笔记本并不知道他为什么会从入口点断开连接，但它知道还有很多应用层的数据要发，因此系统尝试着重新连接入口点。系统开始发送一个广播请求：

19 10:14:48.126596 00:0d:29:57:96:DF 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 62 802.11 Probe Rsp

随后入口点对Mark的请求作出了响应：

31 10:14:48.256144 00:40:96:44:17:DF 00:0d:29:57:96:DF 00:0d:29:57:96:bf 11 570 802.11 Disassoc Req

33 10:14:48.259968 00:0d:29:57:96:DF 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 841 802.11 Disassoc Rsp

36 10:14:48.261711 00:40:96:44:17:DF 00:0d:29:57:96:bf 00:0d:29:57:96:bf 11 61 802.11 WEP Data

随后Mark的笔记本重新连上了入口点并发送数据；

43　10:14:48.264047 　00:40:96:54:56:33 　00:40:96:44:17:DF 　00:40:96:54:56:33 11 　300　802.11 Disassoc

另一个取消连接帧又出现了，并正在断开所有连接记录：

43 10:14:48.265868 　00:0d:29:57:96:bf 　00:40:96:44:17:DF 11 20 802.11 RTS

44 10:14:48.266852 　00:0d:29:57:96:bf 　00:40:96:44:17:DF 11 20 802.11 RTS

45 10:14:48.267347 　00:0d:29:57:96:bf 　00:40:96:44:17:DF 11 20 802.11 RTS

46 10:14:48.269482 　00:0d:29:57:96:bf 　00:40:96:44:17:DF 11 20 802.11 RTS

47 10:14:48.270811 　00:0d:29:57:96:bf 　00:40:96:44:17:DF 11 20 802.11 RTS

充电：RTS/CTS协议(Request To Send/Clear To Send)即请求发送/清除发送协议是被802.11无线网络协议采用一种用来减少由隐藏节点问题所造成的冲突机制。相当于一种握手协议，主要用来解决"隐藏终端"问题。

以上数据显示，入口点多次重复请求发送/清除发送协议并尝试发送数据。 RTS/CTS协议是用来在无线网络中的工作站之间保证有序的通信。如果一个网络中有几台工作站同时要发送数据，就会发生冲突，这时就会看到RTS/CTS协议，这一协议还有助于防止隐藏节点问题，即物理距离远的工作站可以看到入口点但是却看不到其他工作站。由于攻击者的各种操作，于是可能在网络中造成很多冲突。

48 10:14:48.274033 00:40:96:44:17:DF 00:0d:29:57:96:DF 00:0d:29:57:96:BF 11 300 802.11 Disassoc

49 10:14:48.276721 00:0d:29:57:96:DF 00:40:96:44:17:DF 11 20 802.11 RTS

50 10:14:48.278244 00:0d:29:57:96:DF 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 300 802.11 Disassoc

51 10:14:48.281016 00:40:96:44:17:DF 00:0d:29:57:96:DF 00:0d:29:57:96:BF 11 300 802.11 Disassoc

52 10:14:48.290443 00:0d:29:57:96:DF 00:40:96:44:17:DF 11 20 802.11 RTS

53 10:14:48.304852 00:40:96:44:17:DF 00:0d:29:57:96:DF 00:0d:29:57:96:bf 11 300 802.11 Disassoc

54 10:14:48.309054 00:0d:29:57:96:DF 00:40:96:44:17:DF 11 20 802.11 RTS

55 10:14:48.313221 00:40:96:44:17:DF 00:0d:29:57:96:DF 00:0d:29:57:96:bf 11 300 802.11 Disassoc

56 10:14:48.321803 00:0d:29:57:96:DF 00:40:96:44:17:DF 00:0d:29:57:96:bf 11 300 802.11 Disassoc

接着出现了更多的取消连接帧，两个方向都有—从入口点到Mark的笔记本电脑和从Mark的笔记本电脑到入口点。从这一点看，姜华确信网络正在遭受攻击。

从第66帧开始，Mark的笔记本电脑再一次试图连接到无线网络中，随后一个CTS帧结束了RTS/CTS协议，开始发送数据:

攻击者发送了更多的恶意取消连接帧！这个过程反复出现。Mark的笔记本电脑或入口点偶尔成功发送一帧的数据，攻击者随后便伪造一个取消连接帧破坏连接，并强迫它们一遍又一遍地重复连接建立过程，网络中任何正常的业务都无法进行。

林峰的网络正遭受拒绝服务攻击。这次事件的不同和严重之处在于它发生在无线网络中。传统上第二层协议（它是点对点的）只具有有限的安全特性。对于设计上有缺陷的802.11协议来说，几乎不可能防御我们所讨论的取消连接攻击。攻击者只是简单地等待一个通过空气传输的数据帧，随后立即从相反的方向伪造一个802.11管理帧，告诉对方要断开连接。这个攻击很简单，任何一端一旦发送数据就可能收到自称来自另一端的伪造的取消连接帧。因为管理流量没有加密或者认证，因此攻击者可以伪造这些帧的地址并使它们在基本服务集合( Basic Service Set，BBS)中被接收。构造这种攻击帧不需要伪造连接状态，协议只关心MAC地址。

5.总结

以上案例主要由于无线通信的特性造成，这种攻击表面上只是影响随机的系统。当无线信号从传送它们的工作站传播时，无线信号强度会随之衰减，信号衰减的程度取决于传输技术、初始强度还有传输的介质。对于在一个开放的环境中（例如一个大的会议室）使用802.11b直接序列扩频（Direct Sequence Spread Spectrum，DSSS）技术的工作站来说，在信号衰减到它们无法识别之前最佳的上限约500m。那么越接近攻击者的用户就越容易受到影响，而距离较远（比攻击者更接近入口点）的用户可能影响不大，也可能不受影响。

对于802.11协议的缺陷，一旦受到攻击缺乏有效的防范机制。即使是当WEP或一个更高层的加密技术如IPsec或SSL运用其中，漏洞依然会存在。一旦攻击开始，就不太容易减轻。我们还是可以通过信道切换的方式来减轻故障造成的伤害。假如攻击者没有跨越信道的话，将入口点和所有合法的用户转换到一个不相邻的频率可以解决这个问题。

只为一场完美的技术盛宴！

SACC2016

作为国内最受欢迎的架构师盛会，2016第八届中国系统架构师大会(SACC)将于2016年10月27日-29日在北京万达索菲特大酒店撼世来袭！

大会以"架构创新之路"为主题，共设置两个主场分享时段，24个技术交流专场时段；邀请来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域，150多位技术专家及行业领袖来分享他们的经验；并将吸引4000多名系统运维、架构师、及各种企业的IT决策人士参会，为他们提供最具价值的交流平台。

最优折扣来袭！

7月28日前，订购SACC2016门票可立享6.8折优惠！团购更有折上折！

点击“阅读原文”立即购票！

ITPub博客

来自云计算大会上的无线网攻击案例分析

最新文章