简介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 v3Assessor Lite运行方式Java CLIPowerShell主要覆盖Linux / Windows / macOS / 云Windows 为主审计对象本机与远程主机本机交互体验命令行逐步提示命令直接出结果适用场景批量巡检、合规交付单机抽查、学习入门我一般建议团队落地走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 -ltar解压后包内自带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参数速查表参数作用使用建议-i交互输入审计目标和登录凭据第一次跑、临时抽查用避免密码进shell历史-a非交互自动模式结合凭据文件做无人值守-b指定单个基准xml文件明确目标系统版本时用-bd指定基准文件目录机器上有多套基准让工具自动匹配时用-p指定Profile名称和-b配套别拿默认值跑全量-pd指定Profile目录自定义profile存放目录-rd报告输出目录自动化任务里用绝对路径-nt报告不带时间戳命名需要固定文件名做覆盖式采集时用-html生成HTML报告给人看-json生成JSON报告给程序做统计分析-csv生成CSV报告临时Excel透视-xml生成XML报告对接合规汇总平台-l列出可用基准与profile动手前先确认目标基准在不在一个覆盖多场景的组合命令长这样./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 启动报错UnsupportedClassVersionErrorJava版本比工具还老现象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 21crontab的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, encodingutf-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建一张整改跟踪表每周更新状态规则ID状态整改动作复查结果1.1.1FAIL关闭多余服务本期已PASS1.2.3FAIL待业务窗口调整密码策略仍FAIL1.3.2N/A无对应组件确认基线版本保持N/A几张表格下来哪个周期处理哪些项就一清二楚。我自己有个习惯跑完CIS-CAT后JSON一定单独留一份日志补一行。之前做过一次跨季度回顾发现报告目录里的HTML散乱有些还没有时间标识逐份打开翻半天才拼出分数曲线很耽误事。后来改成目录按日期归档加JSON留底复查整改时直接说得出“这个规则ID在哪个周期被修掉”。这个习惯让我少走很多弯路希望帮到你。本文还有配套的精品资源点击获取