小心遭遇来自半路的遭劫　中间人攻击

错误引导——DNS欺骗

临近过年，一辆长途客车满载着归家的旅人们在高速公路上行驶着，此时已是深夜，旅客们 多半都已进入梦乡。司机发现前面不远处摆满了石块，还有一块指向告诉公路旁岔路口的牌子写着：“因前方公路塌方，严禁车辆通过，请绕道。”司机迟疑了一 下，把车驶进了岔路。不远处，几双不安分的眼睛正在注视着客车……

中间人攻击（Man-in-the-Middle Attack，简称“MITM攻击”）是一种“间接”的入侵攻击， 这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。然后入侵者把这台计 算机模拟一台或两台原始计算机，使“中间人”能够与原始计算机建立活动连接并允许其读取或修改传递的信息，然而两个原始计算机用户却认为他们是在互相通 信。通常，这种“拦截数据——修改数据——发送数据”的过程就被称为“会话劫持”（Session Hijack）。

DNS欺骗（DNS Spoofing），就是其中的一种惯用手法。攻击者通过入侵DNS服务器、控制路由器等方法把受害者要访问的目标机器域名对应的IP解析为攻击者所控制 的机器，这样受害者原本要发送给目标机器的数据就发到了攻击者的机器上，这时攻击者就可以监听甚至修改数据，从而收集到大量的信息。如果攻击者只是想监听 双方会话的数据，他会转发所有的数据到真正的目标机器上，让目标机器进行处理，再把处理结果发回到原来的受害者机器；如果攻击者要进行彻底的破坏，他会伪 装目标机器返回数据，这样受害者接收处理的就不再是原来期望的数据，而是攻击者所期望的了。例如让DNS服务器解析银行网站的IP为自己机器IP，同时在 自己机器上伪造银行登录页面，那么受害者的真实账号和密码就暴露给入侵者了。

如此说来，这种攻击理应是最强大最危险的，然而实际上它却很少派上大用场，为什么？因 为DNS欺骗的攻击模型太理想了。在实际生活中，大部分用户的DNS解析请求均是通过自己的ISP服务器进行的，换句话说，就是系统在连接网络时会获取到 ISP服务器提供的DNS服务器地址，所有解析请求都是直接发往这个DNS服务器的，攻击者根本无处入手，除非他能入侵更改ISP服务器上DNS服务的解 析指向。所以这种手法在广域网上成功的几率不大。

当然，这种攻击的成功率也有例外存在，例如一个ISP服务器上存在Bind漏洞，攻击 者就能通过Bind漏洞进入服务器更改掉DNS解析指向，甚至取得最高权限；另一种方法是入侵路由设备，修改里面的DNS服务器地址为自己控制的机器地 址，这种方法只能在用户机器自身是通过路由器返回域名解析的情况下才能成功，多见于一些使用小区宽带连接Internet的用户，因为这种用户机器的 DNS地址通常必须指向小区宽带内部的某台服务器地址或者交给路由进行转向，这时候只要攻击者入侵了路由或者那台关系到所有人的服务器修改掉DNS记录， 整个小区用户的网络都完了。当然，攻击者不能把全世界网站都伪造到他硬盘上，他只需要改几个重要商务站点的指向即可，这样便可导致用户访问某些商务站点时 被转向到攻击者的机器去。但是，这种攻击手法同时对攻击者自身也是一种伤害：如果小区内有许多用户都访问这些商务站点，则大量数据请求会疯狂消耗攻击者的 机器资源，攻击者非但不能实时处理数据，更是面临着机器瘫痪和暴露自己的双重危险。

聪明的攻击者不会选择去入侵DNS服务器，他们会想办法替换掉Hosts文件，从而引导受害者走向自己的机器……

不可信任的陌生人——会话劫持

客车沿着岔路行驶下去，怎料道路越来越颠簸，根本不像能开回高速公路的样子，满车的旅 客被晃醒了，不住的抱怨起来。司机心里也有点发慌，客车在荒山野岭停了下来。在众人不知所措的时候，车外有几个看似本地居民的人请求搭个便车外出，并表示 自己懂得出去的道路。司机虽然半信半疑，可终究还是打开了车门。谁也没有察觉到那几个人的嘴边正浮现出一丝阴险的笑容……

“会话劫持”（Session Hijack）是一种结合了嗅探以及欺骗技术在内的攻击手段。广义上说，会话劫持就是在一次正常的通信过程中，攻击者作为第三方参与到其中，或者是在数据 里加入其他信息，甚至将双方的通信模式暗中改变，即从直接联系变成有攻击者参与的联系。简单地说，就是攻击者把自己插入到受害者和目标机器之间，并设法让 受害者和目标机器之间的数据通道变为受害者和目标机器之间存在一个看起来像“中转站”的代理机器（攻击者的机器）的数据通道，从而干涉两台机器之间的数据 传输，例如监听敏感数据、替换数据等。由于攻击者已经介入其中，他能轻易知道双方传输的数据内容，还能根据自己的意愿去左右它。这个“中转站”可以是逻辑 上的，也可以是物理上的，关键在于它能否获取到通信双方的数据。

