#原创分享#记AF一次“误封”事件

      事件起因：近期准备上线一个业务，上周分配了一个测试公网ip用于新业务测试。上午的时候，看到SIT测试的同事在群里说系统遇到问题了。当TPS到6000/S交易就卡主了，然后过几分钟又好了，当时没有在意。然后过几分钟又恢复，负责SIT测试的同事猜测可能是数据库压力有问题。

      一听是数据库的问题，我刚开始并没有在意。虽然我印象中，之前数据库压测过，TPS到10W/S都没有问题的，但是反正不是我的问题也就没多问了。

       数据库的同事查看之后果然发现没有问题，当测试交易卡主的时候，数据库根本没有执行任何语句。

      看了下他们的描述，应该在卡主的时候数据库没有收到任何流量。这时候我让测试直接通过内网进行压测，5W/S的TPS一直保持了十分钟没有问题。这时候初步分析应该就是通过公网估计有问题。

      问了下测试是如何进行压测的，大概梳理总结如下：三台虚拟机，每台1.5W/TPS同时压测，最后公网从一个源地址出去。也就是说，那个源地址每秒会发很多个数据包，聪明的社区小伙伴应该能猜到是什么情况导致问题发生。

      首先我们来回忆一下AF上如何防御DDOS，设置路径为策略-安全策略-DOS防护

设置扫描和攻击防护，添加保护对象。

DDOS攻击类型里面定义DDOS阈值（按需配置）

以上就是AF的DDOS防御策略设置。

      正是这个配置，导致了测试过程的异常。在进行压测的时候，会大量新建连接，syn的连接数激活了设置的5000阈值，触发DDOS模块，临时封锁300秒。

       在运行状态-攻击中IP这里，能够看到触发的源IP。

      那个源IP，正是来自测试那边的出口IP，原来是压测的时候，触发了DDOS模块，达到了非正常阈值，被AF认为是受到攻击，产生了“误封”，临时封禁了300秒，符合最开始测试说的过一会儿就好的情况。

     最后暂时关闭了DDOS防护，待测试顺利完成后再开启。

其实AF的DDOS这块功能个人觉得一直以来蛮鸡肋的，对于内到外的来说，阈值这一块确实不好调，调太低天天误报，太高又没什么效果。外到内来说，真正碰到DDOS单靠一台AF流量根本清洗不过来的（17年就碰到过AF被打瘫了）。所以这一块功能个人一直觉得很鸡肋，食之无味弃之可惜。

看完这个帖子，再一次感受到，解决问题一定要从业务的角度去查，只有懂得业务系统的前提下，才可以快速的定位问题
技术部分写的也很好，思路很清晰
感谢楼主，期待您更多的分享

感谢分享，在AF中，有几个功能都会自动触发联动封锁。所以在一些有SNAT或者CDN的场景，都需要谨慎开启，除了楼主说的DOS攻击外，还有IPS的暴力破解，WAF的漏洞防扫描，WAF的CC攻击防护，邮件的撞库功能。

感谢分享

您好，感谢您参与社区原创分享计划4，您的文章已被收录到计划中，交由专家评审小组评审，分享奖励将在活动结束后统一安排发放！分享越多，奖励越多，期待您更多的精彩分享哦！:感恩:

我感觉很多企业都关闭了DDOS

回帖是美德

打卡学习

感谢分享

感谢分享

来看看，学习下

了解了，触发了DDOS模块。感谢分享。其实也可以调整一下防护阀值。