知行课栈

外观

拒绝服务原理与数据库安全加固

约 7403 字大约 25 分钟

网络安全技术DoS数据库安全

2026-05-11

本课核心

我们不会"攻击"任何服务器。本课的目的是：通过低强度观测和权限检查，理解 DoS 攻击"为什么能让服务瘫痪"，以及数据库的"权限防线"如何保护数据安全。 每一个理论概念，都会立刻用真实的命令验证它。

课堂红线

拒绝服务实验极易越界。本节唯一允许的攻击实验是：使用 hackingtool 的 Slowloris 攻击本机的 dos-target 靶场容器（127.0.0.1:9090），且攻击目标由课堂脚本搭建、资源受限、随时可 Ctrl+C 终止。禁止行为： DDoS 脚本、洪水攻击工具（LOIC、HOIC 等）、长时间压测、对非本机目标发起任何请求。hackingtool 中除 Slowloris 之外的 DDoS 工具（GoldenEye、UFONet 等）只做风险认知，不运行。

1. 项目任务与交付物

项目任务

理解 DoS/DDoS 的资源消耗原理，掌握数据库最小权限检查方法，能够识别不安全的数据库配置。

工具融入

实际使用 curl、xargs、docker stats、docker exec mysql、SHOW GRANTS。通过 hackingtool 的 DDOS Attack 分类进行风险认知。

最终产出

提交低强度访问观测记录、容器资源截图、数据库账号权限截图和加固建议。

2. 故事引入：为什么要学这一课

在开始动手之前，先想两个真实发生过的事：

2011 年，程序员社区 CSDN 遭遇"拖库"。 攻击者通过应用层的漏洞进入数据库，将 600 万用户的账号密码全部导出，然后在互联网上公开传播。很多人从此养成了"不同网站用不同密码"的习惯——但这只是被动的补救。

某知名连锁酒店，客户数据被拖走。 数据库的连接权限过大，应用服务器直接用 root 账号连接数据库，一旦 Web 应用被攻破，数据库就成了"裸奔"状态。

这两件事的核心问题分别是：资源可用性被破坏（拒绝服务）和数据库权限失控。本课就是来理解这两个问题的原理，并用真实命令验证它们。

3. 第一幕：认识拒绝服务 — 当服务器"吃饱了撑的"

3.1 理论开场：用餐厅来理解 DoS

想象你开了一家餐厅，正常营业时每桌客人点菜、吃饭、结账离开，循环顺畅。但如果出现下面的情况，餐厅就瘫痪了——

场景一（连接消耗）： 一群人走进餐厅，每人只点一杯水，然后占着桌子不走。真正要吃饭的客人进不来。对应到服务器，就是攻击者不断创建连接但不释放，耗尽连接池。

场景二（资源消耗）： 一群人同时冲进餐厅，每个人都点"满汉全席"而且还要求厨师重新做。后厨 CPU 被打满，所有正常订单都做不出来。对应到服务器，就是大量高成本请求打满 CPU 和内存。

场景三（带宽消耗）： 根本不需要进餐厅——几千人在门口同时大声说话，把路堵死了。客人连门都找不到。对应到服务器，就是垃圾流量占满网络带宽。

🔬

DoS 连接消耗实验室

用动画理解服务器资源是如何被吃掉的

客户端
💻PC1
💻PC2
网络
服务器
🖥️
DVWA Web
连接队列 2/20
CPU
5%
MEM
12%
带宽
3%
当前模式课堂观测
请求数10 次
并发连接2
HTTP 状态200 OK
💡
这是"观测"，不是"攻击"

10 次低并发请求不会消耗服务器资源。就像一个人正常走进餐厅点餐——餐厅完全能处理。我们做观测的目的是：看服务是否正常响应（200）、响应时间是否合理（毫秒级）。

🖥️ 对应的实战命令
seq 1 10 | xargs -I{} -P2 curl -s -o /dev/null -w "%{http_code} %{time_total}\n" http://127.0.0.1:8080/login.php

seq 生成 1~10，xargs 每次执行 curl，-P2 限制最多 2 个并发进程。这是"低强度观测"，不是压力测试。

思考时刻

