很多站长在搜索「开源网站防护工具」时，会被一堆名词绕晕：WAF、HIDS、漏洞扫描器看起来都在做安全，装哪个才不浪费精力？现实是三类工具解决的是完全不同层面的问题，选错方向要么白装，要么漏掉真正的攻击入口。本文按实战视角拆解三者的能力边界，给出可直接执行的部署命令、验证步骤与选型清单，帮你在一个下午搭起分层防护。

一、三类工具到底在防什么

先明确边界，再谈选型。三者不是替代关系，而是覆盖不同攻击面。

类型	工作层面	典型能力	看不见什么
WAF	HTTP/HTTPS 应用层	SQL注入、XSS、路径穿越、CC限速、恶意UA拦截	SSH爆破、提权、挖矿进程
HIDS	主机/系统层	文件完整性、登录审计、异常进程、Rootkit检测	HTTP语义、业务逻辑漏洞
扫描器	资产与漏洞面	已知CVE、弱口令、配置错误、暴露面发现	实时拦截、运行时行为

结论很直接：WAF负责挡、HIDS负责看、扫描器负责查。真实入侵路径通常是「扫描器发现暴露面 → WAF未拦住Web漏洞 → 攻击者落地主机」，任何一层缺失都会让证据链断裂。

二、开源WAF：ModSecurity + OWASP CRS 最快落地

开源WAF里，Nginx+ModSecurity配合OWASP CRS是部署成本最低、规则最成熟的组合。以Debian/Ubuntu为例：

apt install libmodsecurity3 libnginx-mod-http-modsecurity -y
git clone https://github.com/coreruleset/coreruleset /etc/nginx/modsec/crs
cp /etc/nginx/modsec/crs/crs-setup.conf.example /etc/nginx/modsec/crs/crs-setup.conf

在Nginx配置中启用模块并加载规则，首次务必用观察模式：

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
# main.conf 中设置
SecRuleEngine DetectionOnly

观察一周后执行收敛：

1. 用 grep -o 'id "[0-9]*"' /var/log/modsec_audit.log | sort | uniq -c | sort -rn 统计高频命中规则；
2. 对确认为误报的规则用 SecRuleRemoveById 942100 单独关闭，不要整体降级；
3. 回归测试登录、支付、上传等关键路径后，把 DetectionOnly 改为 On。

注意CRS默认对请求体大小、上传文件有检查阈值，业务有大文件上传时需调整 SecRequestBodyLimit，否则会出现「上传正常但被静默拦截」的隐蔽故障。

三、HIDS：Wazuh/OSSEC 的关键是配白名单

HIDS不是装完就完事，默认规则全开会产生海量噪声。以Wazuh为例，核心动作是文件完整性监控（FIM）与登录告警：

# 安装后编辑 /var/ossec/etc/ossec.conf
<syscheck>
  <directories check_all="yes">/etc,/usr/bin,/bin</directories>
  <ignore>/var/www/html/cache</ignore>
</syscheck>

落地要点：

• 只监控不该变的目录：系统二进制、配置、Web根目录；缓存、日志、发布临时目录必须排除。
• 登录告警只留高价值事件：root登录、连续失败、非工作时间登录。
• 分级推送：高危即时通知，低危每日汇总，避免告警疲劳。

验证方法：手动 echo test >> /etc/hosts，确认FIM在1分钟内产生告警，否则说明配置未生效。

四、扫描器：Nuclei 定期补盲，别当实时防护

扫描器解决的是「你不知道自己暴露了什么」。Nuclei模板更新快、误报可控，适合每周定时跑：

nuclei -u https://your-site.com -severity critical,high \
  -rate-limit 50 -exclude-tags destructive \
  -o /var/log/nuclei/$(date +%F).txt

三条纪律：限制速率避免压垮老应用；排除破坏性模板；结果必须人工复核，误报直接改配置可能引入新故障。扫描时间选业务低峰，先扫测试环境确认无副作用。

五、选型决策表与落地检查清单

场景	优先组合	理由
个人站/小团队	WAF + 每周扫描	成本低，覆盖主要自动化攻击
多台服务器/有合规要求	WAF + HIDS + 扫描	需要主机层审计与证据留存
高交互业务（登录、支付）	WAF拦截 + HIDS + 业务日志	逻辑漏洞需结合行为分析

落地检查清单：

1. WAF已从观察模式切到拦截，且关键业务路径回归通过；
2. 误报规则已按ID精确排除，而非整体关闭；
3. HIDS的FIM排除项覆盖缓存、日志、发布目录；
4. 登录告警已分级，高危事件有即时通道；
5. 扫描器已配置速率限制与低峰定时任务；
6. 三类工具日志统一留存不少于30天，便于溯源。

如果团队人力有限、希望减少自建规则的维护成本，可以在WAF层引入具备托管规则与自动收敛能力的方案，例如 AegisX 的Web防护能力可与开源栈互补，把精力留给业务本身。

六、行动建议

不要一次上齐三件套。按「先挡后看再查」的顺序推进：本周先完成ModSecurity观察模式部署并收集误报；下周切换拦截并补上Nuclei定时扫描；等服务器规模扩大或出现合规要求时，再引入Wazuh做主机层监控。每完成一步都用清单验证，确保工具真正生效，而不是停留在「已安装」状态。

常见问题（FAQ）

小网站预算有限，只装一个开源防护工具选哪个？

优先选WAF。绝大多数站点面临的自动化扫描、SQL注入与CC攻击都发生在HTTP层，ModSecurity+OWASP CRS能以极低资源开销拦掉大部分通用攻击，且部署在Nginx上不影响业务代码。扫描器可先用Nuclei每周跑一次补盲，HIDS等出现多台服务器或合规要求时再补。

WAF和HIDS能互相替代吗？

不能。WAF工作在应用层，只能看到经过Web服务的HTTP流量，对SSH爆破、提权、挖矿进程、篡改系统文件完全无感；HIDS在主机层监控文件完整性、进程与登录行为，但看不懂HTTP语义。真实入侵往往是先Web漏洞再落地主机，两层都布才能形成完整证据链。

开源WAF误拦截业务请求怎么办？

先把SecRuleEngine切到DetectionOnly观察模式，运行一周收集日志，用grep筛选规则ID命中频率，对高频误报规则用SecRuleRemoveById单独关闭，而不是整体降级。上线前务必用真实业务流量回归测试登录、支付、文件上传等关键路径，再切回On模式。

漏洞扫描器扫自己的站会不会把服务打挂？

一般不会，但要注意速率与危险插件。Nuclei默认并发较高，对老旧应用可能造成压力，建议用-rate-limit限制每秒请求数，并排除destructive类模板。扫描时间选业务低峰，先扫测试环境确认无副作用再扫生产，扫描结果要人工复核，避免把误报当漏洞盲目改配置。

HIDS部署后告警太多看不过来怎么收敛？

先做白名单再谈告警。把已知的定时任务、发布目录、日志轮转路径加入文件完整性监控排除项，登录告警只保留root与失败多次的账号，其余先入库不推送。用Wazuh的规则分级把高危事件单独走即时通知，低危每日汇总，否则告警疲劳会让HIDS形同虚设。