典型的会话劫持是利用TCP/IP的工作原理来设计攻击的。在谈TCP/IP会话劫持 前先解释一下TCP/IP用于确认数据传输的判断机制。许多人一定都有过这样的疑问：我们已经知道TCP/IP是使用点对点（Point to Point）连接进行数据传输的，但是它是如何知道上一条数据和下一条数据存在的联系的呢？如果我发送数据后不慎掉线，恰好另一个人接着我的IP地址连接 到了Internet，那他会不会收到服务器返回给我的数据？其实只要看过TCP/IP协议的书籍就会明白，TCP协议采用了两种条件来确认每条已经建立 连接的TCP通道，第一个是基础连接确认，即TCP连接中的四大必备条件：源IP、源TCP端口、目标IP、目标TCP端口；第二个条件是“序号标识” （Sequence numbers，SEQ），它们是成对出现的，分为“Sequence”（SEQ，序号字段）和“Acknowledgement Sequence”（ACK SEQ，确认序号字段），TCP每次建立一个连接时，会给双方指定这样一条规则：序号字段指出了本报文中传送的数据在发送主机所要传送的整个数据流中的顺 序号，而确认序号字段指出了发送本报文的主机希望接收的对方主机中下一个八位组的顺序号。（这里可能比较难理解，可以举个不专业的例子解释：流水线上的工 人被规定好了每人负责安装8个不同的零件，则每次传输到他们手上的都应该是只留下给他们安装的8个零件位置，这就是序号字段；而下一个工人则被规定在前一 个工人的基础上安装另一个部分的8个零件，这就是确认序号字段，如果这个工人发现传到自己手上的产品多了或少了零件，则说明前一个工人出错，这个产品就被 从流水线提取出来返工，这就是TCP对序号的严密审查和丢弃制度）。TCP如此谨慎，就是为了避免出现前面提到的假设，虽然这种假设发生的几率很小（需要 满足TCP的基础连接确认条件），但是它总有机会发生的。然而不幸的是，这对序号是可以预测的，因为TCP必须遵从以下守则：一台主机即将发出的报文中的 SEQ值应等于它所刚收到的报文中的ACK SEQ值，而它所要发送报文中的ACK SEQ值应为它所收到报文中的SEQ值加上该报文中所发送的TCP数据的长度，即两者存在“本次发送的SEQ=上次收到的ACK SEQ；本次发送的ACK SEQ=上次收到的SEQ+本次发送的TCP数据长度”的联系。知道这个规律后，攻击者就不难发起“中间人攻击”了，他只需要设法监听到受害者TCP连接 中的第一个条件（源IP、源TCP端口、目标IP、目标TCP端口），就可以得知其中一台主机对将要收到的下一个TCP报文段中SEQ和ACK SEQ值的要求，这样攻击者就能在原来的合法主机收到另一台合法主机发送的TCP报文前根据所截获的信息向该主机发出一个符合条件二（序号标识）的TCP 报文，如果该主机先收到攻击报文，就会受到欺骗而把合法的TCP会话建立在攻击主机与被攻击主机之间，而且攻击报文会让被攻击主机对下一次要收到的TCP 报文中的确认序号值的要求发生变化，最终使另一台合法的主机向被攻击主机发出的报文被拒绝，这种模式被称为“主动劫持”。换句话说，就是其中一方合法主机 被攻击者掠夺了连接的权限，而攻击者却成为了合法的连接方之一。这种会话劫持让攻击者避开了被攻击主机对访问者的身份验证和安全认证，从而使攻击者直接进 入对被攻击主机的的访问状态，因而危害严重。例如，你刚向某站点发送完账户密码，就被攻击者抢先冒充你的TCP连接上了，那你的损失可就难预料了。不过， 会话劫持对网络环境的一点要求可以让大家松口气，它必须在使用MAC寻址的网络环境中才能发挥作用，必要时还要配合ARP协议欺骗，能同时满足这两个条件 的只有局域网。而广域网不是靠MAC地址来查找计算机的，因此攻击者很难从现有的广域网结构里插入到某两台计算机之间。

但是，下面的MITM攻击就没那么好运了……

披着羊皮的狼——不再可靠的代理服务器

网络上存在许多各种各样的代理服务器，其中的一些，是披着羊皮的狼……客车在一个“老 乡”的指引下缓缓前进，司机这时候却感到有点不对劲，因为这条小路越来越泥泞！他还没来得及思考更多，就觉得车子颠簸了一下，再也动弹不得：车轮陷进水坑 里了！满车旅客沸腾起来，那几个“老乡”很有自信的说：“我们下车去找人来推！”遂跳下车向后方走去，只留了两个人在车外“守”着。司机趁那两个人看着后 方抽烟的时候偷偷拨打了110……过了一会儿，旅客们欢呼起来，因为他们看到一群“老乡”拿着锄头棍棒等东西走过来。但是只过了很短的时间，欢呼声变成了 恐惧的叫声：那群人气势汹汹的，而且有些人手上还拿着砍刀！这些人不是什么“老乡”，而是一伙歹徒！司机明白自己从一开始就中了圈套，忙开足马力前进，可 是无奈车轮只能在坑里空转……

