合规性报告不等于安全加固效果，它仅反映是否符合规则而非规则防攻击能力；failed项需结合实际攻击面判断风险，如permitrootlogin在公网跳板机为高危但在内网离线节点无影响。
系统合规性报告本身不等于安全加固效果，它只反映“是否符合某套规则”，不验证“规则是否真能防住攻击”。
怎么看合规性报告里的 FAILED 项是不是真风险
很多团队一看到报告里一堆 FAILED 就立刻修，结果改完反而引发服务中断。关键不是数量，而是每条检查背后的攻击面是否真实存在。
-
ssh PermitRootLogin yes在暴露公网的跳板机上是高危，在内网离线管理节点上可能根本无影响 -
password_max_age 90检查失败，但如果所有账号都用ssh_key认证，密码策略实际不生效 - 某些
CIS Benchmark要求禁用IPv6，但你的容器网络依赖IPv6地址分配，硬关会导致Pod启动失败
auditd 日志和 oscap 扫描结果对不上怎么办
常见现象：扫描工具说 /etc/shadow 权限是 0644（应为 0600），但 ls -l /etc/shadow 显示明明是 0600。本质是工具读取的是容器镜像层或快照状态，不是运行时实际文件。
- 用
oscap扫描前，确认执行环境：宿主机？容器？chroot？不同上下文oscap看到的根路径不同 -
auditd规则若监听chmod，但没开auditctl -e 2（锁定规则），重启后规则丢失，日志就断了 - 某些加固脚本会临时改
/proc/sys/kernel/kptr_restrict，导致oscap无法读取内核符号，误报“检查跳过”
安全加固后为什么 curl https://api.example.com 开始超时
合规检查常推动启用 iptables 或 nftables 默认 DROP，但容易漏掉本地出站流量的放行逻辑，尤其涉及 DNS、TLS 时间戳（ocsp）、证书链下载等隐式连接。
- 检查是否放行了
lo接口的全部流量：iptables -A OUTPUT -o lo -j ACCEPT -
systemd-resolved默认监听127.0.0.53:53，但防火墙规则若只放行53/udp，没放开53/tcp（大响应包会降级），DNS 就会卡住 - 加固脚本若修改了
/etc/nsswitch.conf，把files放在dns后面，而/etc/hosts里又没配好服务地址，curl会先查 DNS 再 fallback，拖慢整个流程
真正难的不是跑通一条合规项，而是搞清某条规则在你当前网络拓扑、服务依赖、部署形态下的实际作用域——同一行 sysctl 参数，在裸金属、KVM、containerd 三种环境里，生效位置和副作用完全不同。
