基线核查清单与自动化：把加固变成可复跑的工程

前面七章，我们逐个对象讲了怎么加固：Linux、Windows、MySQL、Nginx、Apache、IIS。但现实里有两个绕不开的问题：

机器一多，手工打勾根本忙不过来——你有 50 台服务器、10 个数据库，怎么保证每台都按基线配了？
配置会漂移——同事改了个参数、打了个补丁、重装了系统，基线又被悄悄改回去，你却不知道。

这一篇就是来解决这两个问题的：把零散的加固项，变成一张清单 + 一套能自动跑的核查/加固脚本，让安全水位可度量、可复现、可监控。

本文脚本与思路仅用于你自有或已授权的资产。自动化改配置前务必在测试环境验证，并保留回滚手段。

第一步：把基线抽象成”检查项”

不管对象是什么，每个加固项都能抽象成同一个结构：检查项 + 期望状态 + 检查方法 + 判定规则。例如：

对象	检查项	期望	检查方法	判定
Linux	root 远程登录	禁止	`grep PermitRootLogin`	含 `no` 即通过
MySQL	secure_file_priv	非空目录	`SHOW VARIABLES`	非 `NULL`/空即通过
Nginx	版本暴露	关闭	`curl -I` 看 Server 头	不含版本号即通过
Windows	账户锁定阈值	≤5	`net accounts`	符合即通过

一旦把基线写成这种”表格”，它就可以被脚本逐条比对——这就是自动化核查的核心思想。

第二步：用 Shell 做单台核查（Linux 示例）

把多条检查写成一个脚本，输出”通过/失败”清单：

#!/bin/bash
# baseline_check.sh —— Linux 基线核查（节选）
pass=0; fail=0
check() { if eval "$2"; then echo "PASS: $1"; ((pass++)); else echo "FAIL: $1"; ((fail++)); fi; }

check "禁止 root 远程登录" "grep -q '^PermitRootLogin no' /etc/ssh/sshd_config"
check "无空密码账户"      "[[ -z $(awk -F: '(\$2==\"\"){print \$1}' /etc/shadow) ]]"
check "禁用 Telnet"       "! systemctl is-enabled telnet.socket 2>/dev/null | grep -q enabled"
check "默认共享未开"      "! ls /etc/samba 2>/dev/null"

echo "---- 结果: PASS=$pass FAIL=$fail ----"

这类脚本可以 cron 每天跑一次，把结果发到运维群或写进监控。失败项高亮，运维按图索骥去修。

第三步：用 Ansible 把”加固”也自动化

核查只能发现问题，修复还得靠人。进阶做法是把加固动作写成 Ansible playbook（幂等，重复执行不会出错）：

# harden_ssh.yml（节选）
- hosts: all
  become: yes
  tasks:
    - name: 禁止 root 远程登录
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
      notify: restart sshd
    - name: 设置密码复杂度
      copy:
        dest: /etc/security/pwquality.conf
        content: |
          minlen = 12
          dcredit = -1
          ucredit = -1

新机器装机时一键 ansible-playbook 应用，基线立刻到位；老机器定期重跑，能自动把”漂移到不安全”的配置拉回基线。这就是”固化”的真正含义——不是改一次，而是持续保持。

第四步：数据库与 Web 的核查脚本

MySQL 用命令行取变量比对：

mysql -N -e "SHOW VARIABLES LIKE 'secure_file_priv';" | \
  awk '{if($2==""||$2=="NULL"){print "FAIL secure_file_priv"}else{print "PASS secure_file_priv"}}'

Nginx/Apache 用 curl -sI 抓响应头，用 grep 判断安全头是否齐全、版本是否隐藏。把这些小检查拼成一个总脚本，就是一套跨组件的”Web+DB 基线核查器”。

第五步：接入配置合规平台（企业级）

机器到几百上千台，脚本也不够看了，需要配置管理数据库（CMDB）+ 合规平台：

用 OpenSCAP / CIS-CAT 直接对照 CIS Benchmark 做权威扫描，输出合规率报告。
用 SIEM / 态势感知 定期拉取各机配置，做”基线漂移”告警——一旦某台偏离，立刻通知。
用 ITSM 把”偏离基线”转成工单，闭环修复。

到这一层，基线核查就从”运维的个人习惯”变成”组织的安全制度”。

常见误区

只有核查脚本没有修复手段：脚本天天报 FAIL，却没人修，等于没查。
脚本不幂等：加固脚本重复跑会报错或叠加重复配置，导致环境不一致。
只在装机时跑一次：忽略了后续漂移，半年后基线早已名存实亡。
清单不更新：新漏洞、新组件出现后，基线清单还是三年前的，覆盖不到新风险。

