日志分析系列之平台实现

本系列故事纯属虚构，如有雷同实属巧合

平台实现前的说明

小B在给老板汇报了"统一日志分析平台"项目后，老板拍板立即开始做，争取下一次能及时发现攻击并且追踪攻击者。于是小B开始分析了市面上商业与开源的日志分析平台架构，大家都神似如下图：

知道了架构如何，接下来的关键就是每层之间选择什么样的产品了。关于如何选择，小B推荐了几个方面：

• 已有架构：避免基础能力的重复，使用目前IT基础框架中已有的东西。假设运维已经有一套ELK，就没有必要重复搭建，只需要与之结合优化数据源与增加安全分析场景即可。
• 技术实力：负责统一日志分析平台人员的技能栈。
• 产品自身优劣：不同产品有各自最适用的场景，所以选择合理产品是核心依据。

小B在选择产品时，参考了一些些资料(见参考资料)。

在经过一番对比之后，小B最终选择了以下产品来实现统一日志分析平台：

下面就容小B细细道来实现统一日志分析平台的那些心酸历程：(如果大家尝试复现小B的统一日志分析平台，请优先阅读踩坑记录，在文章末尾)

小B的统一日志分析平台结构(简易版，实际要复杂的多，这里只是一个Demo环境)：

搭建过程，我就不一一描述了，搭建自己可以查询相关产品的安装文档或者：https://bloodzer0.github.io/ossa

实现日志采集处理与展示

服务器日志

首先关注的是服务器上的日志，Q公司所有的服务器都是Linux(Centos7.x)，极大的减少了小B的工作：

服务器日志采集

• /var/log/audit/audit.log：审计日志，跟用户相关的日志。
• /var/log/cron：记录与系统定时任务相关的日志。
• /var/log/messages：记录系统中主要信息的日志。
• /var/log/secure：记录验证和授权方面信息的日志，如：ssh登录、su切换用户、sudo授权等。
• /var/log/yum.log：记录yum安装软件信息。

关于服务器日志采集filebeat提供了两种采集方法：

• 方法一：直接写配置文件采集：vim /etc/filebeat/filebeat.yml。
• 方法二：使用filebeat模块来收集，使用模块收集也是我们本次采用的方法。因为使用模块内置了pipeline可以解析服务器日志，并且在Kibana中提供了很多图表，减少我们的工作时间。备注：这里有坑，详情请看踩坑0x02

# 首先在我们的测试服务器上安装filebeat
rpm -ivh filebeat-7.4.1-x86_64.rpm

# 修改filebeat配置文件中的ES和Kibana地址，并初始化filebeat
vim /etc/filebeat/filebeat.yml

setup.kibana:
  host: "10.10.10.9:5601"
  
output.elasticsearch:
  hosts: ["10.10.10.9:9200"]

# 初始化filebeat
filebeat setup

# 启动filebeat模块
filebeat modules enable system
filebeat modules enable auditd

# 初始化filebeat模块的pipelines
filebeat setup --pipelines --modules system
filebeat setup --pipelines --modules auditd

# 修改system模块中日志文件路径
vim /etc/filebeat/modules.d/system.yml

- module: system
  syslog:
    enabled: true
    var.paths: ["/var/log/messages"]

  auth:
    enabled: true
    var.paths: ["/var/log/secure"]

# 修改audit模块中日志文件路径
vim /etc/filebeat/modules.d/auditd.yml

- module: auditd
  log:
    enabled: true
    var.paths: