跨境业务网站DDoS防护适配方案

做跨境业务的技术团队都会面临一个很现实的问题：网站或应用部署在海外机房，面对的却是来自全球的访问流量，其中夹杂着大量恶意请求。DDoS攻击不是会不会来的问题，而是什么时候来、以什么形式来的问题。游戏、金融、独立站、SaaS服务，只要业务在线，攻击者就有动机。更麻烦的是，跨境业务的网络架构天然就比纯国内业务复杂，源站可能在AWS美东、阿里云新加坡，用户却分布在欧洲、东南亚、北美，中间隔着多条海底光缆和不同的运营商路由策略。这种多节点、多链路的特性，让防护方案不能简单套用某一家云厂商的默认高防IP，需要根据业务形态做适配。

跨境业务最常见的架构是前端用CDN做加速和HTTPS卸载，回源到一组负载均衡后的应用服务器，数据库和缓存走内网。这个链条上每一层都可能成为攻击目标。DNS解析层可以被DNS Query Flood打瘫，CDN边缘节点可以被HTTP Flood耗尽并发连接，源站IP一旦暴露，攻击者可以直接绕过CDN对源站发起SYN Flood或UDP反射放大攻击。很多团队只给域名接了CDN，却忽略了源站IP是否真的隐藏干净了。检查的方法很简单：用全球多节点Ping工具或DNS历史记录查询服务，看历史解析记录里有没有直接指向源站IP的A记录。如果源站曾经裸奔过，攻击者手里早就有这份记录，加CDN只是掩耳盗铃。

CDN是跨境业务DDoS防护的第一关，选型直接决定防护效果。不是所有CDN都自带强大的DDoS缓解能力。像Cloudflare、Akamai、AWS CloudFront这类全球性CDN，在边缘节点本身就具备Tbps级别的清洗能力，能把HTTP/HTTPS Flood、Slowloris慢速攻击、大流量SYN Flood挡在离用户最近的地方。但要注意，CDN的防护策略需要根据业务定制。默认规则往往过于宽松，比如对某个路径的POST请求频率限制不够，攻击者用几千个肉鸡慢慢发登录请求，单个IP频率不高，整体却能压垮认证服务。需要针对关键接口设置路径级别的速率限制，比如登录接口/api/login每秒每个IP不超过3次，搜索接口/api/search不超过10次。同时开启JS Challenge或CAPTCHA挑战，对可疑流量进行人机验证。对于API业务为主的跨境SaaS，建议在CDN层就启用WAF规则，过滤SQL注入、XSS等应用层攻击，因为这些攻击经常和DDoS混合使用，一边打流量一边找漏洞。

源站IP泄露是跨境业务最致命的破绽。攻击者只要拿到真实源站IP，CDN的防护就形同虚设。收敛入口有几个硬手段。第一，源站只允许CDN的回源IP白名单访问，在安全组或防火墙层面拒绝所有其他入站流量。每个CDN厂商都会公布自己的回源IP段，定期同步更新到防火墙规则里。第二，关闭源站所有非必要端口的公网访问，22端口SSH用跳板机或堡垒机管理，数据库端口3306、6379绝不对外开放。第三，邮件服务、FTP服务等容易泄露源站IP的组件，全部走独立的出口IP，不要和网站源站共用同一个IP地址。第四，SSL证书不要直接部署在源站，否则通过Shodan、Censys这类搜索引擎可以轻松根据证书指纹反查到源站IP。CDN边缘节点做SSL卸载，回源走HTTP或者自签证书加密，源站只信任CDN的回源证书。

对于非HTTP业务，比如游戏UDP通信、自定义TCP协议、IoT设备的MQTT连接，CDN的七层防护就无能为力了。这类业务需要四层清洗能力。跨境场景下，比较务实的做法是在业务覆盖的主要区域各部署一组清洗节点，通过Anycast或DNS调度把流量引到最近的清洗中心。清洗节点检测到攻击流量后，用DPDK、XDP等内核旁路技术做包过滤和速率限制，正常流量通过GRE隧道或专线回注到源站。这个架构成本较高，一般只有对延迟敏感的游戏或金融交易业务才会自建。大多数跨境业务可以选择云厂商的高防IP服务，把业务IP替换成高防IP，流量先经过高防机房清洗再转发到源站。选高防IP时要注意两个指标：一是防护带宽，二是海外节点的覆盖范围。很多国内云厂商的高防服务海外节点有限，对东南亚、中东、南美用户的延迟会明显增加。这时候可以考虑AWS Shield Advanced、Radware、Imperva这类全球部署的清洗服务，或者用Cloudflare Spectrum做四层代理防护。

