企业官网建设流程全解析

简介：cis-cat是一款基于CIS安全基准的自动化合规性扫描工具，面向系统管理员、安全运维及等保测评人员，专门用于快速发现Windows、Linux、Unix等操作系统层面的配置偏差与安全隐患。它既能自动执行标准基线检查，也支持按需定制扫描规则，并输出含严重程度和修复建议的详细报告；同时也会定期更新规则库以应对新威胁，适合批量基线核查、日常巡检和合规审计等需要管理权限的运维场景。

资源包为zip压缩格式，共152个文件、约52.94MB，内含74个exe可执行程序、34个jar辅助模块、16个pyd与14个dll动态库，以及pdf、txt、xml说明文档和ps1、bat、sh配置脚本，解压即可直接调用或二次集成。目前已有1478人学习下载，通过这套完整工具链与配套文档，使用者能快速掌握扫描—分析—加固的闭环工作流，切实提升系统的安全合规水平。

1. CIS-CAT到底是不是漏扫工具：先分清“配置风险”和“漏洞风险”

第一次听说CIS-CAT的人，大多会把它归类到“漏扫工具”里，我最初也拿它当漏扫跑过一次——结果翻完报告发现里面全是配置项而不是CVE，才意识到这类工具和传统漏洞扫描器完全是两个维度。CIS-CAT是一条条对照CIS安全基线去审计系统配置的：它告诉你当前系统距离基线差了哪些项，给出总体分数和失败清单，适合运维、安全、合规三类人群在入网检查、季度巡检、新系统加固场景里使用。

它的价值在于把“安全基线”从一份文档变成可量化的检查结果。漏扫回答的是“系统有哪些已知漏洞”，CIS-CAT回答的是“系统配置离规范还差多少”，两者是互补关系。这篇文章我按实战顺序讲：版本选型、最小命令、常用参数、高频踩坑，最后落到定时巡检和整改闭环，都是可以直接照做的内容。

2. CIS-CAT版本选型与环境准备：Assessor v3 和 Lite 差在哪

拿到CIS-CAT之后，第一件事不是急着解压，而是先确认该用哪个形态。名字一样，背后却分成Assessor v3和Assessor Lite两条技术路线，选错了，后面的命令、报告格式、支持范围全都不一样。我见过有人下载Lite包想在Linux上跑，折腾到看日志才发现连启动器都没有。

2.1 Assessor v3 与 Assessor Lite：差异远不止“免费与否”

Lite是轻量形态，主要跑Windows本机审计，检查引擎直接基于PowerShell，下载包小、启动快，适合个人机器做临时抽查。Assessor v3是完整形态，基于Java命令行工具，能审计本地Linux、远程Linux、远程Windows，还能覆盖云环境、容器、Kubernetes等扩展基准。两者的差异不是“精简版和完整版”这么简单，而是审计范围、运行方式、结果格式都不同。

我一般建议团队落地走Assessor v3，原因是它的输出格式多样、支持远程和多平台，后续接入定时任务和结果对比都方便。Lite当作个人学习或者Windows单机快速验证是可以的，但SLA类的合规留痕用Lite，报告聚合能力会明显吃力。还要注意授权边界：完整Assessor常与商业订阅绑定，评估授权别当正式长时间用，这部分在项目落地前要先确认清楚。

2.2 运行环境准备：Java版本怎么查、启动脚本怎么弄

Assessor v3对运行环境要求不多，但Java的版本和位数是常见翻车点。版本太旧直接启动报错；位数不对则加载库失败。老规矩，先检查再动手。

# 检查 Java 版本与位数，Assessor v3 一般要求 64 位 Java 11 及以上 java -version # 确认当前系统架构，避免 32 位系统跑 64 位 Java 的错位 uname -m