切换上面的"课堂观测" → "压力测试" → "洪水攻击"，观察服务器资源的变化。注意"课堂观测"模式下，CPU 只有 5%、连接队列几乎为空——这就是我们接下来要做的事情：安全地观察，而不是攻击。

3.2 动手实践 1：用 curl 观察正常的 Web 访问

搞明白理论之后，我们立刻动手验证。我们会向本机的 DVWA 靶场发送 10 次请求，模拟一个学生在浏览网页时产生的正常访问。这不是攻击，只是观测——就像在餐厅门口数有多少人进进出出。

命令：

seq 1 10 | xargs -I{} -P2 curl -s -o /dev/null \
  -w "%{http_code} %{time_total}\n" \
  http://127.0.0.1:8080/login.php \
  | sort | uniq -c

这个命令在做什么？

每条指令的目的逐行解释：

命令片段作用
seq 1 10生成 1 到 10 共 10 个数字。只请求 10 次，不是 1000 次，不是无限次
| xargs -I{} -P2把前面的数字逐个传给后面的 curl。-P2 的意思是最多同时跑 2 个请求——这是并发控制，防止制造压力
curl -s -o /dev/null静默访问（不显示进度条），把网页内容扔进黑洞（不保存，因为我们只关心状态）
-w "%{http_code} %{time_total}\n"输出 HTTP 状态码和响应耗时，这才是我们想看的关键信息
| sort | uniq -c按响应归类统计。如果所有请求都返回 200，说明服务正常

真实输出（在 Kali 中运行后得到）：

      1 200 0.005555
      1 200 0.005579
      1 200 0.005954
      1 200 0.006063
      1 200 0.006238
      1 200 0.006282
      1 200 0.006521
      1 200 0.006612
      1 200 0.006828
      1 200 0.007093

看懂输出：

  • 每一行开头的 1 是 uniq -c 的统计计数（因为每行都不同，所以各出现 1 次）
  • 200 是 HTTP 状态码。200 表示"正常响应"，说明登录页面正常工作
  • 0.005555 到 0.007093 是响应耗时（秒）。最快的 5.6 毫秒，最慢的 7.1 毫秒，对于本机访问来说完全正常
  • 如果被 DoS 攻击，你会看到大量 503（服务不可用）或者 超时（响应时间变成几十秒）

关键结论

这 10 次请求对服务器没有任何压力。但试想如果改成 seq 1 100000 并且 -P100，结果会完全不同——这就是观测和攻击的本质区别。本课只做前一种。

3.3 理论深入：拒绝服务攻击分几类？

刚才我们看到了"10 次正常请求"的样子。现在我们从攻击的角度来对 DoS 进行分类——知道敌人长什么样，才能有针对性地防御。

按消耗的资源类型分：

类型攻击原理受害者能感觉到什么
连接耗尽发送大量半开连接（如 SYN Flood），占满 TCP 连接队列新用户连不上，浏览器一直转圈
带宽耗尽发送海量垃圾流量，占满所有可用带宽网站打不开，就像网断了
CPU/内存耗尽请求触发高计算量操作，反复消耗 CPU服务器风扇狂转，所有操作变慢

按攻击是否分布分：

类型攻击来源类比
DoS（单源）一台机器攻击一个目标一个人堵餐厅门口
DDoS（分布式）成千上万台"肉鸡"同时攻击几千人从四面八方堵过来

按攻击目标分：

类型攻击对象影响
服务器端Web 服务器、数据库等网站整体瘫痪
客户端特定用户的连接游戏中被"踢下线"

请求预算模拟器

为什么 10 次观测和洪水攻击完全不同

请求数量10
并发2
课堂处理允许

用于观察状态码和响应时间，不追求让服务变慢。

安全提醒

切换上面的"压力测试"和"洪水攻击"按钮，看看请求量和并发量有多大。这些模式课堂不做，但你需要认识它们——因为你以后配置 WAF 限速规则时，需要知道"多大量才算异常"。

3.4 经典 DoS 攻击手法速览

这里列举几个经典的 DoS 攻击手法，你不需要记住命令，但需要理解它们的攻击思路——这有助于你在检查日志时识别异常。

