在网络安全领域，漏洞扫描是保障系统安全的第一道防线。CIS（Center for Internet Security）基准作为一套被广泛认可的安全配置标准，为各类系统和应用提供了“安全加固”的最佳实践指南。然而，很多安全工程师和运维人员在初次接触CIS合规性扫描时，心中常有一个疑问：当扫描仪对准我的服务器、数据库或中间件时，它究竟在“看”什么？扫描报告里那些“通过”、“失败”和“不适用”的结果又是如何产生的？
本文将深入CIS扫描的“黑盒”，以一台典型的Linux服务器和一款常见的Web应用（如Nginx）为例，完整拆解扫描过程背后的技术原理。我们将从环境准备开始，一步步解读扫描策略，分析典型扫描项，并最终生成一份可操作的合规报告。无论你是负责安全合规的工程师，还是希望提升系统安全性的开发者，都能通过本文理解CIS扫描的工作机制，并掌握根据扫描结果进行有效修复的完整流程。
1. CIS扫描核心概念与工作原理
在深入实操之前，有必要厘清几个关键概念，这有助于理解后续整个扫描流程的逻辑。
CIS基准（CIS Benchmark） ：它不是一款软件，而是一份份详细的、针对特定操作系统或软件的安全配置指南文档。例如，有《CIS Ubuntu Linux 20.04 LTS Benchmark》、《CIS Apache HTTP Server Benchmark》等。每份基准都包含一系列的安全建议（Recommendations），每条建议都对应一个具体的配置检查点。
CIS扫描工具（CIS-CAT Pro, OpenSCAP等） ：这些是能够自动化执行CIS基准检查的软件。它们的工作原理是，将CIS基准文档“翻译”成机器可执行的检查逻辑（通常以XML格式的策略文件存在，如DataStream文件），然后在目标系统上运行这些检查。
扫描过程本质 ：扫描工具在目标机器上（通过远程SSH或本地Agent）执行一系列预定义的命令、脚本，或读取特定的配置文件、系统状态信息，然后将获取的实际结果与CIS基准中定义的“期望安全状态”进行比对。整个过程可以概括为“采集 -> 比对 -> 判定”。
典型扫描结果 ：
- PASS ：当前系统配置符合CIS基准的安全建议。
- FAIL ：当前系统配置不符合安全建议，存在风险。
- NOT APPLICABLE ：该条检查不适用于当前系统环境（例如，检查Docker相关配置，但系统未安装Docker）。
- ERROR ：扫描工具在执行检查时遇到意外错误（如权限不足、文件不存在等），无法完成判定。
- NOT CHECKED ：扫描策略中未包含此项检查（在一些简化或自定义的策略中可能出现）。
理解了这些，我们就可以搭建环境，亲眼见证一次扫描的发生。
2. 环境准备与扫描工具选择
为了获得最直观的体验，我们将在本地虚拟机中搭建一个实验环境。选择一款易于获取且社区支持丰富的扫描工具至关重要。
2.1 实验环境搭建
我们将使用以下环境进行演示：
- 目标系统 ：Ubuntu Server 22.04 LTS (运行在VMware/VirtualBox虚拟机中)
-
待扫描软件
：Nginx 1.18.0 (通过
apt安装) - 扫描工具 ：OpenSCAP。这是一款开源的、功能强大的安全合规性评估框架，原生支持CIS基准，非常适合学习和测试。
- 扫描工作站 ：可以是同一台Ubuntu服务器（本地扫描），也可以是另一台能通过SSH访问目标机的Linux/Mac机器（远程扫描）。本文以本地扫描为例。
首先，在Ubuntu目标系统上安装OpenSCAP套件和必要的工具：
# 更新软件包列表
sudo apt update
# 安装OpenSCAP扫描引擎、SCAP工作台(图形化工具，可选)及评估工具
sudo apt install -y openscap-scanner scap-security-guide oscap-utils
# 安装Nginx作为待扫描的应用程序示例
sudo apt install -y nginx
# 验证安装
oscap --version
nginx -v
安装完成后，
scap-security-guide
包为我们提供了丰富的合规性策略文件，包括CIS基准，它们通常位于
/usr/share/xml/scap/ssg/content/
目录下。
2.2 定位CIS基准策略文件
我们需要找到针对Ubuntu 22.04的CIS基准策略。使用以下命令进行查找：
# 查找所有可用的SSG（SCAP Security Guide）数据流文件
find /usr/share/xml/scap/ssg/content/ -name "*.xml" | grep -i ubuntu | grep 22.04
# 一个可能的输出是：
# /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
这个
ssg-ubuntu2204-ds.xml
就是一个DataStream文件，它像一个容器，里面可能捆绑了多个针对不同用途的配置基线（Profile），其中就包含CIS基准。
列出该DataStream中包含的所有基线：
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
在输出的
Profiles
部分，你会看到一长串列表，我们需要寻找标题或ID中包含
cis
字样的。例如，你可能会发现一个ID为
xccdf_org.ssgproject.content_profile_cis
或名称类似
CIS Ubuntu 22.04 LTS Benchmark
的基线。记下这个完整的Profile ID，我们将在下一步使用它。
3. 执行扫描：命令、过程与输出解读
现在，我们使用OpenSCAP对本地系统执行一次CIS合规性扫描。
3.1 执行扫描命令
假设我们找到的CIS基线ID是
xccdf_org.ssgproject.content_profile_cis
。运行以下命令启动扫描：
# 基本扫描命令，结果输出到终端和report.html文件
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis \
--results scan-results.xml \
--report report.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
命令参数解析 ：
-
xccdf eval： 使用XCCDF（一种描述安全检查清单的XML格式）进行评估。 -
--profile： 指定要使用的合规性基线（Profile）。 -
--results： 将详细的扫描结果（包括每条规则的原始输出）保存为XML文件，便于后续程序化分析。 -
--report： 生成一个人类可读的HTML格式报告。 - 最后的XML文件路径： 指定包含基准的DataStream文件。
注意
：扫描需要root权限（
sudo
），因为许多检查需要读取
/etc/
下的系统配置文件、检查进程权限或审计日志设置，这些操作普通用户无法完成。
3.2 扫描过程实时观察
执行命令后，终端会开始滚动输出。你会看到扫描工具正在逐条执行检查，格式如下：
Title Ensure something is configured
Rule xccdf_org.ssgproject.content_rule_some_id
Result pass
---
每一段输出对应CIS基准中的一条具体规则。扫描引擎会：
- 解析规则 ： 从策略文件中读取规则ID、描述和检查逻辑。
-
执行检查
： 运行规则定义的OVAL（一种用于定义检查步骤的XML语言）定义。这可能是一个Shell命令（如
grep、stat）、一个对文件内容的检查，或一个对系统状态的查询。 - 获取结果 ： 捕获命令输出或检查返回值。
- 进行比对 ： 将实际结果与规则中定义的“合规状态”进行比对。
-
输出判定
： 在终端打印
pass、fail、notapplicable或error。
这个过程可能会持续几分钟，取决于基准的复杂度和系统性能。扫描完成后，会生成我们指定的
scan-results.xml
和
report.html
文件。
3.3 解读扫描报告
生成的
report.html
文件是最直观的结果。用浏览器打开它：
# 如果是在有图形界面的系统上，可以直接双击打开。
# 或在终端使用如下的文本浏览器查看（可选）
# links report.html
HTML报告通常包含：
- 执行摘要 ： 总规则数、通过数、失败数、不适用数、错误数。
- 合规率 ： 一个百分比，直观显示系统与CIS基准的符合程度。
- 规则详情列表 ： 每条规则的ID、标题、结果、严重性。你可以点击失败（FAIL）的规则查看详细信息。
-
规则详情页
： 对于某条失败规则，报告会显示：
- 描述 ： 这条规则要解决什么安全问题。
- Rationale（原理） ： 为什么这条配置是重要的。
- 修复方法 ： 具体的、可操作的修复步骤。 这是扫描报告最核心的价值所在 。
- 检查内容 ： 扫描工具具体检查了什么（例如，它执行了哪条命令，检查了哪个文件）。
4. 深度剖析：典型CIS检查项与修复实战
让我们从报告中选取几条常见的、有代表性的“FAIL”项，深入分析扫描仪到底做了什么，以及我们该如何修复。
4.1 案例一：检查密码过期策略
规则标题
：
Ensure password expiration is 365 days or less
扫描仪在做什么
：
扫描工具会检查
/etc/login.defs
配置文件。具体执行逻辑类似于以下命令的自动化版本：
# 扫描工具会读取这个文件，并查找 PASS_MAX_DAYS 参数
sudo grep ^PASS_MAX_DAYS /etc/login.defs
判定逻辑
： 如果
PASS_MAX_DAYS
的值大于365，或者该参数被注释掉（使用默认值，可能非常大），则判定为
FAIL
。
修复操作
：
根据报告提供的修复指南，我们需要编辑
/etc/login.defs
文件：
sudo vim /etc/login.defs
# 找到 PASS_MAX_DAYS 一行，将其修改为符合策略的值，例如90天
PASS_MAX_DAYS 90
修复后验证 ： 可以再次运行针对该条规则的快速检查，或等待下一次全面扫描。
4.2 案例二：检查SSH协议版本
规则标题
：
Ensure only SSH Protocol 2 is used
扫描仪在做什么
：
扫描工具会检查SSH服务端配置文件
/etc/ssh/sshd_config
。其检查逻辑是查看
Protocol
这个配置项。
# 模拟检查：如果配置文件中没有Protocol行，或者Protocol后面包含1，则可能失败
sudo sshd -T | grep protocol
# 或者直接检查文件
sudo grep -i ^protocol /etc/ssh/sshd_config
判定逻辑
： 如果配置中显式设置了
Protocol 1
或
Protocol 2,1
，则判定为
FAIL
。安全的配置应该是
Protocol 2
。
修复操作
：
编辑SSH配置文件：
sudo vim /etc/ssh/sshd_config
# 确保存在如下一行，且没有被注释
Protocol 2
重要提示
： 修改SSH配置后，必须重启SSH服务 (
sudo systemctl restart sshd
)，并且
务必保持一个当前连接不退出
，先新开一个会话测试连接成功后再关闭原会话，以免配置错误导致无法远程登录。
4.3 案例三：检查Nginx配置文件权限
规则标题
：
Ensure NGINX configuration files are owned by root
扫描仪在做什么
：
这条规则来自CIS Nginx Benchmark。扫描工具会定位Nginx的主配置文件和包含的目录（如
/etc/nginx/nginx.conf
,
/etc/nginx/conf.d/
），然后检查这些文件和目录的所有者和权限。它可能执行类似
stat
或
ls -l
的命令来获取元数据。
# 检查Nginx主配置文件的所有者
stat -c "%U %G" /etc/nginx/nginx.conf
# 期望输出是：root root
判定逻辑
： 如果文件的所有者不是
root
，或者所属组不是
root
（或特定的安全组），则判定为
FAIL
。这可以防止非特权用户意外或恶意修改Web服务器配置。
修复操作
：
# 更改所有者和所属组为root
sudo chown root:root /etc/nginx/nginx.conf
sudo chown -R root:root /etc/nginx/conf.d/
# 同时，确保配置文件权限是644（所有者可读写，其他人只读）
sudo chmod 644 /etc/nginx/nginx.conf
sudo chmod 644 /etc/nginx/conf.d/*.conf
通过这些案例可以看到，CIS扫描并非魔法，它本质上是将安全专家手动的、经验性的检查步骤自动化、标准化和规模化。
5. 常见问题与排查思路
在实际使用CIS扫描工具时，你可能会遇到一些典型问题。
| 问题现象 | 可能原因 | 排查与解决思路 |
|---|---|---|
| 扫描速度非常慢 |
1. 基准包含规则极多（如完整CIS基准）。
2. 部分检查涉及网络超时或复杂命令。 3. 系统资源（CPU、IO）不足。 |
1. 考虑使用更聚焦的基线（如
cis_server_l1
Level 1）。
2. 在测试环境进行扫描，避免影响生产。 3. 分析结果XML，找出耗时最长的规则。 |
大量规则结果为
ERROR
|
1. 扫描权限不足（未使用sudo）。
2. 目标系统缺少必要的检查工具（如
auditctl
,
systemctl
）。
3. 策略文件与系统版本不匹配。 |
1.
始终使用root权限执行扫描
。
2. 安装缺失的基础工具包：
sudo apt install auditd systemd -y
。
3. 确认使用的基准版本与操作系统版本完全对应。 |
| 修复后重新扫描，结果未变 |
1. 服务配置未重载（如SSH, Nginx）。
2. 用户密码策略对已存在用户不立即生效。 3. 扫描工具使用了缓存（某些工具可能有此行为）。 |
1. 修改配置后，重启相关服务：
sudo systemctl restart service_name
。
2. 对于密码策略，需对已存在用户使用
chage
命令单独设置。
3. 清除扫描缓存或使用
--force
参数（如果工具支持）。
|
| HTML报告无法显示或样式错乱 | 报告生成不完整，或浏览器兼容性问题。 |
1. 确保扫描命令成功完成，无中途中断。
2. 尝试使用
--report
生成报告时，同时指定
--results
保存原始结果。
3. 用不同的浏览器打开HTML文件。 |
| 远程扫描连接失败 |
1. 网络不通或防火墙拦截。
2. SSH密钥认证失败。 3. 目标主机SSH服务未运行。 |
1. 检查网络连通性（ping, telnet port 22）。
2. 确保使用了正确的SSH私钥，且公钥已部署到目标机。 3. 确认目标机SSH服务状态：
sudo systemctl status ssh
。
|
6. 工程实践与进阶建议
将CIS扫描集成到日常开发和运维流程中，能极大提升整体安全水位。以下是一些最佳实践：
1. 扫描策略分层与裁剪
- 不要盲目追求100%合规 ： CIS基准通常分Level 1和Level 2。Level 1是对安全性和功能性影响最小的项目，建议所有系统执行。Level 2则更严格，可能影响特定应用，需评估后实施。
- 定制化基准 ： 使用OpenSCAP等工具，可以根据实际情况创建自定义的SCAP策略文件，排除那些确实不适用于你业务场景的检查项（例如，某些针对桌面环境的检查对服务器不适用）。
2. 集成到CI/CD管道
-
镜像安全扫描
： 在构建Docker或虚拟机镜像的最后阶段，集成一次CIS扫描。只有通过基线检查的镜像才能被推送到镜像仓库。可以使用
oscap-docker等工具。 -
基础设施即代码（IaC）扫描
： 使用类似
terraform-compliance、checkov等工具，在Terraform代码部署前，检查其定义的资源是否符合安全策略（其中包含CIS规则）。
3. 自动化修复与配置管理
- 修复脚本化 ： 对于反复出现的、通用的FAIL项，可以编写自动化修复脚本（Ansible Playbook, SaltStack State, Puppet Manifest）。例如，一个Ansible任务来统一设置所有服务器的密码策略。
- 与配置管理工具结合 ： 使用Ansible、Chef等工具来强制实施CIS合规配置，确保系统从创建之初就处于安全状态，而不仅仅是事后扫描。
4. 报告管理与持续监控
-
集中化报告
： 对于大规模集群，不宜手动在每个节点生成HTML报告。应考虑使用能集中收集、存储和分析扫描结果的平台，如OpenSCAP的
scap-workbench服务器版，或商业安全合规平台。 - 设定合规基线并监控趋势 ： 定义可接受的合规率（例如，Level 1规则通过率 > 95%）。通过定期（如每周）扫描，跟踪合规率的变化趋势，一旦下降则立即触发告警和排查。
5. 处理“例外”的规范流程
- 在严格的企业环境中，总会有一些FAIL项因业务原因无法立即修复。必须建立“风险例外”审批流程。
- 记录每项例外： 为什么不能修 （业务影响）、 接受了什么风险 、 谁批准的 、 计划何时修复 、 有哪些补偿性控制措施 （如加强监控、网络隔离）。这既是安全审计的要求，也是风险管理的体现。
安全是一个持续的过程，而非一次性的任务。CIS扫描提供了衡量安全状态的标尺和行动的路线图。通过理解其工作原理，熟练运用扫描工具，并将合规性要求有机融入软件开发和系统运维的生命周期，我们才能构建出真正健壮、可抵御威胁的技术架构。
扫一扫
2510
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
