Wireshark进阶之网络问题案例分析

本文假定的基础是阅读者会使用Wireshark了，这里就对一些应用的场景以及一些不正常的网络环境来进行分析的案例~

这里先列一下筛选器的语法：

过滤语法：

限定词	例子
Type	host、net、port
Dir	src、dst
Protocol	ether、ip、tcp、udp、http、ftp

逻辑运算符：&&、||、！等

操作符：==、！=、>、<、>=、<=等

Wireshark的信息统计（Statistics）

每次查看大量数据包流量时，建议从Wireshark的信息统计部分开始进行总的查看，往往能够了解到大体的一些信息，对后续具体的流量分析作用很大。

查看端点（Endpoints），往往可以观察到该数据包中哪些地址的流量较多等信息，可以判断出哪些地址比较可疑等信息，如下：

如图可知哪些IP地址的流量较多。

查看会话（Conversations），会话跟端点的区别在于会区别显示哪两个IP在通信，且各自都发送多大的数据等，如下：

协议分层（Protocol Hierarchy Statistics），从该窗口中可看出是哪些协议的流量比较多，如下：

每次进行流量检查的时候最好先打开这个窗口，方便进行总的流量查看，若不常用的协议流量较多时则可能存在一些异常行为。

数据包长度（Packet Lengths），可以查看数据包的大小所占百分比，如果存在着很多的较大的数据包，则很可能是在传输数据，如下：

查看IO图（IO Graphs），显示下载量和下载速度，如下分别为下载慢的和快的：

双向时间图（TCP Stream Graph>Round Trip Time Graph），确定是否存在延迟，延迟点的查看即查看峰值较高的点，如下：

专家信息（Analyze>Expert Info Composite），在Analysis中，如下：

可知道这个协议的数据包的状态，其中有四类状态：对话chat（关于通信的基本信息）、注意note（正常通信中的异常数据包）、警告warn（不是正常通信中的异常数据包）、错误error（数据包中的错误，或者解析器解析时错误）。

一些常见的协议包

IPv4头存活时间TTL：TTL值规定了数据包在丢弃之前所能经历的时间或者能够经过的最大的路由数目。通常在创建时就有初始值。如下图：

TCP三次握手：

TCP终止FIN：

TCP重置RST：

ICMP互联网控制消息协议Ping功能：

Type为8、Code为0意味着这是一个echo请求，Type为0、Code为0意味着这是一个echo响应：

DNS查询（资源记录类型A-IPv4主机地址，NS-权威域名服务器，CNAME-规范别名，MX-邮件交换，TXT-文本字符串，AAAA-IPv6主机地址，IXFR-增量区域传送，AXFR-完整区域传送）：

实战案例

1、Wireshark嗅探分别ncat和nc流量来进行无加密和加密传输的对比

nc无加密传输：

打开BT5和Kali，在BT5上输入：nc -lp 1234 -c bash

接着在Kali输入：nc -nv BT5的IP 1234

然后进行远程命令交互，如下：

全程用Wireshark抓包分析，直接追踪TCP流查看得到两者之间的通信内容：

可见，通信内容是明文传输的，容易被嗅探到。

ncat使用--ssl参数进行加密传输：

同样在BT5和Kali上，在BT5上输入：ncat -nvl 1234 -c bash --ssl

接着在Kali输入：ncat -nv BT5的IP 1234 --ssl

然后两者进行简单的通信，内容如下：

全程用Wireshark抓包分析，直接追踪TCP流查看得到两者之间的通信内容：

会发现通信内容被加密了，即使嗅探了也无法得到明文内容。值得注意的是必须在此使用--ssl参数进行加密，否则还是进行明文传输。

2.TCP的错误恢复和流量控制机制以及识别、诊断网络慢的问题

1)TCP重传

重传数据包是TCP最基本的错误恢复特性之一。当数据包发送出去但是接收方并没有发送ACK时，发送方会认为原来的数据包已经丢失然后再重传，期间RTO（重传超时）的值会翻倍。整个过程会持续收到接收方发送的ACK或者是发送方重传次数达到最大值为止。

下面的例子中，随机打开两个连续的包查看RTO值，后者的大约为前者的两倍：

2)TCP重复确认和快速重传

当接收方收到乱序的数据包时，便发送重复的ACK，且TCP在其头部使用序号和确认号字段来确保数据被可靠接受并以发送顺序重组。

接收数据的序号+接收数据的字节数=发出的确认号

当接收方接收到与计算不一样的序号的时候会假设有数据包丢失了，从而会向发送方发送一个包含丢失的数据包序号的ACK数据包让发送方重传数据包。而当发送方收到3个来自接收方的重复ACK时会立刻发送一个快速重传。重传其间其他所有的正在传输的都停止下来等重传数据包完成传输才能继续传输。

