log-analysis - 基准内部网络流量(企业)

Question

我们正在使用 Zeek 以“连接日志”的形式从交换机收集网络流量。然后，连接日志通过 filebeat 存储在 Elasticsearch 索引中。每个连接日志都是一个包含以下字段的元组:(source_ip,destination_ip,port,protocol,network_bytes,duration) 还有更多字段，但为了简单起见，我们现在只考虑上面的字段。我们每小时收到 2 亿条此类日志用于内部流量。 (Zeek 允许我们通过字段识别内部流量。)我们有大约 200,000 个事件 IP 地址。

我们要做的是消化所有这些日志并创建一个图，其中每个节点都是一个 IP 地址，一条边(有向，源目的地)表示两个 IP 地址之间的流量。每个不同的(端口、协议(protocol))元组都有一个独特的边。边缘将具有以下属性:平均持续时间、传输的平均字节数、一天中每小时的日志直方图数。
我尝试过使用 Elasticsearch 的聚合以及更新的 Transform 技术。虽然两者在理论上都有效，而且我已经在一小部分 IP 地址上成功测试了它们，但这些进程根本无法跟上我们的整个内部流量。例如。使用 Transform 消化 1 小时的日志(约 200M 日志)大约需要 3 小时。

我的问题是:
后处理 Elasticsearch 数据是制作此图的正确方法吗？或者是否有一些我们可以在上游使用的产品来完成这项工作？有人建议研究 ntopng，但我在他们的产品描述中没有找到这个特定的用例。 (不确定是否相关，但我们使用 ntop 的 PF_RING 产品作为 Zeek 的前端)。是否有其他产品可以开箱即用？谢谢。

Answer 1

您试图用 Zeek 东西向流量图找出什么问题或根本原因？

似乎更量身定制的用例，例如特定类型的身份验证，甚至更大的问题集(例如端点访问扩展)可能会更好地利用存储、计算、内存以及您其他宝贵的时间和资源，不是吗？

即使您确实想要对 Zeek 数据进行关联或分组，也请尝试将其标准化为 OSSEM ，并且当您可以收集 community-id 时，没有理由收集元组反而。您可以将大型 Zeek 与小型 Suricata 相关联。也许更好的数据架构是VAST .

Kibana 在其最新迭代中确实有 Graph ，甚至旧版本也可以利用第三方kbn_network插入。我可以看到你遇到了 200k 事件 IP 地址和 Elasticsearch 聚合甚至摘要索引的墙。

许多组织将构建超出 Elasticsearch 提供的简单 Serving 层的数据架构。我听说的是直接流入图数据库的Kappa架构，比如dgraph ，也许只是从服务层可用的图的那些边缘。

还有其他方法可以从 IP 地址数据中提问，例如 AWS SageMaker 中的 ML 选项 IP Insights或 Apache Spot项目。

此外，我非常喜欢仅在情况出现时获取正确的数据，尽管以自动化的方式使拼图 block 为我冒泡，我可以简单地将它们锁定到位。如果我特别在处理 Zeek 数据，我可以利用诸如 SecurityOnion 及其精心编排的 Playbook 之类的平台。引擎为我启动其他任务，例如使用 Velocidex 之一进行查询工具，甚至使用内置的 Sigma 进行交叉关联来源。