简介cis-cat漏扫工具是一款面向IT安全运维人员、系统管理员及合规审计工程师的专业级自动化安全评估工具专用于快速识别操作系统层面的安全漏洞与配置不合规项助力企业满足CIS互联网安全中心基准要求。资源包共152个文件含74个可执行程序exe、34个Java运行模块jar、16个Python扩展库pyd及14个动态链接库dll辅以PDF合规文档、XML扫描规则和PowerShell/Shell脚本完整支撑工具部署、运行与结果解析压缩包大小为52.94MB。已有1480人学习下载适用于等保测评预检、基线加固验证及安全实训环境搭建。用户可直接运行cis-cat.bat启动轻量版扫描器结合内置CIS基准对Windows/Linux系统开展一键式检查并获取含风险等级、修复建议与配置定位的结构化报告显著降低人工核查成本。1. CIS-CAT 不是点开就扫的“一键神器”我拿它在三类操作系统上翻车五次才摸清真实能力边界去年接手一个合规加固项目甲方明确要求“必须用 CIS-CAT 做基线扫描”我第一反应是松了口气——毕竟名字里带“CIS”听着就权威。结果第一次在某高校实验室的 CentOS 7 环境里跑完报告里赫然标红“SSH 服务未启用密钥认证”可我亲手配的sshd_config里明明写了PubkeyAuthentication yes第二次在某公司产线的 Windows Server 2019 上工具直接卡死在“加载 GPO 策略”阶段任务管理器里java.exe占满 CPU 却毫无日志输出第三次导出 PDF 报告时字体全乱码第四次发现它根本识别不了容器化部署的 Ubuntu 22.04 容器……直到第五次我才意识到CIS-CAT 不是漏扫工具它本质是一个基于 SCAP 标准的策略符合性验证引擎——它不找漏洞它只问“你有没有按 CIS Benchmark 白纸黑字写的每一条去配置”。新手常把它当 Nessus 用熟手则把它当“配置审计的尺子”。这篇就讲清楚它到底能测什么、在哪种操作系统上最稳、哪些操作系配置它根本看不懂、以及为什么你看到的“高危项”可能只是它读错了配置路径。如果你正被“CIS-CAT 扫不准”“CIS-CAT 在 XX 系统上跑不动”“CIS-CAT 报告和实际不符”这类问题卡住这篇就是为你写的血泪复盘。1.1 这不是漏洞扫描器是“配置合规裁判员”很多人下载 CIS-CAT 后第一件事是双击cis-cat.jar选个 IP 就点“Scan”然后盯着进度条等“漏洞列表”。这从根上就错了。CIS-CAT 的核心逻辑不是发包探测、不是端口爆破、不是代码审计而是本地配置采集 规则匹配。它的工作流非常机械先通过预置的“数据收集器”Data Collector读取目标系统的配置文件、注册表项、命令行输出比如sysctl -a、grep配置文件、reg query再把读到的原始值逐条跟 CIS Benchmark 文档里定义的“期望值”做字符串/布尔/数值比对。比如 CIS Benchmark for RHEL 8 第 5.2.1 条写“/etc/ssh/sshd_config中PermitRootLogin必须为no”CIS-CAT 就会去读这个文件找到PermitRootLogin这一行提取等号右边的值再判断是不是no。它不关心 SSH 服务是否真的监听、不检查密钥是否有效、更不管 root 账户是否被禁用——它只认这一行字面值。所以当你看到“高危PermitRootLogin 未禁用”而你确信已禁用大概率是① 配置文件被 include 机制拆分CIS-CAT 只读了主文件没读子文件② 你用了# PermitRootLogin no这种注释写法它读到的是空值而非no③ 你改的是/etc/ssh/sshd_config.d/01-custom.conf但默认 collector 没配置扫描.d/目录。这种“规则僵硬性”不是 bug是设计使然——CIS Benchmark 本身就要求数值精确匹配工具只是忠实执行。理解这点才能避开 80% 的“误报”焦虑。1.2 三类操作系统支持度天差地别Linux 最稳Windows 最脆容器基本不认CIS-CAT 对操作系统的支持完全取决于它内置的“数据收集器”是否覆盖该系统。我实测过三类主流环境结论很反直觉原生 Linux 发行版RHEL/CentOS/Ubuntu支持度最高Windows Server 次之且高度依赖 Java 版本和权限而容器环境几乎不可用。具体看LinuxRHEL/CentOS/Ubuntu这是 CIS-CAT 的“舒适区”。它的 Shell Collector 能稳定调用cat、grep、awk、sysctl等命令对/etc/下的配置文件路径、内核参数、PAM 模块路径都有成熟映射。我在 CentOS 7、RHEL 8、Ubuntu 20.04 上均能完成全量扫描平均耗时 8–12 分钟报告准确率经人工复核达 92% 以上。关键在于它默认使用sudo提权执行命令只要目标用户有NOPASSWD: ALL权限就能读取所有关键配置。Windows Server2012R2/2016/2019这里问题集中爆发。CIS-CAT 依赖 PowerShell Collector 和 Registry Collector但 Windows 的 UAC、组策略继承、注册表重定向WoW64让它频频失准。最典型的是它调用Get-ItemProperty读注册表时若目标键被 GPO 强制设置PowerShell 返回的是“策略生效值”但 CIS-CAT 的规则库却匹配“本地注册表值”导致大量“策略已启用但报告标红”。另外Java 运行时版本必须严格匹配——用 OpenJDK 11 会卡死在 GPO 加载换成 Oracle JDK 8u202 才勉强跑通。权限更是玄学必须以“本地管理员”身份运行且不能是远程桌面会话否则reg query返回空。容器环境Docker/PodmanCIS-CAT 官方根本不支持。它没有容器专用 collector强行挂载容器 rootfs 后Shell Collector 会因/proc、/sys不可用而大量报错即使手动修改 collector 路径指向挂载点systemctl is-active等命令也因无 systemd 进程而失败。我试过 Alpine、Ubuntu、CentOS 三种基础镜像无一例外在“服务状态检查”环节崩溃。结论很明确CIS-CAT 是为“物理机/虚拟机”设计的不是为容器设计的。想扫容器得换工具或者把 CIS-CAT 当作“宿主机合规检查器”而非容器内部检查器。2. 四个核心维度对比CIS-CAT vs. 主流合规扫描工具OpenSCAP / Lynis / Nessus选型不是比谁图标好看而是看它能不能在你的生产环境里“扛住压力、给出准数、不拖后腿”。我把 CIS-CAT 放进四个硬指标里和三个常被拿来对比的工具拉出来真刀真枪比OpenSCAP社区主力、Lynis轻量级王者、Nessus商业全能选手。不谈虚的“功能列表”只看实测中影响交付的细节——比如扫描耗时波动、报告可读性、二次开发成本、以及最要命的“误报率”。2.1 维度一扫描深度与规则覆盖——谁更贴近 CIS Benchmark 原文CIS-CAT 的最大优势也是它存在的唯一理由它由 CIS 官方团队维护规则库XCCDF 文件与 CIS Benchmark PDF 文档严格同步。比如 CIS Benchmark for Ubuntu 22.04 v1.0.0 发布当天CIS-CAT 就更新了对应 profile连章节编号、检查项 ID如xccdf_org.cis.benchmarks_rule_2.2.1.2都一一对应。OpenSCAP 虽然也支持 CIS Benchmark但它的scap-security-guide包是社区维护常滞后 1–3 个月且部分检查项做了“合理化简化”——比如把“必须禁用 telnet 服务”合并成“检查非必要服务”丢失了 CIS 原文的强制性。Lynis 是纯脚本规则靠作者经验编写压根不遵循 XCCDF 标准无法生成标准 SCAP 报告。Nessus 的 CIS 插件虽全但它是把 CIS 规则“翻译”成漏洞检测逻辑比如把“/etc/passwd中 UID0 的账户数必须≤1”变成“检测是否存在多个 root 账户”底层实现是grep x:0: /etc/passwd | wc -l看似一样但一旦系统用了 LDAP 或 NISNessus 的检测就失效而 CIS-CAT 的 collector 会主动调用getent passwd | awk -F: $30 {print}兼容性更强。实测数据在 RHEL 8 上扫描 CIS Level 1 全量规则127 条CIS-CAT 100% 覆盖OpenSCAP 缺失 5 条集中在 SELinux 模块深度检查Lynis 缺失 23 条全部是 GPG 密钥信任链、内核模块签名等冷门项Nessus 100% 覆盖但其中 8 条存在 LDAP 环境误报。2.2 维度二执行稳定性与资源占用——谁能在生产服务器上安静跑完稳定性不是“不崩溃”而是“崩溃时有迹可循、能快速恢复”。CIS-CAT 的 Java 架构决定了它内存吃得多、启动慢、但单次扫描极稳。我给三台同配置8C16G的测试机同时跑扫描CIS-CAT 平均峰值内存 1.2GB全程无 GC 停顿耗时标准差仅 ±42 秒OpenSCAPoscap xccdf eval峰值内存 480MB但遇到大文件如/var/log/audit/audit.log时会 OOM killLynis 内存仅 15MB但它是 bash 脚本遇到find / -name *.conf -exec grep -l PermitRootLogin这类命令在海量小文件目录下会 fork 爆炸CPU 占满 100% 持续 3 分钟Nessus 最猛单次扫描占满 2.8GB 内存且必须后台常驻服务扫描期间nessusd进程会抢占磁盘 I/O导致同服务器上的数据库响应延迟飙升。更关键的是错误处理CIS-CAT 遇到 collector 失败如grep找不到文件会在报告中标记“信息缺失INFORMATIONAL”并继续后续检查OpenSCAP 遇到同样错误直接中断整个 profileLynis 会打印红色警告但继续Nessus 则静默跳过不提示任何缺失。这对审计交付致命——你得知道哪些项是“真没配”哪些是“工具没读到”。2.3 维度三报告可读性与审计友好度——谁能让甲方签字不皱眉合规报告不是给工程师看的是给风控、法务、外部审计师看的。CIS-CAT 的 HTML 报告天生为审计而生每条结果页都带“CIS Benchmark 原文截图”“检查命令原文”“实际读取值”“期望值”“判定逻辑说明”四栏且所有链接可点击跳转到 CIS 官网对应章节。OpenSCAP 报告只有“结果原始 XML”得靠oscap-report工具二次渲染生成的 HTML 简陋无原文引用。Lynis 报告是纯文本重点靠***符号标记审计师翻三页都找不到“依据哪条标准”。Nessus 报告最华丽有热力图、趋势图但它的“CIS Compliance”视图是聚合统计点进去看不到具体哪条规则、哪行配置不匹配——你得导出 CSV 再用 Excel 筛选效率极低。我让某公司风控总监盲评三份报告隐去工具名他选 CIS-CAT 的理由很实在“第 37 条它直接贴出了/etc/ssh/sshd_config里PasswordAuthentication那行的截图还标红了yes字旁边写着‘CIS v8.0 Section 5.2.2 要求为 no’我不用查文档一眼就懂问题在哪、怎么改。”2.4 维度四定制化与集成成本——谁能让 DevOps 流水线不卡壳很多团队想把合规扫描塞进 CI/CD这时工具的 CLI 友好度和 API 成本就见真章。CIS-CAT 的 CLI 极其纯粹java -jar cis-cat.jar -t target -p profile -o output参数少、文档清、返回码规范0成功1部分失败2严重错误。它不依赖后台服务扫描完即走适合 Jenkins Pipeline 调用。OpenSCAP CLI 更强大支持--fetch-remote-resources但参数多达 37 个新手配个--results-upload都要查半小时手册。Lynis CLI 简单lynis audit system但它不生成标准格式报告想集成进 Jira 或 Confluence 得自己写解析脚本。Nessus 必须走 REST API且 API Key 权限颗粒度粗开个“扫描执行”权限就得附带“策略管理”安全团队死活不批。实测 Jenkins 集成CIS-CAT 从下载 jar 包到生成 HTML 报告Pipeline 脚本仅 12 行OpenSCAP 需 28 行含依赖安装、XML 渲染Lynis 需 15 行但后续解析报告另加 40 行 PythonNessus API 调用脚本 63 行且每次扫描前得等nessusd服务就绪超时机制难写。如果你的流水线追求“快、稳、少维护”CIS-CAT 的 CLI 设计是降维打击。2.5 避坑CIS-CAT 扫描中五个高频翻车现场及解法现象 → 原因 → 解决全是我在客户现场跪着记下的血泪笔记现象扫描 CentOS 7 时报告中 “5.2.1 Ensure SSH Root Login is disabled” 持续标红但grep PermitRootLogin /etc/ssh/sshd_config明明返回no。原因CIS-CAT 默认 collector 使用grep -E ^PermitRootLogin[[:space:]]no /etc/ssh/sshd_config而你的配置是PermitRootLogin no # disable root login#后的空格导致正则不匹配。解决编辑collectors/shell-collector.xml将commandgrep -E .../command改为commandawk -F[[:space:]]*[[:space:]]* /^[[:space:]]*PermitRootLogin[[:space:]]*/ {print $2} /etc/ssh/sshd_config | tr -d [:space:]/command确保提取等号后纯值。现象Windows Server 2019 扫描卡死在 “Loading Group Policy Objects”任务管理器显示java.exe占 CPU 100%无日志输出。原因CIS-CAT 的 GPO collector 调用gpresult /h report.html生成 HTML 报告但该命令在无图形界面的 Server Core 模式下会等待 GUI 渲染无限阻塞。解决在扫描前以管理员身份运行gpupdate /force然后修改collectors/powershell-collector.xml将 GPO 检查命令替换为Get-GPOReport -All -ReportType Xml -Path $env:TEMP\gpo-report.xml直接读 XML 避免 GUI 依赖。现象Ubuntu 22.04 扫描报告中“2.2.1.2 Ensure package manager repositories are configured” 项全部标“信息缺失”但/etc/apt/sources.list文件明明存在。原因CIS-CAT 的 APT collector 默认只读/etc/apt/sources.list而 Ubuntu 22.04 默认使用/etc/apt/sources.list.d/*.list分散管理源主文件为空。解决复制collectors/shell-collector.xml中的 APT collector 段新增一个 collector 专门扫描for f in /etc/apt/sources.list.d/*.list; do cat $f; done并在 profile 中启用它。现象导出 PDF 报告时中文全乱码英文字母正常方框里是小方块。原因CIS-CAT 内置的 Flying Saucer PDF 渲染引擎默认字体不支持中文且未配置 fallback 字体。解决下载 Noto Sans CJK SC 字体noto-sans-cjk-sc-fonts包解压后将NotoSansCJKsc-Regular.otf放入cis-cat/lib/fonts/目录再编辑cis-cat/conf/flying-saucer-config.xml在fonts节点内添加font-family nameNoto Sans CJK SCfontfont-face srcurl(lib/fonts/NotoSansCJKsc-Regular.otf)//font/font-family。现象扫描后生成的 HTML 报告里“Details” 标签页点击无反应浏览器控制台报错Uncaught ReferenceError: detailsToggle is not defined。原因CIS-CAT 生成的 HTML 引用了js/jquery.min.js和js/bootstrap.min.js但这些文件在离线环境中未随报告一起导出或路径写死为网络 CDN。解决进入cis-cat/templates/目录找到html-report-template.xhtml将script srchttps://cdn.jsdelivr.net/npm/jquery3.6.0/dist/jquery.min.js/script替换为script srcjs/jquery.min.js/script并确保js/目录下有对应文件可从官网下载完整包获取。3. 实战复现从零开始跑通一次可信的 CentOS 7 CIS Level 1 扫描光说不练假把式。下面是我在线上环境反复验证过的、可 100% 复现的完整流程。不跳步、不省略、不假设你有 root 密码——所有命令都经过实测参数精确到空格。目标在一台最小化安装的 CentOS 7.9 虚拟机上完成 CIS Level 1 基线扫描生成可交付的 HTML 报告并人工复核 3 条关键项验证准确性。3.1 环境准备装对 Java配好权限关掉干扰项CIS-CAT 对 Java 版本极其敏感。官方文档写“Java 8 or later”但实测中OpenJDK 11 会导致java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverterJAXB 被移除Oracle JDK 17 会因模块系统报错只有Oracle JDK 8u202能 100% 稳定运行。别省事老老实实装这个版本。# 下载 jdk-8u202-linux-x64.tar.gz需 Oracle 账号或从可信镜像站获取 wget https://mirrors.tuna.tsinghua.edu.cn/Adoptium/8/jdk/x64/hotspot/temurin-8u202-b08-jdk_x64_linux_hotspot_2020-01-15.tar.gz tar -zxf temurin-8u202-b08-jdk_x64_linux_hotspot_2020-01-15.tar.gz -C /opt/ export JAVA_HOME/opt/jdk8u202-b08-jdk export PATH$JAVA_HOME/bin:$PATH java -version # 输出应为 java version 1.8.0_202权限是第二大坑。CIS-CAT 必须以能执行sudo命令的用户运行且该用户需在/etc/sudoers中配置NOPASSWD: ALL。切忌用 root 用户直接运行——它会绕过 sudoers 检查导致部分 collector如读取/etc/shadow因权限不足失败。# 创建专用扫描用户 useradd -m -s /bin/bash cis-scan echo cis-scan ALL(ALL) NOPASSWD: ALL /etc/sudoers # 切换用户验证 sudo 无需密码 su - cis-scan sudo -n whoami # 应输出 root且无密码提示最后关掉所有可能干扰扫描的进程。特别是auditd服务它会往/var/log/audit/audit.log写巨量日志CIS-CAT 的日志分析 collector 会因此卡死sudo systemctl stop auditd sudo systemctl disable auditd # 扫描期间禁用完事后可恢复3.2 下载与配置只取必需文件删掉所有花哨插件CIS-CAT 官网下载的是一个 300MB 的巨无霸包包含 Windows/Mac/Linux 三端、所有历史 benchmark、示例脚本、GUI 启动器。生产环境只需最精简的 CLI 核心。我整理出最小依赖集cis-cat.jar核心引擎必须profiles/目录存放 XCCDF profile 文件必须只保留CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xmlcollectors/目录数据收集器定义必须只保留shell-collector.xml、file-collector.xmltemplates/目录报告模板必须只保留html-report-template.xhtmllib/目录Java 依赖必须全保留删除所有windows-collector.xml、powershell-collector.xml、gui-launcher、examples/、docs/。最终包大小压到 42MB启动速度提升 3 倍。# 解压后进入目录执行精简 cd cis-cat rm -rf windows-collector.xml powershell-collector.xml gui-launcher examples docs # 确保 profiles 下只有目标 benchmark ls profiles/ | grep -v CentOS_Linux_7_Benchmark_v3.0.0 # 若有其他版本全部删掉3.3 执行扫描一条命令三个关键参数拒绝 GUICIS-CAT 的 GUI 启动器cis-cat-gui.sh是新手陷阱。它会弹窗、会卡死、会偷偷改配置。生产环境只用 CLI。命令结构极简java -jar cis-cat.jar \ -t localhost \ # 目标localhost 表示本机扫描必须不能省略 -p profiles/CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xml \ # 指定 profile必须路径要对 -o reports/centos7-level1-$(date %Y%m%d-%H%M%S).html \ # 输出 HTML 报告必须 -v \ # 开启详细日志调试必备 -c collectors/shell-collector.xml \ # 指定 collector推荐显式指定 -r templates/html-report-template.xhtml # 指定模板避免默认模板乱码注意三个易错点-t localhost必须写localhost不能写127.0.0.1后者会触发网络 collector失败-p后路径必须是相对cis-cat.jar的路径不能是绝对路径否则报Profile not found-o输出路径的目录reports/必须提前创建否则报错退出。执行后你会看到滚动日志每行代表一个检查项。典型成功日志INFO [main] o.c.c.s.ScapScanner - Starting scan for target: localhost INFO [main] o.c.c.c.ShellCollector - Executing command: grep -E ^\s*PermitRootLogin\s /etc/ssh/sshd_config INFO [main] o.c.c.c.ShellCollector - Command output: PermitRootLogin no INFO [main] o.c.c.r.RuleEvaluator - Rule xccdf_org.cis.benchmarks_rule_5.2.1: PASS3.4 报告验证不看总分盯死三条“黄金检查项”报告生成后别急着交差。我养成一个铁律每次扫描必人工复核三条核心项它们是系统安全的“锚点”一旦 CIS-CAT 在这里都错整份报告可信度归零。检查项 5.2.1SSH Root 登录报告中定位到Rule ID: xccdf_org.cis.benchmarks_rule_5.2.1点击 “Details”看 “Actual Value” 是否为no。然后 SSH 登录服务器手动执行sudo grep -E ^\s*PermitRootLogin /etc/ssh/sshd_config | head -1 # 输出应为 PermitRootLogin no sudo ssh rootlocalhost # 应提示 Permission denied (publickey,password).若报告写PASS但手动能 root 登录说明 CIS-CAT 读错了文件可能是Include /etc/ssh/sshd_config.d/*.conf被忽略。检查项 1.4.1密码重用限制报告中找Rule ID: xccdf_org.cis.benchmarks_rule_1.4.1看 “Actual Value” 是否为5表示最多重用 5 次旧密码。手动验证sudo grep -E ^\s*password\srequisite\spam_pwquality\.so /etc/pam.d/system-auth # 应包含 remember5 sudo grep -E ^\s*password\s\[defaultok\]\spam_unix\.so /etc/pam.d/system-auth # 应包含 remember5注意CIS-CAT 只检查pam_pwquality.so行但实际生效的是pam_unix.so行此处若不一致报告即为误报。检查项 3.4.2关键日志文件权限报告中找Rule ID: xccdf_org.cis.benchmarks_rule_3.4.2看/var/log/secure的 “Actual Value” 是否为600。手动验证ls -l /var/log/secure # 应输出 -rw-------. 1 root root ... sudo stat -c %a %U %G /var/log/secure # 应输出 600 root root若报告写600但stat显示640说明 CIS-CAT 的 file collector 读取了错误路径如读了/var/log/secure-20231001归档文件。提示这三条验证耗时不到 2 分钟但能帮你拦截 90% 的“工具幻觉”。记住CIS-CAT 的价值不在它扫出多少“高危”而在它是否忠实地告诉你“你配的和 CIS 白纸黑字写的一字不差”。4. 深度解析CIS-CAT 的规则引擎如何工作读懂 XCCDF 才能真正定制CIS-CAT 的强大90% 来自它背后的 XCCDFExtensible Configuration Checklist Description Format标准。很多人把 XCCDF 当黑匣子只知下载 profile 就用结果一出问题就抓瞎。其实 XCCDF 就是个 XML 文件结构清晰规则可读。搞懂它你就能① 快速定位某条检查项为何失败② 屏蔽不适用的规则如禁用 IPv6 检查③ 为私有环境添加自定义规则。下面以 CentOS 7 的5.2.1规则为例逐层拆解。4.1 XCCDF 文件结构Rule → Check → Oval Definition → Test打开profiles/CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xml搜索rule_5.2.1你会看到一个Rule节点。它不直接写检查逻辑而是引用一个check节点Rule idxccdf_org.cis.benchmarks_rule_5.2.1 selectedtrue titleEnsure SSH Root Login is disabled/title description.../description check systemhttp://oval.mitre.org/XMLSchema/oval-definitions-5 check-content-ref hrefoval-unlinked.xml nameoval:org.cisecurity:def:1234/ /check /Rule这个hrefoval-unlinked.xml指向另一个文件oval-unlinked.xml同目录下里面定义了真正的检查逻辑。搜索def:1234找到definitiondefinition classcompliance idoval:org.cisecurity:def:1234 version1 metadata.../metadata criteria operatorAND criterion test_refoval:org.cisecurity:tst:5678/ /criteria /definition它又引用了一个test节点tst:5678。继续搜找到unix:file_testunix:file_test idoval:org.cisecurity:tst:5678 version1 checkall check_existenceat_least_one_exists unix:object object_refoval:org.cisecurity:obj:9012/ unix:state state_refoval:org.cisecurity:ste:3456/ /unix:file_test至此逻辑链清晰了Rule → Check → Definition → Test → Object State。Object定义“查什么文件”State定义“期望什么值”。看obj:9012unix:file_object idoval:org.cisecurity:obj:9012 version1 unix:filepath/etc/ssh/sshd_config/unix:filepath /unix:file_object再看ste:3456unix:file_state idoval:org.cisecurity:ste:3456 version1 unix:line datatypestring operationpattern match^\s*PermitRootLogin\sno\s*$/unix:line /unix:file_state原来如此CIS-CAT 的本质就是用 OVAL 标准描述“在/etc/ssh/sshd_config文件中找一行匹配正则^\s*PermitRootLogin\sno\s*$的内容”。它不解析配置语法就是纯文本匹配。4.2 定制化实战屏蔽一条不适用规则禁用 IPv6某客户环境强制使用 IPv4所有 IPv6 相关检查如Rule 2.2.1.1都标红但业务不允许启用 IPv6。与其每次手动改报告不如在扫描前就禁用规则。方法很简单编辑 XCCDF 文件把selectedtrue改成selectedfalse。# 备份原文件 cp profiles/CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xml profiles/CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xml.bak # 查找 IPv6 相关规则 ID通常含 ipv6 或 inet6 grep -n ipv6\|inet6 profiles/CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xml # 输出类似Rule idxccdf_org.cis.benchmarks_rule_2.2.1.1 selectedtrue # 用 sed 直接替换Linux sed -i s/Rule idxccdf_org.cis.benchmarks_rule_2.2.1.1 selectedtrue/Rule idxccdf_org.cis.benchmarks_rule_2.2.1.1 selectedfalse/ profiles/CIS_CentOS_Linux_7_Benchmark_v3.0.0-xccdf.xml更高级的定制添加一条自定义规则检查/etc/motd是否包含公司安全声明。新建custom-rule.xml?xml version1.0 encodingUTF-8? xccdf:Rule idxccdf_org.mycompany_rule_motd_check selectedtrue xmlns:xccdfhttp://checklists.nist.gov/xccdf/1.1 xccdf:titleEnsure /etc/motd contains security disclaimer/xccdf:title xccdf:descriptionCheck that /etc/motd starts with WARNING: Unauthorized access prohibited./xccdf:description xccdf:check systemhttp://oval.mitre.org/XMLSchema/oval-definitions-5 xccdf:check-content-ref hrefoval-custom.xml nameoval:mycompany:def:1/ /xccdf:check /xccdf:Rule再写 oval-custom.xml本文还有配套的精品资源点击获取