进阶：基线与等保/合规挂钩

基线清单不是孤立的——它向上可以映射到等保基本要求、ISO 27001 控制项。比如”禁止 root 远程登录”对应等保”访问控制”条款。把基线条目和合规条款做映射，核查通过率就能直接作为合规证据。这部分在”等级保护”子分类会展开。

自测题

为什么”只核查不修复”等于没做基线管理？
Ansible playbook 的”幂等”为什么对加固很重要？
配置漂移是什么？怎么用自动化防止？
基线清单和等保条款做映射，有什么实际价值？

实战要点与深度解析

把基线”自动化”之后，下一个真实挑战是如何处理”核查永远有 FAIL”这件事。理想很丰满：脚本一跑全 PASS。现实很骨感：总有那么几台老系统因为历史原因改不了（比如某个上古业务必须跑在 root 下、某个设备不支持密钥登录）。这时如果一刀切要求”全部 PASS 才能上线”，业务会和你拼命；如果放任 FAIL，基线又失去意义。成熟的做法是引入风险例外（Exception）机制：每一条 FAIL 必须有人”签字认领”、写明原因、设到期日，到期要么整改要么续期并说明理由。这样基线从”死板清单”变成”有责任人、有期限的活流程”。

再谈一个工程细节：核查脚本自身的可信度。如果攻击者已经拿下你的跳板机，他完全可以改掉基线核查脚本，让它在”被入侵的主机”上也输出 PASS——你的监控反而成了瞎子。所以核查脚本和结果应当在独立、受控的平台运行和存储，最好由配置管理平台（如 Ansible Tower、配置合规中心）主动去拉取各机状态，而不是依赖各机”自报平安”。这也是为什么企业级方案要用中心化的 CMDB + 合规平台，而不是散落各机的本地脚本。

关于 基线和变更管理的结合：很多基线漂移，源头是”一次未经评审的变更”。比如运维为排查问题临时开了个端口、忘了关，三个月后成了入口。把基线核查接入变更流程——任何变更走审批、变更后自动触发一次基线复核查差异——能从机制上减少”临时改动变永久暴露”。这也是 DevOps 里”基础设施即代码（IaC）“的思路：环境由代码定义，偏离代码的状态就是异常，一目了然。

还有一个进阶视角：基线数据反哺威胁建模。当你统计出”全公司 30% 的 Linux 还没关密码登录""50% 的 MySQL 还开着 local_infile”，这些数字本身就是优先级最高的安全投入依据。与其追着每一个新 CVE 跑，不如先把”大面积不合规的高频项”消灭掉——它们才是攻击者批量扫描时最容易命中的目标。基线的统计视图，因此也是安全决策的输入。

最后提醒：别让自动化变成”自动忽略”。有了脚本和平台，人更容易产生”系统会帮我看着”的错觉，反而疏于review。基线工具是放大器，放大你的安全水位，也放大你的疏忽。定期人工抽检、定期复盘 FAIL 趋势，依然不可替代。

速查清单：一份跨对象基线速记

把前面七章的”最高频检查项”压成一张速记表，方便你做核查时一眼过：

Linux：root 禁远程、无空口令、关 Telnet、sshd 改端口、审计开、日志外发。
Windows：强口令+锁定、禁匿名共享、RDP 走堡垒机、关默认共享、审计开、应用池低权限。
MySQL：root 本机、清匿名、应用账号限来源最小权限、secure_file_priv 受限、备份。
Nginx/Apache/IIS：隐版本、限方法、上传目录禁执行、齐安全头、TLS 新协议、日志外发。

记住：这八张清单不是背的，是写成脚本定期跑的。当它们变成自动核查的 PASS/FAIL 输出，基线的价值才真正落地。下一阶段如果你要对接合规，直接把这张表映射到等保条款即可（见”等级保护”子分类）。

这一篇你该记住的

把每个加固项抽象成”检查项 + 期望 + 方法 + 判定”，便于脚本化。
单台用 Shell/Python 脚本做核查，输出 PASS/FAIL，定时跑。
用 Ansible playbook 把”修复”也自动化，且必须幂等。
数据库/Web 用命令行 + curl 抓头做核查，拼成跨组件检查器。
规模上来后接入 OpenSCAP/CIS-CAT、SIEM 做漂移告警与合规闭环。
基线清单向上映射等保/ISO 条款，核查结果可直接作合规证据。

到此，安全加固这一子分类就讲完了。从总论、Linux、Windows、MySQL、Nginx、Apache、IIS，到基线自动化——你已经有了一套可落地的加固方法论。下一套内容我们进入应急响应：当入侵真的发生，怎么按标准流程快速止损、溯源、恢复。

网络安全