实验目的

捕获和分析网络数据
掌握以太网MAC帧、802.11数据帧和IPv4数据包的构成，了解字段含义
掌握ICMP和ARP协议的请求/响应机理
掌握ping、arp和tracert指令

实验内容与分析

任务1：Wireshark抓包

作者使用window10的系统，安装wireshark3.0.3进行抓包。

过滤器的使用

① 过滤特定端口
tcp.port eq 80 ：显示源端口或目的端口为80的报文
tcp.srcport eq 80：显示源端口为80的报文
tcp.dstport eq 55332：显示目的端口为55332的报文
②按长度进行过滤
tcp.len >0：过滤具有有效载荷的tcp报文
udp.length == 26 ：过滤长度为26字节的udp包
ip.len eq 1500 ：过滤长度为1500字节的IP数据包。
frame.len le 128: 过滤数据帧总体长度小于128B的记录
③过滤IP地址
ip.src eq 192.168.1.107 ：按源IP地址过滤的数据包
ip.dst eq 192.168.1.107 ：按目的IP地址过滤的数据包
ip.addr eq 192.168.1.107：不区分源和目的IP地址过滤的数据包
④过滤包含特定字符串域名的报文，如：http.host contains “xmu”
⑤多个过滤条件，例如满足http以及且端口为80的过滤规则：http && tcp.port == 80
PS：
1.此处tcp数据包长度+tcp头部（20）+ip头部(20)+以太网头部（14）=整体数据帧的长度。
2.此处udp数据包长度+ip头部长度（20）+以太网头部（14）=整体数据帧的长度。
3.此处ip数据包长度+以太网头(14)=整体数据帧的长度。
4.在组合表达式中使用“!=”操作符，像eth.addr,ip.addr,tcp.port,udp.port等元素可能会产生非预期效果。
5.MAC层地址的过滤是同样的道理
6.组合符号有and&& 且 or,||,或 not,! 取反这几种。

在上图的数据包中，我发现有不少数据帧是小于60字节的(MAC帧尾部4字节已被网络设备过滤)，但是我们知道Wireshark是工作在数据链路层的，在以太网传输的最小帧长度为64字节，这显然与课上所学不符。查阅相关网络资料得到解答

由于Wireshark在传输帧离开主机进入网络适配器之前就捕获了传输帧，此时的帧并未经过填充至64字节进入以太网，因此可能会捕获到小于60字节的数据帧，并且抓到的数据帧中只有本机发送的数据帧可能会小于60字节，而接收的数据帧一定不会小于60字节。

任务2：捕获分析以太网MAC帧和IPv4数据包

通过ping内网和外网，从捕获的数据包来分析以太网MAC帧和IPv4数据包

ping 的实质：发送一个icmp回显请求报文给目的的主机，并等待回显的icmp应答。然后打印出回显报文。回显的结果包括：字节数、反应时间、TTL（生存时间）

ping的功能如下图

任务要求：

一、内网

(1)首先查看本机的ip地址，再使用ipscan查看当前局域网内有哪些主机可以ping通

可知本机ip是192.168.2.180，子网掩码为255.255.255.0，则子网为192.168.2.0

（1）局域网内另一台主机ip为192.168.2.102
通过以下代码ping通该主机

ping 192.168.2.102 -t

同时打开wireshark捕获数据包

（2）可以看到图中共有5对ICMP请求帧和回应帧
用以下语句过滤得到ICMP报文

icmp

（3）①

1°观察第一个编号为1的Echo (ping) request 数据帧

如上图所示，这个数据帧的结构如下

Ethernet II
IP
ICMP

2°进一步观察Ethernet II（MAC帧）的内容

其数据帧格式如下

目的地址	源地址	类型	数据	FCS
6	6	2	46~1500	4

图中：
Destination: 代表目的MAC地址，有6个字节，图中目的MAC地址为a0:86:c6:8c:da:d5
Source: 代表源MAC地址，有6个字节，图中源MAC地址we为3c:a0:67:16:06:f3
Type: 代表类型，有2个字节，图中类型值为0x0800，代表类型为IPv4
Data: wireshark将数据解析在下一层
FCS: 表示帧校验序列，有 4 个字节，用于校验帧是否出错。该字段内容已被网络设备滤去，抓包软件已无法获取

3°观察IP数据报的内容

