通过ee-outliers与Elasticsearch检测TLS beaconing

2019-05-25 39406人围观 工具

ee-outliers 是用于检测存储在 Elasticsearch 中的事件的异常值的工具,这篇文章中将展示如何使用 ee-outliers 检测存储在 Elasticsearch 中的安全事件中的 TLS beaconing 连接。Beaconing 连接是定期发起的连接,可能表示计算机已经被感染在进行控制通信,例如从 C&C 服务器中获取指令或者静默地在网络中外传数据。

预备 ee-outliers

ee-outliers 完全在 Docker 上运行,因此对环境的要求接近于零。唯一的要求是对 Docker 和 Elasticsearch 集群的连接配置,使其可以访问数据。

该项目的 GitHub 的README页面已经包含了所有细节,无需赘述。

创建配置文件

GitHub 上 ee-outliers 的默认配置文件中包含了所需要的所有配置选项。首先修改 general 部分中的参数,确保 ee-outliers 可以连接到 Elasticsearch 集群。使用时可以保留所有默认值,包括 beaconing_batch_eval_size

[beaconing]
# 在查找异常值前,需要同时定义处理多少事件
# 事件数量的增多通常意味着会有更好的结果,但会导致内存使用量增加
beaconing_batch_eval_size=1000000

将参数 print_outliers_to_console 设置为 1,就可以直接在命令行输出中看到检出的异常值,这便于进一步调试。

print_outliers_to_console=1

额外需要调整一下 ee-outliers 的时间戳字段,提供一个 grok 模式将其转换为 days, hours, minutes 的形式,便于人类阅读。事件的时间戳字段为 timestamp,由此派生出的字段包括 timestamp_daytimestamp_hour

##############################
# DERIVED FIELDS
##############################
[derivedfields]
timestamp=%{YEAR:timestamp_year}-%{MONTHNUM:timestamp_month}-%{MONTHDAY:timestamp_day}[T ]%{HOUR:timestamp_hour}:?%{MINUTE:timestamp_minute}(?::?%{SECOND:timestamp_second})?%{ISO8601_TIMEZONE:timestamp_timezone}?

接下来增加一部分新配置,用于定义统计 TLS beaconing 的检测模型,此用例已在示例配置文件中定义过了,如下所示:

##############################
# BEACONING - DETECT OUTBOUND SSL BEACONING - TLS
##############################
[beaconing_ssl_outbound]
es_query_filter=BroFilter.event_type:"ssl.log" AND _exists_:BroFilter.server_name

aggregator=BroFilter.server_name,BroFilter.id_orig_h,timestamp_day
target=timestamp_hour
trigger_sensitivity=1

outlier_type=suspicious connection
outlier_reason=beaconing TLS connection
outlier_summary=beaconing TLS connection to {BroFilter.server_name}

run_model=1
test_model=0

让我们逐行解释一下,方括号之间的部分是要运行的模型名,名字都以 beaconing_ 为开头,这样 ee-outliers 就知道应用统计 beaconing 检测模型了。

[beaconing_ssl_outbound]

参数 es_query_filter 指定模型要使用的 Elasticsearch 查询,便于收集要分析的事件。在这个特定场景下,从存储在集群中的 ssl.log 文件中选择所有 Bro(Zeek)事件。此外,要筛选出创建 server name 字段的 SSL 事件,稍后在 aggregator 中要使用到这个字段:

es_query_filter=BroFilter.event_type:"ssl.log" AND _exists_:BroFilter.server_name

模型将为每个单独的 aggregator 字段计算目标字段的所有唯一实例。在这个特定场景下,这意味着 ee-outliers 为一天中的每小时都创建 buckets(前文创建的派生字段之一——timestamp_hour),并用 aggregator 的每个唯一实例组合填充这些 buckets

aggregator=BroFilter.server_name,BroFilter.id_orig_h,timestamp_day
target=timestamp_hour
trigger_sensitivity=1

例如,假设集群中关于域名 sneaky.com 的 TLS 连接事件每小时大约出现 5 次,都是针对特定源 IP 地址(192.168.0.2)和特定的日期(19/12)的。然后 ee-outliers 将会创建下列 buckets 来发现异常值:

Aggregator: "sneaky.com - 192.168.0.2 - 19/12"
Target: 00 (midnight)
Total count: 5

Aggregator: "sneaky.com - 192.168.0.2 - 19/12"
Target: 01 (01:00 AM)
Total count: 4

Aggregator: "sneaky.com - 192.168.0.2 - 19/12"
Target: 02 (02:00 AM)
Total count: 5
...

