Linux安全配置核查流程_基线对比说明【指导】

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" 观察变更后行为——这些动作比堆砌检查项重要得多。