图中：
Version:版本号，占4位，4,代表IPv4
Header Length:首部长度，占4位，5, 表示 5 个以 32 bit 为单位的字，即 20 bytes
Differentiated Services Field:区分服务，占8位
Total Length:总长度,占16位，最大为 $2^{16}-1=65535$ 字节，图中为60字节
Identification:标识，占16位
Flags:标志(占3位)和片位移(占13位)，共占16字节，其中标识中MF=1标识后面“还有分片”的数据报，MF=0表示这已是若干数据报片中的最后一个。DF意思是“不能分片”，当DF=1才允许分片。片位移以8个字节（64位）为偏移单位。
Time to live:生存时间，占8位，TTL
Protocol:协议，占8位，图中1代表ICMP
Header checksum:首部校验和，占16位，只检验数据报的首部，但不包括数据部分。
Source:源地址，占32位，图中为192.168.2.180
Destination:目的地址，占32位，图中为192.168.2.102

4°观察ICMP数据报的内容

其数据帧格式如下

0~7	8~15	16~31
类型	代码	检验和
标识符		序列号
数据

图中：
Type：类型，占8位，包括差错报告报文（3：终点不可达，11：时间超过，12：参数问题，5：改变路由）和询问报文（8或0：回送（Echo）请求或回答，13或14：时间戳请求或回答），图中类型值为8，PING请求
Code：代码，占8位，是为了进一步区分某种类型中的几种不同情况
Checksum：校验和，占16位，用于检验整个ICMP报文
Identifier：标识符，占8位用于匹配 Request/Reply 的标识符。
Sequence number：序列号，占8位，用于匹配 Request/Reply 的序列号
Data :数据

可以注意到，上面图中标识符有BE和LE两种，具体什么意思呢？

由上面四张图可以看出，标识符和序列号的BE和LE对应的是相同的内容，但是读写顺序不一样，于是到WireShark官网查看解释https://www.wireshark.org/lists/wireshark-bugs/200909/msg00439.html，发现这样一段话

由此可知， wireshark考虑到window系统与Linux系统发出的ping报文（主要指ping应用字段而非包含IP头的ping包）的字节顺序不一样，BE表示linux系统的big-endian（大头位序），LE表示Windows系统的小头位序，开发者将其分别显示出来。

②

由图可知MAC帧长度为74字节但是这个长度并不包括FCS（4个字节，已被网络设备滤去，抓包软件已无法获取），因此实际长度为78字节

由上图可知IP数据报长度为60字节，二者关系为：IP数据报是属于MAC帧的数据部分，如下图所示

（4）比较ICMP请求帧和回应帧的结构和IP头部字段的变化

从上图可知ICMP请求帧和回应帧的结构相同，但是在内容上，目的地址和源地址交换，ICMP报文的Type和Checksum不同。
观察IP数据报首部

从上面两张图可以发现Identification（标识符）、 Header Checksum（首部校验和）、Source（源地址）、 Destination（目的地址）发生了变化

二、外网

我们选择下面的命令Ping外网

ping www.baidu.com -t

经过观察发现ping外网和ping内网的得到的ICMP帧在结构上并无太大区别

三、改变ping包的大小，观察IP数据包分片

使用下面的命令

ping 192.168.2.102 -t -l 4000
ping 192.168.2.102 -t -l 10000
ping 192.168.2.102 -t -l 20000
ping 192.168.2.102 -t -l 65500

可见一个帧的MTU值为1500（1480+20）字节

可以注意到显示的ICMP帧内有所有的分片，以第一张图为例，然而ICMP帧的长度为1082字节，却有4008字节的IP数据报，这显然不合常理，后研究发现，这只是因为wireshark的人性化显示方式，将其他IP帧放在一起显示。

查看IPv4协议帧和ICMP协议帧的结构

经过分析，我做出以下推断：
①ICMP报文是放在IP数据报里的，在ping指令中的-l，其发送的数据字节数并不包括ICMP首部的8个字节，是指ICMP报文的数据总长度
②ICMP报文分片是从包含ICMP首部的部分开始分片的，wireshark抓到的包ICMP协议显示在最后收到只是WireShark的显示问题。
③ping命令发送和接受的ICMP报文内部填充数据是“a-w”23个字母的循环填充。

接着尝试ping外网的大数据包

ping www.baidu.com -l 1472
ping www.baidu.com -l 1473