aggregator 中所有可能的实例组合都会装进 buckets 中。在这个特定场景下就是 ee-outliers 处理事件范围内唯一 server name、源 IP 地址与时间的组合。

触发灵敏度定义了允许存在多少“标准差”。在上面的例子中,凌晨 1 点只存在 4 个而不是 5 个请求,如果不容忍一些偏差的存在,就不会被视为异常!通过将触发灵敏度设置为 1 或者更高,将不会错过那些微小偏差的异常值。例如,在 trigger_sensitivity 设置为 1 的情况下,下面 24 个计数值(一天中每小时一个)都是 beaconing。

5 5 5 4 4 5 5 5 5 3 5 5 5 2 5 5 5 5 4 5 5 5 5 5

标准差是 0.74,小于设置值 1,所以这个 24 个 buckets 的所有事件都会被标记为异常值。

此外,beaconing 模型的内置要求是至少需要 10 个 buckets,否则不会检测到 beaconing。换句话说,上面如果只有 9 个值而不是 24 个,或者不满足最少的 10 个值的任意个值都不会被标记为异常值。

然后指定异常值类型、成因和摘要。请注意,摘要中可以包含占位符字段,这些字段都会在异常事件中得到丰富,并且将使分析师更容易在以后对其进行可视化。

outlier_type=suspicious connection
outlier_reason=beaconing TLS connection
outlier_summary=beaconing TLS connection to {BroFilter.server_name}

最后,让 ee-outliers 运行该模型。在配置文件的 general 部分中全局启用或禁用运行与测试的开关。

run_model=1
test_model=0

运行 ee-outliers

配置好模型后,运行 ee-outliers 来查看结果。按照 GitHub 上的 README 页面所述运行 ee-outliers。以交互模式运行时,我们可以在命令行输出中看到结果。按照需要,可能需要配置 Docker 网络使得 ee-outliers 能够访问 Elasticsearch,按照 README 页面配置即可,接下来称该网络为 sensor_network

# 构建镜像
docker build -t "outliers-dev" .

# 运行镜像
docker run --network=sensor_network -v "$PWD/defaults:/mappedvolumes/config" -i outliers-dev:latest python3 outliers.py interactive --config /mappedvolumes/config/outliers.conf

查看输出,似乎已经发现了显示为 beaconing 行为的事件:

2018-12-11 23:32:02 - INFO - ===== evaluating ssl_outbound outlier detection =====
2018-12-11 23:32:02 - INFO - analyzing 6,001 events
2018-12-11 23:32:05 - INFO - ssl_outbound - evaluating beaconing model [100.00% done]
2018-12-11 23:32:05 - INFO - evaluating batch of 6,001 terms
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com
2018-12-11 23:32:05 - INFO - outlier - beaconing TLS connection to rules.emergingthreatspro.com

如果在配置文件中启用了 es_save_results 选项,这些事件会被在异常值字段中被标记,就可以对其进行可视化。

可视化结果

我们使用 Kibana 来可视化新标记的异常事件,基于包含 outliers.reason 的所有事件创建直方图。此外还创建了两个表来展示异常值类型与成因,分析师可以快速筛选出感兴趣的内容。

过滤 beaconing TLS connection(这是在之前定义的 outlier_reason 字段的名称),接下来创建一个过滤 outlier_summary 字段的表:

深入展示列表的第二个命中,再次进行过滤 rules.emergingthreatspro.com 就可以得到以下的直方图了。

看起来就像是 beaconing 行为,事实上这是我们实验室的设备,定期在 Emerging Threats 网站中提取新的 IDS 规则

通过检查 aggregator 的值,我们可以看到计算出了哪些 buckets(格式:server_name – IP – hour,与之前定义的完全一致)

最后下钻 terms 字段,可以看到每小时发出了多少请求。请注意,outliers 对每天都进行分析,因为 timestamp_day 是配置的 aggregator 字段的一部分

结论

在这篇文章中,展示了 ee-outliers 检测存储在 Elasticsearch 中的任意字段组合的 beaconing 行为的能力。beaconing 模型可以被用于更多场景:Windows 登录、HTTP 和 DNS beaconing 等。配置触发灵敏度可以决定模型以多严格的标准检测异常值,也为分析师提供根据需要调整和定制的能力。最后,通过使用新字段丰富每个异常事件,在任何喜欢的可视化工具中制作显示异常值的仪表板。

*参考来源:nviso,FB 小编 Avenger 编译,转载请注明来自FreeBuf(FreeBuf.COM)

相关推荐
取消
Loading...

这家伙太懒,还未填写个人描述!

9 文章数 0 评论数 0 关注者

特别推荐

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php