网络安全对抗能力实践 · 课程实验报告
实验名称：攻防对抗环境搭建
| 项目 | 内容 | 项目 | 内容 |
|---|---|---|---|
| 学院 | 网络与信息安全学院 | 姓名 | xxx |
| 班级 | xxxxxxx | 学号 | xxxxxx |
| 实验日期 | 2026 年 9 月 17 日 |
一、实验目的
- 学习和了解 Linux Ubuntu 操作系统；
- 掌握 Linux 基本命令；
- 掌握 VMware 三种网络模式（桥接、NAT、仅主机）的原理与区别；
- 了解基本的网络攻防对抗技战术，为后续渗透测试实验建立可复现的靶场环境。
二、实验所用仪器（实验环境）
| 项目 | 配置说明 |
|---|---|
| 宿主机 | Windows，16 逻辑核心，31.3 GB 内存，C 盘可用 107 GB |
| 虚拟化平台 | VMware Workstation 25.0.1（虚拟硬件版本 22） |
| 攻击机 | Kali Linux 2026.1（4 vCPU / 4 GB 内存 / 20 GB 磁盘） |
| 跳板机 | Ubuntu 24.04.3 LTS（noble，2 vCPU / 4 GB 内存 / 10 GB 磁盘） |
| 靶机 | Ubuntu 24.04.3 LTS（noble，4 vCPU / 4 GB 内存 / 10 GB 磁盘） |
| 虚拟网络 | VMnet8（NAT，192.168.116.0/24）、VMnet1（仅主机，192.168.113.0/24） |
| 软件源 | 清华大学开源软件镜像站 https://mirrors.tuna.tsinghua.edu.cn/ubuntu |
| 客户机工具 | open-vm-tools 2:13.0.10（升级后两台 Ubuntu 均为该版本） |
三、实验基本原理及步骤
3.1 VMware 三种网络模式原理
| 模式 | 原理 | 连通性特点 |
|---|---|---|
| 桥接 Bridged | 虚拟机经 VMnet0 直接桥接到物理网卡，与宿主机同处物理网段，独立获得 IP | 可访问外网；被同网段其他主机直接访问；暴露面最大 |
| NAT | 虚拟机经 VMnet8 由宿主机完成地址转换后出网，宿主机充当网关与 DHCP 服务器 | 虚拟机能出网；外部主机无法主动访问虚拟机；隐蔽性较好 |
| 仅主机 Host-only | 仅通过 VMnet1 或自定义 VMnet 与宿主机通信，无 NAT、无物理网卡桥接 | 与互联网完全隔离；仅宿主机与同 VMnet 内虚拟机互通 |
本实验采用 NAT + 仅主机 组合构造两层网络：攻击机位于 NAT 边界段，靶机位于与互联网隔离的仅主机内网段，跳板机双网卡跨接两个网段。
3.2 拓扑设计与 IP 地址分配
图 1 攻防对抗环境网络拓扑图
| 主机 | 角色 | 网卡 | IP 地址/掩码 | 网络模式 | 默认网关 |
|---|---|---|---|---|---|
| Kali Linux | 攻击机 | eth0 | 192.168.116.128/24 | VMnet8（NAT） | 192.168.116.2 |
| Ubuntu1 | 边界跳板 / 内网网关 | ens33 | 192.168.116.129/24 | VMnet8（NAT） | 192.168.116.2 |
| Ubuntu1 | 内网网关 | ens37 | 192.168.113.128/24 | VMnet1（Host-only） | —（不配） |
| Ubuntu2 | 内网靶机 | ens33 | 192.168.113.129/24 | VMnet1（Host-only） | —（不配） |
3.3 虚拟机与虚拟网络配置步骤
- 虚拟网络配置：确认 VMnet8 为 NAT 模式（子网 192.168.116.0/24，网关 192.168.116.2），VMnet1 为「仅主机」模式（子网 192.168.113.0/24）。
图 2 VMnet8 配置为 NAT 模式
图 3 VMnet1 配置为仅主机模式
- 为跳板机添加第二块网卡：在虚拟机设置中添加网络适配器（
ethernet1，PCI 槽位 37），第一块连 VMnet8、第二块连 VMnet1，使其同时位于两个网段；同时将靶机网卡由 NAT 切换至 VMnet1。
图 4 跳板机双网卡设置（NAT + 自定义 VMnet1）
- 开启内核转发：在跳板机上开启
net.ipv4.ip_forward，使跨网段流量可被转发。 - 配置跨网段路由：Kali 与靶机各添加一条指向对端网段的路由，均经跳板机转发。
图 5 跳板机地址与路由表
图 6 Kali 地址与路由表
图 7 靶机地址与路由表
- 连通性验证：按「同网段 → 跨网段 → 出网」三层顺序逐级验证连通性。
图 8 连通性验证：ping 与 traceroute（第一跳为跳板机）
关键配置命令
# ① 跳板机开启内核转发
net.ipv4.ip_forward=1
# ② 跳板机配置 NAT 出网（使内网靶机可临时访问互联网）
sudo iptables -t nat -A POSTROUTING -s 192.168.113.0/24 -o ens33 -j MASQUERADE
# ③ Kali 添加内网路由
sudo ip route replace 192.168.113.0/24 via 192.168.116.129
# ④ 靶机添加回程路由
sudo ip route replace 192.168.116.0/24 via 192.168.113.128
3.4 软件更新源（APT 源）修改
实验机为 Ubuntu 24.04（noble），其软件源配置已由传统的 /etc/apt/sources.list 改为 DEB822 格式 的 /etc/apt/sources.list.d/ubuntu.sources，替换方式与旧版本不同。
# 备份原配置
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak
# /etc/apt/sources.list.d/ubuntu.sources —— 替换为清华源
Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
# 验证并安装 open-vm-tools
sudo apt update
sudo apt install -y open-vm-tools open-vm-tools-desktop
实测结果：
命中:1 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble InRelease
命中:2 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble-updates InRelease
命中:3 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble-backports InRelease
命中:4 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble-security InRelease
正在读取软件包列表... 完成
图 9 apt update 命中清华源
图 10 安装 open-vm-tools
图 11 复核安装结果（已是最新版）
补充：清理安装介质残留源
实验过程中发现系统残留了一条安装介质源，导致 apt update 直接报错退出，需先行清理（详见 5.1 节）。
grep -rn 'cdrom' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
sudo sed -i.bak '/cdrom/s/^/#/' /etc/apt/sources.list
3.5 Ubuntu 基本命令与文件系统探索
以下命令均在跳板机（Ubuntu1）上实际执行，输出为真实回显。
（1）系统基础信息与当前路径
whoami && id
uname -a
grep PRETTY_NAME /etc/os-release
pwd
实测输出（图 12、图 13）：
cloverdayssss
uid=1000(cloverdayssss) gid=1000(cloverdayssss) 组=1000(cloverdayssss),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),114(lpadmin)
Linux cloverdayssss-VMware-Virtual-Platform 6.14.0-37-generic #37~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 24.04.3 LTS"
/home/cloverdayssss/桌面
图 12 系统信息与用户身份（whoami / id / uname）
图 13 当前所在路径 pwd
（2）新建文件并写入姓名拼音
cd ~
touch 25189100283.txt # 以学号命名
cat > 25189100283.txt # 写入姓名拼音
dengmingjie
cat 25189100283.txt # 验证写入结果
（3）查看详细列表并解读权限
ls -l 25189100283.txt
实测输出：
-rw-rw-r-- 1 cloverdayssss cloverdayssss 12 9月 17 21:34 25189100283.txt
权限解读：
| 字段 | 值 | 含义 |
|---|---|---|
| 文件类型 | - |
普通文件（d 为目录、l 为符号链接） |
| 属主权限 | rw- |
属主可读、可写、不可执行 |
| 属组权限 | rw- |
属组可读、可写（Ubuntu 用户私有组默认 umask 为 002） |
| 其他用户权限 | r-- |
其他用户仅可读 |
| 硬链接数 | 1 |
指向该 inode 的链接数量 |
| 属主 / 属组 | cloverdayssss cloverdayssss |
文件所有者及其所属组 |
| 大小 | 12 |
文件字节数 |
（4）查看内容与统计字符数
cat 25189100283.txt
wc -c 25189100283.txt
wc -l -m 25189100283.txt
实测输出：
dengmingjie
12 25189100283.txt ← 字节数（wc -c）
1 12 25189100283.txt ← 行数、字符数（wc -l -m）
说明：内容
dengmingjie\n共 12 个字符（11 个字母 + 1 个换行符），因全部为 ASCII 字符，字节数与字符数相同。
（5）压缩、删除、复制、改属主、改权限
gzip -k 25189100283.txt # -k 保留原文件
ls # 可见新生成的 25189100283.txt.gz
rm -f 25189100283.txt.gz # 删除压缩文件
ls # 确认已删除
cp 25189100283.txt /tmp/ # 复制到 /tmp 目录
ls /tmp # 确认复制成功
sudo chown root:root 25189100283.txt # 将属主改为 root
ls -l 25189100283.txt
sudo chmod 777 25189100283.txt # 将权限改为 777
ls -l 25189100283.txt
实测输出：
-rw-rw-r-- 1 root root 12 9月 17 21:34 25189100283.txt ← 改属主后
-rwxrwxrwx 1 root root 12 9月 17 21:34 25189100283.txt ← 改权限后
注意：
gzip不加-k会删除原文件，后续步骤将无法继续。
图 14 文件创建、内容写入、权限查看、字符统计、压缩、删除与复制全过程
（6）搜索系统中的隐藏文件
ls -la
find / -name ".*" -type f 2>/dev/null | head -15
实测输出：
-rw-r--r-- 1 cloverdayssss cloverdayssss 3771 3月 31 2024 .bashrc
-rw-r--r-- 1 cloverdayssss cloverdayssss 807 3月 31 2024 .profile
drwx------ 12 cloverdayssss cloverdayssss 4096 9月 17 14:23 .config
/home/cloverdayssss/.config/.gsd-keyboard.settings-ported
/home/cloverdayssss/.bash_logout
/home/cloverdayssss/.profile
/home/cloverdayssss/.bashrc
/home/cloverdayssss/.sudo_as_admin_successful
/home/cloverdayssss/.bash_history
/tmp/.X1025-lock
/tmp/.X1-lock
/tmp/.X0-lock
/etc/.updated
/etc/.pwd.lock
图 15 属主/权限修改与隐藏文件搜索（ls -la 与 find）
3.6 /etc/passwd 文件多维度解读
（1）文件属性与结构
ls -l /etc/passwd
wc -l /etc/passwd
head -3 /etc/passwd
实测输出：
-rw-r--r-- 1 root root 2931 9月 17 20:44 /etc/passwd
50 /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
图 16 /etc/passwd 文件属性、行数与内容
/etc/passwd 属主为 root，权限 644，即所有用户可读、仅 root 可写——这是必要的，因为登录、ls -l 等操作都需读取用户信息，而写入被严格限制以防止提权。
（2）字段含义（以 root 行为例）
| 序号 | 字段 | 含义 | 示例解析 |
|---|---|---|---|
| 1 | 用户名 | 登录账号名 | root |
| 2 | 密码占位符 | x 表示密码已由 /etc/shadow 托管 |
x |
| 3 | UID | 用户标识号，0 为超级用户 | 0 |
| 4 | GID | 主组标识号 | 0 |
| 5 | 注释/描述 | 用户全名等信息（GECOS） | root |
| 6 | 家目录 | 用户登录后的起始目录 | /root |
| 7 | 登录 Shell | 登录时执行的 Shell；nologin 表示禁止登录 |
/bin/bash |
（3）统计与筛选
wc -l /etc/passwd
cut -d: -f1 /etc/passwd
awk -F: '3>=1000 &&3<65534 {print 1,3}' /etc/passwd
awk -F: '3==0 {print1}' /etc/passwd
grep -v "nologin\|false" /etc/passwd | cut -d: -f1
实测输出：
50 /etc/passwd ← 共 50 个账户
普通用户（UID>=1000）：
cloverdayssss UID=1000
UID=0 的账户：
root
可登录用户（shell 非 nologin/false）：
root sync cloverdayssss
（4）安全视角解读
- UID 为 0 的账户即为超级用户。实测仅
root一个，属正常状态；若出现 root 之外的 UID=0 账户，通常意味着攻击者留下的后门账户； - 空密码字段（第 2 字段为空）表示该账户无需密码即可登录，属高危配置；
- Shell 为
/bin/bash的服务账户同样可被用于登录。实测可登录账户为root、sync、cloverdayssss三个，其中sync为系统账户，其 shell 为/bin/sync，并非交互式 shell； - 普通用户 UID 自 1000 起编号，可通过 UID 范围快速区分系统账户与人为创建账户（本机 50 个账户中仅 1 个为普通用户）。
因此 /etc/passwd 是主机安全检查与应急响应中必查的文件之一。
四、实验数据记录
表 1 虚拟机网络配置与连通性验证结果
| 序号 | 源主机 | 目标 | 命令 | 结果 |
|---|---|---|---|---|
| 1 | Kali 192.168.116.128 | 跳板机 192.168.116.129 | ping -c 3 |
通，min/avg/max = 0.495/0.745/0.931 ms |
| 2 | 靶机 192.168.113.129 | 跳板机 192.168.113.128 | ping -c 2 |
通，同网段 |
| 3 | Kali 192.168.116.128 | 靶机 192.168.113.129 | ping -c 3 |
通，经跳板机转发，min/avg/max = 0.788/1.750/2.619 ms |
| 4 | Kali 192.168.116.128 | 192.168.113.129 | traceroute |
第一跳 192.168.116.129，第二跳 192.168.113.129 |
| 5 | 靶机 192.168.113.129 | 223.5.5.5 | ping -c 2 |
不通，网络不可达（Host-only 隔离生效） |
| 6 | 跳板机 192.168.116.129 | mirrors.tuna.tsinghua.edu.cn | apt update |
成功，四个仓库索引全部命中清华源，无 404 / GPG 报错 |
表 2 文件系统基本命令操作记录
| 操作 | 命令 | 结果 |
|---|---|---|
| 新建学号文件 | touch 25189100283.txt |
创建成功，0 字节 |
| 写入姓名拼音 | cat > 25189100283.txt 输入 dengmingjie |
12 字节 |
| 查看权限 | ls -l 25189100283.txt |
-rw-rw-r-- 1 cloverdayssss cloverdayssss 12 |
| 查看内容 | cat 25189100283.txt |
dengmingjie |
| 统计字符 | wc -c / wc -l -m |
12 / 1 12 |
| 压缩 | gzip -k 25189100283.txt |
生成 25189100283.txt.gz |
| 删除压缩包 | rm -f 25189100283.txt.gz |
删除成功 |
| 复制到 /tmp | cp 25189100283.txt /tmp/ |
成功 |
| 改属主 | chown root:root |
-rw-rw-r-- 1 root root |
| 改权限 | chmod 777 |
-rwxrwxrwx 1 root root |
表 3 软件源修改前后对比
| 阶段 | 源地址 | 结果 |
|---|---|---|
| 修改前 | http://sg.archive.ubuntu.com/ubuntu（境外节点） |
apt update 耗时长，下载速率低 |
| 残留源 | file:///cdrom noble |
报错「不再含有 Release 文件」，导致 update 整体失败 |
| 修改后 | https://mirrors.tuna.tsinghua.edu.cn/ubuntu |
四个仓库索引全部命中，获取正常（见图 9） |
五、实验结果分析及回答问题
5.1 实验过程中遇到的问题与排查
问题一：apt update 报错退出，open-vm-tools 未能安装
现象：执行 sudo apt update && sudo apt install open-vm-tools -y 时，命令在 update 阶段即报错终止，&& 之后的安装步骤完全未执行：
E: 仓库 "file:/cdrom noble Release" 不再含有 Release 文件。
N: 无法安全地用该源进行更新，所以默认禁用该源。
原因分析：系统安装时曾将安装光盘作为本地源写入配置（指向 file:/cdrom）。系统安装完成后 /cdrom 已不再挂载，该路径下不存在 dists/noble/Release 索引文件，APT 因无法验证该源而报错。由于命令使用 && 串联，前一条失败导致后续安装被跳过。
解决：定位并注释掉该条源后重新执行，问题解决。
grep -rn 'cdrom' /etc/apt/sources.list /etc/apt/sources.list.d/
sudo sed -i.bak '/cdrom/s/^/#/' /etc/apt/sources.list
经验总结：排查 apt 故障时应先单独执行 apt update 观察完整报错，再执行安装；使用 && 串联命令时，前置失败会静默跳过后续步骤，容易误判为「安装成功」。
问题二：DNS 解析失败导致 apt 无法工作
现象：修改源文件后 apt update 仍然失败，nslookup 报 SERVFAIL，但直接 ping 公网 IP（223.5.5.5）却可以通。
排查过程：
resolvectl status # 显示 Link ens33 的 Current Scopes: none
nslookup mirrors.tuna.tsinghua.edu.cn 223.5.5.5 # 指定 DNS 服务器则解析成功
原因分析：NetworkManager 虽已通过 DHCP 获得网络配置，但未向 systemd-resolved 注册 DNS 服务器（Current Scopes: none），导致本地 stub 解析器（127.0.0.53）无可用上游。因此「能 ping 通 IP 但无法解析域名」。
解决：通过 nmcli 显式指定 DNS 并令其忽略 DHCP 下发的 DNS：
CON=(nmcli -t -f NAME,DEVICE con show --active | awk -F: '2=="ens33"{print 1; exit}')
sudo nmcli con mod "CON" ipv4.dns "223.5.5.5,114.114.114.114" ipv4.ignore-auto-dns yes
sudo nmcli con up "$CON"
修复后 resolvectl status 显示 Current Scopes: DNS、Current DNS Server: 223.5.5.5，解析恢复正常。
经验总结：Linux 网络故障排查应分层进行——先验证链路（ping IP），再验证 DNS 解析（nslookup），最后验证应用层（apt update）。若 ping IP 通而域名不通，问题一定在 DNS 环节。
问题三：跨网段流量无 NAT 规则，内网无法出网
现象：为靶机添加默认路由后，靶机仍无法访问互联网。
原因分析：跳板机虽已开启 ip_forward，但 iptables 的 POSTROUTING 链中没有地址转换规则。靶机的数据包虽然能被转发到 NAT 网段，但源地址仍是 192.168.113.129（私有内网地址），VMware 的 NAT 设备无法为其路由回包，因此必须做源地址转换（MASQUERADE）。
解决：
sudo iptables -t nat -A POSTROUTING -s 192.168.113.0/24 -o ens33 -j MASQUERADE
添加后靶机可正常访问互联网（实测时延 26.8 ms）。
经验总结：转发（ip_forward）与地址转换（MASQUERADE）是两个独立环节，前者负责「让包通过」，后者负责「让回包能找到源」。做跨网段网关时两者缺一不可。
5.2 结果分析
（1）网络层面：同网段（Kali–跳板机、跳板机–靶机）二层直通；跨网段（Kali–靶机）需跳板机开启 ip_forward 并具备双网卡后可达。traceroute 结果清晰印证了两层结构：
traceroute to 192.168.113.129, 5 hops max, 60 byte packets
1 192.168.116.129 0.730 ms 0.653 ms 0.613 ms ← 跳板机（边界网段）
2 192.168.113.129 1.470 ms 1.453 ms 1.120 ms ← 靶机（内网网段）
流量确实经过跳板机中转，而非直达，说明「攻击机—跳板—靶机」的隔离结构成立。靶机位于 Host-only 网段，实测 ping 223.5.5.5 返回 网络不可达，与设计预期一致。
（2）软件源层面：替换为清华镜像源后，apt update 的四个仓库索引全部命中（见图 9），安装 open-vm-tools 无依赖错误，说明源替换生效且版本代号（noble）匹配正确。若 Suites 字段误填其他版本代号，将出现 404 无法获取索引，因此替换前必须用 cat /etc/os-release 确认代号。
（3）文件权限层面：chmod 777 后文件对任意用户可读可写可执行，是典型的危险配置；若该文件为脚本并被 root 执行，则任何用户均可改写其内容从而实现提权，因此生产环境中应避免 777。
5.3 思考题：如何将文件时间修改为某个特定日期？
（1）Linux 文件的四类时间戳
在回答「如何修改」之前，需要先明确「修改哪个时间」。Linux 中一个文件并非只有一个时间，而是四类独立的时间戳，全部保存在 inode 中：
| 缩写 | 名称 | 含义 | 何时更新 |
|---|---|---|---|
| atime | Access Time 访问时间 | 文件内容最后一次被读取的时间 | 执行 cat、read 等读操作时 |
| mtime | Modify Time 修改时间 | 文件内容最后一次被修改的时间 | 写入内容时（echo、vim 保存等） |
| ctime | Change Time 变更时间 | 文件元数据（inode）最后一次变更的时间 | 改权限、改属主、改文件名、以及 mtime 被修改时 |
| btime | Birth Time 创建时间 | 文件被创建的时间（又称 crtime） | 文件创建时，一经写入不可修改 |
本机实测（Ubuntu 24.04 / 内核 6.14 / ext4，以新建的测试文件为例）：
touch /tmp/payload.sh && stat /tmp/payload.sh
文件：/tmp/payload.sh
大小：11 块：8 IO 块大小：4096 普通文件
权限：(0644/-rw-r--r--) Uid: ( 1000/cloverdayssss) Gid: ( 1000/cloverdayssss)
访问时间：2026-09-17 22:11:00.112905170 +0800 ← atime
修改时间：2026-09-17 22:11:00.113984001 +0800 ← mtime
变更时间：2026-09-17 22:11:00.113984001 +0800 ← ctime
创建时间：2026-09-17 22:11:00.112905170 +0800 ← btime
可以看到四个时间精度均达到纳秒级，且初始状态下依次递增（btime < mtime = ctime < atime），符合「先创建 → 再写入 → 再读取」的操作顺序。
（2）回答思考题：如何修改文件时间为特定日期
# ① 修改为指定日期（同时改 atime 与 mtime）
touch -d "2020-01-01 00:00:00" payload.sh
# ② 引用已有文件的时间戳（伪装成与正常文件同一时间）
touch -r /bin/ls payload.sh
# ③ 分别指定 atime 与 mtime
touch -a -d "2020-01-01 00:00:00" payload.sh # 仅访问时间
touch -m -d "2020-01-01 00:00:00" payload.sh # 仅修改时间
# ④ 连带修改 ctime（touch 无法直接修改 ctime，需直接操作 inode）
sudo debugfs -w -R "set_inode_field /home/user/payload.sh ctime 202001010000" /dev/sda2
# ⑤ 更彻底的方式：修改系统时间后再操作
sudo date -s "2020-01-01 00:00:00" && touch payload.sh && sudo hwclock -w
实测验证：对 /tmp/payload.sh 执行 touch -d "2020-01-01 00:00:00" 后，各时间戳变化如下：
| 时间戳 | 篡改前 | 篡改后 | 是否被修改 |
|---|---|---|---|
| atime | 2026-09-17 22:11:00.112905170 | 2020-01-01 00:00:00.000000000 | ✅ 已改 |
| mtime | 2026-09-17 22:11:00.113984001 | 2020-01-01 00:00:00.000000000 | ✅ 已改 |
| ctime | 2026-09-17 22:11:00.113984001 | 2026-09-17 22:11:00.117905496 | ⚠️ 未按预期改，反而更新为当前时间 |
| btime | 2026-09-17 22:11:00.112905170 | 2026-09-17 22:11:00.112905170 | ❌ 完全未变 |
这个结果非常关键：touch 只能修改 atime 和 mtime，对 ctime 和 btime 无能为力。而且因为修改 mtime 本身属于「元数据变更」，反而触发了 ctime 更新为当前时间。
于是产生了一个无法掩盖的矛盾：
mtime = 2020-01-01 00:00:00.000000000 （伪装成四年前）
ctime = 2026-09-17 22:11:00.117905496 （实际篡改动作发生在今天）
即 ctime 晚于 mtime，这在正常情况下是不可能出现的（内容修改必然导致 ctime 同步或更晚更新）。取证人员只要对比 ctime 与 mtime，就能立刻判定该文件的时间戳被人为篡改过。这就是所谓「时间伪装」（timestomping）手法最主要的破绽。
图 17 实测：将文件时间改为 1919 年后，atime 与 mtime 已变，ctime 与 btime 均未改变
（3）为什么需要这么多时间？——四类时间戳的设计用途
核心原因在于：单一时间无法完整还原一个文件的生命周期。四类时间各司其职，分别回答不同的问题：
| 时间戳 | 回答的问题 | 典型用途 |
|---|---|---|
| btime | 这个文件什么时候出现的？ | 判断文件是否为「新出现的可疑文件」；确定入侵时间窗口 |
| mtime | 内容最后一次被改动是什么时候？ | 判断配置是否被篡改、代码是否被植入；版本控制与增量备份的依据 |
| atime | 这个文件最后一次被读取是什么时候？ | 判断敏感文件是否被翻动过（如 /etc/shadow 被读取） |
| ctime | 文件的属性/身份最后变更是何时？ | 抗篡改的关键证据；可揭示权限提升、属主变更、时间伪装等动作 |
从攻防两个视角看：
攻击者视角——木马上传后需要「融入环境」，避免时间戳异常引起注意。因此倾向于：
- 把 mtime 改成与同目录正常文件一致的日期（
touch -r）； - 避免留下与文件创建时间矛盾的访问痕迹。
取证/防御视角——正是利用「四类时间互相牵制」来发现异常。常见的矛盾组合包括：
| 异常模式 | 可能含义 |
|---|---|
| ctime 远晚于 mtime | 时间戳被篡改（touch 修改 mtime 会更新 ctime） |
| btime 晚于 mtime | 文件被替换或重建（先有旧时间，后创建新文件） |
| atime 极新但 mtime 很旧 | 该文件近期被人查看过（可能正在被侦察） |
| mtime 早于 btime | 时间戳被伪造，属明显异常 |
| 多个文件 mtime 完全相同（精确到秒） | 批量操作痕迹（如攻击者一次性释放多个文件） |
因此，四类时间戳本质上构成了一套「交叉验证」机制：单独篡改其中一两个容易，但要同时让四个时间在逻辑上自洽，对普通攻击者而言极其困难。这也是数字取证中「时间线分析」（Timeline Analysis）的基础——取证工具（如 Sleuth Kit 的 fls/mactime）正是按 MAC（Modified-Accessed-Changed）时间排序来重建事件序列的。
（4）防御手段
- 使用
auditd记录文件属性变更事件（ausearch检索 write / attribute change）； - 部署完整性校验工具（AIDE、Tripwire）并保存基线，定期比对；
- 利用 ctime、btime 难以被普通手段篡改这一特性进行交叉比对，重点检查 ctime 与 mtime 的矛盾；
- 挂载时使用
noatime/relatime选项减少 atime 噪声（本机实测挂载选项为relatime），便于集中分析 mtime 异常； - 对关键目录启用不可变属性（
chattr +i），从根本上阻止篡改。
六、实验小结
- 完成 VMware 三种网络模式的原理梳理，掌握 NAT 与 Host-only 的连通性差异；
- 搭建出 Kali → 跳板机 → 靶机 的两层攻防对抗环境，
traceroute验证跨网段流量确实经跳板机转发； - 掌握 Ubuntu 24.04 的 DEB822 源文件格式及替换方法，能独立完成换源与软件安装；
- 排查并解决了 cdrom 残留源、DNS 未注册、NAT 规则缺失三个实际问题；
- 熟练掌握 Linux 文件系统相关命令（文件增删改查、权限与属主管理、隐藏文件搜索）；
- 掌握
/etc/passwd的字段结构与安全审计方法； - 掌握 Linux 文件四类时间戳（atime / mtime / ctime / btime）的语义与用途，实测验证
touch无法篡改 ctime 与 btime，理解「ctime 晚于 mtime」这一时间伪装的破绽，以及四类时间构成交叉验证机制的原理。