【天逸出品】【第圩九期】如何用WAF加持应用负载

每天学习一点点，每天进步一点点

多谢分享

每天学习一点点，每天进步一点点

楼主的文章图文并茂，清晰易懂，看完这波操作可以轻松上手了，如遇到问题再向楼主请教~

每日打卡学习，感谢分享，学习了！！！

每天学习一点新知识，谢谢分享

应用负载大家都不陌生，通过创建虚拟服务的形式，调动后端的节点池，实现应用的负载策略和业务可持续性访问。

如果要在保证业务高可用的同时，增加一些安全防护的话，就可以用咱们的waf产品

这篇帖子主要就是分析不同场景下，如何用waf去跟AD做配合，保障业务的同时，保障安全

场景一：

AD 旁路核心交换机，然后有标准的DMZ区域

拓扑如下：

这种防护方法 可以将WAF 直接串接在DMZ区域上联线路上【推荐配置】

防护注意事项：

这种部署模式是比较常规的，配置也比较简单

WAF可以针对AD访问服务器的流量做防护，如果AD启用了自动SNAT的场景下，一定要把联动封锁关掉

场景二：

客户的AD部署在DMZ区域的交换机上，跟服务器放在一起

拓扑如下：

这个时候如果想防护的全面一点，那就需要将WAF 串接在AD和交换机之间

防护注意事项：

这种部署模式，防护策略配置为   从AD侧到交换机侧的业务防护。针对数据去服务器的流量这*御一下，AD上如果做了SNAT，同样也不能开启联动封锁

如果AD没有配置SNAT的情况下，有这样一个场景，AD针对于某些业务有可能会开启三角传输，在这个场景下，WAF的数据包就会有二次穿越的问题

为了保障业务的可用，需要允许数据包多次穿越设备

场景三：

多层负载嵌套场景，至少有两层应用负载，由一层应用负载调度二层应用负载，再去调度节点池

如果客户的资金能力大，最好还是每个区域采购一台waf进行防护，如果没那么做预算的话买一台设备，对一层负载进行防护

防护注意事项：

防护方向还是从AD侧对核心侧的业务防护策略

如果WAF是硬件单品，或者用的AF是老架构产品（低于8.0.45），这里有一个风险点

如果某一个时间段，一层AD的流量特别的大，这样会出现一个现象  数据只要通过WAF，业务就会变得特别卡慢

就算WAF的性能和吞吐很大，而且CPU和内存的使用率界面上看着很低，但是只要是开启了业务防护，应用就会明显的卡慢

原因是这样，就算是WAF性能比较高，2C 12核心的CPU，但是老架构AF的内核，是通过计算源目IP 二元组的数值，来分配检测数据使用的哪个CPU核心（新架构是4元组）

我这边遇到一个案例，就是有一个业务的流量特别大，12核心有11个核心闲着，1个核心跑满了,如下图：

分析一下经过WAF的流量，防护的数据源目设备都是AD 源是一层AD，目的地址是二层AD，这种流量源目IP是比较固定的，这种情况下导致了业务无法继续使用

解决方法：

为了让WAF的cpu 能使用的均衡一点，这里需要将源目IP多样化，所以在一层负载的snat上，就不要所有的虚拟服务都用同一个地址。

在一层AD的物理接口上，新增多个IP，并且SNAT那里不同的虚拟服务，选择不用的源IP，让每个连接都进行计算，分配到不同的核心上进行检测

调整后CPU核心负载如下：

调整负载以后，WAF不仅能够更好的进行业务防护，也不会出现应用访问超时的情况