引言
在系列文章《数据透视篇》中我们提到，安全设备每天所产生的告警量非常庞大，常常达到上千万量级，而绝大部分的告警都是由正常流量造成的，本文为系列文章的第二篇，浅谈这些误报的形成原因，并且阐述过滤这些误报的方法，经过一系列过滤方法，90%以上的告警都会被当成正常流量过滤掉，高威胁度告警全部在残留的不到10%的告警当中。告警过滤机制为我们后续的分析打下了良好的基础。
一、正常流量的组成
我们知道，基本上现行所有网络侧安全设备的工作原理是基于特征的，也就是说只要网络流量里有类似的特征匹配上，就会触发告警，这种工作模式不可避免地会在正常流量中产生大量告警，导致误报，本小节，我们将详细分析某次红蓝对抗数据中正常流量的组成要素。
需要特别说明的是，在这里，我们需要对“正常流量”和“误报”做出一定的区分，“误报”指的是安全设备的告警类型与实际payload对不上，即由于安全设备的误判而产生的告警；“正常流量”是一个更大的范围，不仅包含“误报”，还包含各种非误报触发的告警，如错误配置、正常业务、用户正常上网行为等等。
首先是正常业务行为，正常业务往往纷繁复杂，会随着企业的不同、时间的不同等因素在告警中呈现较大差异，但无论怎样，这部分流量会贡献绝大多数告警，在我们的数据集中，至少90%的告警都是由正常业务触发的，我们举两个例子：
- 与IP：10.5.237.### 相关的告警中，10.5.237.###为威胁情报数据爬取和存储系统，有5个IP（192.168.200.###，192.168.255.###，10.66.250.###，10.82.180.###，192.168.255.###）对10.5.237.###有大量的SSH访问，主要负责数据的交互，另外，10.5.237.### 有大量的对外代理连接，10.5.237.### 会连接大量的代理池IP，利用这些代理IP进行持续的威胁情报信息爬取。这部分告警占总告警量的45%左右；
- 与 IP段：10.51.10.* 相关的告警，该C段IP会对各种来源的恶意样本进行静态和动态沙箱分析，分析结果会写入到集群当中，也会对集群中的数据进行读取，进行下一步分析，所有通信步骤通过python脚本进行交互，会触发大量的“路径穿越 python_scanner”类型告警，这部分告警占总告警量的20%左右。
用户的正常上网行为也会触发大量告警，如在使用微信的通信过程当中（图1），微信使用基于TLS 1.3的微信安全通信协议mmtls 进行通信，微信的短连接为post请求，通信内容加密，由于无法解密，二进制的字节流，如b’ \x19\xf1\x03\x00\xa1\x00\x00\x00\x9d’，会让设备产生误判，以为是在进行命令注入，产生命令注入类告警；同时用户安装的很多应用程序，如金山、微软等，会在后台持续进行通信，进行数据回传、应用更新等一系列操作，这些对用户透明的通信行为也会触发大量的告警。
常规性的漏洞测试行为。大型公司内部往往会对其内部系统做渗透测试，以发现潜在风险，这种内部的测试行为一旦发生就会触发大量设备告警。由于什么渗透测试属于敏感操作，攻击者在内网中往往也会触发类似的告警，因此对于这部分的告警需要格外注意。
二、正常流量过滤
在第一篇文章《数据透视篇》中我们提到，告警数据不论从源IP、目的IP、告警类型等任何方面，告警分布均呈现出幂律分布的特点，即少量的实体贡献了绝大部分的告警，通过上一小节我们也可以了解到，某几个正常的业务就能触发大部分告警。这一小节我们主要利用这一规律对正常流量进行过滤。
对于常见的正常业务，其最明显的特征就是规律性，这种规律性在多种维度体现：访问时间的规律性、告警类型的规律性、源IP和目的IP的规律性、告警载荷的规律性等等，对于这些规律性，不同业务之间可能会存在较大差异，我们的目标也是发现这些正常业务在告警中体现的规律并且过滤，在此我们举两个例子：
- 示例一
如图2所示，图中展示了10.200.10.###到192.168.255.##的所有告警类型的数量随时间变化的曲线图，纵坐标为每一小时所触发的告警数量，横坐标为时间，其中黄色部分为路径穿越类告警，橙色部分为通用web攻击类型告警。我们可以发现如下规律：
- 告警类型单一。两个IP之间仅触发两种类型的告警，虽然可能存在一定误报的可能，但是单一的告警类型体现出两者之间通信行为的单一，若是攻击者，很难只触发这两种类型告警。
- 告警数量大且持续性高。在5天之内，每小时都触发大约650条告警，数量巨大、持续性强的告警只有正常业务才有可能触发，攻击者很难做到24小时在线，持续大量地触发安全设备告警而不被发现。
- 告警载荷规律性明显。两者之间的所有告警基本全部形如图3所示，仅仅是URL路径存在些许差别，从payload可以看出这些告警都是由正常业务所引发的误报。
经由以上3点，我们基本可以确定10.200.10.##与192.168.255.##之间的告警由正常业务触发。
将上述规律编写相应代码对告警进行过滤，可以发现70%~80%左右的告警符合以上规律，可以作为正常告警滤除。由于数据集为红蓝对抗期间的数据，所有攻击行为对应的告警我们都有真实标签，经验证，滤除的正常告警中不包含攻击告警，这也进一步佐证了我们发现的规律的适用性。
- 示例二
虽然大部分正常告警能被示例一中的规律所捕获，但是依然有大量告警不满足上述规律，在此，我们举一个与示例一差别较大的例子，如图4所示，10.8.##.203 与 10.51.##.60 之间在每天6:30左右会触发大约1000条左右的路径穿越类告警，根据其payload内容（图5）可知，目标为获取某恶意样本的分析报告，因此不难得出结论：该告警由定时爬虫获取恶意样本的分析报告触发。为了过滤类似告警，我们可以总结出如下规律：
- 告警类型单一、呈突发性、数量较大。由于一般正常服务器仅提供较为单一的服务，因此正常流量触发的告警类型一般较为单一，而定时任务一般就呈现突发性的特点；
- 告警触发时间固定。定时任务一般在特定时间触发；
- 告警呈现出集群特性。在该例子中，源IP “10.8.##.203”不仅向目的IP“10.51.##.60” 发起了突发请求，还在6:30附近向同网段内的 IP“10.51.##.79”发送了大量 Post 请求，上传了大量数据，同时，同网段内的 IP“10.8.##.202”也表现出与源IP “10.8.##.203”类似的通信行为。
经由以上3点，我们基本可以断定 10.8.##.203、10.8.##.202 与 10.51.##.60、10.51.##.79之间的路径穿越类告警为正常告警，为了找出符合上述模式的告警集合，可以先采用极值理论（Extreme Value Theory）找出所有符合突发性特征的告警集合，然后通过查看周期性、通过聚类查看集群特性的方法，找出所有符合上述通信模式的告警集合。通过编写代码，我们发现内网中有大量告警呈现出类似的模式，其中并不包含任何已知的攻击告警。
需要特别注意的是，攻击者的攻击行为往往也呈现出突发性的特点，因此我们需要利用周期性、告警数量、集群特性等特征将攻击告警排除在外。
由于正常告警的模式颇多，我们不在此枚举，总之，在我们的数据中，至少有90%的告警是由正常流量所触发的。
三、灰色流量过滤
在这里，我们将“展现出一定的攻击性，但是与攻击方无关的告警”称为灰色告警，灰色告警一般包含如下类型：1. 外部的僵尸网络、蠕虫等发起的攻击行为，2. 内部测试人员对外部服务器的测试行为，3. 企业内部测试行为。
对于第一类攻击行为，僵尸网络和蠕虫在网络通信模式中呈现出一定的差异，僵尸网络一般会在短时间发送多个数据包，分别进行不同漏洞的探测，且攻击目标范围较小，如图6所示，122.70.128.168在1分钟之内向10.18.250.###发起了“Apache php文件后缀解析漏洞，PHPUnit 远程代码执行漏洞(CVE-2017-9841)，PHP代码执行漏洞，ThinkPHP framework 任意代码执行漏洞”等10几种漏洞的相关探测行为，且在安全设备的监控范围内，122.70.128.168仅仅只攻击了10.18.250.###一台服务器。与僵尸网络不同，蠕虫往往只利用少量漏洞，但是攻击范围较广，在告警中表现为同一源IP向大量不同目的IP触发大量相同类型的告警，且这些告警内容和时间上都比较相似。
上述行为虽然都属于漏洞扫描，但是僵尸网络倾向于“深度优先搜索”的方式，蠕虫倾向于“广度优先搜索”的方式，对于僵尸网络触发的告警，可以以源IP为单位进行告警聚合，统计告警类型数量、告警之间的时间差进行过滤，对于蠕虫触发的告警，可以以源IP为单位进行聚合，统计目的IP的数量、告警类型数量、告警之间的时间差进行过滤。编写相关代码后进行过滤发现，每天可以新增几十个IP用于补充威胁情报。
对于第二类和第三类的攻击行为，检测方法与第一类类似，只是在网络流量的流向上有所不同，第二类为“内到外”的流量，第三类为“内到内”的流量。其中第三类攻击行为需要立刻进行排查，判定是内部人员正常测试还是攻击队的内部扫描行为。
灰色流量触发的告警虽然仅占总告警量的5%左右，但是告警总量依然庞大，尤其是第三种攻击行为更需要引起重视，对于企业内部正常漏洞测试行为要做到及时备案。
四、总结
本文介绍了对海量告警进行过滤的方法，依据不同告警的特点设计不同的过滤方法，这些过滤方法具有一定的普适性。经过一系列过滤步骤，红蓝对抗期间平均每天1000万的告警数据量，可以最后被压缩到每天5万以内，而攻击告警全部包含其中，告警压缩比例达到99%以上，这些过滤步骤可以作为各种分析引擎的前置模块，不仅能够减轻分析引擎的压力，更可以尽可能的减少误报，优化告警分析引擎的整体效果。
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。