第一行重点看三处：版本号是否满足要求、是不是64位、JRE还是JDK无所谓但得完整。第二行是为了和Java位数对照，x86_64代表64位，i386或i686就说明缺少64位硬件或系统。这个环境检查最多一分钟，比下载后白折腾半小时划算。

# 解压 CIS-CAT 产品包，得到 Assessor-CLI 目录 tar -xzf Assessor-CLI.tar.gz # 进入命令行工具目录，所有后续审计指令都在这里执行 cd Assessor-CLI # 给 Linux 下的启动脚本加执行权限 chmod +x Assessor-CLI.sh # 列出当前包内可用的基准清单，先确认目标系统基准在不在 ./Assessor-CLI.sh -l

tar解压后包内自带data目录和Assessor-CLI目录；chmod是关键，很多新人打开目录双击脚本没反应，就是没赋执行权限；-l参数用来列出包内已有基准名称及对应profile，是“动手审计前的一眼确认”。这里有个建议：data目录里的基准xml文件不会覆盖所有系统版本，缺了哪份就去补哪份对应文件，不要拿不匹配的基准硬跑。

2.3 Benchmark、Profile与报告的基本心智模型

跑CIS-CAT之前，先建立一个最简单的抽象：Benchmark是一份针对特定系统的检查清单，Profile是这份清单里的预定义勾选范围。同一个系统不同大版本，检查清单往往不同，比如Ubuntu 20.04和22.04的审计项细节有差异；同一份清单里通常又区分Level 1和Level 2两层profile。Level 1是通用环境落地成本低的基础安全配置，Level 2是要做更多变更、对风险控制更严格的高级配置。报告最终给你的是一个合规分数和每条规则的PASS、FAIL、WARNING、NOT-APPLICABLE状态。搞懂这个心智模型，后面的命令参数就都能对号入座了，也方便跟运维同事解释“为什么这条规则是FAIL”。

3. 跑通第一次CIS-CAT审计：最小命令与报告解读

在Assessor v3上跑一次本地审计，最少的命令其实只有一条。把这条命令跑通，后面的远程、批量、无人值守都是在这个框架上叠加参数。第一次跑建议就用本机，把整条链路验证一遍，再考虑跨主机。

3.1 最小可运行的本地审计命令

cd /opt/cis-cat/Assessor-CLI ./Assessor-CLI.sh -i -nt -rd /var/cis-cat/reports -html -json

-i表示交互式输入审计目标和登录凭据，这是第一次跑最稳妥的方式，避免把密码直接暴露在命令历史里；-nt表示报告文件名不加时间戳，方便固定抓取和程序处理；-rd指定报告输出目录，目录不存在时会自动创建；-html和-json同时生成两种格式，人看和程序处理各一份。交互过程会依次询问审计对象是本机还是远程主机、用什么账号登录、是否需要sudo权限等。审计时长取决于规则条数和机器负载，一般几分钟到十几分钟。结束后命令行会给出总体分数，报告落在-rd指定目录。

这里提醒一下：交互过程里碰到密码输入时，确认终端不会把输入记录到shell历史里再继续，尤其是共享的跳板机。

3.2 指定基准与Profile，避免默认菜单浪费时间

如果不指定基准，运行后会进入基准选择菜单，虽然能用但从自动化视角不够利索，而且默认全Profile审计会很慢。指定基准和Profile的命令是这样：

./Assessor-CLI.sh \ -b data/CIS_Ubuntu_Linux_20.04_LTS_Benchmark_v1.0.0.xml \ -p "Level 1" \ -i -nt -rd ./reports -html -json -csv

-b指定要使用的基准文件，必须是xml路径，这里写的是相对路径，因为当前目录已经在Assessor-CLI；-p指定Profile为“Level 1”，只测基础合规，避免Level 2规则拉低整体分数，也缩短时长；-csv多输出一份CSV方便Excel筛选。这样跑下来的报告，目标基线清晰，整改团队拆任务时不纠结。

