网站上线后，每天都会收到各种访问请求。大部分来自正常用户，但也夹杂着恶意爬虫、撞库脚本和漏洞扫描器。阿里云的拦截能力就是把后一类流量挡在服务器之前。常用的产品有三个：安全组、云防火墙和Web应用防火墙（WAF）。它们工作的层次不同，配置时要按一定顺序来。
三层分别拦什么
安全组是最外层的网络访问控制，只允许指定IP段访问指定端口。它不看请求内容，规则简单，适合先把不需要对外的端口关掉。数据库端口和后台管理端口通常不应该对全网开放。
云防火墙处理云上资产的整体出入站流量。服务器较多时，它可以统一管理，阻断已知恶意IP，或限制某些端口的对外访问。它关注的是地址和端口，不解析网页内容。
WAF工作在应用层，检查HTTP和HTTPS请求的内容。它能识别SQL注入、跨站脚本等常见攻击，也能按请求频率、来源地区或User-Agent过滤流量。针对网页业务的攻击，主要在这一层处理。
三个常见场景
商品页被爬价。商品页的访问量在凌晨突然翻倍，订单却没有变化。日志里，同一批IP每秒请求几十次，User-Agent为空。这时可以在WAF里设置基于频率的限流规则，对超过阈值的IP返回验证码。设阈值前，先看一段时间的正常访问峰值。阈值定得太低，真实用户也会被挡住。
官网出现注入尝试。日志里有大量包含“union select”的请求。开启WAF的SQL注入防护规则，先用观察模式跑一段时间，确认无误后再切换为拦截。这样既能看清攻击的规模，也不会在没有验证的情况下误拦正常请求。
后台被境外IP扫描。管理后台只给国内员工使用，却频繁收到境外登录请求。把后台端口的来源限制为公司出口IP，安全组就能直接解决，比在应用层写规则省事。WAF可以再对登录接口加地区限制，作为第二道保险。
配置顺序怎么排
顺序可以按从外到内来理解：先安全组，再云防火墙，最后WAF。外层先挡掉明显不需要的流量，内层再处理复杂的请求内容。每层的规则会更少，也更容易排查。
- 梳理资产。列出需要对外开放的域名、端口和服务，标出哪些只允许内网或固定IP访问。这张表是后面所有规则的依据。没有它，规则很容易互相矛盾。
- 用安全组划定边界。关闭不用的端口，管理类端口只对固定IP开放。改动前先确认自己的出口IP没有变化，否则可能把自己锁在外面。
- 用云防火墙处理整体封堵。对已知恶意IP段和不需要对外的端口做统一管理。服务器数量多时，这一步的收益最明显。
- 接入WAF，先观察。新规则设为观察模式，至少跑满一个完整的业务周期，比如包含一个周末或一次促销。只看一两天的数据，容易漏掉周期性出现的正常请求。
- 确认后切换为拦截。查看观察期的拦截记录，确认下单、登录、支付回调等核心请求没有被误伤，再对攻击类规则启用拦截。
- 定期复盘。每隔一段时间看一次拦截日志。拦截量突然变化时，先判断是攻击增多还是规则误伤，再决定调整阈值还是补充白名单。
误拦截怎么处理
规则越严格，误伤正常用户的概率越高。常见情况有三类：搜索引擎爬虫被当作恶意爬虫，接口请求的参数恰好命中某条规则，移动端用户的IP频繁变动。
遇到误拦截，先在拦截日志里找到对应的规则编号，确认命中的是哪条规则、匹配了什么内容。如果只是个别请求，把它加入白名单即可。如果某类请求反复被拦，就放宽该规则的匹配条件。不要直接关掉整个防护模块，否则真实攻击也会一起放行。
需要留意的几点
拦截能力不能替代代码层面的安全。参数校验、权限判断和密码加密仍然要由开发团队负责。防火墙规则配错同样会造成事故，因此每组规则都应有明确的负责人。
防火墙规则也应纳入变更管理。每次修改都记录原因、时间和修改人，出现问题时才能快速回滚。团队人少的时候，一份简单的修改表格就够用。
