一次CC攻击防护经历

合作多年的跨境独立站，做东欧市场的，最近经历几年来最出乎意料也最恶心的CC攻击，48小时内2次攻击，总共持续时长约6个小时，网站总共购物车停止服务约1小时20分钟，第一波防护处理后，攻击者不死心，强化了BOT的破防能力，但在CDN分流、CDN WAF，站内WAF、Web服务器层以及自定过滤代码等共同保护下，无法再持续影响网站功能，几小时后攻击者放弃。

这个网站多年来一直在CF Pro的保护之下，攻击者既然能成功突破我们打开的所有PHP/WP WAF规则，能精准地组织起不被拦截的CC请求，能精准地控制好请求的时序分布于发送频率，应该是有备而来，应该是技术老辣经验丰富的人，也有可能是花钱够得很强的黑客服务。CF不是完美的，至少20刀每月的这款远远不是。

升服

毫无技术含量的防护法，但有效，为服务器加了100%冗余（相对正常流量，日常跑满60%），即使攻击请求仍旧活跃，前台用户至少能打开结算页面下单了。Access Log显示攻击IP是CF IP，就是说攻击者并未绕过CF，而在CF之后的站点即使受此类攻击，至少CC请求分布与频率仍受CF约束，一旦越过红线就不灵了，也就是说攻击者的破坏力是有天花板的，它做不到赶尽杀绝。实际上即使没有CF，一般机房的网关层也会部署一定的防护能力，没有拿着暴力攻击是真可以肆意妄为的，另外一个约束是攻击者自己的时间成本和钱包，很多时候其实是更强的约束：）碰到这种攻击不是网站末日。

屏蔽到wp-content|wp-includes的非正常请求

到这两个目录的正常WP请求应该都是静态请求（JS|CSS|IMAGE|FONT），如果请求看起来像这样：/wp-content/whatever 或者 /wp-content/whatever.php 只需让Web服务器检查一次文件是否存在，不存在就立刻404，而不是走WP的默认URl重写路径，若文件不存在则委托给index.php继续处理，变成一个动态请求最终还是404但昂贵几百倍。Nginx和Apache都很容易截获这类请求并迅速以高效的404结束之。

屏蔽到wp-admin的攻击请求

到这个目录的正常请求都会是/wp-admin/*.php（index.php常省略），可以同上面wp-content|wp-includes处理，但有更好的办法，就是在CF创建应用了“Security：I’m Under Attack”的Page Rule，即可对所有/wp-admin访问开启recaptch验证，从而挡住任何自动攻击。

应用更省资源的动态页404

对于无法在Web服务器或者CDN WAF快速屏蔽的垃圾动态请求（通常是CC攻击的大部分），比如/duwxxkg–edx，/product/，要让WP尽可能快地404，一般主题的默认的WP404页（像这样）会显示header/footer，可能带来额外数据库操作，是攻击者最喜欢也最容易大量自动化的的一类错误页。好在处理起来不难，用钩子截获返回404并die()即可。

优化缓存

攻击者也会自动化大量到正常存在页面的攻击请求，常见的一类是针对缓存配置漏洞的（可能最大的缓存漏洞是很多WP站点根本连缓存都懒得开），比如/valid-post-name是零SQL的可缓存页，但/valid-post-name?foo=duwk732却是未缓存页，那么大量这类随机变化query string的请求就能消耗大量服务器资源用于数据库查询，你要做的是检查一下你的缓存设置，尽可能多地忽略query param。

另一类是针对正常页面的POST/PUT请求（comment.php也是常见目标），WAF对这类攻击很敏感，绝大多数都较难得逞，如果有漏网之鱼，可以加自定WAF规则，漏进来得如果很多，也可以借助HOOK用代码动态检测快速500。

REST API 限流

REST API（/wp-json）默认是打开的，因为要处理的请求类型更宽泛，一般WP防火墙规则限制也会宽松，遇到攻击时隔离恶意请求难度大，所以防护开销也大，但绝大多数WP站点都可以用插件彻底屏蔽或者有选择地屏蔽端点，或者对匿名访问完全限流，即可拦住自动攻击者的绝大部分企图。

经验教训

• 尽早集成CDN WAF（付费的，别省这个钱），如果这次没有这一层站外WAF，单凭服务器自身，防护成本可能是几十倍或更多（时间与金钱）
• 永远为服务器留出足够冗余，这一点也不浪费，服务器成本也绝不可能是你的主要成本，网站不止要应付下单客户，还要应付不下单客户、善意蜘蛛、恶意蜘蛛、玩票蜘蛛，以及像这种有备而来的敌意流量
• 仔细配置你的缓存插件，把受攻击状态考虑在内
• 提早充分熟悉WAF工具，碰到突发时再去Google可能太慢了，这些工具其实很简单，核心基于WEB界面的过滤器规则设置大概只需要你半小时时间
• 早一点使用网站下线监控报警工具，这次是客户的一个周末加班员工报的错，响应基本没有耽误，并不是每次都能这么好运气，自动化的pingdom或阿里云监控长期才可靠