web安全基线自动化核心是将人工防护固化为可验证流程，覆盖waf同步、权限控制、运行时监控、日志联动与应急响应五类能力，强调精准收敛、最小暴露、快速感知，并通过ansible实现幂等部署、文件防篡改、闭环验证与结构化报告。
标准化 Web 环境安全防御基线，核心是把人工反复检查的防护动作固化为可重复、可验证、可审计的自动化流程，重点覆盖 WAF 规则同步、文件权限控制、运行时监控、日志联动和应急响应五类能力，不追求“全关全锁”，而强调“精准收敛、最小暴露、快速感知”。
聚焦 Web 服务关键面，明确加固范围
Web 环境不是孤立系统，需分层识别风险点并设定基线：
- 静态资源层：网站根目录（如 /var/www/html）、上传目录（如 /uploads）、配置文件（如 .env、wp-config.php）必须设为不可执行（noexec）、不可写（644 或 444）、属主为 web 服务用户（如 www-data）且禁止 world-writable
- 运行时层：PHP-FPM、Nginx/Apache 进程应以非 root 用户运行；禁用危险函数（如 system、exec、eval），通过 php.ini 的 disable_functions 统一管控
- 访问入口层：WAF（如 ModSecurity + OWASP CRS）规则需与等保三级或 CIS Web Server Benchmark 对齐，自动加载最新规则集，并关闭默认宽松策略
- 日志与审计层：Nginx access/error 日志、PHP 错误日志、ModSecurity audit log 必须启用、权限设为 600、按天轮转、转发至中心 SIEM（如 ELK 或 Splunk）
用 Ansible 实现 Web 基线的幂等化部署
Shell 脚本易因路径错误、权限缺失或命令返回值忽略导致加固中断甚至破坏服务。Ansible 提供更稳的落地能力：
- 用 copy 模块 + validate 参数 替代手动 cp，例如部署 .user.ini 时校验语法：
validate: 'php -l %s' - 用 file 模块递归设权限，但避开敏感子路径：对 /var/www/html 设 755，但对 uploads/ 单独设为 750，对 .env 文件强制设为 600
- 用 community.general.modsec_rule 模块批量启用/禁用 ModSecurity 规则 ID（如 932100、942100），支持 dry-run 预检
- 用 lineinfile + backup: true 修改 php.ini，自动备份原文件，并在变更后触发
systemctl reload php-fpm
强化文件防篡改与实时监控
Webshell 和不死马常通过修改文件或创建隐藏进程绕过静态加固，需主动防御：
- 对关键文件（如 /etc/passwd、/var/www/html/index.php、.htaccess）用 chattr +i 加锁，脚本执行前先判断是否已锁定，避免重复操作报错
- 部署轻量级 inotify 监控脚本（Python 或 Bash），监听 uploads/、tmp/、cgi-bin/ 下的新增/修改事件，发现异常 PHP/SH 文件立即告警并移动隔离
- 集成 AIDE（Advanced Intrusion Detection Environment），每日凌晨生成文件完整性快照，比对差异项并邮件通知；AIDE 配置需排除动态日志和缓存目录
闭环验证与结构化报告
加固不是“跑完即结束”，必须验证效果、留痕、可回溯：
- 执行后自动运行验证任务：检查 Nginx 是否监听 80/443、ModSecurity 是否启用（
curl -I http://localhost | grep X-MODSEC）、PHP disable_functions 是否生效（php -r "print_r(ini_get('disable_functions'));"） - 生成 HTML 报告，含加固项状态（✅ 已达标 / ⚠️ 已跳过 / ❌ 失败）、失败原因、受影响路径、修复建议
- 所有操作记录写入 /var/log/web-hardening.log，包含时间戳、执行用户、playbook 名称、变更摘要，供审计调阅
不复杂但容易忽略：真正有效的 Web 安全基线自动化，不在参数堆砌，而在理解业务依赖——比如 CMS 上传目录必须可写但不可执行，API 接口需开放 OPTIONS 方法但禁用 TRACE，这些细节必须通过变量或条件任务显式表达，而不是写死在脚本里。
