容器化网站服务的DDoSCC专项防护方案

容器化网站服务在享受弹性扩缩、快速部署红利的同时，也面临着比传统单体应用更复杂的DDoS和CC攻击威胁。攻击者不再只盯着域名或IP，而是直接瞄准容器集群的Pod漂移特性、Ingress控制器的连接数上限以及服务网格Sidecar的资源消耗。防护方案必须从网络层、应用层、编排层三个维度同步展开，否则任何一层出现短板，都会导致整个集群雪崩。

容器环境下，Pod IP是动态分配的，传统基于固定IP的黑名单策略经常失效。更有效的做法是在CNI插件层面集成eBPF程序，直接在网络数据包到达Pod之前进行过滤。通过XDP挂载点，可以丢弃SYN Flood、UDP反射放大等畸形包，而无需消耗内核协议栈资源。对于HTTP Flood，需要结合连接跟踪表，对单个源IP的并发连接数和新建连接速率做双重限制。关键参数包括：单IP最大并发连接数建议设置在50到200之间，新建连接速率限制在每秒20到100次，具体数值要根据业务正常用户的浏览器并发行为调整。如果使用Calico或Cilium作为CNI，可以直接编写NetworkPolicy配合全局阈值规则，将攻击流量阻断在节点网卡驱动层。

Ingress是容器化网站流量的总入口，也是CC攻击最集中的打击点。Nginx Ingress Controller默认的limit-req和limit-conn模块只能做简单的速率限制，面对分布式代理IP池攻击时误伤严重。建议启用分层的限流策略：第一层对全站启用基于漏桶算法的全局QPS上限，设为正常峰值的1.5倍；第二层针对登录、搜索、支付等CPU密集型接口，单独设置更严格的令牌桶速率，并开启优先级队列，确保已登录用户的请求优先处理。更关键的是在Ingress层集成JavaScript挑战和验证码。可以通过OpenResty或Envoy的Lua扩展，对请求头User-Agent为空、Accept-Language缺失、未携带正常Cookie的流量自动插入302重定向，要求客户端执行JavaScript计算并回传token。这种方式能过滤掉95%以上的脚本化CC攻击工具，因为多数攻击脚本不具备完整的浏览器渲染引擎。

很多团队忽略了一个事实：Istio或Linkerd的Sidecar代理本身会成为攻击的放大器。每个Pod的Envoy进程默认分配256MB内存，当CC攻击导致请求量暴增时，Sidecar的CPU和内存消耗会先于业务容器达到极限，进而触发OOM Kill。必须对Sidecar做资源限制，将CPU limit设置为200m到500m，内存limit设置为128MB到256MB，并开启Sidecar的并发连接数限制。在DestinationRule中配置连接池参数，maxConnections根据后端服务实际承载能力设为100到500，http1MaxPendingRequests设为1，一旦超出立即返回503，避免请求堆积。同时开启异常点检测，连续5次返回5xx错误的主机自动驱逐15秒，配合重试策略中的重试预算，防止重试风暴在网格内部放大。

HPA是容器化服务的核心弹性能力，但在DDoS攻击下，盲目扩容反而会造成资源耗尽。攻击者可以伪造大量请求触发HPA将Pod数量从10个瞬间拉到200个，如果集群节点资源不足，会导致调度失败和现有Pod被驱逐。必须给HPA配置扩缩容延迟，scaleUp.stabilizationWindowSeconds设为120秒以上，避免因瞬时流量尖峰误触发。同时设置maxReplicas硬上限，这个值要根据集群总资源预算的60%来定，留出40%给系统组件和其他服务。更进阶的做法是结合KEDA，用Prometheus指标替代CPU/内存指标驱动扩缩容。例如设置一个自定义指标http_request_duration_seconds的P99值，当延迟超过2秒且持续60秒才触发扩容，这样能有效区分正常流量增长和攻击流量。

