为什么"凭感觉加固"靠不住

很多站长加固服务器的方式是：看到一篇安全文章，照着配几条；出了事，再补几条。这种"凭感觉加固"最大的问题是没有基准——你不知道自己漏了哪些项，也不知道改动是否引入了新风险，更没法在换一台机器后复现同样的安全水位。等到真正需要向客户或平台证明"我的服务器是安全的"时，你手里拿不出任何可量化的证据。

安全基线（Security Baseline）解决的正是这个问题。它把一套公认的安全要求固化成可执行、可检查的规则集，让"加固"从主观经验变成"对着清单打钩、对着分数整改"。在开源世界里，这套标准的代名词就是 SCAP（Security Content Automation Protocol），而它的参考实现就是 OpenSCAP。本文讲清楚 SCAP 是什么、怎么用 oscap 给服务器做一次合规体检、如何读懂结果并生成修复脚本，最后把它变成定期巡检。

SCAP 三件套：标准、内容、扫描器

SCAP 不是某一个软件，而是一组由 NIST 维护的标准集合。理解它只要抓住三层：

• XCCDF（可扩展配置检查清单描述格式）——描述"要检查什么"和"每项的重要级别"，是一份带层级的规则清单。
• OVAL（开放漏洞与评估语言）——描述"怎么检查"，即具体如何读取系统状态并判定通过与否。
• CPE（通用平台枚举）——描述"检查适用于哪些平台"，用于规则与系统的匹配。

三者合起来就是一份"安全内容"（Security Content）。OpenSCAP 则是执行这些内容、跑出报告的扫描器。你要给 Debian/Ubuntu 做基线，需要找到对应平台的安全内容，通常是某个 ssg-*-ds.xml 数据流文件（DataStream）。

安装与获取安全内容

在 Debian/Ubuntu 上安装 OpenSCAP：

apt update
apt install -y libopenscap8 openscap-scanner ssg-debderived ssg-debian

安装后安全内容位于 /usr/share/xml/scap/ssg/content/。先列出系统上有哪些可用的数据流：

oscap info /usr/share/xml/scap/ssg/content/ssg-debian11-ds.xml

输出里会列出 Profiles（配置档）和 Checks。Profile 是预先组织好的规则集合，对应不同的合规标准，比如 CIS Level 1、CIS Level 2、以及等保相关的要求。选取合适的 profile 是决定扫描方向的关键一步，因为标准太严会带来大量误报，太松又失去了意义。

跑一次合规扫描

最基本的用法是选定数据流文件加 profile 名，跑评估并输出结果：

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /root/scap-results.xml \
  --report /root/scap-report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian11-ds.xml

三个参数各有用途：--profile 指定按哪套标准检查；--results 输出机器可读的 XML 结果，供后续分析或对比；--report 生成一份人类可读的 HTML 报告，直接浏览器打开就能看。命令执行过程中，终端会逐条打印每项规则的结果，形如：

Title   Ensure SSH root login is disabled
Rule    xccdf_org.ssgproject.content_rule_sshd_disable_root_login
Result  pass

结果有三种：pass（通过）、fail（不通过）、notapplicable（不适用）。跑完后重点看 fail 的数量和分布。注意：首次扫描几乎必然有一堆 fail，不要慌，这正是基线的价值——它把你所有的安全欠账一次性列出来了。

如果只需要一份评分摘要，不生成完整报告：

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --score /root/score.txt \
  /usr/share/xml/scap/ssg/content/ssg-debian11-ds.xml

读懂报告与优先级排序

用浏览器打开 scap-report.html，你会看到按规则分组的清单，每条带严重度（low/medium/high）和整改说明。面对几十上百条 fail，正确的做法不是一股脑全修，而是按严重度和影响面排序。

通常优先级最高的几类：账户与认证（root 远程登录、空密码账户、密码策略）、网络暴露（不必要的监听端口、IPv6 转发、源路由）、内核与文件权限（SUID 文件、关键文件权限、挂载选项）。这几类一旦出问题，就是直接的入侵入口。相对靠后的是审计日志、时间同步细节这类"纵深防御"项——重要，但紧急度低于前者。

报告里每一条 fail 都附有 Rationale（为什么这条重要）和 Fix（怎么修）。读 Rationale 尤其有价值——它会告诉你这条规则背后防的是什么攻击，而不是让你机械照做。很多站长就是靠读这些说明，第一次真正理解了每条安全配置的意义。

自动生成修复脚本

OpenSCAP 最强的功能之一是能从扫描结果反向生成修复脚本（Remediation）。有两种方式：一是扫描时直接修复，二是先生成脚本再人工审查后执行。生产环境我强烈推荐后者——永远不要直接让扫描器自动改你的生产配置。

