政企网站DDoS防护的难点从来不在“有没有买设备”，而在“买了之后是否真正适配自身业务与运维能力”。大量政企单位已经部署了抗DDoS设备或采购了云清洗服务，但攻击发生时依然出现业务中断，原因往往集中在三个环节：流量牵引不完整、策略更新滞后、内部多系统联动缺失。要搭建一套真正可用的防护体系，需要从架构设计、策略配置、应急响应和常态化运营四个层面同时推进。

先明确防护对象与流量基线

搭建防护体系的第一步不是选产品，而是把需要保护的域名、IP段、业务端口和正常访问特征全部梳理清楚。政企网站通常包含门户首页、办事大厅、OA入口、邮件系统、招标采购平台等多个子业务，每个业务的协议类型和正常流量模型差异很大。例如门户首页以HTTP/HTTPS为主，正常时段并发连接可能只有几百，而办事大厅在特定日期会出现突发访问高峰。如果基线不准确，后续策略就容易误判，把正常高峰当成攻击，或者把低速攻击当成正常流量放行。

建议用至少两周时间采集NetFlow、sFlow或交换机镜像数据，统计每个业务IP的日均带宽、每秒新建连接数、并发连接数、请求速率和源IP分布。基线数据要按工作日、非工作日和特殊保障时段分别记录。只有拿到这些数据，后续的阈值设置和策略调优才有依据。

防护架构采用分层联动而非单点部署

政企网站DDoS防护不能只靠一台设备或一项云服务。有效的架构通常是“云清洗+本地清洗+业务层限速”三层联动。云清洗负责处理大流量攻击，尤其是超过本地带宽容量的流量型攻击；本地清洗设备负责处理中小流量攻击和应用层攻击，同时承担精细策略执行；业务层限速则是在Web服务器或反向代理上做最后一道兜底，防止慢速攻击和CC攻击穿透前两层。

关键点在于联动方式。很多单位买了云清洗服务，但流量牵引依赖DNS切换或BGP通告，攻击发生时切换时间可能超过十分钟，业务已经受到影响。更可靠的做法是使用BGP引流，通过预先建立的GRE隧道或专线把清洗后的流量回注到本地网络。如果本地带宽足够，也可以只保留本地清洗设备，但必须确保设备处理能力高于出口带宽的1.5倍以上。

策略配置要区分流量型攻击和应用层攻击

流量型攻击如SYN Flood、UDP Flood、ICMP Flood，主要靠带宽耗尽或连接表耗尽。针对这类攻击，本地清洗设备需要开启SYN Cookie、连接速率限制、源IP信誉库过滤和异常包丢弃。SYN Cookie要针对每个业务IP单独设置阈值，不能全局一刀切。例如门户首页的SYN速率阈值可以设为每秒5000个，而OA入口可能每秒500个就足够。

应用层攻击尤其是CC攻击，防护难度更高。攻击者往往使用真实浏览器或模拟正常请求，单纯靠IP限速容易误伤。建议在清洗设备或WAF上启用以下策略：一是基于URI的速率限制，对登录、搜索、查询等高风险接口设置每秒请求上限；二是启用JS挑战或验证码，对疑似攻击源进行人机识别；三是结合源IP信誉库和地理位置信息，对异常来源进行阻断或降级处理。对于政企网站，验证码策略要谨慎使用，避免影响正常办事群众，可以只对单IP请求速率明显异常的来源启用。

HTTPS业务需要单独处理证书和会话保持

政企网站大量业务已经启用HTTPS，DDoS防护设备在处理HTTPS流量时面临证书卸载和会话保持两个问题。如果清洗设备不做证书卸载，就无法检查加密流量中的攻击特征，CC攻击可能直接穿透到源站。建议在清洗设备或前置WAF上配置证书卸载，将解密后的流量进行检查后再回注。证书私钥要妥善管理，定期轮换。

会话保持方面，如果清洗设备采用集群部署，需要确保同一源IP的请求始终被同一台清洗节点处理，否则基于会话的登录状态可能丢失。可以通过源IP哈希或Cookie粘滞实现。对于需要保持长连接的WebSocket业务，清洗设备要支持协议识别和连接保持，不能简单按HTTP请求超时处理。

源站保护与回注链路设计