有一个常见误用：有人用默认的“全部Profile”跑出来的结果给运维整改，运维看到一堆因为没用Level 2而FAIL的项会直接懵掉。先想清楚要交付的基线层级，再指定-p，否则报告分数和整改方向都容易失真。

3.3 报告的三种打开方式：HTML给人看，JSON给程序用

HTML报告展示总体分数、失败项分布、每项规则的详情链接，是给人看的首选；JSON适合丢给脚本做汇总；CSV适合临时用Excel透视；XML或SST格式用于对接合规汇总平台。看HTML的顺序我一般是：先看总分，再看按级别或类别分布，最后按规则ID到基准文档里翻加固建议。JSON的结构大概是：

{ "overall_score": 68.5, "rule_results": [ {"rule_id": "1.1.1", "status": "FAIL"}, {"rule_id": "1.1.2", "status": "PASS"} ] }

overall_score就是总体评分，分数高低直接反映与目标基线的距离；rule_results数组里是每条规则的执行结果，FAIL就是需要整改的项；status还可能取WARNING、NOT-APPLICABLE等值。生产环境里我很少打开HTML，在命令行上直接过滤出FAIL的rule_id更高效，后续把JSON保留下来还能做周期对比。这一步操作很多人会跳过，实际却是整改闭环里最省时间的入口。

4. CIS-CAT常用参数与自定义基线：该调的参数一个都别省

CIS-CAT的命令行参数不算多，但每个参数都对应一种落地需求。命令没带对参数，通常不是跑不出来，而是报告形态或审计范围不符合预期。下面这张参数表覆盖了我日常用得最频繁的部分，照着选就不会漏。

4.1 高频CLI参数速查表

一个覆盖多场景的组合命令长这样：

./Assessor-CLI.sh \ -b data/CIS_Debian_Linux_11_Benchmark_v1.0.0.xml \ -p "Level 2" \ -i -nt -rd /data/cis-audit/reports \ -html -json -csv

-b和-p把审计范围钉死在Debian 11的Level 2；-rd使用绝对路径是因为定时任务里相对路径会被切成别的用户目录；多格式输出便于不同角色取数。如果要做更彻底的无人值守，可以把-i换成自动模式并搭配凭据文件，这个在第六章的定时任务里会展开。

4.2 Profile里的Level 1和Level 2怎么选才不返工

Level 1是“大多数生产环境可以直接落”的基线，涉及禁用高危协议、设置日志、明确权限等，对业务运行影响小；Level 2会进一步收紧配置，比如要求默认拒绝策略、更强的密码复杂度、更短的会话超时，很可能让某些老业务“第一轮就亮红灯”。选型顺序上，我习惯让新环境先从Level 1审计，跑完整改一轮后，再评估要不要上Level 2。反过来，一上来就用Level 2，报告评分难看，整改部门也容易疲于应付，最后变成“为了过审关掉审计项”，失去合规意义。特殊行业中若只有Level 2才能满足监管要求，也建议先在测试机验证后再推广。

4.3 Tailoring自定义：处理“真改不了的项”

总有规则因为业务依赖、商业软件、历史迁移等原因改不了。全部红着交也不合适，这时使用Tailoring把个别规则标记为“豁免”或“手动验证”，让报告反映真实可落地的合规状态，而不是虚假的满分。常见做法是先跑一次完整审计拿到原始结果，再确定要豁免的规则ID，生成自定义Tailoring文件后重新审计。示意结构：

{ "benchmark": "CIS_Ubuntu_Linux_20.04_LTS_Benchmark_v1.0.0.xml", "overrides": [ {"rule_id": "1.1.6", "action": "exclude", "reason": "legacy_service_requirement"} ] }

这段只是表达tailoring字段的组织思路，真实文件的字段名和格式要以当前版本发布包里的schema为准；action的exclude表示从审计结果中排除该规则；reason字段记录豁免原因，便于内审和复核。

