企业官网建设流程全解析

简介：cis-cat漏扫工具是一套面向系统管理员与安全运维人员的安全合规性评估资源，基于CIS基准对操作系统配置与漏洞进行自动化检查，帮助快速定位不合规项并给出修复方向，适用于Windows、Linux、Unix等环境的日常安全自查与合规整改场景。压缩包共152个文件，约52.94MB，以74个exe可执行程序、34个jar组件、16个pyd与14个dll动态库为主，辅以少量txt、pdf、xml说明文档及ps1、bat、sh脚本，整体为可独立运行的轻量级扫描工具形态。目前已有1475人学习下载。借助该工具，读者可完成基准扫描、查看含严重程度与修复建议的详细报告，并依据规则库迭代更新持续发现新风险，为系统加固与合规检查提供可落地的参考。

1. cis-cat漏扫工具：为什么合规检查总在“最后一公里”翻车

做过等保、做过主机加固的人大概率都遇到过这种场面：配置基线文档写得漂漂亮亮，脚本也跑过一遍，结果一到正式检查，某个内核参数、某条审计规则、某个服务端口还是被判不合格。问题往往不在“有没有做”，而在“做完之后有没有按同一把尺子复核”。cis-cat漏扫工具就是干这件事的——它把 CIS Benchmark（互联网安全中心发布的系统加固基准）变成可执行的检查项，对目标主机做配置层面的合规扫描，输出“通过/不通过/需人工确认”的清单。

它适合三类人：一是负责主机基线落地的运维，需要批量验证几十上百台机器；二是做等保整改的安全工程师，要把“配置合规”这一块讲清楚；三是刚接手合规工作的新手，想找一个能本地跑、结果可解释的入口。这篇不堆概念，按“装起来 → 跑通一次 → 看懂结果 → 调参数 → 避坑”的顺序讲，中间给可抄的命令和配置，最后落到一个能长期用的复核习惯上。

2. 先把扫描跑通：cis-cat的部署形态与最小执行链路

cis-cat 常见有两种形态：一种是带图形界面的 CIS-CAT Pro Assessor，另一种是命令行版（Assessor CLI），后者更适合放进自动化流程。无论哪种，核心链路是一样的：准备 Java 运行环境 → 放入 Benchmark 内容文件 → 指定目标与扫描配置 → 执行 → 生成报告。下面按命令行版讲，因为它的参数和退出码最容易被脚本消费。

2.1 运行环境与目录结构：别把内容文件和工具混在一起

cis-cat 依赖 Java，先确认版本。很多“跑不起来”的案例，最后都落在 Java 版本不匹配上。

# 查看当前 Java 版本，cis-cat 通常要求 Java 8 或 11 java -version # 建议单独建目录，工具和内容文件分开，升级时不互相覆盖 mkdir -p /opt/cis-cat/{assessor,benchmarks,reports} cd /opt/cis-cat/assessor

逻辑说明：java -version用来确认运行时存在且版本在支持范围内；目录拆成assessor（工具本体）、benchmarks（Benchmark 内容）、reports（输出）三块，是为了后续替换 Benchmark 版本时不动工具目录。参数上唯一要注意的是：如果机器上有多个 Java，用update-alternatives或显式JAVA_HOME指到正确那个，否则会出现“命令行能跑、扫描中途报类找不到”的玄学问题。

2.2 最小扫描命令：一条命令跑通本地合规检查

假设工具解压后主入口是Assessor-CLI.sh，Benchmark 内容放在benchmarks下，最小执行如下：

# 对本机执行一次合规扫描 # -b 指定 Benchmark 文件，-p 指定扫描配置文件，-rd 指定报告输出目录 ./Assessor-CLI.sh \ -b ../benchmarks/CIS_Benchmark_v1.0.0-xccdf.xml \ -p ../benchmarks/profile_level1_server.xml \ -rd ../reports/local_scan_$(date +%Y%m%d)

逻辑说明：-b指向 XCCDF 格式的基准文件，它定义了“检查什么”；-p指向 profile，决定“按哪个等级检查”，比如 Level 1 Server 只覆盖基础项，Level 2 会包含更严格但可能影响业务的项；-rd是报告目录，用日期命名方便回溯。执行完先别急着看 HTML，先看退出码和终端最后几行——如果提示“no profile matched”，多半是 profile 的 id 写错或 Benchmark 版本与 profile 不配套。

2.3 远程扫描：把目标清单和凭据准备好再动手

批量场景下更常用的是远程扫描。cis-cat 通过 SSH 连到目标执行检查，所以目标侧要有可用账号，且该账号具备读取配置文件的权限。

# 远程扫描：-t 指定目标，-u/-p 指定 SSH 凭据 # 生产环境建议用密钥，避免密码出现在命令历史里 ./Assessor-CLI.sh \ -b ../benchmarks/CIS_Benchmark_v1.0.0-xccdf.xml \ -p ../benchmarks/profile_level1_server.xml \ -t 192.0.2.10 \ -u audit_user \ -k /home/audit/.ssh/id_rsa \ -rd ../reports/remote_192.0.2.10

