Wireshark协议分析
常见协议包
ARP协议
ICMP协议
TCP协议
HTTP协议
UDP协议
（OICQ及DNS都是基于UDP的传输层上的协议，因此在过滤器中输入UDP会出来OICQ和DNS两种协议）
DNS协议
（客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可，不用经过三次握手。这样DNS服务器负载更低，响应更快。理论上说。客户端也可以指向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候仅支持UDP查询包）
常用协议分析
协议分析时通常关闭混淆模式，避免一些干扰数据包的存在
ARP协议
1 | 地址解析协议（Address Resolution Protocol）是一个通过解析网络层地址来找寻数据链路层地址的网络传输协议，它在IPv4中极其重要。ARP是通过网络地址来定位MAC地址的（将IP地址解析为MAC地址）。 |
产生ARP数据包
开始抓包——过滤ARP
使用nmap来基于ARP协议进行扫描
1 | nmap -sn (Gateway) |
扫描结果
Boardcast为第一个包：kali（VM虚拟机）发送广播包“who has 192.168.6.2? Tell 192.168.6.128”
这个包为请求数据包
这个包为回应数据包
（请求和回应的源MAC地址和目标MAC地址正好互换）
ARP数据包分析：
| 项 | 含义 |
|---|---|
| Address Resolution Protocol (request) | 说明这是一个请求数据包 |
| Hardware type | 硬件类型（链路层协议）（Ethernet为以太网协议） |
| Protocol type | 协议类型（网络层协议） |
| Hardware size | 硬件地址长度（MAC地址长度）（单位：byte） |
| Protocol size | 协议地址长度（IP地址长度）（单位：byte） |
| Opcode | 操作码（标志ARP数据包类型）（1为request，2为reply） |
| Sender MAC address | 源MAC地址 |
| Sender IP address | 源IP地址 |
| Target MAC address | 目标MAC地址（00:00:00:00为未知） |
| Target IP address | 目标IP地址 |
ICMP协议
开始抓包——过滤ICMP
使用ping来产生ICMP的数据包
（别问为啥是这个网址，教程给的就是这个）
扫描结果
ICMP和ARP类似，也是两个数据包，一个请求一个回应（Destination栏会自动将网站解析为IP地址）
请求包
回应包
ICMP数据包分析：
| 项 | 含义 |
|---|---|
| Type | 类型（8为request请求包，0对应reply响应包即回显应答报文） |
| Checksum | 校验和（数据包完整性校验） |
| Checksum Status | 校验状态 |
| Identifier (BE) | |
| Identifier (LE) | |
| Sequence number (BE) | |
| Sequence number (LE) | |
| Response frame（请求包中） | 反应响应包在第几帧（响应帧的序列号） |
| Request frame（响应包中） | 反应请求包在第几帧（请求帧的序列号） |
| Response time | 响应时间 |
| Data | 填充数据 |
其中中间四字段（identifier和Sequence number在请求和响应包中是一样的，不变）
工作过程：
本机发送一个 ICMP Echo Request的包
接受方返回一个ICMP Echo Reply， 包含了接受到的数据拷贝和一些其他指令
TCP协议
TCP协议面向连接——三次握手，四次挥手，可靠传输，流量控制，多路复用
| 基于TCP的应用层协议 | 全称 | 默认端口 |
|---|---|---|
| HTTP | HyperText Transfer Protocol（超文本传输协议） | 80 |
| HTTPS | Hyper Text Transfer Protocol over SecureSocket Layer（超文本传输安全协议） | 443 |
| FTP | File Transfer Protocol (文件传输协议) | 20用于传输数据，21用于传输控制信息 |
| SSH | Secure Shell | 22 |
| SMTP | Simple Mail Transfer Protocol (简单邮件传输协议) | 25 |
| TELNET | Teletype over the Network (网络电传) | 23 |
开始抓包——过滤tcp
模拟tcp会话建立：通过Xshell远程连接Kali Linux就会捕获到完整的TCP3次握手的连接
（没装没配置Xshell，不用kali了，用教程视频截图了）
三次握手发送[SYN] [SYN, ACK] [ACK]三个数据包
第一次握手物理机发送[SYN]数据包——源IP（物理机）通过Xshell连接到Kali（虚拟机）——物理机打开一个随机高位端口连接虚拟机的22端口，发送[SYN]连接请求
第二次握手Kali（虚拟机）发送[SYN, ACK]数据包——Kali接受连接请求后同意连接，发送[ACK]，同时发送一个[SYN]，请求物理机同意连接随机高位端口
第三次握手发送物理机[ACK]——物理机同意Kali连接此端口——三次握手成功
以下数据包来源：BUUCTF——流量中的线索
第一次握手：
第二次握手：
第三次握手：
流量图
流量图中可以清晰地看到三次握手（最上面那三个）
各项含义
| 项 | 含义 |
|---|---|
| Source Port | 源端口 |
| Destination Port | 目标端口 |
| Sequence number | 序列号 （第三个数据包中 Seq=1 等于上一帧的确认序列号） |
| Acknowledgement number | 确认序列号 （第三个数据包中 ACK=1 确认序号1，上一帧的序号+1） |
| Header Length | 数据包头部长度 |
| Flags | 标志位：标志发送的是什么类型的数据包 …. ..1.=Syn:set表示建立连接 …1 ….=Acknowledgment:set表示确认序列号有效 |
| TCP FLags: · · · · · · · A · · · · | A=ACK |
| Window size value | 窗口大小（流量控制） 第一次握手中表示源能接收的最大流量 |
| Checksum | 校验和（检测数据包完整性） |
| This is an ACK to the segment in frame （仅在低第二、三次握手中出现） |
帧序列，同ICMP协议 |
四次挥手
数据包来源：BUUCTF——wireshark
第一次挥手
服务端（图中115.231.236.116为服务端，上面的三次握手与“流量中的线索”一题中的三次握手类似，不再放图）发送一个[FIN, ACK]表示自己没有数据要发送了，想要断开连接，并进入FIN_Wait_1状态（等待确认）
第二次挥手
客户端收到FIN后，知道不会再有数据从服务端传来，发送ACK进行确认，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），客户端进入CLOSE_WAIT状态
第三次挥手
客户端发送[FIN, ACK]给服务端，表示自己没有数据要发送，客户端进入LAST_ACK状态，然后直接断开TCP会话的连接，释放相应的资源
第四次挥手
服务端收到了客户端的FIN信令后，进入TIMED_WAIT状态，并发送ACK确认消息。服务端在TIME_WAIT状态下等待一段时间，没有数据到来，就认为对面已经收到了自己发送的ACK并确认关闭进入了CLOSE状态，自己也断开了TCP连接，释放所有资源。当客户端收到服务端的ACK回应后，会进入CLOSE状态并关闭本端的会话接口，释放相应资源
HTTP协议
HTTP是TCP的上层协议，所以过滤TCP的数据会包含HTTP协议的数据包
因此抓包仍然以tcp为过滤器
使用
1 | curl -I baidu.com |
抓取HTTP数据包（得到百度头部信息）
curl是一个在命令行下工作的文件传输工具，这里用来发送http请求
-I 大写的 i 表示仅返回头部信息
抓包结果如下
包含TCP三次握手，四次挥手以及HTTP部分（第四个和第六个）
整个过程：
发送HTTP的HEAD请求（第四个）
服务端收到后返回[ACK]进行确认（第五个）
确认完成后服务端将头部信息返回给客户端（200 OK表示页面正常）
客户端收到服务端返回的头部信息后，向服务端发送[ACK]表示确认收到信息
然后客户端发送[FIN, ACK]表示无数据传输了，请求关闭（后接TCP四次挥手）
可以通过追踪流——HTTP流来追踪整个过程
红色为客户端请求，蓝色为服务端回应