很多单位只关注清洗设备本身，却忽略了源站保护。攻击者如果直接攻击源站真实IP，清洗设备就形同虚设。必须确保源站IP不对外暴露，只允许清洗设备或指定代理IP访问。具体做法包括：源站防火墙只放行清洗设备回注IP段；源站服务器不配置公网IP或只绑定内网地址；DNS解析只指向清洗设备或CDN节点。

回注链路的设计同样重要。如果回注链路带宽不足，清洗后的正常流量无法顺利回到源站，业务依然会中断。回注链路带宽至少要为正常业务峰值的两倍，并且与清洗设备之间采用直连或专线，避免经过复杂的路由交换。回注流量要打上VLAN标签或使用策略路由，确保不会被再次牵引到清洗设备形成环路。

应急响应流程要具体到分钟级操作

攻击发生时，运维人员最需要的是清晰的判断标准和操作步骤，而不是泛泛的“立即启动应急预案”。建议制定一份DDoS应急响应手册，包含以下内容：攻击判定指标，例如出口带宽利用率超过80%持续5分钟、某业务IP连接数超过基线10倍、源站CPU持续高于90%等；分级响应措施，例如一级攻击由值班人员直接处理，二级攻击上报安全负责人，三级攻击启动多部门会商；每一步操作的具体命令和预期结果，例如在清洗设备上执行“show ddos attack”查看攻击类型，执行“enable mitigation policy”启用策略。

手册要定期演练，至少每季度一次。演练不能只做桌面推演，要在测试环境或低峰时段实际触发清洗策略，验证流量牵引、策略生效和回注链路是否正常。演练后记录发现的问题，更新手册和配置。

常态化运营比设备更重要

DDoS防护体系搭建完成后，最大的风险是“建完不管”。攻击手法不断变化，策略和阈值需要持续调整。建议每周分析一次清洗设备日志，统计攻击类型分布、误判率和漏判率。对于误判的源IP，加入白名单；对于漏判的攻击特征，更新规则库或调整阈值。每月进行一次全链路巡检，检查证书有效期、设备负载、链路带宽余量和策略一致性。

此外，政企单位往往有多个安全设备，如防火墙、WAF、IDS、清洗设备等，这些设备之间如果缺乏联动，防护效果会大打折扣。例如WAF检测到某个源IP在进行SQL注入，应该通知清洗设备对该IP进行限速或阻断；清洗设备发现某个IP段攻击流量激增，应该通知防火墙进行临时封禁。可以通过Syslog、API或安全编排平台实现联动，至少做到日志集中收集和告警统一推送。

常见误区与规避方法

第一个误区是只关注大流量攻击，忽视低速慢速攻击。很多政企网站被攻击时带宽并不高，但源站连接数被占满，导致正常用户无法访问。针对这类攻击，需要在清洗设备上启用连接数限制和请求速率限制，同时在源站Web服务器上配置连接超时和请求体大小限制。

第二个误区是过度依赖IP黑名单。攻击者使用僵尸网络时源IP变化很快，单纯封IP效果有限，而且可能误伤NAT出口用户。建议结合行为分析，例如同一源IP在短时间内请求大量不同URI、请求间隔异常规律、User-Agent异常等，综合判断后进行处置。

第三个误区是防护策略过于激进，影响正常业务。政企网站面向公众服务，不能因为怕攻击就把验证码、IP限速等策略设置得过于严格。所有策略上线前都要在测试环境验证，上线后观察一周，确认无误判后再固化。

最小化可行搭建路径

对于预算有限或技术力量薄弱的政企单位，可以按以下顺序逐步搭建：第一步，梳理业务和流量基线，确定保护对象；第二步，部署本地清洗设备或启用云清洗服务，完成基础流量牵引；第三步，配置SYN Cookie、连接限制和URI限速等核心策略；第四步，隐藏源站IP，收紧源站防火墙；第五步，建立应急响应手册和日志分析机制。每一步完成后都进行验证，确认有效后再进入下一步。不要试图一次性采购所有设备并全部上线，那样反而容易因为配置复杂而出错。

DDoS防护体系不是一次性项目，而是一个持续运营的过程。政企网站的特殊性在于既要保证安全，又要兼顾公众服务的可用性和易用性。只有把架构、策略、流程和人员都纳入体系化管理，才能在攻击发生时真正扛得住、恢复快、影响小。