先把修复脚本生成出来：

oscap xccdf generate fix \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --fix-type bash \
  --output /root/remediation.sh \
  /root/scap-results.xml

生成的 remediation.sh 是一个 shell 脚本，逐条修复 fail 项。执行前务必：

less /root/remediation.sh        # 通读每一行
bash -n /root/remediation.sh     # 语法检查
grep -nE "rm |dd |mkfs|> ?/etc/(passwd|shadow|fstab)" /root/remediation.sh  # 找危险操作

脚本里常见的操作是修改 /etc/ssh/sshd_config、/etc/sysctl.conf、/etc/pam.d/ 等，其中 sshd_config 的改动可能导致你被锁在门外——比如"禁止 root 登录"和"禁止密码认证"这两条，如果同时生效而你又没有配置好密钥登录，下次连接就进不去了。执行修复脚本前，必须确保已有一个可用的 SSH 密钥登录通道，并且保持一个当前会话不关闭，作为万一失联时的回退。

用 tailoring 定制基线

标准基线不适合所有场景，这时需要裁剪（Tailoring）。比如你的服务器跑的是 Web 服务的宿主机，某些针对桌面系统的规则并不适用；又或者你因为业务原因必须保留某项配置，不想被反复报 fail。OpenSCAP 支持用一份 tailoring 文件覆盖 profile 的选择项：

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --tailoring-file /root/custom-tailoring.xml \
  --report /root/scap-report-tailored.html \
  /usr/share/xml/scap/ssg/content/ssg-debian11-ds.xml

定制化的意义在于：让基线"贴合你的环境"，而不是让环境去硬凑标准。一个被裁剪得当、分数真实可信的基线，远比一个满分但靠豁免规则刷出来的报告有价值。

变成定期巡检

基线扫描做一次没有意义，它必须是周期的。我把它做成一个定时任务，每周跑一次，把结果存档并对比趋势：

#!/bin/bash
# /usr/local/bin/scap-weekly.sh
D=$(date +%Y%m%d)
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /var/log/scap/results-$D.xml \
  --report  /var/log/scap/report-$D.html \
  /usr/share/xml/scap/ssg/content/ssg-debian11-ds.xml > /dev/null 2>&1
# 提取分数并记录
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --score /var/log/scap/score-$D.txt \
  /usr/share/xml/scap/ssg/content/ssg-debian11-ds.xml > /dev/null 2>&1
echo "$D $(cat /var/log/scap/score-$D.txt)" >> /var/log/scap/trend.log

配合 systemd timer 每周触发，trend.log 就会形成一条安全水位曲线。这条曲线的用处很大：分数突然下跌，意味着有人改了配置或新装了软件，你能立刻察觉；分数持续上升，则证明加固工作在稳步推进。安全工作的可见化，全靠这条曲线。

真实复盘：一次"满分"报告背后的假象

说一个值得警惕的案例。有次我扫完一台机器，CIS Level 1 报告的 pass 率高得异常，几乎全绿。我一开始还挺高兴，仔细核对才发现问题：扫描结果里大量规则显示 notapplicable，原因是我选的 profile 是 cis_level1_server，而数据流文件的实际平台标识与当前系统版本存在细微不匹配，导致一部分规则根本没被评估，直接被跳过了。

这个坑的教训是：永远不要只看总分，必须看 pass/fail/notapplicable 三项的具体数量。如果 notapplicable 占比过高（比如超过三分之一），说明数据流和系统不匹配，报告是失真的。正确的做法是先用 oscap info 核对数据流支持的平台，确认 profile 里的规则数量合理，再相信分数。

# 统计结果里三种状态各有多少（把 result 标签的值抓出来再聚合计数）
grep -o "result>[0-9a-zA-Z]*" /root/scap-results.xml | sort | uniq -c

另外还有一个常见误区：把 OpenSCAP 当成一次性工具。它真正的价值在于对比——这次和上次比，fail 减少了多少、有没有新出现的 fail。单次的绝对分数意义有限，趋势才是判断安全状况的关键。

总结

OpenSCAP 把"安全加固"从散点经验升级为可量化、可复现、可审计的工程实践。核心流程就四步：oscap info 选对数据流与 profile → oscap xccdf eval 扫描并生成报告 → 按严重度排序整改、审查后再跑修复脚本 → 用 systemd timer 定期巡检存档趋势。三个必须记住的坑：优先看 pass/fail/notapplicable 三项分布而非总分、生成的支持脚本必须先通读再执行并备好密钥回退通道、扫描要连续做才能看出趋势。对个人站长来说，这套工具的最大意义不在于应付谁，而在于拥有一份属于自己的、能随时拿出来看、能证明"我确实认真对待过服务器安全"的客观依据。