自托管服务一旦公开到公网，就会直面两类"不那么善意的流量"：一是 DDoS/CC——用海量请求或连接把入口/后端打瘫；二是 Web 攻击——SQL 注入、XSS、路径穿越、扫描探测。前面聊的限流挡"频率滥用"，防火墙挡"端口"，但针对"应用层攻击与超大流量"还要更专的一层：WAF（Web 应用防火墙）做请求内容检测，配合 CDN/高防做流量清洗，形成纵深防御。这篇讲清 WAF 与 DDoS 防御解决什么、ModSecurity/OpenResty 怎么落地 WAF、DDoS 的分层应对，以及常见坑与边界。
一、WAF 与 DDoS 防御解决什么：在"入口"拦掉攻击流量，别让业务层接招
攻击者打的是"业务入口"（你的域名/IP），如果业务层直接暴露，每个攻击请求都会消耗真实资源、制造真实错误。防御的核心思想是"把攻击拦在业务之前"：WAF 在反代/网关上检查请求内容（URL、参数、请求体、头），命中注入/XSS/扫描特征就直接拦截（返回 403/挑战页），不让它到达应用；DDoS 应对则是在"流量层面"分流——超大带宽型（流量打爆链路）靠高防/CDN 清洗，连接/请求型（CC）靠限流与防护节点扛住。两层合起来，业务层接到的才大多是"正常请求"。对自托管，"你暴露的入口有没有防护"决定了被攻击时是"小麻烦"还是"直接被打瘫"。
它和前面聊的各层的分工：防火墙管"端口/来源"，限流防爬管"频率"，WAF 管"请求内容是否恶意"，DDoS 防护管"流量规模是否异常"——从网络层到应用层逐层收口，每一层挡一类，合起来才是纵深防御，没有哪一层能单独兜底。
二、WAF 怎么落地：ModSecurity + OWASP CRS 或 OpenResty 规则
自托管落地 WAF 的两条主流路线：一是 ModSecurity（老牌 WAF 引擎）配 OWASP Core Rule Set（CRS，社区维护的注入/XSS/扫描检测规则集），通常挂在 Nginx 前（libmodsecurity 模块）或反向代理层；二是用 OpenResty（Nginx + Lua）按 Lua 规则做请求检查（前面聊 OpenResty 网关时的同款技术栈）。落地模式：反代先解析请求 → WAF 规则检测 → 命中则拦截/记录/挑战，不命中再转发后端。先"检测 + 记录"（Detection）跑一段，再开"拦截"（Block），避免误伤合法请求。
# ModSecurity + CRS 的最小思路（Nginx + libmodsecurity）
# nginx.conf 里启用 ModSecurity 并加载规则
modsecurity on;
modsecurity_rules_file /etc/modsecurity/modsecurity.conf;
# modsecurity.conf 关键设置：
# SecRuleEngine DetectionOnly # 先只检测记日志，不拦截
# Include /etc/modsecurity/crs/crs-setup.conf
# Include /etc/modsecurity/crs/rules/*.conf
# 观察一段日志、确认无误伤后，再改为 On 真正拦截
# 也可用 OpenResty + Lua 写更贴合业务的自定义检测/限流
WAF 的坑主要是"误伤"与"规则噪音"：CRS 全开很敏感，合法请求（带特殊字符的表单、正常 API 参数）可能被误拦——先 DetectionOnly 跑、按自己的流量调规则/加白名单；以及"绕过"——攻击者会变体绕过规则，WAF 是"拦截常见攻击"而非"绝对免疫"，配日志与分析持续跟进。别把 WAF 一开就以为安全了，它需要观察、调优与更新规则。
三、DDoS 分层应对：带宽型、连接型、应用型各打各的
DDoS 要分型而治。带宽型（UDP flood/反射放大，把链路打满）：单机自扛无解，要接"高防 IP/CDN 清洗"——流量先经过高防节点被清洗掉攻击，再回源到你的机器，前提是"源站 IP 不暴露"。连接型（SYN flood/连接耗尽）：靠系统参数（syn cookies、连接队列）与防火墙/防护节点扛。应用型/CC（慢速连接、高频请求打业务接口）：靠限流（前面聊过 limit_req）、WAF 规则与业务层兜底。核心策略是"源站隐藏 + 流量前置清洗 + 逐层限流"，以及"别等被打才想起：平时就配好 CDN/高防与源站防护"。
# 应对思路分层示意
# 带宽型：接 CDN/高防，流量先清洗，回源只放真实 IP；源站 IP 别暴露
# 连接型：系统层调高连接承受力（net.ipv4.tcp_syncookies=1 等）+ 防火墙限速
# 应用型：Nginx limit_req/limit_conn 限频 + WAF 拦截 + 业务幂等与快速失败
# 运维层：DDoS 时要有"快速切换入口/回源"预案与告警，别临场找方案
DDoS 的坑是"源站暴露"与"等被打才配"：接 CDN/高防但 DNS 里泄露了源站 IP（历史记录、漏配的旁路域名），攻击者直接打源站，清洗等于白配；以及"没有预案"——真被打时手忙脚乱。平时就把"CDN/高防 + 源站隐藏 + 限流兜底 + 告警预案"配好，DDoS 才从"事故"变成"可处理的运维事件"。
四、常见坑：误伤、源站暴露、只堆一层、没有观测
Web 安全防御四个坑要尤其防。一是"误伤"：WAF/限流配得过狠，把正常用户也拦了——先 DetectionOnly/宽阈值观察、再收紧，敏感路径严、普通访问宽（前面聊限流时同款原则）。二是"源站暴露"：一切流量清洗的前提是源站不被直接找到——检查历史 DNS、子域、旁路端口，源站 IP 尽量只在回源白名单里。三是"只堆一层"：只装 WAF 不管限流、或只限流不管 WAF，都会被对方钻空子——各层配合才叫纵深。四是"没有观测"：拦截日志没人看、告警没人配，攻击过去了都不知道——把 WAF 拦截、DDoS 事件、限流命中都接进日志与告警（前面聊过），让"被攻击"变成可发现、可复盘。
# 排障 SOP：被攻击/被误伤时的快速定位
# 1) 是哪种流量？看监控：带宽打满→带宽型；连接数爆→连接型；接口高并发→CC
# 2) 被 WAF 误伤？查 WAF 拦截日志与规则命中，调整规则/白名单
# 3) 源站被打？查是否有源站 IP 泄露，收紧回源与入口
# 4) 都有预案吗？平时配好 CDN/高防、限流、告警，别临场找方案
把它当排障 SOP：先"分型定位（带宽/连接/应用）"，再"查对应层是否生效（清洗/限流/WAF）"，后"看观测数据复盘与调优"。防御是"配置 + 观测 + 预案"的组合，缺了观测，配了等于没配。
五、边界：WAF/DDoS 防护挡"常见攻击与流量规模"，不是绝对免疫
这层的边界要认清：WAF 拦"已知模式的 Web 攻击"、DDoS 防护扛"流量规模"，但**不是绝对免疫**——绕过规则的变体、针对业务逻辑的攻击（如薅羊毛、恶意下单）、以及超大规模（Gbps/Tbps 级）DDoS 靠自托管单点本来就不现实（那要专业高防资源）。其次，防御层挡住攻击，但业务本身要"扛得住合法流量下的异常"（限流兜底、快速失败、幂等），否则被 CC 打到业务逻辑照样挂。最后，所有拦截/清洗都引入额外链路，要接受"防御层的延迟与成本"，并在"防护强度"与"正常用户体验"间平衡。
把 WAF 与 DDoS 防御放回自托管整体：它是"入口纵深防御"的关键层——WAF 管"请求内容是否恶意"，DDoS 防护管"流量规模是否异常"，与防火墙/限流/网络策略合起来把攻击拦在业务之前。落地要点：用 ModSecurity + CRS（或 OpenResty Lua）在反代层做 WAF，先 DetectionOnly 再 Block、按业务调规则防误伤；DDoS 按带宽/连接/应用分型应对——CDN/高防清洗 + 源站隐藏 + 系统参数与限流兜底 + 告警预案；防住误伤、源站暴露、只堆一层、没有观测四坑；并认清它挡常见攻击与规模、非绝对免疫，超大流量要专业高防。当你把"入口清洗、内容检测、限流兜底、观测预案"这串纵深做好，自托管的公网服务才敢说"扛得住、也看得清"。
结语
WAF 与 DDoS 防御的价值，是把攻击拦在业务层之前：WAF 用规则检测请求内容拦掉注入/XSS/扫描，DDoS 防护用 CDN/高防清洗与限流扛住流量规模，与防火墙、限流合起来构成入口纵深防御。落地要点：反代层上 ModSecurity + OWASP CRS（或 OpenResty Lua），先 DetectionOnly 观察、再 Block，按自己流量调规则防误伤；DDoS 分带宽/连接/应用三型应对——高防/CDN 清洗 + 源站 IP 隐藏 + 系统参数与 limit_req 兜底 + 告警预案；防住误伤、源站暴露、只堆一层、没有观测四坑；并认清它挡常见攻击与规模、非绝对免疫、超大流量需专业高防。当入口的每一层都有人值班、有数据可查，自托管的公网服务才能在被攻击时"有惊无险"而不是"一打就瘫"。
