XDR 的技术栈参考

这几年，随着各家企业安全建设的日渐成熟，安全运营越来越得到重视。讲到安全运营，实际上脱离不开相关的安全产品及技术，尽管相关产品和技术已发展了这么多年，但整体现状却不是特别乐观。

如果要把安全产品粗粗分个类，我们可以有这么一种分法：端点型的和综合平台型。

端点型的安全产品，像 EDR、NDR、WAF 等，虽然可以在端点上把能力做到极致，但它们的安全视角是非常有限的，仅仅能看到、检测到自身端上的数据，很多似是而非的行为无法判定是不是真正的攻击。

综合平台型的安全产品，像 SIEM、SOC、态势感知等，虽然汇集了大量安全数据，实际情况往往陷入 1+1 < 2 甚至 1+1< 1 的困境，对于单点产品的威胁检测和响应的效率提升非常有限。

大家肯定听说过木桶效应，这个在企业安全中也一样存在：整个企业的安全水位线取决于安全防护水平最低的那块木板。

谁都不想被这块木板所困扰，那么，怎么样才能提升企业整体的威胁检测和响应能力呢？

这个时候，XDR（可扩展威胁检测与响应）就应运而生了。

下面给大家介绍一下 XDR 平台具体使用到的技术栈。这块内容主要给大家自研或者学习过程中，作为技术选型的参考。这里会围绕 XDR 提供的四大功能（采集、分析、检测、响应）进行介绍。

技术栈：采集

数据采集功能中，主要用到了分布式数据采集框架、高性能分布式消息队列、分布式文件/对象存储。

XDR 采集的数据，整体上分为网络流量、日志、事件三大类，每种数据都有各自最佳的采集框架。

日志类数据，有 Apache Flume、Logstash、Filebeat。Logstash、Filebeat 都是 Elastic 出品的，Filebeat 相对 Logstash，比较轻量级，底层基于 golang 编写，有非常好的性能，部署的时候就一个可执行文件和配置文件。

网络流量类数据，一般以 pcap 格式传输和保存。linux 上简单的可以选择 tcpdump、tshark，tshark 是 wireshark 的命令行版本。当然，也可以选择基于底层抓包的类库编程实现。linux 上网络流量抓包可以选择 libpcap，windows 上可以选择 winpcap。这两个都是比较底层的类库，也可以选择更高层的封装，比如 golang 版本的 gopacket，python 版本的 pypcap。但总得来说，底层都是基于 libpcap 或者 winpcap。

libpcap 有个比较大的问题，在大量流量下，丢包率比较高。可以考虑 PF_RING，但是 PF_RING 需要安装支持 PF_RING 的网卡驱动。

这里顺便讲一下分布式文件/对象存储，抓取到的 pcap 文件，需要存储到分布式文件/对象存储上，供后续的报文解析和内容分析。

分布式文件/对象存储分为支持对象存储和不支持对象存储。支持对象存储有 MinIO、Ceph，如果没有大量的、长期的、多种类型的文件存储需求，可以选择 MinIO，Ceph 相对比较重。

事件类数据，比如 windows 安全事件、mysql binlog，这些事件通常需要调用特定 api、和特定进程通信获取数据。windows 安全事件的有 winlogbeat，采集到的数据都已经非常友好地格式化为 json 格式了。mysql binlog 的有 canal、flink cdc。

另外，还有一类属于综合型的采集框架，集成多种采集方式，比如 apache nifi，还提供了一定的 etl 能力，可以以可视化方式编排采集和 etl。

上面这些采集框架，除了 nifi 之外，都缺乏对采集端的统一管理能力，比如采集端有没有正常在采集、采集量有多少、能不能暂时先关闭采集、能不能限制采集端过多得占用主机的资源，这个是 XDR 在实际落地的时候需要考虑的。

最后，采集到的数据需要发送到高性能分布式消息队列上，供后端的解析和 etl 系统进行消费。不直接在采集端进行解析和 etl 的主要原因在于，解析和 etl 通常都是一个消耗 cpu 的过程，把这些功能从采集端分离出去，中间通过消息队列进行消费的负载均衡，有助于提升整个系统的负载。

消息队列业内基本上会选择 kafka，另外，也可以考虑新兴的 apache pulsar。kafka 在实际 XDR 落地实现过程中，topic 分区没法动态调整，无法原生支持有序和延时消息等问题，也是令人头疼的问题，好在都有变通方案，而且在吞吐量足够高，基本满足需求。

技术栈：分析

数据分析功能中，主要考虑在海量数据的情况下，用户需要边观察数据边分析。这就要求 XDR 提供海量数据的近实时分析能力。下面是一些常用的技术。