注意：Tailoring文件里的豁免记录要保留内部复核留痕，别让合规报告变成自说自话。

不要滥用tailoring，尤其别把网站URL、公开服务口的高危项一揽子豁免。每次豁免都要在公司内部走记录流程，否则合规报告经不起审计。

5. CIS-CAT实战避坑：五个高频问题与排查路径

跑CIS-CAT踩过的坑，多半不在工具本身，而在版本匹配、权限、传输和报告处理上。下面这五个问题，频率高、现象典型，每一条都按现象、原因、解决展开。

5.1 审计结果全部FAILED：先查账号权限，不是工具坏了

现象：审计命令跑得很顺，报告里绝大多数规则都是FAIL，整体分数低得离谱。原因：最典型的是用了一个没有sudo权限的普通账号去审计Linux本机，CIS-CAT读取系统配置文件时被拒绝，只能把结果记作不满足。解决：换用有sudo权限的账号，在交互登录时提供sudo能力的凭据；远程审计Linux同样需要目标机上有对应权限的账号。不要为了图省事直接root跑审计，某些规则在非root会话下判断更接近真实用户视角；root和普通账号各跑一次对比差异，反而能定位工具在“读不到配置”场景下的假失败。

5.2 Not Applicable占一大半：先对系统版本

现象：报告里NOT-APPLICABLE的比例很夸张，一条条规则在系统上“不存在对应检查对象”。原因：最普遍的是基准版本和系统版本不匹配，比如拿Ubuntu 20.04的基准去跑22.04的机器；还有拿服务器目标套用了桌面工作站的Profile，查的项压根没安装。解决：跑之前用uname -a和cat /etc/os-release核对系统版本，再到-l输出里找相同系列的基准。实在没有完全对应的版本时，先确认该基准的适用范围能否覆盖目标系统，不行就别硬套，否则报告会被N/A淹没，失去参考意义。版本不匹配导致的N/A，和规则自身按系统条件判定的N/A是两回事，别混在一起看。

5.3 HTML报告单独拷走后空白：报告目录必须整体搬

现象：把服务器上的HTML报告拖回笔记本，打开页面框架在，分数和图表空白。原因：CIS-CAT生成的HTML不是单文件，它会把样式、脚本、数据放到报告目录下的资源文件里，报告文件引用的是相对路径，单独拷走等于断链。解决：传输时打包整个报告目录，而不是只点一个html。自动化任务里也可以固定通过JSON采集结果，不依赖HTML的渲染资源；如果非要单文件交付，就用工具把页面资源内联，但那属于额外加工，别指望原包直接给你单文件。

5.4 远程审计Windows连不上：按“WinRM→防火墙→域名→转义”排查

现象：远程Windows目标连不上，日志里不是权限拒绝就是连接超时。原因：远程Windows审计走WinRM，常见的四个断点依次是WinRM服务没启用、防火墙没放5985或5986端口、用户名漏写域名前缀、密码里的特殊字符在shell被转义。解决：在目标机器上先执行winrm quickconfig；再由管理机用Enter-PSSession验证同一凭据能连通；确认用户名带对域名前缀；最后把包含$、\等符号的密码用单引号包裹或写入凭据文件传参，避免被解释。按这个顺序排查，基本能定位九成以上的远程Windows连接失败。

5.5 启动报错UnsupportedClassVersionError：Java版本比工具还老

现象：Assessor-CLI.sh一启动就报UnsupportedClassVersionError，瞬间退出。原因：Java版本低于工具运行要求，或装了32位JRE，数据位不匹配。解决：java -version看版本与位数，把JRE升级到64位的11或17。不要顺手装最新Java大版本，工具在验证过的LTS版本范围内最稳；升级后先跑Assessor-CLI.sh -l验证基线能正常列出，再正式开跑。这条排错一分钟的事，别在那里瞎猜配置文件。

6. 把CIS-CAT嵌进日常巡检：定时任务与整改闭环

