流量劫持，这种古老的***沉寂了一段时间后，最近又开始闹的沸沸扬扬。众多知名品牌的路由器相继爆出存在安全漏洞，引来国内媒体纷纷报道。只要用户没改默认密码，打开一个网页甚至帖子，路由器配置就会被暗中修改。互联网一夜间变得岌岌可危。
***还是那几种***，报道仍是那千篇一律的砖家提醒，以至于大家都麻木了。早已见惯运营商的各种劫持，频繁的广告弹窗，大家也无可奈何。这么多年也没出现过什么损失，也就睁只眼闭只眼。
事实上，仅仅被运营商劫持算是比较幸运了。相比隐匿在暗中的神秘***，运营商作为公众企业还是得守法的，广告劫持虽无节操但还是有底线的。这不，能让你看见广告了，也算是在提醒你，当前网络存在被劫持的风险，得留点神；相反，一切看似风平浪静毫无异常，或许已有一个天大的间谍潜伏在网络里，随时等你上钩 —— 这可不是弹广告那样简单，而是要谋财盗号了！
我会被劫持吗？ 不少人存在一个错误的观点：只有那些安全意识薄弱的才会被***。只要装了各种专业的防火墙，系统补丁及时更新，所有的密码都很复杂，劫持肯定是轮不到我了。
的确，安全意识强的自然不容易被***，但那只对传统的病毒***而已。而在流量劫持面前，几乎是人人平等的。网络安全与传统的系统安全不同，网络是各种硬件设备组合的整体，木桶效应尤为明显。即使有神一样的系统，但遇到猪一样的设备，你的安全等级瞬间就被拉低了。现在越来越流行便宜的小路由，它们可是承载着各种网上交易的流量，你能放心使用吗？
即使你相信系统和设备都绝对可靠，就能高枕无忧了吗？事实上有问题的设备并不多，但出问题的事却不少，难道其中还存在什么缺陷？没错，还遗漏了最重要的一点：网络环境。
如果网络环境里有***潜伏着，即使有足够专业的技术，是在所难逃了，敌暗我明，稍不留神就会落入圈套。
当然，苍蝇不叮无缝的蛋。有哪些隐患导致你的网络环境出现了裂缝？太多了，从古到今流行过的***方式数不胜数。甚至可以根据实际环境，自己创造一种。 现在回忆下尝试过的劫持案例。
上古时代：
Hub 嗅探
MAC 欺骗
MAC 冲刷
ARP ***
DHCP 钓鱼
DNS 劫持
CDN ***
中世纪：
路由器弱口令
路由器 CSRF
PPPoE 钓鱼
蜜罐代理
工业时代：
WiFi 弱口令
WiFi 伪热点
WiFi 强制断线
WLAN 基站钓鱼
1.Hub 嗅探：
集线器（Hub）这种设备如今早已销声匿迹了，即使在十年前也少有人用。作为早期的网络设备，它唯一的功能就是广播数据包：把一个接口的收到的数据包群发到所有接口上。且不吐槽那小得惊人的带宽，光是这转发规则就是多么的不合理。任何人能收到整个网络环境的数据，隐私安全可想而知。
嗅探器成了那个时代的顶尖利器。只要配置好过滤器，不多久就能捕捉到各种明文数据，用户却没有任何防御对策。
防范措施：还在用的赶紧扔了吧。 这种设备目前唯一可用之处就是旁路嗅探。利用广播的特性，可以非常方便分析其他设备的通信，例如抓取机顶盒的数据包而不影响正常通信。
2.MAC 欺骗 ：
交换机的出现逐渐淘汰了集线器。交换机会绑定 MAC 地址和接口，数据包最终只发往一个终端。因此只要事先配置好 MAC 对应的接口，理论上非常安全了。
不过，很少有人会那么做，大多为了偷懒，直接使用了设备默认的模式 —— 自动学习。设备根据某个接口发出的包，自动关联该包的源地址到此接口。
然而这种学习并不智能，甚至太过死板，任何一个道听途说都会当作真理。用户发送一个自定义源 MAC 地址的包是非常容易的，因此交换机成了非常容易被忽悠的对象。只要伪造一个源地址，就能将这个地址关联到自己的接口上，以此获得受害者的流量。
不过，受害者接着再发出一个包，绑定关系又恢复原先正常的。因此只要比谁发的频繁，谁就能竞争到这个 MAC 地址的接收权。如果伪造的是网关地址，交换机就误以为网关电缆插到你接口上，网络环境里的出站流量瞬间都到了你这里。
当然，除非你有其他出站渠道，可以将窃取的数据代理出去；否则就别想再转发给被你打垮的真网关了，被劫持的用户也就没法上外网。所以这招危害性不是很大，但破坏性很强，可以瞬间集体断网。
防范措施：机器固定的网络尽量绑定 MAC 和接口吧。貌似大多数网吧都绑定了 MAC 和接口，极大增强了链路层的安全性。同时，独立的子网段尽可能划分 VLAN，避免过大的广播环境。 大学里见过千人以上还不划分 VLAN 的，用一根短路网线就可以毁掉整个网络。
3.MAC 冲刷 ：
之前说了集线器和交换机的转发区别。如果交换机发现一个暂时还未学习到的 MAC 地址，将会把数据包送往何处呢？为了不丢包，只能是广播到所有接口。
如果能让交换机的学习功能失效，那就退化成一个集线器了。由于交换机的硬件配置有限，显然不可能无限多的记录地址对应条目。我们不停伪造不重复的源地址，交换机里的记录表很快就会填满，甚至覆盖原有的学习记录，用户的数据包无法正常转发，只能广播到所有接口上了。
防范措施：还是 MAC 和接口绑定。一旦绑定，该接口只允许固定的源地址，伪造的自然就失效了。当然，好一点的交换机都有些策略，不会让一个接口关联过多的 MAC 地址。
曾经在家试过一次，捕捉到小区内用户上网的流量。不过伪造包发的太快，~15万包/秒，更致命的是发错目标地址，发到城域网准入服务器上，导致工作人员切断了整个小区半天的网络… 所以必须得选一个 VLAN 内的、并且实际存在的地址做为目标 MAC，以免产生大量的数据风暴。
4.ARP ***：
这种***大家几乎都听出老茧了，即使不懂电脑的人也知道装个 ARP 防火墙保平安，其危害之大可想而知。
简单的说，ARP 就是广播查询某个 IP 对应的 MAC 地址，在用这个 IP 的人回个声。知道这个 IP 对应的 MAC 地址，就可以链路通信了（链路层只能通过MAC地址通信）。如果有人冒充回复，并抢在正常人之前，伪造的答案也就先入为主。IP 被解析到错误的地址上，之后所有的通信都被劫持了。
事实上，早期的系统还有个更严重的BUG：直接给用户发送一个 ARP 回复包，即使对方从没请求过，系统也会接受这个回复，并提前保存里面的记录。这种基于缓存的投毒，让劫持成功率更上一层楼。
防范措施：由于这种***太过泛滥，以至大部分路由器都带了防 ARP ***的功能。客户端的 ARP 防火墙也数不胜数，似乎成了安全软件的标配。当然，系统也支持强制绑定 IP 与 MAC 的对应，必要时可以使用。
很多教程都是用 Wireshark 来演示，事实上当年有一款叫 Iris 的软件非常好用，可以修改封包再次发送，用它可以很容易搞明白各种***的原理。不过N年没更新了还不支持64位的。
5.DHCP 钓鱼 ：
现实中，并不是每个人都会配置网络参数，或者出于方便，让网络系统自动配置。出于这个目的，DHCP 服务诞生了。
由于没有配置IP地址、网关、DNS等，在网络上是寸步难行的，因此首先需要从DHCP那获得这些。然而，既然连 IP 地址都没有，那又是如何通信的？显然，只能发到广播地址（255.255.255.255）上，而自己则暂时使用无效的IP地址（0.0.0.0）。（事实上，链路层的通信只要有 MAC 地址就行，IP 地址已属于网络层了，但 DHCP 由于某些特殊需要使用的是 UDP 协议）
因为是发往广播，内网环境里的所有用户都能听到。如果存在多个DHCP服务器，则分别予以回复；用户则选择最先收到的。由于规则是如此简单，以至于用户没有选择的余地。
尚若***也在内网里也开启了DHCP服务，用户收到的回复包很可能就是***发出的，这时用户的网络配置完全听天由命了，不想被劫持都难了。
防范措施：如果是用网线上网的话，最好还是手动的配置。当然，管理员应该严格控制DHCP回复的权限，只允许交换机特定的接口才有资格发送回复包。 只要是这类提问/抢答模式的，都面临被冒充回答的风险。很多原理都类似。
6.DNS 劫持 ：
如同 ARP 将 IP 解析成 MAC 地址 一样，DNS 负责将域名解析成 IP 地址。作为网络层的服务，面对的用户更广泛，当然面临的风险也大的多。一旦遭到***，所有用户都倒霉了。近些年的重大网络事故无不和 DNS 有关。
DNS 服务一旦被***控制，用户发起的各种域名解析，都将被暗中操控。将正常网站解析成***服务器的 IP，并事先开启了 HTTP 代理，用户上网时几乎看不出任何破绽；而***则获取到所有访问流量，各种网站账号信息都将一览无余。
由于 DNS 服务器的重要性，现实中通常有着较高的安全防护，想***它系统不是件易事。但实际未必如此兴师动众，一些 DNS 程序本身就存在着设计缺陷，导致***能控制某些域名的指向。其中最恶名昭彰的当属 DNS 缓存投毒。
大家或许已发现，域名->IP->MAC->接口，只要是动态查询的就会多一个环节，风险自然增加。灵活性与安全性始终是不可兼得。
防范措施：手动设置一些权威的 DNS 服务器，例如 8.8.8.8，4.4.4.4 会靠谱的多。
公网上的 DNS 劫持很少发生，但家用路由器的 DNS 劫持已泛滥成灾了。开头报道的路由器漏洞，最终的利用方式也就是修改了 DNS 地址。
7.CDN *** ：
CDN 能加速大家都知道，但其中原理不少人都不清楚。其实，CDN 本身就是一种 DNS 劫持，只不过是良性的。
不同于***强制 DNS 把域名解析到自己的钓鱼 IP 上，CDN 则是让 DNS 主动配合，把域名解析到临近的服务器上。这台服务器同样也开启了 HTTP 代理，让用户感觉不到 CDN 的存在。
不过 CDN 不像***那样贪心，劫持用户所有流量，它只『劫持』用户的静态资源访问，对于之前用户访问过的资源，CDN 将直接从本地缓存里反馈给用户，因此速度有了很大的提升。
然而，只要是有缓存的地方，都是大有可为的。一旦 CDN 服务器遭受***，硬盘上的缓存文件就岌岌可危了，网页被注入脚本，可执行文件被感染，一大波僵尸即将出现。
防范措施：感觉运营商不靠谱的话，换个第三方不带加速的 DNS，或许就不会解析到 CDN 服务器上了。 不少 CDN 黑白通吃，为了省流量不按套路出牌，超过了缓存时间也不更新，甚至还有忽略 URL 问号后面的，导致程序猿们在资源更新的问题上头疼不已。
l