DNS是跨境业务最脆弱的一环。攻击者发起DNS Query Flood，向递归DNS服务器发送大量随机子域名查询请求，导致权威DNS服务器过载，正常用户解析超时，业务就等于断网了。防护DNS DDoS需要从几个方面入手。使用高可用的DNS托管服务，比如Cloudflare DNS、AWS Route 53、NS1，这些服务本身就具备抗DNS Flood的能力，在全球有大量解析节点。启用DNSSEC防止DNS缓存投毒和劫持，虽然DNSSEC不直接防DDoS，但能避免攻击者结合劫持手段放大攻击效果。设置合理的TTL值，对于A记录和CNAME记录，TTL可以设到300秒甚至更低，这样在切换解析时生效更快，但平时会增加解析请求量，需要在DNS服务商那里确认能承受。最关键的是，不要把域名的权威DNS服务器和业务服务器放在同一个网段或同一个服务商，否则一次大流量攻击可能同时打瘫DNS和业务。

防护方案再完善，也做不到100%防住所有攻击。跨境业务必须做好弹性降级预案。应用层做到无状态设计，Session数据放到Redis或数据库中，这样应用服务器可以随时水平扩容，不依赖单台机器的本地状态。数据库层做好读写分离和主从切换，RDS类的托管数据库服务通常自带高可用，但要测试故障切换的实际耗时。静态资源全部上CDN或对象存储，源站只处理动态请求，减少回源带宽压力。对于突发的大流量攻击，最有效的应对手段是快速扩容和流量调度。提前准备好备用IP段和备用域名，当主入口被打满时，通过DNS切换或BGP宣告把流量引到备用入口。这个切换过程要反复演练，形成SOP文档，确保值班工程师在凌晨三点被叫醒时也能按步骤操作，而不是手忙脚乱地翻聊天记录。

没有监控就没有防护。跨境业务的监控需要覆盖全球多个区域，因为攻击可能只针对某个地区的用户。用Pingdom、Catchpoint、ThousandEyes这类全球探测工具，从不同大洲的探测点持续监控业务可用性和响应时间。当某个区域的探测点同时报告不可达或延迟飙升，而其他区域正常，很可能是区域性DDoS攻击或骨干网拥塞。流量层面的监控要看带宽使用率、PPS、新建连接数、并发连接数这几个核心指标。设置基线，当指标偏离基线两倍以上时触发告警。告警通道不能只依赖邮件，要接入即时通讯工具和电话告警。应急响应流程里要明确谁负责判断攻击类型、谁负责切换高防、谁负责和CDN厂商沟通、谁负责通知客户。每次攻击事件后做复盘，把攻击特征更新到防护规则里，形成正向循环。

跨境业务的特殊性在于数据要在不同国家和地区之间流动。GDPR、CCPA以及东南亚各国陆续出台的数据保护法规，对流量清洗和数据传输提出了要求。选择DDoS防护服务商时，要确认其清洗节点分布是否符合数据驻留要求。比如欧洲用户的流量是否只在欧盟境内的节点清洗，不回传到美国或其他地区。有些CDN厂商提供区域性清洗策略配置，可以把特定区域的流量锁定在指定地理范围内的节点处理。另外，WAF规则里如果涉及请求体检查，可能会接触到用户提交的个人数据，需要评估是否构成数据处理行为，是否需要在DPA中明确约定。这些问题技术团队容易忽略，但法务和合规部门会很关注，提前沟通清楚能避免后续麻烦。

DDoS防护是一项纯成本支出，不产生直接收入，所以预算总是有限的。跨境业务在防护成本上要有取舍。把防护资源集中在最核心的域名和IP上，边缘业务、测试环境、内部管理后台可以用独立的次级域名和IP段，即使被打掉也不影响主营业务。CDN和高防服务按需购买，平时用基础套餐，攻击发生时临时升级到高级防护。很多云厂商的高防服务支持按天购买弹性防护带宽，比长期包月划算得多。自建清洗集群对绝大多数团队来说不划算，硬件成本、带宽成本、运维人力加起来远超购买商业服务。把钱花在刀刃上，就是把有限的预算投入到最可能被攻击的入口，而不是试图把所有资产都保护到同一水平。

防护做得再好，也只是被动挨打。跨境业务可以主动做一些攻击溯源工作，把攻击特征、源IP、攻击手法记录下来，形成内部威胁情报库。如果行业内有可信的情报共享机制，可以参与进去，了解同行业近期遭受的攻击类型和IOC指标，提前在自己的防护系统里做预置规则。不过要注意，攻击溯源涉及法律边界问题，跨境追踪源IP可能跨越多个司法管辖区，私自做反制措施可能触犯当地法律。稳妥的做法是把攻击证据提交给服务商的安全团队和执法机构，由他们按正规流程处理。

跨境业务DDoS防护没有一劳永逸的方案，攻击手法在进化，防护策略就要跟着迭代。核心思路是分层防护、收敛入口、弹性降级、持续监控。把CDN、高防IP、WAF、DNS防护组合成一套适配自身业务形态的体系，定期做红蓝对抗和压力测试，验证防护效果。当攻击真的来临时，团队能按照预案从容应对，业务在攻击期间保持基本可用，这就是防护方案成功的标志。