🥷
🥷
文章目录
  1. 其他
  2. Resources

日志收集解决方案概览

最近一般时间在做日志收集的东西,也算有了一些收获。不过主要是在数仓建设这一块的。因此整理了下图,以便有个整体的感觉。对比一下怎么样去做日志收集,或者也可以改成叫数据收集。因为这些解决方案并不局限于日志收集,适用于任何形式下的数据收集。

image

日志收集的首要步骤是你要知道哪些数据类型需要收集,以及如何进行收集。 先看图,图中绿色标记的部分是生产网和办公网重叠的类目,即无论是生产网还是办公网均需要收集的数据。因此无论是生产网还是办公网的DNS解析记录,VPN请求,NAT日志还是NIDS日志,都需要进行收集。除此之外,需要尽可能的分别针对对应领域进行收集。有点像废话,不过事实确实如此。生产网相较于办公网一般来说,更加纯净,容易收集。而办公网面临着环境复杂,分散的问题,导致覆盖率不足,以及数据难以收集的问题等等。比如说在全国有40个办公室,存在着外包员工,公共账号等情况,以及网络环境或者网络设备不满足收集条件等等。

在整个链路而言,无非收集数据,落数据,读数据,计算。一般情况下是由以下几个部分组成的: log收集部分,数据库部分,消息队列,检索引擎,以及实时计算部分。这些部分并非是全部必须的。比如说消息队列,。当在日质量较大时通过消息队列订阅可以避免数据丢失,但是数据量小的话,其实并不是必要的。同样,甚至可以直接将所有数据直接推入es之中,而不需要数据库等。目前(32C*64G) * 4slave + (40C*128G) * 1master就足以应对大部分的场景了。当然,也有可能面临着异常慢的查询,需要你的优化。关于日志收集部分的,作为基础,可以选择filebeat或者logstash,一般来说,我是用这两个。同时,针对syslog的采集也可以选择rsyslog。实时计算的话,似乎没有太多的选择,spark or flink, spark有着较好的文档和问答支持与搜索,但是flink则不然。同时,spark不能进行实时计算,只能做batch处理,因此需要实时计算需要选flink.

当我们看完了正常情况下的链路建设,顺便看下云上的。虽然云上的本质也是这一套,但毕竟是PAAS,So让我们参考下这里 云上不同服务商的服务对比 (csv转markdown看起来确实不怎么样,建议通过上面分享的文档来看。)

image

我分别针对阿里云,腾讯云,华为云和aws分别从采集方式,查询,存储,消费,自身监控,权限以及等方面进行了对比。首推AWS和阿里云,国内首推阿里云的SLS。

最后想说的是就是数仓的建设,数仓的建设重点针对数据进行分层输出,这是一个原始数据(raw数据)->结构化数据->指标数据的过程。当然细节绝对不止于此。从图中可以看出,元数据层和数据源层到数据抽取以及数据集市和ETL工程,到富含Intelligence的指标数据以及具有逻辑的数据。并针对整个链路的监控数据等等,可以说是一个巨大的工程了。当然这些都是逻辑上的,具体的建设其实还是在Hadoop or Hive or ODPS等等之上,建立不同的project,写不同的sql,创建各样的定时任务,使其根据预先设计的逻辑形成对应的数据。在这个过程中,重要的一点就是区分实体,模型,并找到之间的关系,并定义模型自身的属性。图中最下面的CIM部分的数据取自Splunk,可以很明显的看出来,针对不同的原始数据制定出的领域模型。比如说Vuln参考这里 可以看到针对漏洞这个实体本身输出的属性:

  • cve
  • tag
  • url
  • user_agent

当然这些是比较容易理解的属性,还有些其他的属性也是针对漏洞本身定义的。除此之外,针对Malware, Email分别也有对应的定,等等吧,总之还有很多。

其他

最近针对入侵检测的传统检测方式(规则类的检测方式)做了一些标准化,也写了一些文档去标准化。总结起来就是有一套数据源落地指南,规则命名规范,规则实体区分,编写排错手册。针对来自不同数据源(hids, edr…)的不同实体:(file, system, network, host等)对应到不同类型的规则(exec, ioc, connect, behavior等等)输出的不同等级(分值1-10)的告警(通过webhook或者钉钉通知到对应的人员)。在这个过程中也可以针对规则的类型输出一条ATT&CK 的标识。当然以上所讲的只是理想情况。不同数据源的标准化也是一个容易踩坑的地方。

踩一个坑,填一个坑,锅不是目的,解决问题才是。后面再写个关于规则编写的吧。

落笔已是接近凌晨一点。

Resources