安全技术雁门关知多少
一、什么是雁门关
电商平台会遭受来自灰黑产、竞争对手的网络攻击,针对这些恶意攻击需要进行防护。
雁门关系统(Yanmen Meili-inc Secure Gateway,简称YMG)是集团安全网关,基于实时集群检测能力,结合旁路检测和大数据离线分析,防御常见Web应用攻击,并过滤恶意CC攻击1⃣️,避免资产信息泄露,保障安全和可用性。
** 注释1⃣️:恶意CC攻击防护,从业务角度可理解为防刷防爬*
理想模型中的雁门关系统:
-
覆盖集团全部流量
-
由安全团队进行漏洞研究,配置安全规则,提供防护能力
-
支持业务精准防护,快速过滤恶意流量
-
拥有大数据安全能力,通过分析丰富恶意样本库、动态构建特征、建立可信流量模型、持续优化规则
-
秒级生效,提供高可靠、高可用的服务
二、为什么做
网络攻击包含多种不同攻击类型。
其中,流量型DDoS攻击,由于出口带宽限制以及攻防成本不对等,只能通过电信云堤或公有云高防解决。我们也采用了此方案。
除流量型DDoS外,如Web应用攻击、恶意CC攻击,一般通过Web应用防火墙(Web Application Firewall,简称WAF)解决。而商业WAF针对HTTP/HTTPS请求,由于集团研发团队走在技术前沿,MWP、IM等自定义协议的出现,使得商业WAF不能满足我们的需求。
1. 硬件设备
调研测试国内几家厂商的硬件WAF,标明吞吐量2Gbps,在HTTPS请求下只能到小几百Mbps。为保护通信安全,全站HTTPS是必然趋势2⃣️,集团已经在改造进行中,若采用,需要堆叠大量设备。放弃。
** 注释2⃣️:如,防止用户访问蘑菇街时页面弹澳门在线赌场的小广告*
调研测试Imperva(全球Top硬件WAF),在HTTPS请求下吞吐量只下降30%,提供强大的Web防护能力,可动态构建特征、威胁情报联动,支持多种部署方式,非常强大。不过作为硬件WAF,Imperva的扩容需要增加设备并修改部署,而电商大促流量峰值为日常流量的好几倍,需要以大促峰值再加一定冗余来评估。Imperva有一特点就是贵,以大 促流量计算,再加上主备,成本浪费比较大。
再考虑迁移黑石机房,虽然与黑石沟通可带硬件设备进机房,但后续的设备维护以及可能的扩容都存在风险。同时,Imperva无法识别MWP、IM的自定义协议,不能提供防护3⃣️。放弃。
** 注释3⃣️:即,MWP接口被恶意刷,只能扩容或限流*
2. 云服务
不谈各家云厂商的安全防护能力,先说共同存在的问题。
-
能轻易被绕过:云安全服务主要通过将用户的DNS解析到云节点实现防护,如果攻击方获取了服务器真实IP地址,可以轻松绕过
-
有数据安全风险:使用云安全服务,所有访问数据需要先到云端再到用户服务器,而根据已了解的信息,公有云都有流量转发口子,存在数据泄露风险
考虑上述两点,似乎腾讯云网站管家(腾讯云WAF)能满足需求。
-
网站管家属于腾讯云安全方案,迁移黑石机房后可直接防护,不用DNS解析
-
毕竟是腾讯爸爸,有商务合作和信任
调研腾讯云安全管家,以腾讯业务为主,极少量外部客户,单客户流量峰值200+QPS,能否为集团提供Web防护能力待验证测试。不过作为通用WAF方案,腾讯云安全管家也是针对HTTP/HTTPS请求,无法对MWP、IM请求进行识别和防护。放弃。
3. 软件应用
相继放弃硬件设备和云服务后,调研软件方案。市面上 有多种实现,如基于主机Agent的安全狗、基于Nginx的ModSecurity等。
起初,一群小伙伴4⃣️借鉴ModSecurity开发了基于Nginx扩展的WAF,即WAF1.0。WAF1.0在Nginx Server中hook住请求,基于规则进行检测和拦截。
** 注释4⃣️:感谢原业务安全团队@梵天@云竹@幽鬼@婉明 以及网络安全团队@林泉 对WAF1.0的贡献,架构图来自@梵天 的系统介绍文档*
WAF1.0上线后,覆盖17个应用、268台服务器,拦截恶意攻击请求400+万次/周,对线上业务起到了一定防护作用。
但WAF1.0存在其固有缺陷:
-
单机模式:对于服务器多的应用,单机规则阈值只能设置很高,否则容易误杀正常请求,因此当遭受恶意CC攻击时,需要较长的检测时间,而在这间隔期间会引起限流、用户访问失败等问题
-
基于Nginx:随着研发团队技术变革,App请求(走MWP长短连)的业务Server没有了Nginx,WAF1.0无法覆盖这部分流量
故放弃WAF1.0方案5⃣️。
** 注释5⃣️:WAF1.0已不再维护,只作为雁门关的降级方案保留*
经历以上种种后,最终决定开发雁门关系统,为集团提供安全防护能力。
三、架构如何
先看集团机房流量简略图:
可以看到接入层主要分为:
- PC/H5/log6⃣️请求,走LVS => YMG Proxy7⃣️ => Nginx Proxy => Server
- App长连接请求,走LVS => MWCS => MWP Router => Server
- App短连接/容器内H5/小程序请求,走LVS => MWP Router => Server
- IM长连接,LVS => IM Gateway => Server
** 注释6⃣️:PC、App、小程序的打点日志,都走log系统,请求量非常大,日常QPS约等于PC、App、小程序QPS总和,故单独标注*
** 注释7⃣️:原LVS => Nginx Proxy => Server链路中,增加YMG Proxy,负责转发流量至检测集群,接收检测结果:若通过则转发至Nginx Proxy,若拦截则直接返回*
再看雁门关系统架构图:
- 接入模块:结合集团机房流量简略图,由YMG Proxy、MWCS的plugin、IM Gateway的plugin组成,负责将集团全部流量转发至检测集群
- 实时检测模块:YMG Server集群,负责对流量进行检测,检测结果返回接入模块进行防护
- 离线检测模块:通过Storm进行近实时离线检测,补充检测能力,记录流量数据
- 离线分析模块:流量数据接入大数据平台,进行离线分析,确认准确率、召回率,并提炼规则模型
- 管理模块:管理系统规则、配置、监控告警,展示数据视图
梳理雁门关上下游:
- LVS:配置权重,将PC/H5/log请求转到YMG Proxy
- MWCS:请求进行解析后,将流量数据发到YMG plugin,由plugin转发到YMG Server;plugin接收检测结果,返回给MWCS,MWCS转发至MWP Router或直接返回
- IM Gateway:请求进行解析后,将流量数据发到YMG plugin,由plugin转发到YMG Server;plugin接收检测结果,返回给IM Gateway,IM Gateway转发至Server或直接返回
- Nginx Proxy:PC/H5/log请求通过YMG Proxy后,转到Nginx Proxy
- TGW:黑石机房4层LB,迁移黑石后将替代LVS