逻辑说明：-t可以是单 IP，也可以是一个文本清单（每行一个目标），具体取决于版本；-k指定私钥，比-p传密码更安全，也避免密码被ps看到。这里最容易翻车的是权限：审计账号如果不能用sudo读/etc/shadow、/etc/ssh/sshd_config这类文件，扫描结果会大量出现“无法确定”，看起来像“不通过”，实际是“没权限看”。

3. 看懂结果：报告里哪些是“真问题”，哪些是“误报”

扫描跑完只是开始，报告解读才是分水岭。同一份报告，有人读出 30 个待整改项，有人读出 5 个，差别在于是否理解检查项的判定逻辑。

3.1 结果状态的含义：pass/fail/notapplicable/unknown 怎么区分

cis-cat 的结果通常分几类：pass（通过）、fail（不通过）、notapplicable（不适用）、unknown（无法判定）、manual（需人工确认）。其中unknown和manual最容易被误当成 fail 去整改，浪费大量时间。

逻辑说明：把unknown单独拎出来，是因为它和fail的整改动作完全不同——前者是“扫描条件没满足”，后者是“配置确实不对”。我一般会先把所有unknown过一遍，确认是不是审计账号权限或缺少某个命令导致的，再去看fail。

3.2 从报告定位到具体配置：以 SSH 和审计规则为例

报告里每个检查项都有 rule id、标题、当前值和期望值。以 SSH 配置为例，常见检查项是“是否禁用 root 直接登录”“是否限制空密码”。定位时不要只看标题，要看它实际读的是哪个文件、哪一行。

# 手动复核报告里提到的 SSH 检查项，确认扫描结果与现状一致 grep -Ei '^\s*(PermitRootLogin|PermitEmptyPasswords|Protocol)' /etc/ssh/sshd_config # 审计规则类检查项，确认规则是否真的加载 auditctl -l | grep -i execve

逻辑说明：第一条命令直接看 sshd 配置里相关指令的当前值，和报告里的“当前值”对照，能快速判断是扫描误读还是配置真有问题；第二条看审计规则是否生效，因为有些规则写在文件里但没加载，扫描读文件会判 pass，实际运行时并没有生效——这类“文件对、运行不对”的情况，是合规检查里最隐蔽的坑之一。

3.3 报告归档与对比：让两次扫描能看出“改没改”

单次报告只能说明当下状态，真正有价值的是前后对比。建议每次扫描输出到带日期和目标的目录，并保留原始 XML 结果，方便用脚本做 diff。

# 保留原始结果，便于后续对比 ls -l ../reports/remote_192.0.2.10/ # 典型输出包含 HTML 报告和 XML 原始结果 # 用 diff 对比两次扫描的 fail 项数量变化 grep -c 'result="fail"' ../reports/remote_192.0.2.10/*.xml

逻辑说明：grep -c只是快速统计 fail 数量，真正做对比要按 rule id 对齐。参数上注意：不同次扫描如果用了不同 profile，结果没有可比性，所以报告目录命名里最好带上 profile 名，避免“拿 Level 1 的结果去对比 Level 2”这种低级错误。

4. 参数与调优：让扫描既准又不拖垮业务

cis-cat 默认配置偏向“查得全”，但在生产环境直接跑，可能遇到超时、目标负载升高、结果噪声大等问题。这一章讲几个真正需要调的参数和取舍。

4.1 超时与并发：批量扫描时先小范围试跑

远程扫描时，目标多、网络慢，容易出现个别目标超时导致整体耗时拉长。常见做法是先拿 2 到 3 台试跑，确认单台耗时，再决定批量规模。

# 伪代码：控制并发，避免一次性打满目标 # 实际参数名以所用版本为准，这里示意思路 for host in $(cat hosts.txt); do ./Assessor-CLI.sh -b ../benchmarks/CIS_Benchmark_v1.0.0-xccdf.xml \ -p ../benchmarks/profile_level1_server.xml \ -t "$host" -u audit_user -k /home/audit/.ssh/id_rsa \ -rd ../reports/"$host" & # 控制同时运行的任务数，例如每 5 个等待一次 done wait

逻辑说明：并发不是越高越好，SSH 连接数和目标侧命令执行都会消耗资源。参数上，如果工具本身提供超时设置，把它设成单台平均耗时的 2 到 3 倍；如果没有，就在外层脚本控制并发数。血泪经验是：一次性对上百台机器并发扫描，目标侧的审计日志和 CPU 都可能被拉高，反而影响业务。

4.2 profile 选择：Level 1 和 Level 2 的边界在哪

Level 1 通常是“不影响业务功能”的基础加固项，适合所有生产服务器；Level 2 包含更严格但可能影响兼容性的项，比如某些内核参数、某些服务禁用。选错 profile 的后果是：要么漏掉关键项，要么把业务搞挂。