SYN Flood（SYN 洪水） 利用 TCP 三次握手机制。攻击者发送大量 SYN 请求但不完成握手，服务器为每个"半开连接"分配资源等待 ACK，最终耗尽连接表。防御方法：SYN Cookie、连接数限制。

Smurf 攻击 攻击者伪造受害者的 IP 地址，向网络的广播地址发 ICMP 请求，所有收到广播的主机都向"受害者"回复。这是一种放大攻击，攻击者发 1 份流量，受害者收到几十份。防御方法：禁用 IP 定向广播。

Ping of Death（死亡之 Ping） 发送超过 65535 字节的异常 ICMP 包，部分老旧操作系统处理时会崩溃。现代系统已修复此漏洞，但思路值得警惕——利用协议的边界条件制造破坏。

Teardrop（泪滴攻击） 发送重叠偏移的 IP 分片包，部分操作系统在重组时出错导致崩溃。同样利用了协议的实现缺陷。

4. 第二幕：动手观测服务器"健康指标"

4.1 理论：服务器有哪些关键资源？

在动手之前，先理解我们要看什么。一台 Web 服务器就像一个人的身体：

资源指标对应含义正常范围
CPU %计算能力——处理请求的能力< 30%（轻载）
MEM %内存——同时能处理多少事情< 60%（合理使用）
NET I/O网络吞吐——流量进出量平稳，无突增
PIDS进程数——有多少"工人"在干活稳定，不暴增

当 DoS 攻击发生时，这些指标会发生异常变化——但不同攻击类型影响的指标不同。SYN Flood 打 CPU 和连接表，带宽洪水打网络，而 Slowloris 则专打连接数（CPU 几乎不动，内存温和上升）。下面我们实际查看 DVWA 容器的当前状态。

4.2 动手实践 2：查看容器资源状态

docker stats --no-stream dvwa

这个命令在做什么？

docker stats 是 Docker 自带的资源监控命令。--no-stream 参数意思是只采集一次就退出，而不是持续刷新——这又是一次"观测"，不是"持续监控"。dvwa 是我们 DVWA 靶场的容器名字。

真实输出（在 Kali 中运行后得到）：

CONTAINER ID   NAME      CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O       PIDS
4d3ceeeea7a7   dvwa      2.62%     128.5MiB / 7.75GiB   1.62%     575B / 2.42kB     46.8MB / 117MB  38

逐列解读：

  • CONTAINER ID：容器唯一标识符，前 12 位就够了
  • NAME：容器名 dvwa，这就是我们的靶场
  • CPU %：当前 CPU 占用 2.62%——处于轻载状态。如果被 DoS，这个数会明显升高
  • MEM USAGE / LIMIT：128.5MiB / 7.75GiB。用了 128MB，总量 7.75GB。用了才 1.62%，说明内存很富余
  • NET I/O：网络输入/输出量。格式是 接收 / 发送。575B / 2.42kB 是从容器启动至今的累计值。正常使用时增长缓慢
  • BLOCK I/O：磁盘读写量。格式是 读取 / 写入
  • PIDS：容器内进程数量 45 个。如果突然暴涨到几百个，说明可能出了异常——比如某个进程在疯狂 fork

如何对比观测效果

建议你在执行 curl 观测命令之前和之后各跑一次 docker stats --no-stream dvwa，对比两次的 NET I/O 差异。你会发现 10 次请求增加的流量只有几 KB——这就是低强度访问的特征。如果某天你看到流量每秒增长几十 MB，那就要警惕了。

4.3 扩展观测：再看几个有用的命令

以下命令你可以在 Kali 中自己运行，增加对服务器状态的感知：

# 查看 DVWA 容器监听的端口
docker port dvwa

# 查看本机所有监听端口（看看有没有不该开放的服务）
ss -tlnp | grep LISTEN

# 快速查看系统整体负载
uptime

5. 第三幕：亲手打崩网站 — Slowloris 实战

安全边界重申

本实验的攻击目标，是你刚刚搭建的本机容器（127.0.0.1:9090），不涉及任何外部服务器。攻击过程中可以随时按 Ctrl+C 停止。本实验的目的是亲眼看到 DoS 的效果，理解防御原理。

5.1 为什么选 Slowloris？

