陈仲凯这周培训班的作业终于交上去了。作业分三块：一份带异常流量的 Web 日志溯源、一段问题明显的口令存储示例代码、一台权限配置松散的主机。三题放在一起看，其实挺有意思——题目本身不难，但每一道都贴着安全运维的日常工作场景，做完之后反而比单纯听课记得牢。我把自己完整的解题思路、验证过程和踩坑点整理成这份 wp，既是阶段复习，也给正在学日志分析、口令安全和主机加固的同学一个参考。
先说清楚，这份 wp 不是标准答案，是"我拿到题目之后怎么一步步想、一步步做"的记录。里面会夹带一些个人判断，比如哪些命令最省事、哪些验证步骤不能跳过、哪些坑是题目故意埋的。你完全可以按自己的思路做，但如果能把我的排查链路和你的思路对上，这周的学习目标基本就达成了。
1. 第四周作业复盘：这周考察的三个核心能力
1.1 三道题的范围与考察意图
第一题是日志溯源。题目给了一份 nginx 的 access.log，总共几万行，要求从里面还原攻击者的完整行为路径：从哪个 IP 进来、访问了哪些路径、做了什么类型的尝试、最终有没有成功。这道题考察的是日志分析基本功，核心不是跑命令，而是怎么在海量记录里快速锁定异常，再用证据链把"灰飞烟灭"的访问过程串联起来。
第二题是口令存储方案分析。题目给了一段 PHP 代码片段，内容是把用户密码用 md5($password) 直接存储，要求指出问题、解释原理、给出加固方案。这道题偏理论，但非常贴近实际——我见过不少早期遗留系统到现在还是这么存密码的，所以它不是在考你会不会背 MD5 的缺点，而是考你能否给出一套可落地的整改建议。
第三题是主机权限加固。题目给了一份 Linux 用户列表、sudo 配置和关键目录权限的截图，要求列出风险点，并给出修改后的配置。这道题是实打实的动手题，需要你理解 Linux 权限模型、sudo 规则、ACL 等多层机制，还得考虑"改完之后服务还能不能正常跑"。
1.2 我给自己定的解题顺序
拿到题我没有按题号顺序做，而是先评估了每道题的时间成本。
日志题最花时间，因为要反复看日志、验证结论，所以放在最先做，这样后面有充足时间沉淀思路。口令题虽然是理论题，但写起来容易，需要把几个算法的对比讲清楚，我放在第二。权限加固题需要动手测试，我把它放在最后，因为改错权限导致服务起不来的概率最高，放在最后一步不容易影响前面交作业的节奏。
这个顺序说白了就是：先做最不确定的，再做确定但需要打磨的，最后做可能会有意外状况的。实际执行下来，确实比按题号顺序写省心很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 日志溯源题：用一条异常 IP 串起整个攻击链
2.1 锁定异常 IP 的具体方法
拿到 access.log 的第一件事不是直接打开看内容——几万行直接看会看到眼瞎，效率极低。我先统计每个 IP 的访问次数，把 Top 10 拉出来。
bash复制awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
这一条命令输出如下格式：
code复制 4876 10.12.34.56
2134 192.168.1.88
908 172.16.3.77
...
10.12.34.56 的访问次数遥遥领先，但 IP 访问次数高不代表一定是恶意，也有可能只是公司出口 IP 做健康检查。所以下一步要看这个 IP 到底访问了什么。
继续用 grep 把该 IP 的全部请求拎出来，单独存成一个文件，再按时间和路径观察：
bash复制grep '10.12.34.56' access.log > ip_10.12.34.56.log
less ip_10.12.34.56.log
观察之后发现几个特征：
- 请求时间非常规律，几乎固定每隔 2 到 3 秒出现一次，像机器脚本而非人工行为。
- 请求路径从根路径
/逐渐扩展到/admin、/login、/api/v1/user、/backup.zip等敏感路径。 - 大量请求返回 404，但也有一部分返回 200 和 302。
- User-Agent 固定为一个不常见的字符串，明显不是主流浏览器。
到这里基本可以判定：这不是正常的访问流量，而是对站点进行目录枚举和敏感文件探测的脚本行为。
2.2 时间戳、User-Agent 与状态码的交叉验证
只靠访问频率高就下结论，说服力不够。做题时我特意做了三个维度的交叉验证。
时间戳维度。 正常用户访问网站的时间分布是随机的，会有停顿、有跳跃，但脚本请求间隔非常稳定。我把相邻请求的时间差算出来，大部分都在 1 到 3 秒之间，方差极小。这种规律性本身就是机器行为的重要信号。
User-Agent 维度。 这个 IP 的 User-Agent 是 python-requests/2.31.0。虽然攻击者可以伪造成 Chrome 或 Firefox，但很多自动化脚本不会专门改 UA，直接用默认值。这里可以作为辅助判断依据，但不能单独作为证据——有些爬虫也会用默认 UA，但爬虫和恶意扫描的性质完全不同。
HTTP 状态码维度。 我按状态码统计了这个 IP 的请求分布：
| 状态码 | 次数 | 含义 |
|---|---|---|
| 200 | 156 | 路径存在，正常响应 |
| 404 | 4217 | 路径不存在，说明在大量枚举 |
| 302 | 98 | 重定向，可能是访问需要认证的路径被跳转到登录页 |
| 403 | 37 | 目录存在但禁止访问 |
一个扫描类 IP 出现大量 404（超过 80%），同时有少量 200 和 403，强烈说明它是在探测目录结构。尤其是 403 的存在，往往表明有些路径是存在的，但访问被拒绝，这会进一步刺激攻击者尝试绕过。
把三个维度的证据拼在一起，结论就清晰了：10.12.34.56 正在对目标进行目录枚举和后端路径探测，UA 特征和请求频率都指向自动化工具，时间集中在凌晨 2 点到 4 点之间，正好避开监控高峰。
2.3 从单点告警还原完整行为链
锁定了 IP 之后，我开始按时间线把它的请求顺序排列，尝试还原攻击路径。这一步我用了一个小技巧：把日志里的时间列单独提出来，转成 Unix 时间戳，再配合 sort 命令按时间排序。这样就能看到攻击者先访问了什么、后访问了什么。
观察到的路径顺序如下：
- 先访问
/和/robots.txt，这是攻击者用来了解站点结构的常规操作。 - 接着访问
/admin、/wp-login.php、/backup.zip等常见后台路径。 - 然后访问
/api/v1/user/这类 API 路径，并携带?id=1、?id=2之类参数，疑似尝试遍历接口。 - 最后尝试向
/upload/目录发送 POST 请求，但被 403 拒绝。
这条链路非常完整：从信息收集 → 路径枚举 → 接口探测 → 上传尝试。虽然最终没有攻击成功的迹象，但行为意图已经非常明确。
这道题真正想考察的不是"你跑了几条命令"，而是你有没有能力把分散的日志记录拼成一条有逻辑的线。告警只是告诉你"有事发生"，但具体发生的是什么、影响范围有多大，要靠日志链来还原。
2.4 做题过程中最容易忽略的坑
日志分析题有个很容易踩的坑：看到异常 IP 就急着下"被入侵"的结论。我第一遍写 wp 的时候，把"攻击者上传了 WebShell"写进了结论，后来复查才发现那个 POST 请求返回的是 403，根本没有上传成功。如果这是真实应急响应场景，这个结论会直接带偏处置方向。
正确的做法是把结论分档：
| 证据强度 | 结论 |
|---|---|
| 强证据 | 攻击者上传了 WebShell 且成功执行，需按安全事件处理 |
| 中证据 | 攻击者存在探测和访问行为，但未发现写入痕迹，建议阻断并持续监控 |
| 弱证据 | 只有高频访问，无明确恶意 payload，需进一步分析 |
作业里的日志只到中证据级别，所以我在 wp 里的结论写的是"探测与枚举行为，需采取阻断措施"，而不是"已被入侵"。
3. 口令存储方案分析：这段示例代码问题出在哪
3.1 作业给出的代码与问题定位
第二道题给了一段典型的老式代码，核心逻辑如下：
php复制<?php
// 用户注册时
$password = $_POST['password'];
$hash = md5($password);
$sql = "INSERT INTO users (username, password) VALUES ('$username', '$hash')";
?>
这段代码的问题不止一个，我从严重程度从高到低列了一遍：
- 口令以可逆或弱哈希形式存储。如果直接存明文，那是最严重的；这里用了 MD5，虽然比明文好一点，但 MD5 已经被证明不具备防碰撞能力，且在口令存储场景下计算速度太快，极易被暴力破解。
- 没有加盐（salt）。两个用户若设置相同口令，生成的哈希值完全一致。攻击者一旦拿到哈希表，可以直接通过频率分析猜出哪些用户使用了弱口令。
- 没有使用专业的口令哈希算法。像 bcrypt、scrypt、argon2 这类算法在设计时专门考虑了抗 GPU 暴力破解，而 MD5 和 SHA-1 系列是为快速校验设计的，方向完全不同。
3.2 为什么"快速哈希"不适合存口令
这是我做题时想得比较深的一点。MD5、SHA-1、SHA-256 这些算法设计的初衷是文件完整性校验、数字签名等场景，要求计算速度越快越好，越快则校验效率越高。但口令存储场景恰好相反——我们希望攻击者在拿到哈希后花费尽可能长的时间去破解。
打个比方，普通文件的校验码就像办公室大门钥匙，一拧就开，方便日常进出。而口令哈希应该是银行金库的锁，开锁过程故意设计成需要 3 秒而不是 0.1 秒，这样小偷即便拿到锁，也无法在短时间内批量试出密码。bcrypt 和 argon2 就是这种"故意慢"的锁，可以通过参数调节计算成本，让单次哈希耗时从毫秒级提升到百毫秒级甚至秒级。
我在作业里用 Python 做了一个小测试，对比了 MD5、SHA-256、bcrypt 在同一口令下的耗时。
python复制import hashlib
import bcrypt
import time
password = b"Tr0ub4dor&3"
start = time.time()
for _ in range(10000):
hashlib.md5(password).hexdigest()
print(f"MD5 10000次耗时: {time.time() - start:.4f}s")
start = time.time()
for _ in range(10000):
hashlib.sha256(password).hexdigest()
print(f"SHA-256 10000次耗时: {time.time() - start:.4f}s")
salt = bcrypt.gensalt(rounds=12)
start = time.time()
for _ in range(100):
bcrypt.hashpw(password, salt)
print(f"bcrypt(rounds=12) 100次耗时: {time.time() - start:.4f}s")
输出结果大致如下：
code复制MD5 10000次耗时: 0.2315s
SHA-256 10000次耗时: 0.4121s
bcrypt(rounds=12) 100次耗时: 3.2030s
这个差距非常直观：同样的口令，MD5 每秒钟能算几万次，而 bcrypt 每秒钟只能算三十几次。如果攻击者拿到的是 MD5 哈希，配合 GPU 可以在短时间内尝试海量口令；但如果拿到的是 bcrypt 哈希，同样算力下破解效率会骤降几个数量级。
3.3 加盐与彩虹表：为什么盐让预计算失效
关于"加盐"这个概念，我特意在笔记里用自己的话重新讲了一遍。加盐就是在计算哈希之前，给原始口令拼接一段随机字符串，再对这个组合串做哈希。
python复制import hashlib
import secrets
password = "Tr0ub4dor&3"
salt = secrets.token_hex(16) # 生成 16 字节随机盐
salted_hash = hashlib.sha256((salt + password).encode()).hexdigest()
print(f"salt: {salt}")
print(f"hash: {salted_hash}")
加盐的核心价值在于让每个用户的哈希都变得独一无二。即使 A 和 B 用了完全相同的口令，因为盐不同，最终的哈希值也不同。攻击者如果想用彩虹表破解，必须为每一个盐值单独生成一整张表，而这个盐值的随机空间大到让预计算成为不可能——彩虹表在加盐面前基本失效。
有一点需要注意：盐本身不是机密，不需要严格保密。盐的价值在于增加预计算的成本，而不是作为密钥。所以盐可以跟哈希值一起存在数据库里，这在实际业务中是完全可接受的。
3.4 各类哈希算法的适用场景对比
我整理了一张表，方便自己将来做技术方案时直接参考：
| 算法 | 输出长度 | 同口令哈希是否固定 | 计算速度 | 适用场景 |
|---|---|---|---|---|
| MD5 | 128 bit | 是（无盐时） | 极快 | 文件校验，不适用口令存储 |
| SHA-1 | 160 bit | 是（无盐时） | 快 | 已淘汰，不推荐 |
| SHA-256 | 256 bit | 是（无盐时） | 快 | 数据完整性校验、证书签名，不适用口令存储 |
| bcrypt | 192 bit 左右 | 否（自动加盐） | 慢 | 口令存储，推荐 |
| scrypt | 可变 | 否（自动加盐） | 慢 | 口令存储，抗硬件破解强 |
| argon2 | 可变 | 否（自动加盐） | 慢 | 口令存储，目前安全强度最高 |
关于 argon2，实际生产环境用的会比 bcrypt 少一些，因为很多开发框架默认还没切换到 argon2。我的建议是：如果框架只支持 bcrypt，就用 bcrypt；如果条件允许，优先用 argon2。
3.5 加固方案的完整表述
这道题最后要求给出加固方案，我分了三个层面写：
代码层： 使用 password_hash() 或 bcrypt.hashpw() 替代 MD5；为每个用户独立生成随机盐；把 cost/rounds 参数调到一个合理的值，比如 bcrypt 的 rounds=12。
业务层： 增加登录失败次数限制和锁定策略，防止在线暴力破解；支持多因素认证，即使口令泄漏也能拦截大部分风险。
制度层： 定期提醒用户更换口令，但不要强制要求每 30 天必须改一次——研究表明频繁强制改密会导致用户使用弱口令或把口令写在便签上，反而降低安全性。
4. 主机权限加固：最小权限原则不是一句口号
4.1 初始配置里的三个高危点
第三题给了一台 Linux 主机的配置信息，我看了一眼就发现三个非常典型的高危点：
高危点 1：root 用户允许直接 SSH 登录，且启用了密码认证。 这意味着攻击者只要拿到 root 的弱口令，就能直接获得最高权限。正确做法是禁用 root 远程登录，改用普通用户登录后通过 sudo 提权。
高危点 2：所有运维用户都在 sudo 组，且拥有 ALL=(ALL) ALL 权限。 这是"图省事"的典型配置。sudo 的本意是让普通用户临时获得特定命令的权限，但 ALL 权限等于把所有用户都变成了 root，一旦某个用户账户被攻破，攻击者立刻就能获得整个系统控制权。
高危点 3：应用数据目录权限为 777。 很多部署脚本图省事，直接把 /var/www/html 之类的目录设为 777，导致系统上任何用户都能读写这些文件。攻击者不需要提权就能篡改网站内容或植入恶意文件。
4.2 设计加固方案时的两个关键问题
动手写配置之前，我先想清楚了两件事。
第一，谁是这台主机的"业务角色"？ 是 Web 服务器、数据库服务器，还是开发测试机？角色不同，最小权限的具体定义就不同。题目里的主机是一个典型的 Web 服务器，所以 Apache/Nginx 进程需要读取网站文件、写入日志，但这些操作并不需要 root 权限。
第二，每个运维用户需要哪些命令？ 多数运维日常只需要执行日志查看、服务重启、配置检查和文件编辑等操作，根本不需要完整的 root shell。我可以把它们拆成具体的授权命令，而不是直接给 ALL。
4.3 我实际执行的加固步骤
我在自己的测试环境里完整做了一遍加固，以下是可以直接参考的步骤。
第 1 步：创建专用运维用户，而不是共用一个 root。
bash复制useradd -m -G wheel deployer
passwd deployer
第 2 步：配置 SSH 公钥登录，禁用 root 远程登录和密码登录。
bash复制mkdir -p /home/deployer/.ssh
echo "ssh-rsa AAAA... user@workstation" >> /home/deployer/.ssh/authorized_keys
chown -R deployer:deployer /home/deployer/.ssh
chmod 700 /home/deployer/.ssh
chmod 600 /home/deployer/.ssh/authorized_keys
然后修改 /etc/ssh/sshd_config：
code复制PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
改完记得 systemctl restart sshd。这一步有个大坑：如果你忘了先把公钥放到 authorized_keys 里，直接重启 sshd，你会把自己锁在门外。 我建议在修改之前开一个 SSH 会话保持连接，改完配置后另开一个新会话测试，确认能登录成功再关掉旧会话。
第 3 步：收紧 sudo 权限。
先把 deployer 从所有组里拿出来，单独加入 sudo 组，然后编辑 /etc/sudoers.d/deployer：
code复制deployer ALL=(ALL) /usr/bin/systemctl restart nginx
deployer ALL=(ALL) /usr/bin/systemctl reload nginx
deployer ALL=(ALL) /usr/bin/journalctl -u nginx
deployer ALL=(ALL) /usr/bin/tail -f /var/log/nginx/*
这样部署人员只能重启和查看 Nginx 服务，无法执行 useradd、passwd、chmod 等系统管理命令。修改 sudoers 必须用 visudo 命令，因为它会在保存前做语法检查，避免写错导致所有用户都没办法提权。
第 4 步：修正文件目录权限。
bash复制chown -R root:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
网站目录由 root 拥有、www-data 组可读，Web 进程能读文件但无法写入，需要上传文件的目录（如 uploads）单独设置为 775 且属组为 www-data，并确认该目录不被 Web 入口直接访问。
第 5 步：启用 auditd 审计关键文件变更。
bash复制apt install auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/sudoers -p wa -k sudoers_changes
auditctl -w /var/www/html -p wa -k webroot_changes
这一步的作用是，即使后续有人改了配置，管理员也能通过 ausearch -k sudoers_changes 定位到操作者和变更时间。
4.4 加固后的验证：不能只改不测
加固方案写完之后，我模拟了三个场景做验证：
- 普通用户执行 systemctl 重启 Nginx：确认可以执行。
- 普通用户执行 passwd root：确认被拒绝，提示权限不足。
- root 远程登录：确认连接被拒绝，提示密码认证不可用。
这个验证环节非常重要。很多加固方案写完看上去很完美，但实际一测才发现要么权限收得过头导致服务起不来，要么某条 sudo 规则语法错误导致所有人都无法提权。我在测试过程中就踩过一个 sshd 配置的坑——忘了把 PasswordAuthentication 注释掉，导致新配置没生效，还好我保留了旧会话才能抢救。
5. 这次作业带来的三点学习体会
5.1 对"确定攻击者意图"这件事的理解
以前我以为日志分析就是"找到攻击者 IP"，这次做完之后我的想法变了。找到异常流量只是第一步，真正的难点在于判断对方到底想干什么、做到哪一步、有没有成功。一个 IP 即使访问了一百遍后台路径，只要没有突破认证、没有写入文件，它的影响和"已经上传了恶意文件"的事故等级完全不同。做题时把结论写清楚、把证据链列出来，比抛出一个吓人的结论更有价值。
5.2 复盘比做题更重要：把 wp 变成自己的知识库
交作业不是终点。我会把每道题里用到的命令、犯过的错误、卡壳的地方整理进自己的笔记，并且用一种特殊的方式记录——把知识点写成问题，而不是写成结论。
比如，我不会写"MD5 不适合存储口令"，而是写"为什么 MD5 不适合存储口令？"；不会写"需要加盐"，而是写"加盐是如何让彩虹表失效的？"。下次复习时，看着提问比看着结论更能倒逼自己思考。这个方法我试了一个月，记忆效果比来回看图文笔记好很多。
5.3 给准备做这类作业的同学的三点建议
建议一：环境比答案重要。 日志分析、权限加固这类题目一定要动手搭环境。拿虚拟机或容器开一个测试系统，把题目里的配置复制进去，亲手跑一遍。光看我的 wp 或者对照答案去理解，跟实际动手的差距非常大。
建议二：改配置前先留后路。 做 sshd 配置、sudoers 修改之前，先打开一个额外的 SSH 会话，或者准备一个定时任务把配置文件自动恢复。万一改错了，还能有办法救回来，不至于把唯一入口也堵死。
建议三：多问一句"如果我是攻击者"。 无论是看日志还是看权限配置，我都会强迫自己切换视角：如果我是攻击者，看到这个目录权限会怎么利用？看到这个空口令哈希会怎么做？这种换位思考练多了，你会发现漏洞识别的敏感度提升非常快。