moloch 网络流量回溯分析系统
0x01 故事背景
某一天的早上 你怀着愉快的心情来到公司,开始美好的 一天工作生活。有个业务后台的同事找到你说 昨天下班后有人反馈说访问他的业务后台有问题,他想分析网络层面的数据包看看,是否能看出什么问题。你微微一笑,作为一个资深网工,抓包这种小事,这不是正是花式秀 tcpdump还是tshark的时候么?
突然又觉得那里不对…什么鬼,要抓昨天晚上的数据包,你突然想到的竟然是这货...
既然没有这么逆天的技能的时光鸡小伙伴 那还是搭建一个流量回溯系统吧
0x02 架构简述
流量回溯系统首先要面临几个问题:数据包的存取和协议的分析,当数据量很大的时候检索的速度等…
刚开始的想法是使用tshark 设定数据包大小,让tshark在后台一直抓包。用了一下效果不忍直视。
后来又找了一些其它的解决方案比如: Analyzing Network Packets with Wireshark, Elasticsearch, and Kibana之类的,效果都不是很好
直到有一天 老大介绍了一个系统 moloch
数据的来源是交换机的镜像端口,moloch 系统主要涉及三个组件 Capture,elasticsearch 和 Viewer
Capture 用来抓取 流量会以pcap的格式存储到硬盘上面,还会存一份对应关系到es中,Viewer提供web界面。
moloch简介
Moloch是一款由 AOL 开源的,能够大规模的捕获IPv4数据包(PCAP)、索引和数据库系统
环境搭建
存储数据包对机器的性能要求 moloch 提供了评估页面
Moloch Estimators
硬件环境:我的测试环境是一台Dell Inc. PowerEdge R720/0T0WRN
cpu : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
memory: 100G+
disk: 8T
这是一台配置比较好的机器。所以我的Capture Machines和Elasticsearch Machines都放在一台上面, 有条件的强烈推荐把这2个组件分离开来
根据官方的文档有2个事情注意一下:
1 Moloch is no longer supported on 32 bit machines.
moloch不支持32位系统
2 Our deployment is on Centos 6 with the elrepo 4.x kernel upgrade for packet performance increases.
内核4.X 有助于抓包性能提升
我的系统环境 centos7 更新到最新的版本
[root@moloch ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core)内核版本也更新到4.x。
[root@moloch ~]# uname -r4.13.7-1.el7.elrepo.x86_64moloch 安装
先去官网下载一下安装包 Downloads
我选择是Nightly 版本 可以体验新的特性
moloch安装命令
rpm -ivh moloch-nightly.x86_64.rpmpfring 安装
moloch的Capture 默认使用libpcap 后面我们会用pfring 提升抓包性能
• cd /etc/yum.repos.d/ • wget http://packages.ntop.org/centos-stable/ntop.repo -O ntop.repo• wget http://packages.ntop.org/centos-stable/epel-7.repo -O epel.repo• yum erase zeromq3 (Do this once to make sure zeromq3 is not installed) • yum clean all • yum update • yum install pfringelasticsearch 安装配置
es可以选择在配置moloch时候安装 也可以自己单独安装 我选择自己单独安装
安装命令
rpm -ivh elasticsearch-5.6.2.rpm# 优化es[root@moloch elasticsearch]# vim jvm.options# Xms represents the initial size of total heap space# Xmx represents the maximum size of total heap space-Xms32g-Xmx32g[root@moloch elasticsearch]# vim elasticsearch.yml#抓包经常会把硬盘用完,当硬盘使用空间到80% es 就开始报警 ,我直接把报警关掉的。cluster.routing.allocation.disk.threshold_enabled: falsenetwork.host: 10.10.7.7[root@moloch ~]# curl http://10.10.7.7:9200{ "name" : "E2BtdPC", "cluster_name" : "elasticsearch", "cluster_uuid" : "EiSTiNE-QGaTt9z0V8HPkw", "version" : { "number" : "5.6.2", "build_hash" : "57e20f3", "build_date" : "2017-09-23T13:16:45.703Z", "build_snapshot" : false, "lucene_version" : "6.6.1" }, "tagline" : "You Know, for Search"}0x03 配置优化
配置moloch
不要使用弱口令哦
moloch 登陆
经过上面的配置,让我们来访问一下 moloch
在浏览器中输入 http://10.10.7.7:8005 输入账号上面定的密码。
出现如下界面的时候 表示系统已经搭建起来啦。
0x04 数据删除
我现在的环境每天都有好几个T的数据包,es每天也有差不多200个G数据产生,所以当系统搭建起来后第一件事情 强烈推荐大家考虑数据的删除保留问题。
# 关于pcap的数据包 我是使用moloch来控制删除[root@moloch ~]# vim /data/moloch-nightly/etc/config.ini# moloch 默认是freeSpaceG = 5%,也就是磁盘空间会保留5% freeSpaceG = 5%# es使用moloch自带的脚本来控制删除 [root@moloch db]# vim daily.sh #!/bin/sh# This script is only needed for Moloch deployments that monitor live traffic.# It drops the old index and optimizes yesterdays index.# It should be run once a day during non peak time.# CONFIGESHOSTPORT=10.100.10.7:9200 RETAINNUMDAYS=1 /data/moloch-nightly/db/db.pl $ESHOSTPORT expire daily $RETAINNUMDAYS# 在做个定时任务 每天晚上跑一次[root@moloch ~]# crontab -e01 04 * * * /data/moloch-nightly/db/daily.sh >> /var/log/moloch/daily.log 2>&1网卡优化
High Performance Settings
pfring 配置
查看抓包
我们在来看看同一时间moloch中抓包数据量,因为都是动态数值,但是结果如此接近,是不是可以说千兆网卡下已经可以做到100% 数据包抓取 不信你去看pfring 官方文档
0x05 功能使用
看到这里的同学都应该是真爱了,下面开始满满都是福利啦
历史数据分析
你可以写一些 search expression 自由搭配检索你需要的信息,es作为支持速度就是快。
举个例子: 源ip == 10.101.26.60 and 协议是 http的 信息如下:
数据包导出
你要是更习惯用wireshark分析 ,没有问题 moloch导出pcap也是很方便的
推荐 time range : “00:00:01” , bounding: “last packet” 。moloch显示的是会话信息,bounding就很好理解了。
还有记得点一下 “matching items” 我的环境一秒钟 大概导出200M的数据量。
先确定一下时间 然后点一下 export pcap
然后开始 export pcap 就这么简单
0x06 结束语
流量分析是一个比较复杂的系统工作,moloch在大规模的捕获数据包、索引方面做得相当卓越了。
在数据包的存取问题解决的情况下,随之而来的更多是数据包的分析:tcp的重传,mysql的慢查询,http的响应时间,这些可以从网络层面给业务带来红利的研究 值得大家去深挖研究。
欢迎有兴趣的小伙伴留言一起讨论。
往期文章
Exploiting Python PIL Module Command Execution Vulnerability
Eat.Hack.Sleep.Repeat - YSRC 第二期夏日安全之旅
Django的两个url跳转漏洞分析:CVE-2017-7233&7234
A BLACK PATH TOWARD THE SUN - HTTP Tunnel 工具简介