发现如上图的异常，查阅相关资料得知百度网站这是百度网站设置的拒绝服务，PING1500字节以上被baidu.com认为是PING洪水攻击，对于其有可能造成瘫痪，因此拒绝返回ICMP报文，但是图中在1473字节便拒绝服务，这是为什么呢？

我使用以下两条命令得到测试结果，其中-f表示在数据包中设置“不分段”标记(仅适用于 IPv4)。

ping 4399.com -l 1472 -f
ping 4399.com -l 1473 -f

在前文笔者提到，ping的-l只表示ICMP报文的数据部分长度，并不包括ICMP报文的首部8个字节和IP数据报的首部20个字节，由于MTU为1500，因此ping在不分片的情况下-l参数最大为1500-8-20=1472字节

作为对比，笔者ping如下另外两个外网IP，均无异常

ARP协议工作原理分析

首先使用arp –d命令，清空本机已有的ARP缓存

arp -d

产生如上错误，是因为权限不够
到C:\Windows\System32右键使用管理员身份运行cmd.exe，成功清空本机已有的ARP缓存

接着发起PING命令，浏览网站等网络活动，抓取到一系列包

上面红框内是一对arp协议
首先观察MAC帧

上面可以发现与ICMP协议数据报的两点不同：Type是ARP以及多了Trailer这一项

Trailer这一项是指附加数据。在以太网中，每个数据包最小是64字节。如果数据包不足64字节，就会由网卡进行填充。由于填充的部分不属于实际数据，就会被Wireshark单独解析出来，以Trailer字段进行表示，称为附加数据。附加数据虽然只是为了格式需要，但也可以用来传递数据，如传递协议不支持的数据。

接着观察arp数据报

Arp报文总共占了28个字节

Hadware type:硬件类型，占2字节，表示ARP报文可以在哪种类型的网络上传输，值为1时表示为以太网地址。
Protocol:上层协议类型，占2字节，表示硬件地址要映射的协议地址类型，映射IP地址时的值为0x0800。
Hardware size：MAC地址长度，占1字节，标识MAC地址长度，以字节为单位，此处为6。
Protocol size：IP协议地址长度：占1字节，标识IP得知长度，以字节为单位，此处为4。
Opcode：操作类型：占2字节，指定本次ARP报文类型。1标识ARP请求报文，2标识ARP应答报文。
Sender MAC address：源MAC地址，占6字节，标识发送设备的硬件地址。
Sender IP address：源IP地址，占4字节，标识发送方设备的IP地址。
Target MAC address：目的MAC地址，占6字节，表示接收方设备的硬件地址，在请求报文中该字段值全为0，即00-00-00-00-00-00，表示任意地址，因为现在不知道这个MAC地址。
Target IP address：目的IP地址，占4字节，表示接受方的IP地址。

图中共有两种ARP报文: ARP请求报文和ARP回复报文

如上图是ARP请求报文，既有广播又有单播，当为广播时，其目的是发送到每一个IP地址，以得到命中IP地址关于其MAC地址的回应，当为单播时，其为ARP请求确认报文，如下图

从上图可以看到，经常有这种“明知故问”的arp单播请求报文，而且还会重复发多次，这是为什么呢？查阅相关资料

ARP对于高速缓存中的每一个映射地址项目都有设置有生存时间，凡超过生存时间就从高速缓存中删掉。从https://www.cnblogs.com/lipx9527/p/9436019.html找到以下答案

对于ARP回复报文，wireshark捕获到两种:arp单播回复报文和arp广播回复报文

上图是ARP单播回复报文，其作用是告诉目的IP自己的MAC地址

上图是ARP广播回复报文，其目的是：主动告诉广播域里的其它主机，IP= 10.30.0.1 对应的MAC = 04:40:a9:68:82:01，其它主机都会将这个对应关系缓存（Cache）下来，即ARP Table Cache，这样可以避免别的主机和10.30.0.1 通信时，事先还需要先ARP广播请求，大大减少ARP广播。下图源自https://blog.csdn.net/bobozai86/article/details/82693339

分别ping同一局域网的计算机和局域网外的计算机
使用以下命令ping内网

ping 10.30.27.181

可以得到一对单播请求和回复报文

使用下列命令ping外网

ping 4399.com

并没有抓到关于外网网址的ARP请求包和回复包