Slowloris 是一种低带宽、高效率的 HTTP DoS 攻击。它的攻击原理非常巧妙：

正常 HTTP 请求：
  客户端  ──→  GET / HTTP/1.1\r\nHost: ...\r\n\r\n  ──→  服务器处理 → 返回页面

Slowloris 攻击：
  客户端  ──→  GET / HTTP/1.1\r\n                         ──→  服务器等待……
  等待 10 秒 →  X-Ignore: a\r\n                              →  继续等待……
  等待 10 秒 →  X-Ignore: b\r\n                              →  继续等待……
  （永远不发送 \r\n\r\n，请求永不完成）

关键点： HTTP 协议规定，请求头以 \r\n\r\n（空行）结束。Slowloris 故意永远不发送这个空行，让服务器一直"等"。服务器为每个"等待中"的连接分配一个处理线程/进程，当所有线程被占满时——正常用户就进不来了。

而我们的靶场容器，Apache 最大连接数被故意设置为 10。200 个 Slowloris 连接可以轻松打满。

5.2 搭建靶场：一台"易受攻击"的网站

先确保你已下载 setup-dos-target.sh 脚本，然后运行：

chmod +x setup-dos-target.sh
./setup-dos-target.sh

脚本做了什么？

步骤操作目的
1生成 Apache 配置，MaxRequestWorkers = 10故意把连接池缩到最小
2写入一个仿真的学生门户网页让"被打崩"的效果更直观
3docker run --cpus=0.3 --memory=64m限制 CPU 和内存，模拟真实服务器资源紧张
4映射到 127.0.0.1:9090只监听本机，不暴露到外网

搭建完成后，在浏览器打开 http://127.0.0.1:9090，你会看到一个漂亮的"星辰在线教育"学生门户——有导航栏、课程卡片、实时服务器状态灯。记住它现在的样子，因为几分钟后你将亲眼看到它"挂掉"。

5.3 攻击前：记录正常状态

# 查看正常资源状态
docker stats --no-stream dos-target

记录下 CPU %、MEM %、PIDS 的数值，攻击后做对比。

5.4 发动攻击：用 hackingtool 的 Slowloris

打开 hackingtool，进入 DDOS Attack Tools 菜单，选择 Slowloris：

cd ~/hackingtool
sudo python3 hackingtool.py

在 hackingtool 菜单中：

步骤操作
① 主菜单选择 DDOS Attack Tools
② 子菜单选择 Slowloris
③ 输入目标http://127.0.0.1:9090
④ 连接数200（远超 Apache 的 10 个连接槽）
⑤ Timer100

备选方案： 如果 hackingtool 的 Slowloris 模块不可用，使用 Kali 自带的 slowhttptest：

slowhttptest -c 200 -H -i 10 -r 200 -t GET -u http://127.0.0.1:9090 -x 24 -p 3

5.5 攻击中：亲眼看到"服务不可用"

前台观测 1 —— 刷新浏览器：

切换到浏览器窗口，刷新 http://127.0.0.1:9090。

你会看到：浏览器一直转圈，几十秒后显示"无法连接"或"连接超时"。

这就是 DoS 攻击最直接的效果——合法用户无法访问服务。 刚才还正常运行的网站，现在处于"被打崩"状态。

前台观测 2 —— 查看资源变化：

在另一个终端执行：

docker stats --no-stream dos-target

对比攻击前后的数据：

真实输出（在 Kali 中运行后得到）：

--- before ---
CONTAINER ID   NAME         CPU %     MEM USAGE / LIMIT   MEM %     NET I/O           BLOCK I/O         PIDS
816766a52680   dos-target   0.00%     27.29MiB / 64MiB    42.63%    2.61kB / 27.8kB   15.1MB / 20.5kB   4
--- during ---
CONTAINER ID   NAME         CPU %     MEM USAGE / LIMIT   MEM %     NET I/O           BLOCK I/O         PIDS
816766a52680   dos-target   0.01%     35.86MiB / 64MiB    56.03%    54.7kB / 55.9kB   16.6MB / 20.5kB   12
--- probe during ---
000 3.002111
opened=200
--- after ---
CONTAINER ID   NAME         CPU %     MEM USAGE / LIMIT   MEM %     NET I/O         BLOCK I/O         PIDS
816766a52680   dos-target   0.50%     40.01MiB / 64MiB    62.52%    108kB / 199kB   23.1MB / 24.6kB   9
--- probe after ---
200 0.003843