逻辑说明：如果业务方明确说“这台机器不能停”，优先用 Level 1，把 Level 2 的项单独列出来做人工评估。参数上，自定义 profile 时一定要记录“为什么豁免”，否则下次检查换个人就说不清楚。

4.3 结果过滤：把“不适用”和“已豁免”分开管理

报告里notapplicable和人工豁免项混在一起，会让整改清单越来越长。建议在流程上分两张表：一张是“待整改”，一张是“已评估豁免”，后者要写清理由和评估人。

# 从 XML 结果里提取 fail 项，生成待整改清单 # 具体 XPath 以实际报告结构为准，这里示意 grep -o 'rule-id="[^"]*"[^>]*result="fail"' ../reports/remote_192.0.2.10/*.xml \ | sed 's/.*rule-id="\([^"]*\)".*/\1/' | sort -u > fail_rules.txt

逻辑说明：把 fail 项单独抽出来，是为了让整改清单可跟踪。参数上，sort -u去重，避免同一 rule 在多处出现导致重复统计。注意：抽取规则要跟报告实际结构对齐，不同版本 XML 的标签名可能不同，先拿一份样本确认再写脚本。

5. 避坑与排查：cis-cat 落地时最容易踩的五个坑

这一章按“现象 → 原因 → 解决”写，都是实际环境里反复出现的。

5.1 扫描结果大量 unknown，看着像全不合格

现象：报告里一半以上是unknown，整改无从下手。 原因：审计账号权限不足，读不到关键配置文件；或目标缺少某些命令，检查项无法执行。 解决：给审计账号配置最小必要的 sudo 权限，只放开读取类命令；先在一台机器上手动执行报告里提到的命令，确认哪些是权限问题、哪些是命令缺失。

5.2 同一台机器两次扫描结果不一致

现象：间隔几分钟跑两次，fail 项数量不一样。 原因：部分检查项依赖运行时状态（如进程、端口、临时文件），状态变化会导致结果波动；也可能是扫描时目标正在做变更。 解决：固定扫描时间窗口，避开变更期；对运行时类检查项，在报告里标注“需结合当时状态判断”，不要当成配置漂移。

5.3 报告说 pass，实际检查却不通过

现象：cis-cat 判 pass，但正式检查时被判不合格。 原因：检查项读的是配置文件，而实际运行参数被其他机制覆盖，比如配置写了但服务没重载，或者有更高优先级的配置片段。 解决：对关键项做“文件 + 运行时”双重确认，比如 SSH 配置改完要sshd -T看生效值，审计规则要auditctl -l确认已加载。

5.4 批量扫描把目标 SSH 连接数打满

现象：扫描中途大量目标报连接失败，业务侧也反馈登录变慢。 原因：并发过高，SSH 连接数超过目标MaxStartups限制。 解决：降低并发，或在目标侧临时调整 SSH 连接限制；更稳妥的做法是分批扫描，每批之间留间隔。

5.5 升级 Benchmark 后旧报告无法对比

现象：换了新版本 Benchmark，rule id 和检查项都变了，历史报告对不上。 原因：Benchmark 版本升级会增删和重编号检查项。 解决：升级前先记录旧版本号和 profile，升级后重新建立基线，不要拿新旧报告直接 diff；如果必须对比，先做 rule id 映射表。

6. 把 cis-cat 用成长期习惯：一个可复用的复核节奏

工具本身不难，难的是让它持续产生价值。我自己的做法是：把 cis-cat 当成“配置变更后的复核手段”，而不是“一年跑一次的检查任务”。具体节奏是——任何涉及主机基线的变更（改 SSH、调内核参数、加审计规则）完成后，对相关机器跑一次单机扫描，确认没有引入新的 fail；每月对核心资产做一次批量扫描，输出 fail 趋势；每季度对照 Benchmark 版本更新一次 profile，评估是否需要调整豁免清单。

验证扫描是否“真的有效”，可以做一个简单测试：手动把某个已知检查项改坏，比如临时把PermitRootLogin改成yes，跑一次扫描，看报告是否准确标出 fail。如果没标出来，说明扫描链路或 profile 有问题，先修工具再谈整改。

# 验证扫描有效性：改坏一个配置，扫描应能捕获 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sed -i 's/^PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config sshd -t && systemctl reload sshd # 跑一次扫描，确认对应 rule 变为 fail # 验证后恢复 mv /etc/ssh/sshd_config.bak /etc/ssh/sshd_config systemctl reload sshd

逻辑说明：这个测试的价值在于确认“扫描器真的在读配置”，而不是只看报告数量。参数上，改完一定要sshd -t做语法检查再 reload，避免把 SSH 改挂导致失联——这种翻车一旦发生在远程机器上，后悔药是没有的。

最后说一个我自己的习惯：每次扫描完，不只看 fail 数量，而是随机抽 3 个 pass 项手动复核。因为漏报比误报更危险，误报最多浪费点时间，漏报会让你在正式检查时措手不及。这个习惯坚持下来，比任何工具参数都管用。希望帮到你。

本文还有配套的精品资源，点击获取