搜索引擎，主要用于数据的快速搜索和回溯，es 和 solr 两个基本上是唯二选择。solr 和 lucene 师出同门，相对有比较好的性能表现。es 自动化运维比较方便。两者仁者见仁智者见智。

为了提高海量数据的聚合计算速度，近实时数据分析引擎一般采取空间换时间的方法，这个空间可以是内存、磁盘、cpu 等资源。典型的如预计算，将维度数据提前计算好并存储起来，比如 kylin。另外典型的有利用多节点并行计算的 mpp，将计算分摊到更多节点上的 cpu 和内存，比如 presto。这里有一点要注意，类似 presto 的 mpp 类分析引擎，通常只提供一个分析引擎，计算和存储分离，好处是可以独立各自扩展，坏处是需要再选择部署一个存储引擎，而且存储引擎无法针对分析引擎进行特定的优化。

这里单独把 clickhouse 列出来，不仅因为最近几年的确很火，而且在单表 TP 级数据量查询上的性能的确很出色。虽然 clickhouse 也可以算是 mpp 类分析引擎，但它却一起提供了存储引擎，而且针对不同的场景提供了多种数据存储模型。

另外，分析中，有时候需要基于图的关联查询和分析，特别是二度三度关联的场景，可以选择图数据库。neo4j 一直是霸占第一的宝座，但是分商业版和社区版，社区版不支持集群部署，这是一大遗憾。国产可以选择 nebula graph，性能较好，社区活跃度也较高。

选哪一种分析引擎，没有唯一选项，还是得看实际需求。如果采集到的数据种类较少，字段固定，预计算类型和 clickhouse 都是很好的选择。另外，es 和 solr 在大数据简单查询条件下的近实时搜索优势还是非常明显的，并且也支持不是特别复杂的非海量数据的快速聚合，在 XDR 落地实现中几乎是必选。

很多时候，需要多种技术的组合使用。

最后，这里还涉及到如何可视化展现数据，主要是前端相关的技术，echarts 是一个不错的选择，除非 echarts 已经满足不了了，比如绘制一些大屏、复杂的网络拓扑图等，可以考虑 d3。

技术栈：检测

乍一看，检测功能中的技术非常多，但很多是可选的。我们一个个看。

决策引擎，也就是规则引擎，检测过程中最为核心的组件，所有的检测逻辑最终都要在规则引擎上实现。

传统方案可以选择 jboss 的 drools，作为规则引擎里的元老级和全能型框架，当然全能也意味着重量级。如果没有强烈的需求，并不太建议选择。

轻量级方案有 easyrules，十分钟上手，半天看完源码，足够轻量级。但很多情况下，估计会不太够用，需要扩展，甚至扩展了还不如选其它的框架。

这里我比较推荐表达式引擎，有些表达式引擎甚至还支持简单的 if else 逻辑和自定义函数，几乎是一门新的编程语言了。国产的 aviator 和 qlexpress 都是很好的选择。qlexpress 支持自定义函数。

groovy 其实不能算表达式引擎，但使用 groovy 完成简单的表达式求值完全没问题，更复杂的还可以动态生成 groovy 代码完成更加复杂的逻辑。当然，太过于底层，面向字符串的编程也是使用 groovy 作为规则引擎的一个大问题。

另外，flink cep 也可以作为规则引擎，和 flink 进行很好地集成。如果使用 flink 作为实时流计算框架，flink cep 是一个很好的选择。

规则引擎负责的是逻辑和算法，至于其中用到的数据，就是下面的各种框架和数据库们的事情了。

首先是实时流处理框架，这里只写了一个 flink，实际上目前业内的最佳选择，也就是 flink。用于实时计算相对简单的较短时间内的数据。

其次是离线数据处理框架，这里也只写了一个 spark，同样的，也是目前业内的最佳选择。用于离线计算相对复杂的跨天跨周跨月的数据。

然后是图计算框架，这块有基于 spark 的 graphx，有 apache 孵化的 giraph，也有国产 Tecent 的 Plato。这里面 spark graphx 整体的计算性能较差，但和 spark 集成度较好。

接着是机器学习开发框架，把机器学习相关的框架放在检测功能中，倒不是指在检测功能中去使用这些框架，而是指检测功能中会调用这些框架调教出来的模型。而且，这里也没有把深度学习框架放进来，我觉得安全领域对深度学习的落地场景太少。

最后提一下这个高性能缓存和 KV 数据库，这些缓存和数据库主要是给实时流处理框架在计算过程中使用，存储中间计算结果或者查询全局缓存类数据。因此，这类缓存和数据库必须是支持高性能并发读写的，数据结构可以足够简单。

技术栈：响应

响应功能的核心技术就是工作流引擎，市面上主流的工作流引擎无非 jboss 的 jbpm，以及 activiti 和从 activiti 衍生出来的 flowable、camunda，大同小异，选择一个适合自己的就行。