从无到有的日志分析演变过程

导读

作为一个萌新的我，虽然在学校开始自学网络安全知识，安全乙方公司实习了2年多，做了2年多份安全开发工作，渐渐的对网络安全有了深入的了解，2年间主要是负责安全工具开发和日志系统开发，后面由于自身问题跳到了甲方公司，开始对甲方公司的网络安全进行从无到有的开发，由于之前开发过日志分析平台，因此，我开始了从无到有的日志开发工作，也是公司的日志开发的演变。

一代目日志分析系统（千手柱间）

我们对日志分析系统做了初代的思路并将其实现，在这种结构中只有简单的Logstash、Elasticsearch。Logstash通过输入插件直接读取文件获取数据，过滤插件自动根据已经写好的切分规则进行切分，然后把已经切分好的字段传输给Elasticsearch。然而当最简单的架构出来后，我们又发现了新的问题，Logstash Agent的维护不是很理想，Logstash是基于Ruby的，启动它就要有几十兆内存被jvm吃掉，我们想避免在每个机器上都要起一个Logstash。并且在我们使用过程中Logstash非常不稳定，莫名其妙就死掉了，还需要一个守护进程守护它。

二代目日志分析平台（千手扉间）

这种架构解决了Logstash在各服务器节点上占用系统资源高的问题。相比Logstash，Filebeats所占系统的CPU和内存几乎可以忽略不计。另外，Filebeats和Logstash之间支持SSL/TLS加密传输，客户端和服务器双向认证，保证了通信安全。因此这种架构适合对数据安全性要求较高，同时各服务器性能比较敏感的场景。但是对于这种架构也是存在着不少问题，就是在一开始导入日志的时候，或一次性读取所有日志文件，全量输出给Logstash，这样的话吞吐量大会出现内存不够用，导致系统奔溃。为了解决这一种情况，我们采用了Kafka，Logstash从Kafka里消费这些日志，写到ElasticSearch里面去，然而当我们业务量数据达到上亿的时候，服务器再一次没有扛得住压力了，而且这只是做了简单的存储，还没有用到检测规则和告警服务。

三代目日志分析平台（猿飞日斩）

为了解决二代目日志平台遗留下来的问题，对架构LogStash做了重新的规划，改用Storm作为日志切分，对数据进行预处理，白名单过滤等预处理，添加正则引擎对nginx上GET请求做检测判断，判断攻击的打上攻击标签，但是由于检测性能消耗过大，因此把检测和本身存储日志分开存储到ElasticSearch，业务监控也只是对一些特殊接口做了检测。但是这随着引发出了另外一个问题，那就是当数据量短时间内高吞吐量多的时候，出现了日志延时的问题，高峰时间越长，吞吐性能越低，而且监控是采用python脚本去查ElasticSearch定时跑任务，统计并发出告警，在设计上无法实现想要的效果。检测性能也需要优化。

四代目日志分析平台（波风水门）

为了更好的解决三代目日志分析平台的问题，我们又重新处理了一下，改用了性能更好，吞吐量高的Flink，也支持和Storm一样的数据流处理，窗口支持较为完善，自带一些窗口聚合方法，并且会自动管理窗口状态。同时又在Flink上做了监控统计告警，通过对每一次的数据量进行统计，获取到实时的数据流状态，充分考虑到上下游的关系，在检测性能上也得到了很大的提升，也解决了在监控上是采用python脚本去查ElasticSearch定时跑任务，统计并发出告警的问题，更加方便快捷。

总结

在上面经过一年间的不断实验，最终得到了这样一个相对稳定的日志分析版本，但是其中还有很多优化的空间，比如检测到的攻击行为如何定义为一个事件，比如扫描器事件、撞库事件、扫号事件等，还有联动WAF实现封禁的问题，都需要后面慢慢对规则进行优化，还有一点是褥羊毛的行为，这需要很强的用户访问路径，大量数据来统计，做机器学习模型来判断一个用户的一个访问路径，上下文关系是否正常。还有登录和注册接口可以利用数据挖掘和机器学习等方法，刻画用户画像，并找到异常/恶意帐号。