En

流量分析在安全攻防上的探索实践

作者:腾讯安全平台部 球头人牛长公布时间:2020-04-26阅读次数:3405评论:0

分享

【导语】

前段时间,lake2与大家分享了从网络流量层针对IDS/IPS进行绕过的一些尝试研究,其中埋了个坑“感谢宙斯盾的球头人牛长一起测试这个代号007的项目,后面的流量分析就交给他来跟进”,让我压力山大。从毕业进部门,一直从事DDoS网络攻防对抗工作,先后负责安全系统的后台开发和策略运营,近段时间也在基于流量层面对传统安全能力增强进行尝试。趁着某天下午一杯星巴克的劲,苦苦思索(其实是失眠)到凌晨三点,理出一些头绪,也算做下阶段性总结,暂时填上这个坑,更以期与业界同行交流学习。 


传统基础安全领域,在通用产品能力上,一般分为三大件:网络层的防DDoS、主机层的防入侵和应用层的防漏洞。除了防DDoS之外,其他两个领域也给流量分析应用留下足够的想象空间。
网络流量分析既指特定用途的硬件设备(如绿盟的NTA),也指基于网络层的安全分析技术,在FW\IDS\IPS中很常见。相比于主机层、应用层是以日志、请求等为分析对象,流量分析面对的是更底层的网络数据包,所包含的信息元素更多,但是分析起来也更加生涩。流量分析已被应用于多个领域,如带宽资源的合理性管控、网络链路排障以及本文所要探索的安全攻防领域。 


【工具】


网络流量一般都是传输的海量数据,可以旁路部署(如端口镜像、链路分光),也可以串行接入(如物理链路串联、BGP按需导流),无论是哪种模式都需要一个强大的计算后台来支撑,同时策略上结合实时+离线,达到对分析性能和覆盖功能的平衡。其中有几个关键组件: 


[1、 高性能的网络IO ]


无论是在业务服务器层还是机房出口层进行分析,都需要解决从网卡进行高速收包的问题。中断收包肯定是不能用的、协议栈肯定也是不能过的。常见的机制有Pcap(如网工必备应用tcpdump,但用作高性能收包现在已较少了)、Pfring(印象中是最早提出并实践了零拷贝Zero-Copy理念)、DPDK(Intel的解决方案,这几年使用非常流行),这些机制要么是基于linux内核的cBPF进行hook、要么是直接消除协议栈。而从3.17版本开始,内核引入了全新的eBPF(与老的cBPF相比,简直是鸟枪换炮,功能厉害得不行),由此诞生出了一个新的网络处理引擎XDP,近两年被业界颇为称道。与DPDK不同,XDP并不消除协议栈,而是工作在网卡收包与协议栈之间,甚至于是在内核分配skb之前。也就是经过XDP分析处理之后,数据包可以直接丢弃、直接发送,或者是继续送到协议栈处理。这对基于业务服务器层的卸载加速、流量管控、安全过滤有了更好的选择,目前国外大厂用的还比较多。


[2、 特征匹配引擎 ]


流量分析可以分为两种类型,一种是DFI(深度流检测)、一种是DPI(深度包检测),前者注重量的统计、后者注重内容的分析。而特征匹配是内容分析很重要的组成部分,虽然业界常说当前的攻防对抗已升级、传统基于黑特征的检测防御会悉数失效,但从实际现网来看,通过黑特征还是能解决很大一部分的通用性攻击威胁。传统的字符串匹配如KMP、Sunday和AC多模,正则匹配如Pcre、Re2和随DPDK广泛使用的Hyperscan。纯软件的方案毕竟会共消耗和共用机器CPU,因此也有基于硬件加速的方案,比如多插一张FPGA卡,用来专门做匹配查找计算;另外还有Mellonax BlueField直接在网卡上加一个处理芯片(智能网卡),做协议卸载和匹配加速。 



[3、 流重组 ]


很多安全威胁都发生在TCP类的业务协议上(如Web漏洞、高危端口),黑客除了在业务处理逻辑层面对安全防护措施进行绕过,也会在更底层的网络传输进行尝试,比如lake2文章里所提到的一些思路。因此对于TCP的分段传输特性,流重组对提升安全对抗的检测覆盖能力起到重要作用。实际落地上,业界少有现成的开源方案,自研实现上需考虑对内存的合理高效使用、对算法的精心调优,而现网使用中,则需要平衡性能和功能,太考虑性能则某些场景覆盖不了、太考虑功能则会导致处理性能下降,需要根据具体业务场景来定。

【场景】


将流量分析应用于安全攻防领域,除了在网络层异常检测和拦截上的天然契合,对于主机安全、应用安全都能起到不错的能力补充增强。 


[1、 网络层 ]
a) DDoS检测防护:目前应用最为成熟的领域,我们也自研了宙斯盾DDoS防护系统,有兴趣使用英雄联盟、王者荣耀同款防护软件的同学可以去腾讯云T-SEC DDoS防护产品体验,这里就不再赘述。
b) Web漏洞防护:基于机房出口的流量牵引,对业务接入成本最低,因为并不需要业务更改域名指向或者安装Agent插件。因此,在几年前,面对公有云业务的需求和场景,我们曾基于DDoS流量牵引回注整套体系实现了一套网络层WAF(具备流重组功能),提供给第三方客户使用。但后面随着使用场景的增多,这套方案的弊端也凸显,这个问题后面再说。



