导读
作为一个萌新的我,虽然在学校开始自学网络安全知识,安全乙方公司实习了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实现封禁的问题,都需要后面慢慢对规则进行优化,还有一点是褥羊毛的行为,这需要很强的用户访问路径,大量数据来统计,做机器学习模型来判断一个用户的一个访问路径,上下文关系是否正常。还有登录和注册接口可以利用数据挖掘和机器学习等方法,刻画用户画像,并找到异常/恶意帐号。