CIS-CAT：等保测评中的配置审计与合规基线扫描实战指南

简介在安全运维中漏扫工具常被理解为CVE漏洞扫描但真正的合规基线检查需要的是配置审计能力。CIS-CATCIS Configuration Assessment Tool正是这样一款对标CIS基准的配置审计工具它不匹配CVE数据库而是通过读取系统账号策略、内核参数、文件权限等配置项与基准值比对直接输出不合规项及修复建议。其价值在于把“系统配置是否符合规范”量化呈现适用于等保测评、集团安全自查、基线合规巡检等场景。与Nessus/OpenVAS等漏扫工具互补cis-cat能补足配置维度盲区。本文从工具原理、单机最小命令、批量落地、远程与本地模式到避坑指南和XML二次校验完整展示如何将cis-cat纳入常态化合规巡检流程高效支撑等保测评整改与审计取证。1. 为什么说cis-cat是等保测评里被低估的“漏扫工具”做漏扫这几年每次甲方喊“漏扫”第一反应都是掏出Nessus或OpenVAS去扫CVE。但真到等保测评、集团安全基线检查时光有CVE列表根本交不了差甲方要的是“系统配置是否符合CIS基准”。这时候cis-cat这个命令行工具比一堆CVE漏洞清单实用得多。CIS-CAT全称CIS Configuration Assessment Tool是互联网安全中心提供的配置审计工具很多服务商在等保整改里默认拿它做合规基线检查。它不找你开了哪些危险端口而是直接告诉你这台机器的密码策略、内核参数、文件权限、服务配置里哪些项不符合规范。适合安全运维、等保测评人员和系统管理员快速定位一台机器的“不合格项”。2. cis-cat的原理与边界它和常见漏扫工具的差别2.1 漏扫和合规基线扫描真不是一回事“漏扫工具”这个词本身有误导性。大多数漏扫工具是匹配CVE数据库告诉你“这台机器开了3389端口可能有MS17-010永恒之蓝”。但cis-cat不关心你有没有打补丁它只关心“这台机器是否按CIS建议的方式配置了”。比如密码最长使用期限是不是90天root是否禁止远程SSH登录系统审计日志有没有开启。这些不叫“漏洞”但配置出问题风险不比CVE低。对比项漏扫工具Nessus/OpenVAScis-cat检测侧重点软件版本、CVE漏洞、弱口令系统安全配置、账号策略、文件权限、审计策略检测原理特征库匹配 指纹识别读取系统配置项与CIS基准比对输出内容漏洞名称、CVSS分、修复补丁号不合规项ID、严重级别、修复建议典型应用场景日常漏洞管理、渗透测试等保测评、集团安全自查、基线合规实际工作中这两类工具是互补的。打个比方漏扫是给服务器做“体检”看有没有生病cis-cat是查“内务条令”看账号是否该锁的锁了、该设的密码有效期设了没有。很多安全管理员一开始只做漏扫后来被等保测评机构要求提供基线合规报告才回过头来用cis-cat补上这一环。cis-cat的工作机制也不复杂。它本质上是一个Java命令行程序内置了一系列CIS基准文件JSON/XML格式每个基准文件对应一个操作系统、数据库或中间件版本。扫描时它会执行大量探测动作类似读取/etc/shadow的密码策略当然是通过编程式接口或者查Windows注册表里某个安全选项的值再把结果和基准文件里的“建议值”做比对。2.2 下载解压后你应该看到什么目录结构与运行前提cis-cat本身不是一个需要安装的服务解压即用。从CIS官网下载对应版本通常有Lite版和Pro版传到一台内网跳板机或直接放到被扫描机器上。解压后目录结构如下$ ls -la drwxr-xr-x 2 root root 4096 Oct 20 10:00 benchmarks -rw-r--r-- 1 root root 102400 Oct 20 10:00 CIS-CAT.jar -rw-r--r-- 1 root root 2048 Oct 20 10:00 LICENSE.txt drwxr-xr-x 2 root root 4096 Oct 20 10:00 import -rw-r--r-- 1 root root 25600 Oct 20 10:00 README.txtbenchmarks目录是核心里面装着各个系统的基线定义文件比如cis_ubuntu_linux_20.04_benchmark_v1.0.0.xml、cis_windows_server_2019_benchmark_v1.0.0.xml。import目录放自定义配置文件。CIS-CAT.jar是主程序运行前必须确认机器上有Java运行时环境。常见做法是直接装一个OpenJRE 11版本太老会直接报ClassNotFoundException。2.3 跑通一个最小命令把单台Linux服务器扫出报告第一次使用建议先跑一台测试机不要直接上生产。我一般在Ubuntu 20.04测试机上这样跑java -Xms512m -Xmx1024m -jar CIS-CAT.jar \ -a \ -b ./benchmarks/cis_ubuntu_linux_20.04_benchmark_v1.0.0.xml \ -t html \ -o ./report命令参数含义如下参数含义示例-a执行评估模式不加就是列出可用基准-b指定基准文件路径./benchmarks/cis_ubuntu_linux_20.04_benchmark_v1.0.0.xml-t报告格式html、xml、json、csv-o输出目录./report跑完后在report目录下生成一个HTML文件。打开它就能看到这台机器在各检查项上的“合规率”和“不合规项明细”。这里有一个索引记分卡按严重级别分组一眼就能看出是账号策略拖了后腿还是文件权限项大面积失败。这个最小命令适合单机验证跑通后你才敢往批量上去推。2.4 报告里到底看到些什么别被那些红色标识吓到首次跑出HTML报告时你可能会被那一大片红色不合格项吓到以为系统已经被攻破了。其实不然cis-cat把检查项默认划分为几个类别账号策略、日志审计、内核参数、网络服务、文件系统权限。很多系统默认配置本身就带几个不合规项比如Ubuntu默认允许root通过SSH登录这在CIS基准里就是高危项。在报告里每个检查项会显示实际值从这台机器上探测到的真实配置值。期望值CIS基准中建议的值。严重级别F失败、W警告、I通过。修复建议一段文字说明告诉你“应该把PermitRootLogin改成no”之类的具体操作。所以第一份报告的红色一大片不代表灾难它只是把系统和最严基准之间的差距拉平摆在你面前。真正要做的是先把高危项处理掉再根据企业实际容忍度决定中危项怎么改。等保测评通常要求核心系统满足90%以上合规率否则就会被扣分。3. 批量落地从单机到几十台主机的cis-cat实操3.1 先跑通一台机器从下载到出报告的最小化命令刚才那条命令是单机的基础。批量落地前我习惯先在一台机器上把环境变量和依赖理顺。把Java装好后有一个关键坑cis-cat扫描进程会占用不少内存特别是加载大型基准文件时。最小化命令如下export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH cd /opt/cis-cat java -Xms512m -Xmx2048m -jar CIS-CAT.jar \ -a -b ./benchmarks/cis_centos_linux_7_benchmark_v1.0.0.xml \ -t html,xml -o /opt/cis-cat/reports这次我改用-t html,xml一次生成两种格式。XML格式是给后续解析做准备的HTML格式是给人看的。执行时要注意-Xmx设成2048m是因为基准文件动辄几十MB扫描时会构建大量对象。如果内存不够会出现OutOfMemoryError下方避坑章节会专门说这个。扫描过程会持续几分钟到十几分钟不等取决于机器配置和网络延迟。跑完后在reports目录下看到类似下面的文件到这一步就说明单机跑通了$ ls -l /opt/cis-cat/reports total 10240 -rw-r--r-- 1 root root 1024000 Oct 20 10:30 2024-10-20_CIS_Ubuntu_Linux_20.04_LTS_Benchmark_v1.0.0.html -rw-r--r-- 1 root root 2048000 Oct 20 10:30 2024-10-20_CIS_Ubuntu_Linux_20.04_LTS_Benchmark_v1.0.0.xml3.2 大批量扫描用配置文件固定扫描模板单机跑通了批量扫描就别再一条条敲命令了。cis-cat支持通过properties配置文件把公共参数固定下来。我会在/opt/cis-cat/conf/下建一个scan-ubuntu.propertiesbenchmark./benchmarks/cis_ubuntu_linux_20.04_benchmark_v1.0.0.xml output./reports reportFormatsxml profilecis_ubuntu_linux_20.04_level1然后在命令行里用-p指定这个配置文件java -Xms512m -Xmx2048m -jar CIS-CAT.jar -p ./conf/scan-ubuntu.properties这样做的最大好处是模板统一团队里所有人都用同一套参数不会出现有人扫level1、有人扫level2导致报告不可比的情况。profile参数尤其值得细说CIS基准通常按level1和level2分级level1是“基础安全要求”改动后对业务影响较小level2是“严格模式”要求禁用一些服务或强制复杂密码策略。一般企业建议先按level1批量跑针对不合规项做一次整改再考虑要不要上level2。批量扫描时要控制并发。我一般不会在一个脚本里同时发起几十个Java进程而是写一个简单的shell循环每次最多跑5台机器防止把跳板机的CPU和内存跑满。3.3 本地扫描还是远程扫描两种模式的分寸拿捏我用过的cis-cat扫描模式有两种。第一种是本地Agent模式把整个工具包分发到目标机器上在目标机器本地执行扫描生成的报告再收集回来。第二种是远程模式在跳板机上通过SSH/WMI连接到目标机器扫描。本地模式更稳不会因为网络认证问题导致扫描失败但分发工具包本身是一个工作量而且目标机器上如果已有业务进程再跑Java进程容易引起资源竞争。远程模式省去了分发但需要提前在目标机器上配好SSH密钥或Windows的WinRM服务且扫描账号需要具备足够的只读权限。我自己的习惯是Linux服务器用远程SSH模式Windows服务器用本地模式。Windows远程扫描依赖WinRM配置比较复杂不是每台机器都开了翻车概率高。Linux的SSH只要密钥通了基本能一次搞定。远程扫描命令大致是java -Xms512m -Xmx2048m -jar CIS-CAT.jar \ -a -b ./benchmarks/cis_centos_linux_7_benchmark_v1.0.0.xml \ -t xml -o ./reports \ -i ./conf/targets.propertiestargets.properties里是目标机器的IP、SSH端口、用户名和私钥路径。注意这里扫描账号一定不要给root给一个sudo权限或者只读账号最好。3.4 从报告里批量提取“不合规项清单”批量扫描完成之后你手上会有几十份XML报告靠人工一份份翻HTML是低效的。我一般用Python把XML里的不合规项汇总成一张Excel表发给各系统负责人去整改。解析XML的核心思路是遍历Rule节点筛出Result不为PASSED的项import xml.etree.ElementTree as ET import os result_rows [] for f in os.listdir(./reports): if not f.endswith(.xml): continue tree ET.parse(os.path.join(./reports, f)) root tree.getroot() hostname root.findtext(./Target) or root.attrib.get(name, f) for rule in root.iter(Rule): rule_id rule.attrib.get(id, ) status rule.findtext(./Result) if status not in (PASSED, NOT_SELECTED): result_rows.append([hostname, rule_id, status]) for row in result_rows: print(,.join(row))这段代码的逻辑很简单遍历当前目录下所有XML报告找到Target节点获取主机名然后遍历每条Rule节点把状态不是PASSED的记录拉到结果列表里。实际使用中我会加上规则描述文本和严重级别字段这样发给业务方时别人一眼就能看懂是哪里不合规。到这里批量落地已经从“能跑”走到了“能用的结果”下一步才是真正处理那些不合规项。4. 避坑指南用了大半年cis-cat踩过的5个坑4.1 远程扫描总是连接失败不是账号密码错了是WinRM没开现象远程扫描Windows服务器时cis-cat一直报“Connection refused”或“Authentication failed”确认账号密码是对的防火墙也放了5985端口还是连不上。原因Windows远程管理服务WinRM默认是关闭的即使开放了防火墙端口服务没有启动照样白搭。此外在域环境里还要额外配置信任主机。解决net start winrm set-item WSMan:\localhost\Client\TrustedHosts -value 10.0.0.10在目标机器上把WinRM服务启动并添加扫描机的IP到TrustedHosts列表。如果目标机器不在域里这步是必须的。配好后再回跳板机重试就通了。这个坑在第一次用cis-cat远程扫描Windows时几乎必踩所以我后来干脆对Windows机器走本地Agent模式不再折腾远程。4.2 扫描高版本系统时直接报“No benchmark found”现象下载了最新版cis-cat扫描RHEL 9或Windows Server 2022时命令直接退出什么报告都不生成。原因cis-cat的benchmarks目录里没有对应版本的基准文件。工具本身更新了基准文件不一定同步更新。解决去CIS官网单独下载对应版本的Benchmark下载后放入benchmarks目录再重新指定-b参数指向新文件。这里要特别确认下载的是不是适用于当前cis-cat版本的JSON格式有些老基准包是XML格式也能兼容但字段对应关系可能会有差异。遇到版本匹配问题先查README.txt里的兼容性说明不要盲目换机器。4.3 Java内存溢出基准库很多扫描线程也开得很多现象批量并发执行8个扫描进程跑了几个小时后部分进程报java.lang.OutOfMemoryError: Java heap spaceCPU高但就是不出报告。原因默认Java堆内存太小。cis-cat在加载基准文件和目标系统探测结果时需要大量内存并发进程多时每个进程都占几百MB直接把内存撑爆。解决给Java设堆内存上限单机扫描用-Xmx1024m或-Xmx2048m并发时不要把并行数拉到8改为每个进程分配合理内存后再跑java -Xms512m -Xmx2048m -jar CIS-CAT.jar -p ./conf/scan.properties此外把不必要的报告格式去掉只保留XML也能减轻内存压力。记住cis-cat不是一个轻量级工具它加载的是几十MB的基准文件不要把它当ls命令那样使。4.4 报告生成后打不开文件巨大无比现象扫描完成后生成一个几百MB的HTML报告浏览器打开直接卡死Excel导入也卡。原因我把全量资产打包到一个报告里了或者单台机器上需要检查的规则太多导致报告体积过大。解决把输出拆成按主机按日期的独立文件不要累计合并。同时在生成时只输出xml或csv格式减少HTML渲染带来的体积。我从那以后统一用XML输出配合上面的Python脚本直接提取不合规项再也不会因为报告太大而卡电脑。4.5 开着“修复模式”扫描把线上服务器的审计策略改掉了现象在测试环境跑得好好的到生产环境一跑发现目标服务器的安全审计策略变了日志量暴增。原因我用了-r修复模式参数cis-cat不只是“检查”它会把不合规项直接改掉。生产环境里不该让工具主动改配置尤其涉及审计策略和密码策略的变化会影响业务稳定性。解决把-r去掉只用-a评估模式。扫描账号也改成只读权限限制它没有写权限。除非是非常明确要自动加固的内网隔离环境否则不要开修复模式。这一点我是在一次凌晨生产事故后学会的从那以后我写的所有扫描命令里都不带-r。5. 进阶用法用XML报告和Python脚本做二次校验等保测评或者年度自查时最烦的不是扫描本身而是扫描结果出来后被审计单位质疑“这个不合规项真的存在吗你是不是误报”所以我现在内部推广时从来不看HTML文件全部用XML导进工单系统。这样既能保留原始证据也能随时二次校验。一个常见方法是做“双重确认”先用cis-cat扫一遍拿到不合规项编号后用Python脚本在目标机器上执行对应命令确认实际值和cis-cat报告里写的是否一致。比如报告说“SSH PermitRootLogin是yes”脚本再跑一次sshd -T验证字段这样在等保测评答疑时能拿出确凿证据。import subprocess rule_id 4.1.1 expected_cmd sshd -T | grep -i permitrootlogin result subprocess.run(expected_cmd, shellTrue, capture_outputTrue, textTrue) if PermitRootLogin no in result.stdout: print(当前配置已修复) else: print(配置仍未修复请检查 /etc/ssh/sshd_config)这段脚本把“报告结果”和“实际状态”绑定在一起避免被质疑时还要重新登录机器去查。真正在客户端跑起来时我会把所有这些输出汇总成一张清单按系统责任人分类直接发给对方整改整改完再复用同一份脚本复测。这个方案值不值得做答案是肯定的。尤其等保2.0落地以后测评机构对配置基线的检查越来越细靠人工一台台去对配置项根本不现实。把cis-cat纳入常态化巡检每个季度跑一次把报告归档等到测评时直接拿出最近一次扫描记录既省事又专业。最后补一个习惯我在每台机器扫描后都会校验一下XML报告的大小小于1MB的十有八九是扫描没跑完就结束了。宁可多跑五分钟不要急着收报告。希望帮到你。本文还有配套的精品资源点击获取