如下：

3)TCP滑动窗口机制

TCP滑动窗口机制用于检测何时发生了数据包丢失并调整数据传输速率加以避免。

窗口大小：服务器会计算客户端在此前发送数据包的速率并计算按如此速率下去接受是否会发生数据包丢失，若可能会发生丢失时，服务器会根据能够接受的速率进行调整返回的ACK数据包的TCP头部窗口大小值来实现数据的正常接受。另外，窗口大小值递减，是主机延迟增加的一个典型指标。

零窗口：有时候服务器会没办法处理客户端发送过来的数据，这是服务器会发送一个数据包指明窗口大小是零，让客户端停止所有的数据传输。但客户端依然会通过发送“保活数据包”来保持和服务器的连接以便确认服务器接受窗口的状态。

实例：

窗口大小逐渐减小至零窗口大小之后恢复：

窗口大小减少至零窗口后无法恢复：

小结：

若客户端检测到服务器没有接收到它发送的数据的话就会发生重传；

当接收到重复ACK时肯定是因为接收到乱序的数据包才引发的；

滑动窗口与服务器的接受、处理数据的故障直接相关。

4)网络高延迟

正常通信

整个通信过程是相当迅速的，即每个数据包发送的时间不会隔很久：

线路延迟

第二个数据包SYN/ACK的发送存在延迟，这是客户端和服务器之间的设备导致的。因为当服务器收到一个SYN数据包时，它不涉及任何传输层以上的处理，是只需要很小的处理量就能够进行发送一个响应的，即使是在承受巨大的流量负载的时候也一样能迅速响应，从而排除了服务器的可能性。另外，客户端也是理所当然地排除在外，因为它除了之前发送一个SYN之后就没做过啥了。因而推敲是线路的问题。

第五个数据包也存在高延迟现象，是在数据包4即HTTP的GET请求从客户端正常发送给服务器之后的，而同样，服务器在发送数据之前先发送一个ACK是不会耗费很多处理资源的，因而这也是线路延迟的一个标志。

线路延迟说明了问题并不是出在客户端或者服务器中，而是线路中的某些设备中，可能是防火墙、代理服务器之类的问题等等。

客户端延迟

三次握手正常，到数据包4即进行HTTP的GET请求时存在延时。查看数据包3和4之间，数据包3是客户端发送ACK给服务器进行三次握手的最后一步，接着再数据包4也是客户端发送HTTP的GET请求给服务器，所以可以确定和服务器无关而问题是出在客户端，即其中发送ACK之后并没有快速地切换到GET，因而导致了高延迟。

服务器延迟

直到最后一个数据包才出现高延迟的现象。

例子中，数据包5是服务器响应客户端GET请求的ACK，在其之后，服务器应当立即开始发送数据给客户端而不是延迟了一段时间。这说明了服务器没能够及时地处理好这些数据，即可判定是服务器存在延迟现象。

延迟定位框架

下图总结一下对于网络延迟问题的定位，对于任何基于TCP的通信都几乎可用：

①线路延迟

②客户端延迟

③服务器端延迟

3.抓包分析NMAP工具进行SYN扫描

TCP SYN扫描是依赖于三次握手来确定目标主机上哪些端口是开放的。攻击者会发送TCP SYN数据包到目标主机的一个范围的端口上，假装是要进行建立正常的通信连接，这也是TCP三次握手的第一次。若目标机器回复了TCP SYN/ACK数据包，则表明该端口是打开的，且这时候攻击者是不进行任何回复的，这样导致目标主机会进行3次重传SYN/ACK；若攻击者收到相应的RST数据包，表明端口已经关闭了；若攻击者没有收到任何响应，则意味着端口被某个中间设备过滤了，可能是防火墙或者主机本身。

示例：

可以通过“统计”>“会话”中的数据来快速识别哪些端口是开放的或者是关闭的：

其中点击Conversations窗口内的TCP：1994，让packets按从大到小的顺序排序，其中5个包（SYN、SYN/ACK、三次重传SYN/ACK）的端口就是开放的，2个包（SYN、RST）的端口就是关闭的，剩下的都是一个包（SYN）的都是不确定的。

4.被动式操作系统指纹术

“操作系统指纹术”是指在无物理接触的情况下，来确定目标主机运行的操作系统的一组技术，分为主动式和被动式。

主动式主要为使用Nmap发起主动的扫描，然后再与指纹数据库进行对比后确认。而被动式则主要是根据不同操作系统实现的TCP/IP协议栈都必须为这些域定义它自己的默认值来实现识别的原理。

可以参考下图直接进行识别：