6.1 每周自动审计：脚本与定时任务

手动跑久了肯定想自动化。常见做法是把审计命令封装成脚本，每周执行一次，输出目录按日期区分。

#!/bin/bash # 基础路径按实际安装位置调整 BASE_DIR="/opt/cis-cat/Assessor-CLI" REPORT_ROOT="/var/cis-cat/reports" BENCHMARK="$BASE_DIR/data/CIS_Ubuntu_Linux_20.04_LTS_Benchmark_v1.0.0.xml" TODAY=$(date +%Y%m%d) # 按日期建目录，方便后续做周期对比 mkdir -p "$REPORT_ROOT/$TODAY" "$BASE_DIR/Assessor-CLI.sh" \ -b "$BENCHMARK" -p "Level 1" \ -i -nt -rd "$REPORT_ROOT/$TODAY" \ -html -json # 用退出码判断本次审计是否正常完成 if [ $? -eq 0 ]; then echo "$(date '+%F %T') audit ok" >> /var/log/cis-cat/weekly.log else echo "$(date '+%F %T') audit failed" >> /var/log/cis-cat/weekly.log fi

脚本先用TODAY生成日期目录，把每周结果归到独立文件夹；再执行审计命令；最后通过判断退出码写审计日志。这个版本保留-i交互模式，适合管理员手动触发；如果要完全无人值守，把-i替换成凭据文件相关参数，并把凭据文件权限压到600。

提示：凭据文件用600权限，并限制只能被运行账号读取，别把密码散落在脚本里。

定时任务放在root的crontab里，每周日凌晨2点跑一次：

0 2 * * 0 /opt/cis-cat/scripts/run_weekly_audit.sh >> /var/log/cis-cat/cron.log 2>&1

crontab的5段分别是分、时、日、月、星期，这里表示每周日2点整执行；输出重定向到cron.log，方便检查任务是否被系统正常拉起。执行crontab -e -u root写入这条规则。

6.2 两个周期结果对比：分数之外还要看失败项变化

只看分数容易自己骗自己：这周总分上升了，可能只是新增了很多PASS的项，真正该修的FAILED项一个没动。稳妥做法是把两周期的JSON放在一起，比分数也比失败项数量。我常用的对比脚本：

import json, glob # 按目录名字符串排序，取最近两个周期的JSON报告 paths = sorted(glob.glob("/var/cis-cat/reports/2*/*.json")) pre, cur = paths[-2], paths[-1] def load_summary(p): data = json.load(open(p, encoding="utf-8")) rows = [r.get("status") for r in data.get("rule_results", [])] return data.get("overall_score", 0), rows.count("FAIL") score_pre, fail_pre = load_summary(pre) score_cur, fail_cur = load_summary(cur) print(f"上次得分 {score_pre} 失败项 {fail_pre}") print(f"本次得分 {score_cur} 失败项 {fail_cur}")

glob按目录名字符串排序，找到最近两个周期的JSON报告；load_summary分别取出总分和FAIL计数；两次结果一起打出来，就能看出分数和失败项到底有没有同步收敛。目录命名保持类似“20250316”的结构就能直接复用这段逻辑，不用改代码。跑完把两行输出留在日志里，省得每次翻HTML。

6.3 整改闭环与我的报告归档习惯

分数只是基线体检的量化指标，整改闭环才是落点。我按规则ID建一张整改跟踪表，每周更新状态：

几张表格下来，哪个周期处理哪些项就一清二楚。我自己有个习惯，跑完CIS-CAT后JSON一定单独留一份，日志补一行。之前做过一次跨季度回顾，发现报告目录里的HTML散乱，有些还没有时间标识，逐份打开翻半天才拼出分数曲线，很耽误事。后来改成目录按日期归档加JSON留底，复查整改时直接说得出“这个规则ID在哪个周期被修掉”。这个习惯让我少走很多弯路，希望帮到你。

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