大促前一晚，某中型电商的商品页突然打不开，客服后台的投诉一条接一条进来。运维查看流量曲线，入口带宽十分钟内涨了二十多倍，订单量却几乎没动。这基本可以判断是网络攻击。真正麻烦的是后面的问题：该防哪一层，用哪类产品，预算花在哪里。阿里云防攻击的分层思路，就是围绕这几个问题展开的。
先分清攻击从哪里来
网站受到的攻击大致有三类，手段不同，防法也不同。混在一起看，很容易买错产品。
- 流量型攻击（DDoS）：攻击者控制大量僵尸主机，向服务器发送海量数据包，目的是占满带宽，或者耗光网络设备的资源。
- 应用层攻击（CC）：请求量未必很大，但会集中访问登录、搜索、查询这类消耗数据库资源的接口。服务一步步变慢，最后停摆。
- Web漏洞攻击：利用SQL注入、跨站脚本、文件上传等漏洞窃取数据或植入后门。这类请求看起来和正常访问很接近，所以最难察觉。
分层部署，各管一段
单一产品很难兜住所有场景，实际做法通常是按层叠加。阿里云防攻击大致可以这样分：
- 网络层：用Anti-DDoS基础防护挡住常见的流量攻击。中小业务的基础保护，多从这里开始。
- 高防层：攻击规模大，或者业务对稳定可用要求很高时，把域名接入DDoS高防IP。攻击流量先在清洗中心处理，干净的请求再回源。
- 应用层：Web应用防火墙（WAF）负责识别恶意请求，拦截SQL注入、XSS等常见攻击，也可以按自己的业务配置访问控制规则。
- 监控与响应：安全中心集中展示告警、攻击事件和安全评分，运维能较早看到异常，不必等用户投诉才发现。
案例一：大促时的流量洪峰
回到开头那家电商。此前它只靠服务器自带的带宽，攻击流量直接打在源站上，正常用户进不来。调整时，团队把域名解析切到DDoS高防IP，源站只允许高防节点回源，同时隐藏真实公网IP。之后再遇到类似攻击，清洗中心自动过滤了异常流量，页面延迟回到正常范围，订单系统没有中断。
这个案例的关键在于隐藏源站。攻击者只要知道真实IP，前面即使套了高防，也可以绕过清洗直接打源站。
案例二：CC攻击拖垮登录接口
一家SaaS公司的用户反馈，登录失败率突然升高。日志显示，同一批IP在几分钟内向登录接口发出了数万次请求，大多是密码错误。数据库连接被占满，正常用户也登不上去。团队在WAF中配置了基于频率的访问控制：单个IP在指定时间窗口内的请求数超过阈值，直接拦截，同时给登录接口加上验证码校验。半小时内攻击停止。之后，这条阈值规则被纳入日常监控，定期检查有没有误伤。
案例三：扫描器盯上旧漏洞
某企业的内容管理系统有一个旧版本漏洞，还没来得及修复。攻击者用自动化工具扫描全网，请求里带着明显的SQL注入特征字符串。WAF规则库识别并拦下了这些请求，安全中心同步生成告警。运维据此定位漏洞位置，完成补丁更新。需要记住，WAF替代不了漏洞修复。它的作用是争取时间，让补丁在攻击者得手之前上线。
两个常见误区
第一个误区是觉得买了高防就万事大吉。高防解决的是流量问题。业务代码有漏洞，攻击者照样能从应用层进入系统。
第二个误区是规则设得太严。频率阈值定得过低，共用公司出口网络的大批员工或合作伙伴会被当成攻击者，正常业务跟着中断。规则上线前，先用观察模式运行一段时间，确认误拦率可以接受，再切换为拦截。
选型与配置的几条建议
- 先看日常流量和历史峰值，判断基础防护是否够用，还是需要上高防IP。
- 源站只对高防节点或WAF的回源地址开放，关闭对公网的直接访问。
- 登录、支付、短信等敏感接口，单独配置一套访问频率规则。
- 开启告警通知，定期做一次攻防演练，检查规则有没有误伤正常用户。
- 产品规格、防护峰值和计费方式都可能调整，具体以阿里云官网的当前说明为准。
