linux安全配置核查核心是确认配置与所选安全基线（如等保2.1、cis、nist）一致且差异可控；须严格匹配基线版本与系统版本，区分通用/扩展要求，自动化工具需辅以手工验证运行时状态，偏差处置应基于风险、业务依赖与补偿控制综合判断。
Linux 安全配置核查不是“跑个脚本打个分”就完事的，核心在于确认当前配置与组织采纳的安全基线（如等保2.1、CIS Benchmark、NIST SP 800-53）是否一致，且差异具备可解释性与可控性。
如何确认你用的是哪份基线？
很多人跳过这步直接查配置，结果发现检查项对不上、严重等级理解错、甚至拿 CentOS 7 的 CIS v2.0 去套 RHEL 9 —— 基线版本和系统版本不匹配，结论必然失效。
-
CIS Benchmarks按发行版和版本细分，例如CIS_Red_Hat_Enterprise_Linux_9_Benchmark_v1.0.0和CIS_CentOS_Linux_7_Benchmark_v2.2.0是不同文档，检查项数量、路径、命令都可能不同 - 等保2.1 要求的是“通用要求+扩展要求”，
/etc/ssh/sshd_config中的PermitRootLogin属于通用项，但容器环境下的seccomp策略属于云计算安全扩展项，不能混为一谈 - 企业自定义基线必须有明确版本号和发布日期，建议存为
/opt/baseline/cis-rhel9-v1.1-202403.yaml这类带时间戳的路径，避免多人使用不同草稿
手动核查 vs 自动化工具输出，哪个更可信？
自动化工具（如 lynis、oscap、inspec）能快速覆盖 80% 的文件权限、服务状态、密码策略类检查，但对以下场景极易误报或漏报：
-
sysctl参数是否生效：工具读/etc/sysctl.conf发现net.ipv4.conf.all.rp_filter = 1，但没验证sysctl -n net.ipv4.conf.all.rp_filter实际值是否为1（可能被 systemd-sysctl 或运行时覆盖） - 日志审计规则是否持久：
auditctl -l显示规则已加，但没检查/etc/audit/rules.d/*.rules文件里是否落盘，重启后是否丢失 - SELinux 策略是否真启用：
getenforce返回Enforcing，但若/etc/selinux/config中SELINUX=disabled，下次重启就失效
发现配置偏差后，怎么判断该修复还是保留？
不是所有“不合规”都要改。关键看三点：风险是否真实存在、业务是否强依赖、补偿控制是否到位。
- 例如基线要求禁用
telnet，但某旧设备只支持 telnet 管理且无法替换——此时应记录为“已知例外”，在/var/log/audit/exceptions.log中写明设备 IP、责任人、替代方案时间节点，而非强行关闭导致断连 - 基线要求
umask为027，但某应用服务用户（如webapp）需创建组内可写的临时目录——应单独为其 shell 配置umask 002，而非全局改/etc/bashrc - 修改
/etc/pam.d/system-auth启用pam_faillock.so锁定账户前，务必先测试是否影响 SSH 密钥登录、sudo 免密场景，否则可能把自己锁在外面
#!/bin/bash # 示例：检查 sysctl 实际值是否与配置文件一致（易被忽略的点） CONFIG_FILE="/etc/sysctl.conf" PARAM="net.ipv4.ip_forward" EXPECT="0" ACTUAL=$(sysctl -n $PARAM 2>/dev/null) if [ "$ACTUAL" != "$EXPECT" ]; then echo "ALERT: $PARAM is $ACTUAL (expected $EXPECT) — check runtime vs config" fi
真正卡住进度的，往往不是“不知道怎么查”，而是查完不敢动、动了怕出事、出了事没回滚路径。每次修改前，用 systemctl show --no-pager servicename 看依赖关系，用 diff 备份原配置，用 journalctl -u servicename --since "1 hour ago" 观察变更后行为——这些动作比堆砌检查项重要得多。