网络层和容器层的防护只能挡住通用攻击，定制化的CC攻击需要业务层做最终裁决。在应用代码中植入请求指纹采集逻辑，收集客户端TLS握手时的JA3指纹、HTTP2的SETTINGS帧顺序、WebSocket的压缩算法协商特征。将这些特征组合成设备唯一标识，存入Redis并设置30分钟过期。当同一设备标识在短时间内请求超过阈值，直接在后端返回429状态码，并写入黑名单同步到Ingress层的Lua脚本中。对于需要登录的业务，将登录态与设备标识绑定，一个账号在多个设备标识间频繁切换时，立即触发二次验证。这种纵深防御思路，让攻击者即使更换IP、伪造UA，也难以绕过行为层面的检测。

事后分析日志对DDoS防护毫无意义，必须做到秒级检测和自动响应。将Envoy的access log输出格式改为JSON，通过Fluent Bit直接打入Kafka，再用Flink做滑动窗口聚合。关键检测指标包括：单路径的请求速率环比增长超过300%、特定状态码占比突增、请求体大小分布严重偏离基线。一旦检测到异常，Flink通过webhook回调一个自建的Operator，自动修改Ingress的ConfigMap，将攻击特征路径的请求全部drop，或者将攻击源IP段注入到Cilium的CiliumNetworkPolicy中。整个检测到阻断的闭环控制在10秒以内，远快于人工介入。

容器化服务通常运行在云厂商的VPC内，但LoadBalancer类型的Service会直接暴露公网IP，攻击者绕过CDN直接打击源站的情况屡见不鲜。必须在Service上配置loadBalancerSourceRanges，仅允许CDN厂商的回源IP段访问，其他所有IP一律拒绝。同时修改Ingress的配置，校验请求头中是否包含CDN特有的回源标识，如X-Forwarded-For的格式、特定自定义头，不匹配的直接返回444断开连接。对于WebSocket等长连接服务，需要在CDN侧开启连接保持和会话亲和性，避免回源请求被负载均衡分散到不同Pod导致状态丢失。

这看似与DDoS防护无关，实则影响巨大。攻击者经常利用容器内遗留的调试工具或漏洞组件发起反射攻击。构建镜像时必须使用多阶段构建，最终运行镜像只包含二进制文件和必要的CA证书，连curl、wget、nc等工具一律不装。基础镜像选用distroless或scratch，将攻击面降到最低。同时启用PodSecurityPolicy或OPA Gatekeeper，禁止容器以root运行、禁止挂载宿主机敏感目录、禁止添加SYS_ADMIN等危险能力。即使攻击者通过应用漏洞拿到了容器Shell，也无法安装攻击工具或发起横向移动。

对于持续性的大流量攻击，单集群的带宽和清洗能力总有上限。在DNS层面做多集群调度，正常状态下通过权重轮询将流量分散到不同区域的集群。当某个集群遭受攻击、出口带宽被打满时，通过ExternalDNS自动摘除该集群的A记录，将流量全部切到备用集群。这要求容器化应用必须做到无状态，Session数据统一存储在跨地域同步的Redis集群中，静态资源全部上对象存储并通过CDN回源。切换过程对用户完全透明，DNS TTL设置为60秒，配合客户端重试机制，可将中断时间控制在2分钟以内。

DDoS防护方案越完善，资源开销和云服务费用就越高。eBPF程序虽然性能好，但开发和维护成本高；CDN的Web应用防火墙功能强大，但按请求数计费在攻击时会产生巨额账单。需要在防护效果和成本之间做取舍。建议将防护分为常态和战时两套配置。常态下只开启基础的速率限制和eBPF包过滤，CDN的WAF仅启用OWASP核心规则集。一旦监控到攻击，通过自动化脚本一键切换到战时模式：提升CDN防护等级、启用更严格的验证码、缩紧HPA的maxReplicas、在Ingress层开启请求限速的硬拦截。平时做好切换演练，确保战时能在30秒内完成策略切换，攻击停止后5分钟内自动恢复到常态配置，避免持续产生高额费用。