路由器错配故障分析
故障现象
服务器A，B共处于同一个子网内，会出现A可以和B通信，而B有时却不能和A通信，经检查发现在子网掩码配置时，两个服务器为下图所示:
网络中主机之间的基本通信可以分为两种类型:
- 同一网络内主机间的通信:数据可以直接发送给对方，不需借助网关.
- 不同网络之间的主机通信:数据必须先发送给网关，然后再通过网关转发给对方.
故障分析
从A到B的通信:A的子网掩码255.255.255.0，由此它得知自己所在网络的网络地址是192.168.80.0.现在它要发送数据给B，将B的IP地址192.168.80.3与A自己的掩码进行与运算，得知B所在的网络地址也是192.168.80.0，因而判断出B与自己在同一网络，可将数据直接发送给B.
从B到A的通信:B的子网掩码255.255.255.224，由此它得知自己所在网络的网络地址是192.168.80.0.现在它要发送数据给A，将A的IP地址192.168.80.129与B的掩码进行与运算，得知A所在的网络地址是192.168.80.128，与B不在同一网络，因而必须要借助于网关将数据转发给A.
结论:A可以直接将数据发送给B，而B却只能通过网关将数据转发给A。如果没有网关，A和B之间将无法通信.
用WireShark验证故障
搭设好实验环境，收集路由器A，B和网关MAC地址
服务器A：00-0c-29-bb-bb-7f
服务器B：00-0C-29-8C-BF-6D
默认网关：00-50-56-fe-c8-98
在服务器B上启动Wireshark，然后执行ping命令与A通信，此时Wireshark会将通信过程进行抓包.ping命令结束之后，停止抓包
报文分析
最上面的窗口列出了抓到的所有数据包，主要包含的信息有：数据包序号、数据包被捕获的相对时间、数据包的源地址、数据包的目的地址、数据包的协议、数据包的大小、数据包的概况信息.
选中1号包，在上方的窗口中会看到这是一个ARP广播包，这个包是由服务器B发出去的，目的是询问网关192.168.80.2的MAC地址.在下方的窗口中，第一行显示这个包的基本信息
在服务器B上ping服务器A，B首先会去解析网关的地址
2号包是默认网关返回的响应信息，告诉服务器B自己的MAC地址。注意这些MAC地址的开头都被替换成了Vmware，这是由于MAC地址的前3个字节表示厂商.
3号包是服务器B发出的ping包，指定的目的IP为A（192.168.80.129），但目的MAC却是默认网关的00-50-56-fe-c8-98，这表明B希望网关把包转发给A.
5号包是A发出的ARP广播，查询B的MAC地址.这是因为在A看来，B属于相同网络，因而无需借助于网关
6号包是B直接回复了A的ARP请求，把自己的MAC地址告诉A，这说明B在执行ARP回复时并不考虑同一网络问题，虽然ARP请求来自于其它网络，但也照样回复—ARP协议特点
破解网站密码
每当你在网站上输入用户名和密码后敲回车键，实际上将你的密码发送出去.
如果网站使用HTTP(明文格式)验证身份，捕获该流量，之后通过局域网(甚至通过互联网)从任何机器来分析此流量其实很简单.
只需要能够位于网关或交换机上(如果你获得访问权，流量通过其来转发，BGP路由器也可以).
还可以利用伪Wi_Fi基站（最简单）获得网站登录信息.
分析
在数据报文中，只有HTTP协议中的POST请求报文会还有用户信息。
为过滤所有流量、找出POST数据，在过滤器部分键入下列部分
http.request.method == “POST”
屏幕截图如下所示.它显示了1个POST事件
分析POST数据，寻找用户名和密码
现在鼠标右击这一行，选择Follow TCP Steam
这会打开一个新的窗口，窗口里面含有像这样的内容：
HTTP/1.1 302 Found
Date: Mon, 10 Nov 2014 23:52:21 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
P3P: CP=“NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”
Set-Cookie: non=non; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/
Set-Cookie: password=e4b7c855be6e3d4307b8d6ba4cd4ab91; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/
Set-Cookie: scifuser=sampleuser; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/
Location: loggedin.php
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
用户名：sampleuser
密码：e4b7c855be6e3d4307b8d6ba4cd4ab91
由上面的密码值可以猜想，e4b7c855be6e3d4307b8d6ba4cd4ab91肯定不是真实的密码值，而应该是一个哈希值.
需要注意的是，一些不注重安全的网站并未对用户发送的密码值求哈希值，而是直接将密码明文发送给服务器.对于这种网站，到这一步就能够得到用户名和密码信息了.而在我分析的例子中，我们还需要更进一步，即识别该哈希值对应的密码值.
确定秘钥的Hash值
在这一步中，将使用hash-identifier工具来确定上面的密码哈希值到底是什么类型的哈希。打开终端，然后输入“hash-identifier”并将上面的哈希值粘贴到终端，回车之后hash-identifier将会给出可能的匹配值.
MD5哈希值最可能。
可以使用hashcat或者cudahashcat破解该MD5哈希值
也可去在线MD5解密：http://www.cn.freemd5.com/index.php
结论:
目前，不可能确保每个网站都使用SSL来保证密码的安全，因为对于每一个URL来说，使用SSL服务都需要花钱.配置一个SSL网站，需要多花费1500USD.然而，网站的开发者至少应该在登录环节进行更加安全的策略来防止攻击者破解网站密码.（比如Salt算法）
数据流跟踪
合天网安中的一个实验案例：
黑客A通过ARP欺骗，使用Wireshark获取了整个局域网内的网络流量信息。无意之中，他发现有人在某个网站上上传了一份文件.但是他不知道怎么样通过Wireshark去还原这份文件，没办法，他将监听到的数据包保存为了一份Wireshark的监听记录，能帮助他找到那份上传的文件吗？
案例解析过程
准备一张图片test.jpg，并随便找一个允许上传的网站，然后用Wireshark将上传的过程抓包，这里我已经将自己的抓包结果保存成文件catchme.pcapng
打开抓包文件之后，会发现数据记录一共有344条.如果单纯的从开始到结尾去一条一条的审计，是非常费力的事情.
使用显示过滤器进行过滤，由于上传文件采用的是HTTP协议，因而使用过滤规则“http”，过滤之后发现数据包由原来的344个变成了137个，这样就很容易了.经分析，在第209条数据包的info中看到upload这个词，怀疑这条就是涉及到上传的数据包.
与上传数据有关的报文集合
由于上传文件都是采用POST方法，因而我们也可以使用过滤规则“http.request.method==POST”进行更精确的过滤，这时就只有47个数据包了.
虽然看到了有upload关键字，有POST方法，但是还不能确定是不是真的就是上传文件的那个请求。双击第209号数据包进行专门分析，在应用层数据中可以看到确实是上传了文件，而且文件名是test.jpg.
在传输层部分可以看到，由于文件比较大，TCP协议将其分成了16个数据段Segment，每个数据段都是一个独立的数据包，点击各个Frame，就可以看到数据包中的内容.
但问题是每个数据包中都只包含了上传文件的一部分，要想还原上传的文件，就必须将这些被分片的数据包重新组合成一个整体。在Wireshark中提供了一项“数据流追踪”功能，就可以来完成这项任务.回到Wireshark的主界面，在209号数据包上点击右键，选择“追踪流/TCP流”，
这时整个TCP流就会在一个单独的窗口中显示出来，我们注意到这个窗口中的文件以两种颜色显示，其中红色用来标明从源地址前往目的地址的流量，而蓝色用来区分出相反方向也就是从目的地址到源地址的流量.这里颜色的标记以哪方先开始通信为准，一般情况下都是由客户端主动发起与服务器的连接，所以大都是将客户端的通信显示为红色.
将数据流保存成原始文件，以便下一步处理。需要注意的是，在保存之前一定要将数据的显示格式设置为“原始数据”。
这里将文件的扩展名指定为.bin，以使用二进制形式保存文件.
利用WinHex工具还原原始图片数据
将之前保存的temp.bin用WinHex打开，可以看到文件中包含HTTP请求信息以及我们的图片信息，还有文件结尾的尾部信息.我们需要做的事情是确定图片文件的原始信息头和尾，并去掉多余的部分.
回到Wireshark中，会看到我们刚才的数据流中关于图片的头部分
在Content-Type: image/pjpeg后面有两个换行符，在原始文件中换行符用十六进制表示是 “0D 0A”，因为有两个，所以我们在图片名字test.jpg附近寻找“0D 0A 0D 0A”，后面的部分就表示图片的开始.
回到wireshark中，我们看看图片传送完毕之后的尾部部分。可以看到，这次是一个换行符，后面有些文件结束标志“-------------”.
原始文件中删除它们
这时候我们的文件中就仅仅是原始图片的内容了，将文件另存为test.jpg.
某电商网站流量劫持案例分析
故障现象
某天在家里访问常购物的某电商J网站时，突然发现浏览器先突然跳到了第三方网站再回到J的，心里第一个反应就是中木马了.
分析
首先在重现的情况下抓包，J网确实返回了一段JavaScript让浏览器跳转到了yiqifa.com.下图是应用层的抓包.
服务器返回的代码导致跳转，基本可以排除本地木马，推测是网络或者服务器的问题。根据经验，这种情况很大可能是链路上的流量劫持攻击.当然也不能排除J网站服务器被黑的情况.
继续排查.应用层已经不行了，要用Wireshark抓网络层的包.
从Wireshark结果可以看到，网络上出现了两个J网站的HTTP响应：97#和101#号报文.
第一个97#先到，所以浏览器执行里面的JavaScript代码转到了yiqifa.com；
第二个101#HTTP响应由于晚到，被系统忽略（Wireshark识别为out-of-order）.
两个J网站的HTTP响应包，必然一真一假.再来看看两个HTTP响应的IP头.第一个包TTL值是252，第二个包TTL值是56，而之前TCP三次握手时J服务器的TTL值是56，故可以判断先到的包是伪造的，真的包晚到而被系统忽略.
至此，确认是链路上的劫持.
攻击方式分析
伪造包的TTL值是252，也就是说它的原始TTL值应该是255（大于252的系统默认TTL值只能是255了，一般不会修改），也就表明攻击者的设备离我隔了3个路由；而正常的J网站的HTTP响应TTL值是56，隔了8个路由。物理上假的设备离我近，所以伪造的HTTP响应会先到——比较有意思的是，实际监测时候发现也有伪造包晚到导致劫持失败的情况.
推测是一个旁路设备侦听所有的数据包，发现请J网站首页的HTTP请求就立即返回一个定制好的HTTP响应。大致的攻击示意图如下.
推测攻击者在链路上大动干戈应该不会只针对一个网站，于是就访问了下其它几个知名的电商网站，结果发现其中有几个电商也受到同样的攻击.看起来这次流量劫持的目的是将电商网站流量导给返利联盟，通过返利联盟获得当前用户成交金额的返利.
基本确认运营商有问题，但是无法确认是运营商官方故意的还是遭到黑客攻击或者是内部人士偷偷搞的.
攻击源定位
来看看当时的路由结果：
如果按初始TTL值为255来算，HTTP包到达本机后为252，推算出经过了3（255-252）个路由，出问题的地方就在第4个路由附近，也就是这里的119.145.220.86
虽然基本可以确认是第四个路由附近的问题（笔者连续几天抓包，伪造的HTTP响应包TTL值一直是252），但是不排除设备故意构造一个初始TTL值（比如设置为254）来增加追查难度，为了严谨的治学态度及避免被攻击者迷惑，所以证据要坐实了.
定位劫持者位置：
既然攻击设备是旁路侦听数据包，可以推测它是基于包而非状态攻击的，我们构造被侦听的数据包（也就是直接发出访问J电商首页的HTTP请求TCP包，不需要三次握手）多次发送，TTL值从1开始递增，精确地传递数据包到每一个路径上，直到出现伪造响应——没有问题的位置是不会有响应的，第一个出现伪造响应的位置就是出问题的位置.
这个时候就需要一个数据包构造工具了，于是一路发过去，TTL值等于4的时候伪造的响应包出现了——确认就是第四跳路由出问题了，同时119.145.55.14回复了Time-to-live Exceeded的ICMP包.
攻防之道
链路劫持对企业和用户都是很麻烦的，影响用户体验，还泄漏敏感信息，而且还是分地域的，检测和防御起来也相对困难。链路劫持已经被某些人运用的炉火纯青。比如近期业界发现部分区域的百度联盟广告脚本被植入恶意JavaScript去DDoS攻击GitHub.
有运营商的区域DNS劫持和链路劫持、运营商区域DNS Server遭到缓存投毒攻击（利用CVE-2007-2926，非常经典）、开发商在路由软件中植入劫持代码、CDN与源通信遭到ARP攻击、用户PC本地木马.当然，这些目前都已经解决了，也在持续监测中.
为了对抗链路劫持，使用了HTTPS或者私有协议.
链路劫持
TCP链路劫持攻击
TCP链路劫持其实就是指网络链路上侦听、伪造TCP包，达到控制目标网络链路的行为。最常见的就是某些设备实现的对非法站点的访问拦截，以及一些地区运营商的网页植入广告行为。
因为广域网的链路劫持影响面大，一般会影响一个地区甚至是全国，所以本文重点讨论广域网的TCP链路劫持，局域网的劫持如ARP攻击不在讨论范围。
目前发现的TCP链路劫持攻击一般有两种形式：
中断访问型（分为单向发包和双向发包）
替换页面型
中断访问型:
中断访问型常见于阻止用户访问某些网站，如某些设备禁止用户访问某些站点、某地运营商的禁止ADSL多终端上网功能。其原理就是伪造服务端给用户发RST包阻止TCP连接的建立（单向发包）.某些设备做得比较狠，在冒充服务端给用户发RST包的同时也冒充用户给服务端发RST包（双向发包）.
替换页面型
常见于运营商植入广告，也有篡改正常网页进行SEO、骗流量的。最恶劣的莫过于钓鱼，如2011年出现过的Gmail钓鱼事件以及一些不能告之钓鱼事件。原理也简单，就是在一个HTTP请求后伪造服务端的HTTP响应给客户端.
下图所示就是一次典型的TCP链路劫持替换页面，可以看到，TCP三次握手完成后，HTTP请求包发送后，客户端收到两个HTTP响应包，因为伪造的第一个包（10号）先到，所以第二个正常的HTTP响应包（13号）被客户端忽略了.很明显，在网络上有一个设备，侦听整个会话，当匹配某个特征就抢先发包劫持会话.
利用链路劫持进行的弹窗广告、“技术问题”产生的误拦截、植入代码不慎将页面弄乱、甚至是钓鱼等将会损害用户利益.
要解决链路劫持先要搞清楚是否是链路劫持，如果是，则出问题的大概位置在哪里？链路劫持是区域性的，一般来讲某地区用户集中投诉，就可以联系用户调查了.
抓到可疑包之后关注两个关键点：TTL值和IP id（Identification）.根据实际观测，伪造的TCP包的TTL值和id是不符合逻辑的.
如下图，真实包的TTL是53，id是按顺序自增的，而伪造的包的TTL是64，id始终是0.也见过某地运营商禁止ADSL多终端上网功能会伪造id值恒为8888的RST包.
通过伪造的TTL值就可以大致定位侦听设备的位置。利用伪造的数据包的TTL值加上当时用户的路由即可定位：数据包每经过一个路由TTL值就会减一，找到假的包，TTL（一般初始发出的TTL是256或128或64）减了多少，反推回去就找到出问题的位置了.
截图中，伪造的TCP的TTL是64，可以推测出链路劫持就发生在局域网内，这是一个路由器软件进行链路劫持的案例
如果攻击者聪明一些，定制一个TTL值，就会导致难以精确定位。比如某些设备会发三次RST包，每次的TTL都不一样.注意，这里说的“难以定位”并非“不能定位”，还是有办法的，需要动动脑子.
双向RST的情况，部署在机房的IDS也可以发现端倪.
如果是替换页面型攻击，页面hash或者HTML元素个数会有异常，这里也可以作为一个检测点.
防范链路劫持就比较困难，毕竟攻击者控制着网络链路不过并非不可能.
一是网站全程使用安全套接层（SSL）.
再一个就是在客户端或（和）服务器丢弃伪造的TCP包.比如前面说到的单向中断访问型攻击，就可以丢弃包含伪造特征的TCP包（如Id为0或8888）.
最后，广域网一点都不安全，所以敏感信息传输一定要加密，还要高强度加密；自动升级的程序也一定要校验文件签名.