对比攻击前后的数据：

指标攻击前攻击中原因
CPU %0.00%0.01%慢连接主要占用连接槽，本地轻量容器的 CPU 不一定明显升高
MEM27.29 MiB35.86 MiB200 个等待中的连接让 Apache 分配更多内存
NET I/O2.61 kB / 27.8 kB54.7 kB / 55.9 kB连接建立和慢速请求头让网络累计量上升
PIDS412Apache fork 出更多工作进程处理等待中的连接

000 3.002111 表示测试请求在 3 秒超时时间内没有拿到 HTTP 响应；停止慢连接后，探测恢复为 200 0.003843。

核心洞察：真实数据说明了什么

你的实验产生了三组关键证据：

证据数据说明
连接数暴增ss -tan | grep :80 = 201（正常时 < 10）Apache 的 10 个连接槽被 200 个假连接全部占满
CPU 几乎没动0.00% → 0.01% → 0.50%Slowloris 不消耗 CPU，它只是"占着茅坑不拉屎"
探测结果攻击中 000 3.002111，攻击后 200 0.003843攻击时请求在 3 秒超时内得不到响应；停止攻击后 3.8 毫秒恢复

这三个数据拼在一起，完整解释了 Slowloris 的原理：

  • 它不靠"打爆 CPU"来瘫痪服务（所以 CPU 几乎不变）
  • 它靠"占满所有连接槽"让合法用户排不上队（所以连接数 = 200+）
  • 这就是为什么连接数限制和超时控制是最有效的防御手段

DoS 的本质不是"破坏服务器"，而是"抢走所有排队的名额"。Slowloris 就像一个在银行柜台前假装填表的骗子——他不吵不闹、不耗费柜员精力（CPU 低），但他占着窗口不走，后面的真顾客永远轮不到。

5.6 停止攻击，验证恢复

在 hackingtool/slowhttptest 运行的终端按 Ctrl + C。

所有 200 个假连接瞬间断开。Apache 释放连接槽。立即刷新浏览器——网站恢复正常。

攻击后资源状态细节

停止攻击后，docker stats 显示：

CONTAINER ID   NAME         CPU %     MEM USAGE / LIMIT   MEM %     NET I/O         BLOCK I/O         PIDS
816766a52680   dos-target   0.50%     40.01MiB / 64MiB    62.52%    108kB / 199kB   23.1MB / 24.6kB   9

两个值得注意的细节：

  • MEM 从 35.86 MiB 进一步涨到 40.01 MiB（62.52%），并没有立即回落到攻击前的 29.36 MiB。因为 Apache 的 worker 进程在断开连接后不会立即退出——它们会保持存活一段时间等待复用
  • PIDS 从 12 降到 9，说明部分 worker 进程已退出，但还剩一些处于 idle 状态

这个"攻击→瘫痪→恢复"的完整循环，正是你作为防御方需要深刻理解的：

  • 攻击者只需要发送"慢连接"，就能让服务不可用——不需要高带宽，不需要高 CPU
  • 防御方通过连接数限制、超时控制、速率限制来防止连接池被占满
  • 即便攻击停止，资源释放也有延迟——真正的 DDoS 如果持续数小时，服务器的恢复时间会更长
🔬

DoS 连接消耗实验室

用动画理解服务器资源是如何被吃掉的

客户端
💻PC1
💻PC2
网络
服务器
🖥️
DVWA Web
连接队列 2/20
CPU
5%
MEM
12%
带宽
3%
当前模式课堂观测
请求数10 次
并发连接2
HTTP 状态200 OK
💡
这是"观测"，不是"攻击"

10 次低并发请求不会消耗服务器资源。就像一个人正常走进餐厅点餐——餐厅完全能处理。我们做观测的目的是：看服务是否正常响应（200）、响应时间是否合理（毫秒级）。

🖥️ 对应的实战命令
seq 1 10 | xargs -I{} -P2 curl -s -o /dev/null -w "%{http_code} %{time_total}\n" http://127.0.0.1:8080/login.php

