【导语】
前段时间，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。
如有侵权请联系:admin#unsafe.sh