c) 基于网络层的阻断:理论上,所有基于IP的流量管控拦截都可以通过这套体系实现。比如针对特定端口请求的常态拦截,防止运维同学手抖操作开放了高危端口;针对0day漏洞的虚拟补丁机制,为下游业务升级版本赢得时间窗;甚至将能力开放给到业务自助操作,从机房入口层级屏蔽业务上来自某些恶意源的异常访问、请求限速等(图示为宙斯盾的网络流量阻断配置)。


[2、 主机层 ]
a) 入侵回溯:传统的主机安全检测响应EDR系统,通过Agent方式采集主机日志、命令操作等信息,然后上报到控制中心进行策略建模,从而发现主机入侵威胁。比如高风险命令注入执行,单纯基于主机端数据仅能知道发生了什么,若同时能在流量层面针对这些强特征命令字进行检测,进一步关联,就能溯源到攻击者是如何利用的。此外,流量层的检测能力,也能与主机层发现互补,形成多个铃铛的告警能力。

(主机端发现命令执行并告警)

(流量层抓取到网络请求和路径,形成关联)
b) 木马通信:比如ICMP木马,进程也不会监听端口,对主机层检测能力提出更大挑战,甚至如上面提过的XDP,在协议栈之前对流量进行劫持处理,主机端tcpdump也无法抓取。而作为中间管道,在流量层进行检测分析,会是更好的补充手段。

(从源主机向目标主机129.226.x.x进行ping操作,可以正常ping通)

(在目标主机上使用tcpdump抓取源主机115.159.x.x的包,无法抓获)

[3、 应用层 ]
a) 网络资产搜集:安全工作的前置步骤是对资产大盘的全面搜集和掌控。以漏洞扫描为例,传统方法是依靠流程和系统,让业务侧主动登记上报,再配以爬虫,但会存在漏的问题,影响覆盖率。而基于流量的访问采集可以确保只要CGI出现网络访问就可被记录,且对业务侧无感。这种方式部门的洞犀兄弟团队已运营多年,负责人马老在他之后的DevSecOps文章中会有详细分享(我也来挖坑)。
b) 高危资产主动发现:高危端口、高危组件和高危服务的对外开放占据了漏洞攻击的很大一部分口子,传统方法是靠主动扫描来感知,存在扫描周期和扫描被屏蔽的问题。而通过流量则可以较好的解决上述问题,内部团队曾经复盘一起安全事件,业务高危端口从对外开放到被探测利用的时间只有45秒,针对资产数量较多的大中型企业来说,很难在45秒内完成一轮扫描,而通过流量建立相关通信特征的检测,则可以实现秒级响应。及时的捕捉到这些高危通信行为,让安全团队迅速卷入,收敛风险。实现上单纯依靠入流量还不够,网络上的大量扫描和探测会带来误报,提高运营成本,结合出流量的回显关联,则能较好的解决误报问题。

c) 脆弱点/漏洞主动发现:漏洞扫描一般重点关注在对特征类漏洞的发现,发送特定构造参数或payload以触发是否存在漏洞,对于业务层面的不合规行为或者逻辑类漏洞则覆盖不足,比如敏感信息明文传输、越权、管理后台类等,这些场景却是流量分析大显身手的地方。在此以管理后台来说,存在弱口令、而又未做ACL访问控制的管理后台直接对外开放,一直是白帽黑客特别喜欢的入侵入口。传统扫描方法基于关键字,灵活性和可维护性不高,而通过流量分析,同时引入AI算法,模型可以自动学习页面特征,效果远超过传统方案。同时,引入正负反馈机制配合AI模型训练,提升模型识别率。此外这不但可以监测管理后台的对外开放问题,而且也可以对存在弱口令的管理后台进行告警。 

 
(JS生成的管理页面,若扫描器不能解析JS则不能主动发现) 


(根据流量识别出的风险页面对外开放)

[4、 云时代安全能力 ]
如果流量足够多、类型足够丰富,那基于流量层面进行威胁情报建设、pdns积累、0day发现等都有实践意义,目前我们也在进行相关尝试。

【展望】


流量是座大宝藏,对于传统安全场景,流量分析不是替换传统方法,而是互补和结合,“流量+”也会将企业的安全能力带上一个新台阶。但事无完美,流量层也存在硬伤:加密问题。随着https普及以及http2、QUIC特性的使用,传统网络层看到的将是一串加密二进制数据,不再是http下的明文字符,基于黑特征的检测拦截能力都将失效(上面我们提到的网络层WAF方案的弊端)。解决办法是将流量接入层下移,比如位于接入网关GW/LB解密卸载之后;同时对于某些场景,需要降低对黑特征、关键字的依赖,综合利用大数据、AI等手段,构建基于行为的检测机制,比如木马主控C&C行为的发现。 




【结语】


流量分析助力安全能力提升,我们也在摸索中,上面内容也仅是一家之言,希望能和业界有更多的探讨交流。若有对这方面感兴趣的各路小伙伴,欢迎加入我们“共谋大业”,有意向的同志可投递简历至 security at tencent.com。 

评论留言

提交评论 您输入的漏洞名称有误,请重新输入