必须先确认适用合规基线（如等保2.0三级对应ospp、通用企业选cis），再用oscap info验证SCAP内容包及profile列表，确保版本匹配、策略生效范围全覆盖，避免因标准错配或配置断链导致“未验证”或“不满足控制点”。
Linux 安全合规不是加几个配置就完事，而是要匹配具体标准（比如等保2.0三级、CIS Benchmark），否则检查时会卡在“未验证”或“不满足控制点”。直接上手前，先确认你面对的是哪类测评——这决定了哪些项必须做、哪些可裁剪。
怎么判断当前系统该套哪个合规基线
别一上来就改 /etc/shadow 或 sshd_config。先用工具识别适用标准：
-
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml—— 输出里有Profile列表，比如xccdf_org.ssgproject.content_profile_cis或xccdf_org.ssgproject.content_profile_ospp（OSPP 是等保常用） - 金融/政务系统大概率要用
ospp；通用企业环境优先选cis；若无 SCAP 内容包，rpm -q scap-security-guide会提示未安装 - 注意版本对齐：
ssg-rhel7-ds.xml不能用于 CentOS 8，否则oscap xccdf eval报Invalid data stream
账号口令类配置最容易踩的坑
很多团队配了 PASS_MAX_DAYS 90 却仍被判定不合规，问题出在策略未生效范围：
-
/etc/login.defs只影响新用户；老用户需用chage -M 90 <username></username>单独设置，否则awk -F: '($3==0)' /etc/passwd查出的账号可能仍永不过期 -
pam_tally2（RHEL 7+）和pam_faillock（RHEL 8+）不能混用：旧配置里留着pam_tally.so行，新系统会忽略它，导致锁定失效 -
auth required pam_wheel.so group=wheel要配合usermod -aG wheel username，否则su -直接拒绝，且错误日志里只写Authentication failure，不提示组权限问题
SSH 和 nginx 配置必须联动验证
单独改 sshd_config 的 PermitRootLogin no 不够，等保要求“身份鉴别+访问控制+审计”三者闭环：
- nginx 若代理 SSH 管理端口（如跳板机场景），
server块里必须同步限制allow/deny，否则扫描工具仍能打穿 -
LogLevel VERBOSE在sshd_config中开启后，/var/log/secure才记录密钥指纹，否则等保“审计日志包含用户标识”项不通过 - nginx 的
auth_basic用户文件必须用htpasswd -B（bcrypt）生成，-d（crypt）或-s（SHA）会被判定为弱哈希
firewalld 默认 drop 区域不等于安全
设成 default-zone=drop 后，很多人以为万事大吉，但实际漏掉关键点：
- firewalld 不管本地回环（
lo）接口，默认放行所有127.0.0.0/8流量——攻击者若拿下 webshell，可直连本地数据库或 redis -
firewall-cmd --permanent --add-service=http开放端口时，没加--zone=public，规则会落到默认 zone，而drop区域下该服务实际不可达 - 若用
iptables规则混用（比如某些容器网络插件残留规则），firewall-cmd --list-all看不到它们，但它们仍在生效，导致策略冲突
faillock 但没清空 /var/run/faillock/ 里的旧锁文件，导致所有用户首次登录即被锁。合规是链条，断一环，整条线就挂。 