这是因为，ARP是解决同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题。源主机A首先比较目的IP地址与自己的IP地址是否在同一子网中，如果在同一子网，则向本网发送ARP广播，获得目标IP所对应的MAC地址；如果不在同一子网，就通过ARP询问默认网关对应的MAC地址，将数据帧送到路由器上。（参考ARP地址解析过程（同一子网和不同子网）)

tracert分析

Tracert 的实质：利用ICMP数据报和IP数据报头部中的TTL值。TTL（Time To Live）是一个IP数据报的生存时间，当每个IP数据报经过路由器的时候都回把TTL值减去1或者减去在路由器中停留的时间，但是大多数数据报在路由器中停留的时间都小于1秒种，因此实际上就是在TTL值减去了1。这样，TTL值就相当于一个路由器的计数器。

当路由器接收到一个TTL为0或者1的IP数据报的时候，路由器就不再转发这个数据了，而直接丢弃，并且发送一个ICMP“超时”信息给源主机。Tracert程序的关键就是这个回显的ICMP报文的IP报头的信源地址就是这个路由器的IP地址。同时，如果到达了目的主机，我们并不能知道，于是，Tracert还同时发送一个UDP信息给目的主机，并且选择一个很大的值作为UDP的端口，使主机的任何一个应用程序都不使用这个端口。所以，当达到目的主机的时候，UDP模块就产生一个“端口不可到达”的错误，这样就能判断是否是到达目的地了。

Windows tracert参数如下

使用如下命令并用wireshark抓包

tracert 210.34.0.12
tracert xmu.edu.cn
tracert -4 xmu.edu.cn#强制使用IPV4

从上图（第一个命令）可以看出:tracert是通过借助TTL，发送一系列探测包，设置探测包的TTL初始值分别为1,2,3……，根据返回的超时通知（Time-to-live exceed）得知源地址和目的地址之间每一跳路由的信息。

从上面可以看到，发起tracert命令的主机每种TTL发一组ICMP探测包，每次发送3个，途径路由器会相应发送回TTLE ICMP超时通知，当收到收到目的主机发送回来的Echo(ping)reply包，便会停止发送ICMP探测

如上图取一个ICMP超时通知包，我们可以发现ICMP报文注明了类型，上面的TTL=252，而TTL最大是255，可知其传回来经过了3个路由器

于是可知tracert的工作原理如下:
①从源地址发出一个ICMP请求回显（ICMP Echo Request）数据包到目的地址，并将TTL设置为1
②到达路由器时，将TTL减1
③当TTL变为0时，包被丢弃，路由器向源地址发回一个ICMP超时通知（Time-to-live Exceeded），内含送IP包的源地址，IP包的所有内容及路由器的IP地址
④当源地址收到该ICMP包时，显示这一跳路由信息
⑤重复①～④，并每次设置TTL加1
⑥直至目标地址收到探测数据包，并返回ICMP回应答复（ICMP Echo Reply）
⑦当源地址收到ICMP Echo Reply包时停止tracert

下为以中转两个路由器为例的图示

任务3：抓取802.11数据报并分析

1°首先搭建环境抓取802.11协议包
由于自身笔记本性能太差，搭载不懂双系统，另外也想尝试使用树莓派（微型单片机电脑）搭载kali系统（系统装在32Gtf卡中）,
连接方式：通过笔记本开启wifi网络共享用网线直连树莓派再用ssh远程登录树莓派kali系统

利用putty ssh登录树莓派kali系统

开启xrdp服务用window下的mestc.exe远程登录桌面

Wifi服务被关掉

选择第一个接口,即可开始抓包

将其另存为pcapng数据包

将网卡监听模式关闭，否则CPU耗费过大而死机

2°分析802.11协议帧

帧类型	过滤器语法
Management frame	wlan.fc.type == 0
Control frame	wlan.fc.type == 1
Data frame	wlan.fc.type == 2
Association request	wlan.fc.type_subtype == 0x00
Association response	wlan.fc.type_subtype == 0x01
Reassociation request	wlan.fc.type_subtype == 0x02
Reassociation response	wlan.fc.type_subtype == 0x03
Probe request	wlan.fc.type_subtype == 0x04
Probe response	wlan.fc.type_subtype == 0x05
Beacon	wlan.fc.type_subtype == 0x08
Disassociate	wlan.fc.type_subtype == 0x0A
Authentication	wlan.fc.type_subtype == 0x0B
Deauthentication	wlan.fc.type_subtype == 0x0C
Action frame	wlan.fc.type_subtype == 0x0D
Block ACK requests	wlan.fc.type_subtype == 0x18
Block ACK	wlan.fc.type_subtype == 0x19
Power save poll	wlan.fc.type_subtype == 0x1A
Request to send	wlan.fc.type_subtype == 0x1B
Clear to send	wlan.fc.type_subtype == 0x1C
ACK	wlan.fc.type_subtype == 0x1D
Contention free period end	wlan.fc.type_subtype == 0x1E
NULL data	wlan.fc.type_subtype == 0x24
QoS data	wlan.fc.type_subtype == 0x28
Null QoS data	wlan.fc.type_subtype == 0x2C