seq 生成 1~10，xargs 每次执行 curl，-P2 限制最多 2 个并发进程。这是"低强度观测"，不是压力测试。

6. 第四幕：DDoS — 攻击者的"人海战术"

6.1 理论：DDoS 的三层结构

DDoS（分布式拒绝服务）不是一个人攻击一个目标，而是一个有组织、有层级的攻击体系：

这个结构的精妙（或者说可怕）之处在于：

  1. 攻击者隐藏：攻击者只和主控端通信，从不直接接触受害者。追踪难度极大
  2. 代理端是"肉鸡"：代理端通常是被感染的家庭路由器、摄像头、智能设备——主人并不知道自己的设备在帮黑客"打人"
  3. 放大效应：1 个攻击者 → 几个主控端 → 成千上万个代理端 → 受害者承受的流量是攻击者发出流量的几万倍

历史上著名的 DDoS 案例：

事件年份规模手法
GitHub DDoS20181.35 TbpsMemcached 放大攻击
Dyn DNS 攻击2016~1.2 TbpsMirai 僵尸网络（IoT 设备）
暴雪战网攻击持续不定多向量 DDoS

6.2 动手实践 3：认识 hackingtool 中其他 DDoS 工具

在上一章的 Slowloris 实验中，你已经用过 hackingtool 的 DDOS Attack Tools 菜单中的 Slowloris 了。现在回到这个菜单，看看还有哪些工具——但只看不碰。

除了 Slowloris，其余工具不运行

hackingtool 的 DDOS Attack 分类中，Slowloris 是本课唯一允许运行的攻击工具（且仅限攻击本机 dos-target 容器）。该分类下的其他工具——包括 GoldenEye、UFONet、aSYNcrone 等——只看名字、理解原理，不运行、不配置、不测试。 这些工具在未授权网络中使用是违法的。

你需要知道：

  • hackingtool 的 DDOS Attack 菜单里包含 Slowloris、GoldenEye、UFONet、aSYNcrone 等
  • Slowloris（已实操）的原理是耗尽 HTTP 连接池
  • GoldenEye 同样是 HTTP DoS，但使用更复杂的请求模式
  • UFONet 是 P2P 分布式 DoS 工具，涉及僵尸网络概念
  • aSYNcrone 是 SYN Flood 工具，攻击 TCP 三次握手
  • 防御方需要了解攻击工具的特征，才能配置对应的防护策略

7. 第五幕：数据库安全 — 权限就是生命线

7.1 理论：数据库安全的四个支柱

拒绝服务是针对"可用性"的攻击。而数据库安全保护的，是数据的机密性、完整性和可用性。一个数据库是否安全，可以从四个维度来衡量：

维度通俗理解课堂怎么检查
最小权限每个账号只做自己该做的事。前台服务员不该有保险柜钥匙SHOW GRANTS 看权限
访问控制数据库不对公网开放，只允许信任的应用访问看 Host 字段是否 localhost
审计可追踪谁在什么时候查了什么数据，都有日志检查审计日志是否存在
备份恢复万一数据被破坏，能够恢复确认备份策略存在

数据库权限范围

同一个漏洞，在不同权限下影响范围不同

权限语句
GRANT ALL PRIVILEGES ON dvwa.* TO app@localhost
读取数据允许
新增数据允许
修改数据允许
删除结构允许

靶场中权限较大，方便实验；真实系统应继续拆分。

切换看看

在上面的控件中切换"root 管理员" → "DVWA app" → "读写账号" → "只读账号"。你会发现，root 什么都能做（包括删除整个数据库结构），而只读账号只能查数据。思考：你的 Web 应用用的是哪种账号？

7.2 动手实践 4：查看你的数据库里有哪些账号

现在我们把理论转化为实际行动。进入 DVWA 容器中的 MySQL，看看数据库的结构。

docker exec dvwa mysql -uroot -pdvwa -e "SHOW DATABASES; SELECT User,Host FROM mysql.user;"

这个命令在做什么？