代理服务器（Proxy Server）的存在已经是很长久的事实了，而且由最初的几个基于TCP/IP协议的代理软件如HTTP、SMTP、POP3和FTP等发展到如今 SSL、SOCK4/5以及其他未知的代理类型，可谓给一些特殊用途者提供了极大的方便。例如，通过代理跨过某些服务器的IP屏蔽，从而浏览到本来不能看 到的信息；或者害怕自己IP暴露被对方入侵而寻找层层代理把自己包裹起来；还有些是因为系统不支持Internet共享而被迫采用代理软件来让内部网络的 计算机能正常连接Internet……此外还有许多原因，让各种代理服务器经久不衰。

然而，广大网民在享受着代理的便利时，却不曾想过，任何事情都是要付出代价的……

这要从代理服务器的工作原理谈起。代理服务器相当于一个透明的数据通道，它根据客户发 来的“要求连接某计算机”的请求数据，进而用自己本身作为原客户机器去连接目标计算机，在目标计算机返回数据后，再发送给原客户，这时目标计算机获取到的 是代理服务器的IP，而不是原客户IP，从而实现突破IP屏蔽或者让对方无法获取你的真实IP。

简单举个HTTP代理服务器工作的原理：IE发送一个包含目标URL的HTTP请求， 代理服务器接收并析出HTTP报文里的目标URL和相关参数，然后把这个URL作为一次标准的HTTP连接过程与目标网站连接，获取目标网站返回的数据后 缓冲到代理服务器的硬盘上，再把这些数据返回给客户端。

请求连接目标URL------> 连接目标服务器------->

客户端-------------------------代理服务器------------------------目标服务器

<-----返回数据----(缓冲) <-------------返回数据

其它协议的代理工作模式也都差不多，代理服务器充当了一个数据转向的工作站，相当于一个专门负责数据转发的“勤劳工人”。

然而，再忠诚的狗也会偷吃的，代理服务器有时候也并非完全透明的……

不知道大家在看我描述代理服务器原理的时候，有没有产生一个“似曾相识”的感觉？没 错！代理服务器的工作模式，正是典型的“中间人攻击”模型！代理服务器在其中充当了一个“中间人”的角色，通讯双方计算机的数据都要通过它！因此，“代理 服务器进行的‘中间人攻击’”逐步成为现实，相对于其他“中间人攻击”方法，这种利用代理服务器暗渡陈仓的做法简直天衣无缝，攻击者可以自己写一个带有数 据记录功能的代理服务程序，放到任意一台稳定的肉鸡甚至直接在自己机器上，然后通过一些社会工程学手段让受害者使用这个做了手脚的“代理服务器”，便可守 株待兔了。这种方法最让人不设防，因为它利用的是人们对代理的无条件信任和贪便宜的想法，使得一个又一个“兔子”自动撞了上来，在享受这顿似乎美味的“胡 萝卜”的同时却不知道安全正在逐渐远离自己。

如果制作这个代理服务器的攻击者仅限于窥探数据，那么受害者的损失可能还能估量，但是 如果攻击者在目标服务器返回的数据里加入一个带有木马程序的数据呢？例如在HTTP代理返回的HTML报文里加入一个MIME攻击漏洞代码，而受害者的计 算机恰好没有打相应补丁，那么由此带来的损失就难以估量了，而且计算机技术不高的受害者也难以查出木马究竟是从哪里来的，因为很少有人怀疑代理服务器自身 会有问题！

拒绝“中间人”——我们该怎么做

谈了这些MITM攻击，许多用户会觉得恐惧，其实，攻防为一家，有攻就有防，只要措施正确，MITM攻击是可以预防的。

对于DNS欺骗，我们要记得检查本机的HOSTS文件，以免被攻击者加了恶意站点进 去；其次要确认自己使用的DNS服务器是ISP提供的，因为目前ISP服务器的安全工作还是做得比较好的，一般水平的攻击者无法成功进入；如果是依靠网关 设备自带的DNS解析来连接Internet的，就要拜托管理员定期检查网关设备是否遭受入侵。

至于局域网内各种各样的会话劫持（局域网内的代理除外），因为它们都要结合嗅探以及欺 骗技术在内的攻击手段，必须依靠ARP和MAC做基础，所以网管应该使用交换式网络（通过交换机传输）代替共享式网络（通过集线器传输），这可以降低被窃 听的机率，当然这样并不能根除会话劫持，我们还必须使用静态ARP、捆绑MAC+IP等方法来限制欺骗，以及采用认证方式的连接等。

但是对于“代理中间人攻击”而言，以上方法就难以见效了，因为代理服务器本来就是一个 “中间人”角色，攻击者不需要进行任何欺骗就能让受害者自己连接上来，而且代理也不涉及MAC等因素，所以一般的防范措施都不起作用。笔者认为，除非你是 要干坏事，或者IP被屏蔽，或者天生对网络有着恐惧，否则还是不要整天找一堆代理来隐藏自己了，没必要的。常在河边走，即使遇上做了手脚的代理也难察觉。