应用负载大家都不陌生,通过创建虚拟服务的形式,调动后端的节点池,实现应用的负载策略和业务可持续性访问。
如果要在保证业务高可用的同时,增加一些安全防护的话,就可以用咱们的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不仅能够更好的进行业务防护,也不会出现应用访问超时的情况
|