命令片段作用
docker exec dvwa在名为 dvwa 的容器中执行命令
mysql -uroot -pdvwa以 root 用户（密码 dvwa）连接 MySQL
-e "..."执行引号中的 SQL 语句，执行完就退出（不进入交互模式）
SHOW DATABASES;列出所有数据库。这是第一条 SQL
SELECT User,Host FROM mysql.user;从系统表 mysql.user 中查所有用户名和来源主机。这是第二条 SQL

真实输出（在 Kali 中运行后得到）：

Database
dvwa
information_schema
mysql
performance_schema
User	Host
app	localhost
root	localhost

逐行解读：

数据库列表：

  • dvwa：靶场业务数据库，存放用户数据、登录信息等
  • information_schema：MySQL 自带的"字典库"，存放数据库的结构信息
  • mysql：MySQL 系统库，存放账号、权限等安全元数据。这个库是攻击者的首要目标
  • performance_schema：性能监控库，存放运行时统计信息

用户列表：

  • app@localhost：应用程序连接数据库时用的账号。localhost 说明只能从本机连接——这是正确的配置
  • root@localhost：数据库管理员账号。同样只能从本机连接。但在真实环境中，Web 应用绝对不应用 root 连接数据库

7.3 动手实践 5：检查应用账号到底有多大权限

找到了 app 账号之后，必须检查它拥有哪些权限。

docker exec dvwa mysql -uroot -pdvwa -e "SHOW GRANTS FOR 'app'@'localhost';"

这个命令在做什么？

SHOW GRANTS FOR '用户名'@'来源'; 是 MySQL 中查看特定用户权限的标准命令。这是数据库安全审计的第一步：知道谁有什么权限。

真实输出（在 Kali 中运行后得到）：

Grants for app@localhost
GRANT USAGE ON *.* TO 'app'@'localhost' IDENTIFIED BY PASSWORD '*99DE6805356A04FDF37D7361BCF994E8B5DC75FF'
GRANT ALL PRIVILEGES ON `dvwa`.* TO 'app'@'localhost'

逐行解读：

第一行 GRANT USAGE ON *.*：

  • *.* 表示"所有数据库的所有表"
  • USAGE 是 MySQL 中权限最小的状态——允许连接，但什么都不能做
  • 这行实际上只是声明"这个账号存在"，密码哈希为 *99DE6805...
  • IDENTIFIED BY PASSWORD 后面是密码的加密散列值

第二行 GRANT ALL PRIVILEGES ON \dvwa`.*`：

  • \dvwa`.*` 表示"dvwa 数据库中的所有表"
  • ALL PRIVILEGES 表示拥有对该数据库的全部操作权限：增删改查、创建表、删除表、创建索引……什么都能做
  • 这对教学靶场来说没问题，但对真实业务来说——风险太大了

安全分析

如果 Web 应用（DVWA）存在 SQL 注入漏洞，攻击者通过 app@localhost 账号就能：

  • 读取 dvwa 库所有数据（SELECT）
  • 修改或删除数据（UPDATE, DELETE）
  • 甚至删除整张表（DROP TABLE）

但因为 app 的权限被限制在 dvwa 库内（不是 *.*），攻击者无法通过这个账号访问 mysql 系统库（那里存放着所有账号密码）。这就是"最小权限"的第一个体现——虽然还不够小。

7.4 给数据库做个"X-Ray 透视"

刚才我们看到了权限表面的信息。现在做一个思维实验：如果这台服务器已经被入侵，攻击者可能留下了什么？

🖥️

服务器运行状态

系统用户列表
  • root UID: 0
  • ubuntu UID: 1000
运行中进程
  • PID 1354 /usr/sbin/nginx
  • PID 2120 mysqld
网络连接状态
  • TCP 0.0.0.0:80 (LISTEN)
  • TCP 0.0.0.0:443 (LISTEN)
安全日志状态
  • /var/log/nginx/access.log (2.4MB)
  • /var/log/auth.log (正常)

要点

点击"开启深度扫描"按钮，你会看到隐藏在正常进程和连接背后的异常——隐藏的管理员账号、反弹 Shell、被清空的日志。这些是攻击者留下"后门"的常见手法。防御方需要定期做这类"透视检查"。

8. 第六幕：防御与加固 — 把漏洞堵上

