20253909 2024-2025-2 《网络攻防实践》实验三
20253909 2024-2025-2 《网络攻防实践》实验三
本文记录了网络攻防课程第三次作业的完整实现过程：使用 tcpdump 对访问 www.tianya.cn 过程进行嗅探分析、使用 Wireshark 对 TELNET 登录 BBS 过程进行嗅探与协议分析，以及对网络扫描数据包（listen.cap）进行取证分析。
目录
一、实验内容
本次实验围绕网络嗅探与协议分析展开，主要完成以下三项任务：
任务一：使用 tcpdump 对本机访问 www.tianya.cn 网站首页的过程进行嗅探，统计浏览器实际访问的 Web 服务器数量及其 IP 地址。
任务二：使用 Wireshark 对本机以 TELNET 方式登录 BBS 的过程进行嗅探与协议分析，获取目标服务器 IP 与端口、分析 TELNET 明文传输特性，并从数据包中还原登录凭据。
任务三：对给定的网络扫描数据包文件 listen.cap 进行取证分析，识别攻击主机与目标主机 IP、判断所使用的扫描工具与扫描方法、确定开放端口及攻击者操作系统信息。
二、实验过程
第一部分：使用 tcpdump 嗅探访问 www.tianya.cn 过程
步骤 1：确认本机 IP 地址
在 Kali Linux 上执行 ifconfig，确认本机网络接口 eth0 的 IP 地址为 192.168.200.8，子网掩码为 255.255.255.128，网卡 MAC 地址为 00:0c:29:83:85:26：
图1：执行 ifconfig 确认本机 IP 地址为 192.168.200.8，随后执行 tcpdump 监听命令
步骤 2：启动 tcpdump 进行嗅探
以 root 权限执行如下 tcpdump 命令，监听 eth0 接口上源地址为本机（192.168.200.8）、目标端口为 80 或 443、且带有 TCP SYN 标志位（tcp[13] & 2 != 0）的数据包，从而捕获所有由本机发起的 HTTP/HTTPS 新建连接请求：
sudo tcpdump -n -i eth0 src 192.168.200.8 and 'tcp port 80 or tcp port 443' and 'tcp[13] & 2 != 0'
各参数含义如下：
| 参数 | 含义 |
|---|---|
-n |
不进行 DNS 反向解析，直接显示 IP 地址（避免干扰） |
-i eth0 |
监听 eth0 接口 |
src 192.168.200.8 |
仅捕获源地址为本机的数据包 |
tcp port 80 or tcp port 443 |
仅捕获 HTTP（80）或 HTTPS（443）流量 |
tcp[13] & 2 != 0 |
仅捕获带有 SYN 标志的数据包（即新建连接请求） |
启动 tcpdump 后，在浏览器中打开 www.tianya.cn，等待页面完全加载后按 Ctrl+C 终止捕获。
步骤 3：在浏览器中访问 www.tianya.cn
在 Kali Linux 上的 Firefox 浏览器地址栏中输入 www.tianya.cn 并回车，等待天涯社区首页完全加载：
图2：在 Firefox 中访问 www.tianya.cn，天涯社区首页完整加载，同期 tcpdump 在后台持续捕获
步骤 4：分析 tcpdump 捕获结果
页面加载完成后，终止 tcpdump，共捕获到 321 个数据包（321 packets captured，0 packets dropped）。终端末尾输出如下：
图3：tcpdump 终止后显示共捕获 321 个数据包，0 丢包
对全部捕获记录中本机发出的 SYN 包（192.168.200.8.xxxxx > 目标IP.端口: Flags [S]）进行去重统计，提取所有不重复的目标 IP 地址，汇总如下：
| 序号 | Web 服务器 IP | 目标端口 | 连接次数 | 协议 | 序号 | Web 服务器 IP | 目标端口 | 连接次数 | 协议 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 34.160.144.191 | 443 | 2 | HTTPS | 22 | 153.3.237.72 | 443 | 4 | HTTPS |
| 2 | 151.101.89.91 | 443 | 6 | HTTPS | 23 | 101.72.203.38 | 443 | 1 | HTTPS |
| 3 | 34.107.243.93 | 443 | 3 | HTTPS | 24 | 121.29.103.75 | 80 | 1 | HTTP |
| 4 | 34.107.221.82 | 80 | 1 | HTTP | 25 | 59.110.122.164 | 443 | 2 | HTTPS |
| 5 | 116.136.159.35 | 443 | 16 | HTTPS | 26 | 125.39.155.25 | 443 | 3 | HTTPS |
| 6 | 61.48.83.207 | 80 | 5 | HTTP | 27 | 23.215.212.237 | 80 | 3 | HTTP |
| 7 | 61.240.129.37 | 443 | 2 | HTTPS | 28 | 111.206.208.190 | 443 | 6 | HTTPS |
| 8 | 125.37.133.138 | 443 | 2 | HTTPS | 29 | 123.117.132.38 | 443 | 2 | HTTPS |
| 9 | 36.110.220.120 | 443 | 8 | HTTPS | 30 | 110.242.68.129 | 443 | 6 | HTTPS |
| 10 | 140.207.198.246 | 80 | 5 | HTTP | 31 | 112.65.69.211 | 443 | 4 | HTTPS |
| 11 | 202.108.29.170 | 443 | 2 | HTTPS | 32 | 150.138.110.35 | 443 | 1 | HTTPS |
| 12 | 220.197.30.48 | 443 | 8 | HTTPS | 33 | 115.25.216.36 | 443 | 1 | HTTPS |
| 13 | 220.197.30.54 | 443 | 4 | HTTPS | 34 | 202.108.29.171 | 443 | 4 | HTTPS |
| 14 | 220.197.30.52 | 443 | 3 | HTTPS | 35 | 140.207.202.182 | 443 | 4 | HTTPS |
| 15 | 220.197.35.208 | 443 | 8 | HTTPS | 36 | 61.240.129.34 | 443 | 10 | HTTPS |
| 16 | 220.197.35.192 | 443 | 3 | HTTPS | 37 | 61.182.142.22 | 443 | 1 | HTTPS |
| 17 | 121.29.103.82 | 443 | 8 | HTTPS | 38 | 27.221.68.35 | 443 | 6 | HTTPS |
| 18 | 60.6.1.220 | 443 | 2 | HTTPS | 39 | 39.91.132.43 | 443 | 4 | HTTPS |
| 19 | 125.39.27.211 | 443 | 6 | HTTPS | 40 | 112.65.69.195 | 443 | 4 | HTTPS |
| 20 | 157.119.252.118 | 443 | 3 | HTTPS | 41 | 60.221.18.41 | 443 | 1 | HTTPS |
| 21 | 23.11.39.161 | 80 | 5 | HTTP | 42 | 60.9.5.124 | 80 | 1 | HTTP |
回答问题——访问 www.tianya.cn 时浏览器访问了多少个 Web 服务器、IP 地址是什么：在本次嗅探中，浏览器共向 42 个不同的 Web 服务器发起了连接请求，IP 地址如上表所示。其中绝大多数使用 HTTPS（443 端口），少数使用 HTTP（80 端口）。IP 地址涵盖国内 CDN 节点以及境外 CDN 节点，说明天涯社区首页通过大量 CDN 节点分散加载各类静态资源（图片、脚本、广告等），以提升访问速度和可靠性。
第二部分：使用 Wireshark 嗅探 TELNET 登录 BBS 过程
步骤 1：确认抓包环境并选择正确的网络接口
本次实验中，Kali Linux 运行在 VMware 虚拟机中，网络连接方式设置为 VMnet8（NAT 模式）。由于虚拟机通过 NAT 与外部网络通信，因此在宿主机上使用 Wireshark 抓包时，必须选择对应的 VMware Network Adapter VMnet8 作为监听接口，才能正确捕获 Kali 发起的 TELNET 会话数据。
图4：在 VMware 中将 Kali 虚拟机的网络连接方式设置为 VMnet8（NAT 模式）
图5：在 Wireshark 中选择 VMware Network Adapter VMnet8 作为抓包接口
如果抓包时选错了接口，例如选择宿主机的物理网卡而不是 VMnet8，那么就很可能无法完整看到虚拟机与外部 BBS 服务器之间的 TELNET 通信过程。
步骤 2：在 Kali 中以 TELNET 方式连接 BBS
在 Kali 终端中执行如下命令连接北邮人论坛 BBS：
luit -encoding gbk telnet bbs.byr.cn
其中，telnet bbs.byr.cn 用于向目标 BBS 发起 TELNET 连接；由于该站点字符界面采用 GBK 编码，为避免中文乱码，这里使用 luit -encoding gbk 对终端字符集进行转换。
图6：在 Kali 终端中执行
luit -encoding gbk telnet bbs.byr.cn 发起连接
连接建立后，可以看到 BBS 的欢迎界面以及登录提示，说明 TELNET 会话已经成功建立：
图7：成功连接北邮人论坛，终端显示登录界面与"请输入代号"提示
步骤 3：在 Wireshark 中过滤 TELNET 流量并确定目标服务器
在宿主机 Wireshark 启动抓包后，回到 Kali 执行上述 TELNET 命令并进行登录操作。随后在 Wireshark 顶部的显示过滤器中输入：
telnet
即可快速筛选出本次实验相关的 TELNET 数据包。通过观察抓到的会话可以发现，数据包的源地址为本机 Kali 的 NAT 地址 192.168.200.8，目标地址为远程主机 211.68.71.66，且 TCP 目标端口为 23，这正是 TELNET 的默认服务端口。
图8：在 Wireshark 中过滤
telnet 流量，可见目标主机为 211.68.71.66，目标端口为 23
| 项目 | 分析结果 |
|---|---|
| 本机 IP | 192.168.200.8 |
| BBS 服务器 IP | 211.68.71.66 |
| 服务端口 | 23 |
| 协议 | TELNET |
从图中还可以看到，Wireshark 在 Info 栏中直接解析出了多个 TELNET 选项协商字段，如 Will Echo、Do Terminal Type、Negotiate About Window Size 等，这表明该会话在正式传输用户数据前，先进行了 TELNET 选项协商。
回答问题一——你所登录的 BBS 服务器的 IP 地址与端口各是什么：从 Wireshark 过滤后的 TELNET 会话可知，本次登录的 BBS 服务器 IP 地址为 211.68.71.66，服务端口为 23。其中，211.68.71.66 出现在数据包的 Destination 字段中，而 23 出现在 TCP 目标端口字段中。
步骤 4：分析 TELNET 协议如何传送用户名与登录口令
TELNET 是一种典型的远程终端协议，工作在 TCP 之上，默认使用 23 端口。其通信过程通常可以分为两个阶段：
第一阶段是连接建立与选项协商阶段。 客户端与服务器先完成 TCP 三次握手，随后通过 IAC、DO、WILL 等控制命令协商终端回显、终端类型、窗口大小等参数。
第二阶段是交互数据传输阶段。 进入该阶段后，客户端键入的用户名、口令以及后续命令，都会以明文形式直接封装在 TCP 负载中发送给服务器。也就是说，TELNET 并不会像 SSH 那样对认证信息进行加密保护。
需要注意的是，密码不回显不等于密码被加密。在很多登录场景中，终端不会把口令显示在屏幕上，但这些字符仍然会从客户端发往服务器，并且仍可在抓包结果中被还原出来。这也是 TELNET 协议最大的一项安全缺陷。
回答问题二——TELNET 协议是如何向服务器传送你输入的用户名及登录口令：TELNET 在完成 TCP 连接和选项协商之后，会将用户输入的字符以明文方式封装到 TCP 负载中发送给服务器。用户名如此，口令也是如此。虽然口令在终端界面上一般不显示，但它依旧会以未加密的方式在网络中传输，因此只要对会话进行抓包，就可能被第三方还原出来。
步骤 5：利用"追踪 TCP 流"还原 TELNET 会话内容
为了更直观地查看整个登录会话，可以在 Wireshark 中选中任意一个属于该 TELNET 会话的数据包，右键选择 "追踪流" → "TCP Stream"，即可让 Wireshark 按应用层顺序重组整个 TCP 会话内容。
图9：右击 TELNET 数据包，选择"追踪流（TCP Stream）"查看完整会话内容
打开 TCP 流后，Wireshark 会将客户端与服务器之间的应用层数据按时间顺序还原出来。由于 BBS 是基于字符终端的全屏界面程序，因此流中会混杂大量 ANSI 控制字符和颜色转义序列，但这并不影响我们定位用户名和口令。
图10：Wireshark 追踪 TCP 流后，可还原整个 TELNET 会话内容
在实际分析时，可以采用如下思路提取账号与口令：
先在 TCP 流窗口中保持 ASCII 显示方式，寻找服务器出现的登录提示，如"请输入代号""login:"或"Password:"。紧接在这些提示之后，由客户端发往服务器的数据就是用户实际输入的内容。由于 TELNET 为明文传输，因此用户名和口令都能在对应的数据负载中被直接看到。
如果 TCP 流中混入了较多界面控制字符，导致阅读不够直观，还可以进一步使用更精确的显示过滤器，仅保留客户端发往服务器且真正携带数据的报文：
ip.src == 192.168.200.8 && ip.dst == 211.68.71.66 && tcp.port == 23 && tcp.len > 0
此时再逐个查看这些数据包的 Data 字段，就可以更清楚地看到客户端发送的用户名、口令以及回车换行等内容。
回答问题三——如何利用 Wireshark 分析嗅探的数据包，并从中获取你的用户名及登录口令：具体方法是：先使用 telnet 或 tcp.port == 23 过滤出相关会话；然后根据源地址和目标地址锁定本机与 BBS 服务器之间的那条连接；接着右击任意一个会话数据包，选择 "追踪流 → TCP Stream"，还原完整应用层数据；最后在登录提示之后，查看客户端方向发送的数据即可。用户名通常出现在"请输入代号"或"login:"提示之后，口令通常出现在"Password:"或口令输入提示之后。由于 TELNET 为明文协议，这些内容可以直接从报文载荷中恢复。
若抓包覆盖了完整的登录过程，则可以在此处写出恢复结果：
本次抓包恢复得到的用户名为：【此处填写实际抓到的用户名】
本次抓包恢复得到的登录口令为：【此处填写实际抓到的口令】
通过本次实验可以直观看出，TELNET 协议虽然实现简单、便于教学演示，但由于其认证信息和交互内容都以明文方式在网络中传输，安全性极差，因此在真实网络环境中早已被更安全的 SSH 所取代。
第三部分：取证分析实践——解码网络扫描器（listen.cap）
课程材料中将该文件写作 listen.cap，而我在实际分析环境中拿到的文件名为 listen.pcap。两者对应的是同一份网络扫描取证数据文件。下文统一按照我本机中的实际文件名 listen.pcap 记录分析过程。
步骤 1：准备分析文件与辅助工具
本次实验采用离线取证分析的方式完成，即不直接抓取实时流量，而是对已给出的扫描数据包文件 listen.pcap 进行回放与分析。为便于后续使用 Snort 和 p0f 等工具，我先将该文件放入 /etc/snort/ 目录中，并补充安装 p0f，用于后续对攻击主机进行被动操作系统指纹识别。
图11：将
listen.pcap 放入 /etc/snort/ 目录，准备进行离线分析
图12：安装
p0f 工具，为后续被动识别攻击主机操作系统做准备
步骤 2：使用 Snort 对 listen.pcap 做离线初检
为了先从整体上把握数据包文件的规模与内容，我首先使用 Snort 对 listen.pcap 进行离线读取分析。执行命令如下：
sudo snort -c /etc/snort/snort.lua -r /etc/snort/listen.pcap -A alert_full
其中，-r 表示读取离线 pcap 文件，-A alert_full 表示按较详细的格式输出告警信息。该命令的目的并不是直接给出全部结论，而是先确认数据文件是否可以被正常解析，并对其包含的协议类型和总体流量规模形成初步认识。
图13：使用 Snort 对
listen.pcap 进行离线读取分析
图14：Snort 完成初步离线解析，可见共分析了
135580 个数据包
从输出结果可以看到，Snort 以 read-file 方式成功读取了该文件，并给出了较完整的统计信息。其中显示共接收到并分析了 135580 个数据包，绝大多数都是 TCP 报文，这与"端口扫描"场景的流量特征高度一致。说明该样本可以被正常解析，后续可以进一步借助 Wireshark、tshark 与 p0f 对关键字段做更精确的筛选和验证。
步骤 3：在 Wireshark 中整体观察流量并初步锁定通信双方
接下来，我使用 Wireshark 直接打开 listen.pcap 文件，对其进行可视化分析。刚打开数据包时，从整体视图就可以看到，大量报文集中发生在少数几台主机之间，并且连续出现了成批的 [SYN]、[SYN, ACK] 以及 [RST, ACK] 报文，这已经非常接近典型的TCP 端口扫描形态。
图15：在 Wireshark 中打开
listen.pcap 后，可以整体观察到大量针对单一主机的 TCP 探测流量
为了进一步确认目标主机，我先在 Wireshark 顶部输入显示过滤器：
arp
过滤后可以看到，抓包中出现了多次针对 172.31.4.188 的 ARP 查询与应答，例如"Who has 172.31.4.188"以及"172.31.4.188 is at ..."。这说明 172.31.4.188 是局域网中一个被频繁访问、并且确实存在的主机地址。虽然 ARP 记录中还出现了 172.31.4.2、172.31.4.1 等地址，但这些只是同一网段中的普通地址解析行为，真正的扫描方向还需要结合 TCP SYN 报文来判断。
图16：使用
arp 过滤器观察地址解析过程，可见 172.31.4.188 被反复查询
步骤 4：过滤纯 SYN 报文，识别攻击主机与扫描范围
在端口扫描分析中，最关键的一步是找出谁在主动探测端口。因此，我在 Wireshark 中进一步输入如下过滤器，仅保留带 SYN 标志但不带 ACK 标志的 TCP 报文，也就是扫描发起方发送出的初始探测包：
tcp.flags.syn == 1 and tcp.flags.ack == 0
过滤后可以看到，这类报文的主要方向固定为：
172.31.4.178→172.31.4.188
同时，目标端口在不断快速变化，例如 3306、139、995、23、80、110、8080 等多个端口被依次探测。这表明 172.31.4.178 正在主动向 172.31.4.188 发起大量 TCP 连接探测。因此可以判定：
- 攻击主机 IP 地址为：
172.31.4.178 - 被扫描目标主机 IP 地址为：
172.31.4.188
图17：过滤纯 SYN 报文后，可见
172.31.4.178 正在对 172.31.4.188 的多个端口发起探测
为了更直观地提取这些扫描报文中的关键信息，我又在终端中使用 tshark 对该 pcap 文件进行字段级提取：
tshark -r listen.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" \
-T fields -e ip.src -e ip.dst -e tcp.dstport | head -50
输出结果显示，源地址始终为 172.31.4.178，目标地址始终为 172.31.4.188，而目标端口不断变化，进一步印证了这是由攻击主机对目标主机发起的一次批量端口扫描。
图18：使用
tshark 提取纯 SYN 报文的源/目的地址及目标端口字段
从 Wireshark 状态栏还可以看到，纯 SYN 报文数量高达 67657 个，数量级已经非常接近一次全 TCP 端口范围的大规模扫描。因此，本次攻击并不是只针对少数几个常见端口，而是对目标主机发起了一个范围极广的 TCP 端口探测过程。
回答问题一——攻击主机的 IP 地址是什么：攻击主机 IP 地址为 172.31.4.178。依据是：在纯 SYN 报文过滤结果中，绝大多数主动探测流量均由 172.31.4.178 发往 172.31.4.188。
回答问题二——网络扫描的目标 IP 地址是什么：目标主机 IP 地址为 172.31.4.188。依据是：ARP 解析与 TCP 扫描流量都集中指向该地址，并且它对多个探测端口返回了不同类型的 TCP 响应。
步骤 5：过滤 SYN/ACK 响应，判断目标主机的开放端口
在 TCP SYN 扫描中，判断开放端口的关键依据是：开放端口会返回 SYN/ACK 报文，而关闭端口通常会返回 RST/ACK，或者在某些情况下不作响应。因此，我继续在 Wireshark 中使用如下过滤器，专门筛选由目标主机返回的 SYN/ACK 报文：
tcp.flags.syn == 1 and tcp.flags.ack == 1
过滤后可以看到，172.31.4.188 会从若干端口向 172.31.4.178 返回 [SYN, ACK]，例如 3306、139、23、80 等。这说明这些端口在目标主机上处于监听状态，可以被视为开放端口。
图19：过滤 SYN/ACK 报文后，可见目标主机对部分端口返回开放响应
为了避免人工逐条统计产生遗漏，我进一步使用 tshark 将满足条件的报文源端口提取出来，并做去重统计：
tshark -r listen.pcap \
-Y "ip.src==172.31.4.188 && ip.dst==172.31.4.178 && tcp.flags.syn==1 && tcp.flags.ack==1" \
-T fields -e tcp.srcport | sort -n | uniq
最终得到的开放端口列表为：
21
22
23
25
53
80
139
445
3306
3632
5432
8009
8180
图20：使用
tshark 对 SYN/ACK 报文源端口去重，得到目标主机开放端口列表
将这些开放端口按常见服务含义整理如下：
| 端口 | 可能对应服务 | 端口 | 可能对应服务 |
|---|---|---|---|
| 21 | FTP | 445 | SMB / Microsoft-DS |
| 22 | SSH | 3306 | MySQL |
| 23 | TELNET | 3632 | distccd |
| 25 | SMTP | 5432 | PostgreSQL |
| 53 | DNS | 8009 | AJP13（Tomcat） |
| 80 | HTTP | 8180 | HTTP（应用服务端口） |
| 139 | NetBIOS Session Service | — | — |
回答问题五——在蜜罐主机上哪些端口被发现是开放的：本次分析中，共发现目标主机开放了 13 个端口，分别为：21, 22, 23, 25, 53, 80, 139, 445, 3306, 3632, 5432, 8009, 8180。
步骤 6：判断扫描工具与扫描方法
在整体分析过程中，我重点关注了以下几个特征：
- 攻击主机持续向目标主机大量端口发送纯 SYN 探测包；
- 目标主机对开放端口返回 SYN/ACK；
- 抓包中可以看到扫描方并没有完成完整的 TCP 三次握手，而是在获得开放端口响应后立即复位或中止连接；
- 扫描端口数量极大，且端口分布广泛，明显不是手工逐个连接测试。
这些特征完全符合TCP SYN 半开扫描（Half-open Scan）的行为模式，也就是通常所说的 SYN Scan。这种扫描方法的工作原理是：
扫描器先向目标端口发送一个 SYN 报文。 如果端口开放，目标主机会回复 SYN/ACK；扫描器据此判定该端口为开放，但通常不会继续发送 ACK 去完成握手，而是直接发送 RST 或中止会话。这样既能快速得到端口状态，又能避免真正建立完整连接，因此其隐蔽性和效率都高于传统的完整 TCP Connect 扫描。如果目标端口关闭，目标主机通常会返回 RST/ACK；如果端口被防火墙过滤，则可能直接无响应或返回 ICMP 不可达报文。
结合其报文行为、扫描规模以及 Linux 环境下最常见的扫描实现方式，可以判断本次案例中所使用的扫描工具最符合 Nmap 的特征，并且扫描方式对应于 nmap -sS 类型的 TCP SYN 半开扫描。进一步结合纯 SYN 报文数量和端口分布情况，可以认为该扫描在效果上接近一次对目标主机全 TCP 端口范围的扫描，也就是类似于：
nmap -sS -p- 172.31.4.188
这里之所以写"类似于"或"相当于"，是因为从现有数据包中可以准确还原扫描方法和扫描范围特征，但不能仅凭这份 pcap 就百分之百写出攻击者当时在终端输入的完整命令行参数。不过，就实验结论而言，将其判断为 Nmap 发起的 TCP SYN 半开扫描是充分且合理的。
回答问题三——本次案例中是使用了哪个扫描工具发起这些端口扫描，你是如何确定的：综合判断，本次案例最符合 Nmap 的扫描特征。判断依据包括：大批量纯 SYN 报文、开放端口返回 SYN/ACK、扫描器并不完成完整握手、扫描范围极广且节奏很快，这与 Nmap 常见的 -sS SYN 半开扫描行为高度一致。
回答问题四——攻击者使用了哪种扫描方法，扫描的目标端口是什么，并描述其工作原理：攻击者采用的是 TCP SYN 半开扫描。从报文数量与端口变化范围看，其扫描范围接近目标主机的全 TCP 端口范围。其工作原理是：攻击者向目标端口发送 SYN，如果端口开放，目标返回 SYN/ACK；扫描器据此判定端口开放，但不会继续完成握手，而是直接复位或中止连接；如果端口关闭，则一般返回 RST/ACK；如果端口被过滤，则无响应或返回 ICMP 不可达。这样既能快速枚举端口，又不真正建立完整连接，隐蔽性和效率均优于完整 TCP Connect 扫描。
步骤 7：使用 p0f 对攻击主机进行被动操作系统识别
最后，为了识别攻击主机的操作系统，我使用 p0f 对 listen.pcap 进行被动指纹分析。执行命令如下：
p0f -r listen.pcap
图21：使用
p0f -r listen.pcap 对攻击主机进行被动指纹识别
p0f 会根据 TCP SYN 报文中的 MSS、窗口大小、时间戳、SACK 选项等特征，对通信发起方进行操作系统指纹匹配。分析结果显示，在 172.31.4.178 发往 172.31.4.188 的 SYN 报文中，客户端操作系统被识别为：Linux 2.6.x。
图22：
p0f 输出结果显示攻击主机操作系统为 Linux 2.6.x
回答问题六——攻击主机的操作系统是什么：根据 p0f 对 TCP SYN 报文的被动指纹分析结果，攻击主机操作系统为 Linux 2.6.x。
问题回答与分析结论
结合以上分析过程，可以将本次 listen.pcap 的取证结果总结如下：
| 问题 | 分析结果 |
|---|---|
| 攻击主机的 IP 地址是什么？ | 172.31.4.178 |
| 网络扫描的目标 IP 地址是什么？ | 172.31.4.188 |
| 使用了哪个扫描工具？ | 综合报文行为判断为 Nmap |
| 使用了哪种扫描方法？ | TCP SYN 半开扫描（-sS 特征） |
| 扫描的目标端口是什么？ | 扫描范围极广，接近全 TCP 端口范围；从报文数量看属于大规模端口扫描 |
| 蜜罐主机上哪些端口被发现是开放的？ | 21, 22, 23, 25, 53, 80, 139, 445, 3306, 3632, 5432, 8009, 8180 |
| 攻击主机的操作系统是什么？ | Linux 2.6.x |
三、学习中遇到的问题及解决
-
问题 1：安装 Snort 时镜像源连接失败，导致无法继续实验。
-
问题 1 解决方案：在最初阶段执行
apt install snort时，终端提示部分镜像站点无法连接，出现 "connect (101: 网络不可达)" 报错。经过排查，问题主要出在当前环境对某些镜像源的 IPv6 连接不可达，而apt在获取软件包时优先尝试了 IPv6，因此导致下载失败。为此在命令中显式加入Acquire::ForceIPv4=true选项，强制apt改用 IPv4 方式更新与安装，问题得以解决：
图23：最初安装
snort 时，由于镜像站连接失败导致安装中断
sudo apt-get -o Acquire::ForceIPv4=true update
sudo apt-get -o Acquire::ForceIPv4=true install snort
图24：通过强制
apt 使用 IPv4，成功完成 snort 安装
这一问题让我意识到，实验环境中"软件装不上"往往并不是工具本身的问题，而可能是网络协议栈、镜像源连通性或系统配置造成的。
-
问题 2：
listen.pcap中数据包数量过多（共 135580 个），人工逐条统计效率很低，容易产生遗漏。 -
问题 2 解决方案：采用"Wireshark 做可视化确认，tshark 做字段提取和去重统计"的办法。先在 Wireshark 中通过显示过滤器确认分析思路，再在命令行中用
tshark批量提取关键字段，并配合sort -n | uniq直接得到去重后的结果。例如统计开放端口时，使用如下命令，原本需要人工反复核对的统计工作被自动化完成，既提高了效率，也提升了结论的准确性：
tshark -r listen.pcap \
-Y "ip.src==172.31.4.188 && ip.dst==172.31.4.178 && tcp.flags.syn==1 && tcp.flags.ack==1" \
-T fields -e tcp.srcport | sort -n | uniq
-
问题 3：仅看 ARP 记录时，容易误判真正的扫描主机。
-
问题 3 解决方案：在最开始使用
arp过滤器观察数据包时，抓包中不仅出现了172.31.4.178，还出现了172.31.4.2、172.31.4.1等多个地址，容易误把"谁在查询目标主机地址"当成"谁在真正发起端口扫描"。后来意识到，ARP 只能帮助确定某个主机地址在局域网中真实存在、并且被频繁访问，却不能单独用来判断端口扫描的发起方向。真正锁定攻击主机，必须回到 TCP 层，改用如下过滤器去看谁在持续发送纯 SYN 探测包，这样扫描方向就非常清楚了：
tcp.flags.syn == 1 and tcp.flags.ack == 0
通过这个问题，我也更加明确了一个取证分析原则：链路层信息适合用来辅助定位，但真正的攻击行为判断，必须结合更高层的协议语义。
四、学习感悟、思考等
通过这次对 listen.pcap 的取证分析，我最大的体会是：网络安全分析并不是"看见一个可疑包就立刻下结论"，而是要一步一步建立证据链。 本次实验中，我先用 Snort 做整体初检，再用 Wireshark 观察总体流量形态，然后通过显示过滤器锁定纯 SYN 与 SYN/ACK 报文，最后再借助 tshark 做统计、用 p0f 做操作系统识别。整个过程并不是某一个工具单独完成的，而是多个工具相互配合、彼此验证，最终才得到较可靠的结论。
第二个体会是，我对 TCP SYN 半开扫描 的理解变得更加具体了。以前在书上看到"开放端口返回 SYN/ACK，关闭端口返回 RST/ACK，扫描器不完成握手"时，更多停留在文字层面；而这次是直接在真实的数据包中把这个过程完整地看了一遍。尤其是在 Wireshark 中看到大量连续的 SYN、SYN/ACK 以及 RST/ACK 交替出现时，我对端口扫描的工作原理、效率优势和隐蔽性来源都有了更直观的认识。
第三个体会是，命令行工具在大规模数据分析中的价值非常高。如果只依赖图形界面手动查看十几万条数据包，分析工作会非常低效；而 tshark 结合 sort、uniq 等文本处理工具后，就能快速得到开放端口列表、通信方向等关键信息。这让我认识到，在网络攻防实践中，图形界面更适合"看"，而命令行工具更适合"批量处理"和"精确统计"，两者缺一不可。
最后，从安全防护角度来看，这次实验也让我更加深刻地意识到：主机暴露的服务越多，潜在攻击面就越大。 在本次样本中，目标主机开放了 FTP、TELNET、MySQL、PostgreSQL、SMB、AJP 等多个端口，这意味着攻击者一旦完成扫描，就可以继续针对不同服务版本开展漏洞利用、口令爆破或弱配置攻击。因此，在真实系统中，必须尽量减少不必要的开放端口，关闭无用服务，并对外暴露的服务做好访问控制和安全加固。只有这样，才能在攻击者进入真正利用阶段之前，就尽可能压缩其攻击空间。
参考资料
- tcpdump 官方手册
- Wireshark 官方文档
- Nmap 官方文档
- p0f 被动指纹识别工具说明
- Snort 3 官方文档
- 诸葛建伟. 《网络攻防实践》电子教材第4章[M]. 清华大学, 2010.
- 诸葛建伟. 课程4讲义：网络嗅探技术[R]. The Artemis Project/狩猎女神项目组, 2010.
浙公网安备 33010602011771号