效果如下图所示

802.11共有三种帧：控制帧、数据帧、管理帧，其作用如下

Management frame (管理帧)	作用
Association request/Association response	关联请求 / 关联响应，一旦STA找到网络并通过认证，就会发送Association Request，请求 AP 进行关联。AP以Association Response进行回应。如果AP接受该请求，将为该STA分配资源。
Reassociation request/Reassociation response	重关联请求 / 重关联响应，一旦STA找到网络并通过认证，就会发送Association Request，请求 AP 进行关联。AP以Association Response进行回应。如果AP接受该请求，将为该STA分配资源。
Probe request/Probe response	探测请求/探测响应，Probe request由STA发出，用于探测周围的BSS。如果指定了SSID，则只有SSID与之一致的BSS(准确来说是BSS内的AP)会通过Probe Response进行响应；如果未指定，则所有BSS都会进行响应。和Beacon Frame一样，Probe Response提供了BSS的基本信息。
Beacon	信标帧，一个提供服务的AP会定时发送Beacon Frame以告知BSS的存在，并提供了BSS的一些基本信息，如BSSID、SSID、Channel等。
Disassociate	解除关联，用来终结关联关系。收到Disassociation后，AP将释放先前为该STA分配的资源。
Authentication	认证，Authentication中，包含认证类型(Authentication Algorithm)，认证进度(Authentication SEQ)，认证状态(Status Code)。AP可以根据相关信息决定接受还是拒绝某个STA的加入，并同样通过Authentication进行回复。
Deauthentication	解除认证，用来终结认证关系。
Action frame	Action Frames are a type of management frame used to trigger an action in the cell.

Control frame（控制帧）	作用
Block ACK requests	Block ACK请求，同下。
Block ACK	The Block Ack mechanism improves channel efficiency by aggregating several acknowledgments into one frame.
Power save poll	省电-轮询，休眠的AP定期发送。
Request to send（RTS）	请求发送，表明A要向B发送若干数据，申请预约。目的是为了避免同时有多人向B发送帧，导致冲突。
Clear to send（CTS)	清除发送，收到Request To Send后，如果B同意该预约，则通过Clear To Send宣告其他人在一定时间内暂停向自己发送数据，避免冲突。
ACK	确认收到的数据帧，如果收到的数据帧校验出错，则不发送ACK，等待重传。
Contention free period end	无竞争周期结束，让STA脱离PCF模式，开始以DCF(基于竞争)模式。

Data frame（数据帧）	作用
NULL data	没有数据的空帧，但可以有其它的标记信息
QoS data	Qos Data，Data帧的 Qos 版本
Null QoS data	Null帧的 Qos 版本

任务4：探索Wireshark更丰富的功能

1°数据流追踪
如下图操作可以追踪TCP流

根据上图的ASCII显示数据，我们可以利用文件格式的文件头和文件尾找到对应的数据并将其提取成新文件。

2°协议分层统计
使用如下操作实现

上图统计通信流量中不同协议占用的百分比

3°网络节点和会话统计功能

下图为网络节点功能

下图为网络会话功能

实验小结

本次实验我通过使用Wireshark，对各种网络协议有了进一步的了解。实验中常常会遇到与课本所学知识有所出入的问题，例如所熟知的“ARP广播请求和单播回复”，但是在实验中便遇到了“明知故问”的ARP单播请求和陌生的ARP广播回复，但是在认真分析以及查阅相关资料，便了解到ARP请求并不是只能广播，ARP回复也可以广播。再比如Wireshark捕获到的数据帧有可能小于60字节。此外，我加深了对各个协议的结构，内容，作用的认识，理解了各种网络指令的工作原理与应用。此次实验收获颇多，今后会进一步学习使用Wireshark抓包，掌握更多的技巧与知识，在网络安全学习方面进行应用。