学完攻击原理和权限检查，最后必须落到防御上。这里提供可操作的加固清单。

8.1 DoS 攻击的防御策略

风险场景防御措施一句话说明
单 IP 大量请求速率限制（Rate Limiting）Nginx 的 limit_req 模块，每个 IP 每秒最多 N 次
SYN FloodSYN Cookie不立即为半开连接分配资源，先验证真实性
应用层高成本请求接口限流 + 异步处理登录接口加验证码，报表导出放到后台队列
大流量 DDoSCDN + 流量清洗Cloudflare、阿里云高防等，在上游过滤攻击流量
带宽耗尽黑洞路由 + 上游协作联系 ISP 在骨干网层面丢弃攻击流量

8.2 数据库安全加固清单

当前风险加固措施执行命令（示例）
应用账号权限过大拆分为只读、读写、管理账号GRANT SELECT ON dvwa.* TO 'app_ro'@'localhost';
数据库端口对外暴露仅允许 127.0.0.1 访问修改 my.cnf 中 bind-address = 127.0.0.1
弱口令更换为强密码ALTER USER 'app'@'localhost' IDENTIFIED BY '新密码';
无审计日志开启查询日志和慢查询日志SET GLOBAL general_log = 'ON';
root 可用于 Web 应用创建专有应用账号创建新用户，只授权业务需要的库

8.3 最小权限改造示例

如果你要加固 DVWA 的数据库，应该怎么做？下面是一个步骤参考：

-- 步骤1：创建一个只读账号（用于报表查询）
CREATE USER 'app_readonly'@'localhost' IDENTIFIED BY 'StrongPassword123!';
GRANT SELECT ON dvwa.* TO 'app_readonly'@'localhost';

-- 步骤2：创建一个读写账号（用于正常业务）
CREATE USER 'app_readwrite'@'localhost' IDENTIFIED BY 'AnotherStrongPwd456!';
GRANT SELECT, INSERT, UPDATE, DELETE ON dvwa.* TO 'app_readwrite'@'localhost';

-- 步骤3：回收 root 的远程访问（如果存在）
DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1');

-- 步骤4：验证权限
SHOW GRANTS FOR 'app_readonly'@'localhost';
SHOW GRANTS FOR 'app_readwrite'@'localhost';
FLUSH PRIVILEGES;

9. hackingtool 分类映射

hackingtool 分类本节关系使用方式
DDOS Attack ToolsSlowloris 已实操（攻击本机容器）；其余工具（GoldenEye、UFONet 等）仅做风险认知，不运行
Web Attack Tools了解应用层攻击入口只在 DVWA 做低强度观测
Forensic Tools关联资源异常与取证概念认知，了解取证思路

10. 课堂验收清单

验收项标准
DoS 原理能用"餐厅比喻"解释连接耗尽、资源消耗和带宽消耗
Slowloris 实验能搭建 dos-target 靶场，用 hackingtool Slowloris 发起攻击，在浏览器中观察到服务不可用
攻击前后对比能对比攻击前后的 docker stats 数据，解释 CPU/MEM/NET/PIDS 的变化原因
访问观测能用 curl + xargs 做 10 次低并发观测，解释 200 状态码和响应时间
DoS 分类能区分 DoS、DDoS、SYN Flood、Smurf 等概念
数据库账号能查出数据库中有哪些账号、各自来自哪些主机
权限分析能读懂 SHOW GRANTS 的输出，指出权限过大的问题
加固建议能提出限流、最小权限、访问控制等具体加固方案

11. 课后任务

  1. Slowloris 实验报告：搭建 dos-target 靶场，用 hackingtool Slowloris 攻击，截图记录攻击前/中/后的浏览器状态和 docker stats 数据，并解释每项指标的变化原因
  2. 访问观测记录：在 Kali 中执行低强度访问观测（10 次请求），截图并标注每列含义
  3. 资源对比：执行 docker stats --no-stream dvwa，记录数据并解释每个指标的含义
  4. 权限审计报告：执行 SHOW GRANTS 命令，根据输出写一段分析，提出 3 条加固建议
  5. 风险认知：用自己的话解释 DoS、DDoS 和应用层 DoS 的区别，并举例说明