一、“上传下达”
工欲善其事,必先利其器。安全团队对抗网络攻击,离不开趁手的工具。随着网络安全技术的发展,工具日趋专业化,针对每一类攻击,都有相应的防护检测工具。为了形成纵深防御,每个安全团队手里基本上都有一大把工具。为了应对某一个安全场景,往往需要多个工具配合使用。于是,如何统一管理,如何关联分析,如何有效感知安全态势,成为安全团队需要解决的主要矛盾。
尽管各类工具花样百出,但是从统一管理的角度,基本可以归纳为日志上收和策略下达两个通道,就像人体一样,眼耳鼻舌身接触信息,通过神经系统反馈至大脑,大脑进行判断,指导行为,如此,我们称之为“上传下达”信息通道。在“上传”过程中,将感知到的安全日志实时上传给后台统一接收、存储和分析;在“下达”过程中,将安全策略统一下发到各个安全设备并执行。
花开两朵,各表一枝,此次先说信息收集中的上传。一般来说,上传信息分两类,文体两开花,信息收集又分为网络流量侧和主机日志侧,限于篇幅和懒惰程度,此次尝试徒手搭建上传中网络流量监听并组建检索和检索平台(有的说法叫“泰式”感知)。
好处是免费,不花钱就能搭建自己的流量监听和检索(市面上动辄几十万设备费用先省了,搭起来看了再说),缺点是需要一定技术基础(但我都能行,你一定行的,咱们一步步来)。
let"s start...
二、Beats系列
对于日志统一接收、存储和分析,大家对于Elastic家族的ELK(ElasticSearch、Logstash、Kibana)产品组合比较熟悉。基于ELK,可以搭建一套日志管理平台,类似于SIEM。而对于前端探针,Elastic家族也提供了Beats系列,满足各种场景下的数据采集需求。详见官网:https://www.elastic.co/cn/products/beats
Filebeat:用于采集文件形式日志。
MetricBeat:用于监测操作系统运行性能指标。
Packetbeat:用于采集网络流量数据。
Winlogbeat:用于采集windows事件日志。
Auditbeat:用于采集Linux审计框架数据,以及各类主流操作系统文件完整性监测。
Heatbeat:用于监测运行的服务。
FunctionBeat:用于采集云服务数据。
可以看到,Beats系列已经形成了相对完善的体系,基本覆盖了运行监控的各方面需求。对于安全来说,通过适当的选型和组合,可以满足网络和端点两方面的安全监测需求。
(一)基础数据
如果只是采集相对原始的基础数据,那么直接选用相关组件就可以了:
网络:Packetbeat
端点:Winlogbeat(windows平台)+Auditbeat(Linux平台)
(二)安全日志
如果需要采集经过安全系统分析后的日志,那么就需要依赖Filebeat。比如,端点的HIDS选择OSQUERY,可以将OSQUERY的日志文件通过Filebeat发送给Elastic Search。
一般安全产品都会有多种日志输出方式,除了最基础的本地文件,一般还有Syslog、API甚至直接输出给Logstash等等。选择Filebeat的优势在于,一是避免了针对不同产品API接口的开发工作量;二是采集过程技术选型统一,易于后期维护。当然,对于不提供日志文件的安全产品(主要是商业产品),一般还是要采用Syslog+Logstash的解决方案。
三、网络流量采集及展现
本文主要探索基于Packetbeat和Elastic Search、Kibana,搭建网络流量监测系统。操作系统环境为CentOS 7。
(一)安装过程
1. 安装Elastic Search(存储和检索平台)
1.1 下载并安装Elastic Search:
curl -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-x86_64.rpm
rpm -ivh elasticsearch-7.1.1-x86_64.rpm
1.2 配置
1.2.1 修改配置文件elasticsearch.yml
vi /etc/elasticsearch/elasticsearch.yml
主要修改内容:
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["127.0.0.1", "[::1]"]
1.2.2 修改限制资源使用配置文件/etc/security/limits.conf
vi /etc/security/limits.conf
增加内容:
* soft nofile 65536
* hard nofile 65536
* soft nproc 4096
* hard nproc 4096
重启生效:
reboot
1.3 Elatic Search不允许以root权限运行。在安装过程中,已经添加了elasticsearch账户,查看/etc/passwd可以发现,该账户需要指定shell:
usermod -s /usr/bin/bash elasticsearch
1.4 运行Elastic Search:
首先切换账户
su elasticsearch
然后运行:
/usr/share/elasticsearch/bin/elasticsearch -d
启动后,退出即可:
exit
1.5 Web访问9200端口,查看Elastic Search运行状态:
curl http://127.0.0.1:9200
2. 安装Kibana(展现平台)
2.1 下载并安装Kibana
curl -O https://artifacts.elastic.co/downloads/kibana/kibana-7.1.1-x86_64.rpm
rpm -ivh kibana-7.1.1-x86_64.rpm
2.2 配置kibana.yml
vi /etc/kibana/kibana.yml
server.port: 5601
server.host: “0.0.0.0”
server.name: “Kibana”
elasticsearch.hosts: [“http://127.0.0.1:9200”]
i18n.locale: “zh-CN”
其中最后一条配置为使用中文界面,可能会导致部分页面出现告警提示(如已保存对象等),但不影响使用。
2.3 启动Kibana
service kibana start
2.4 访问Kibana
从终端打开浏览器访问http://IP:5601
2.4.1 Kibana启动需要几分钟时间。
2.4.2 CentOS需要配置防火墙入栈规则,允许外部访问5601端口。当然如果是内部测试环境也可以简单粗暴关闭防火墙:
systemctlstopfirewalld.service
3. 安装Packetbeat(网络流量收集平台)
3.1 下载并安装Packetbeat:
curl -O https://artifacts.elastic.co/downloads/elasticsearch/packetbeat-7.1.1-x86_64.rpm
rpm -ivh packetbeat-7.1.1-x86_64.rpm
3.2 配置packetbeat.yml
完整配置可以参照/etc/packetbeat/packetbeat.reference.yml。本文仅关注重点配置项。日志存储使用elasticsearch,展示分析使用kibana,不配置logstash。
vi /etc/packetbeat/packetbeat.yml
3.2.1
packetbeat.interfaces.device: any
配置监听的网卡,可以事先通过ip addr命令获取本机网卡信息并填写对应网卡名称。如果填写any则监听全部网卡。如果使用虚拟机部署,则需要将相应物理网卡桥接给虚拟机使用。
3.2.2
packetbeat.interfaces.with_vlans: true
如果镜像流量中存在vlan标识,则需要进行此配置,否则可能出现只记录flow信息而不解析网络协议的情况。
3.2.3 Transaction protocols中全部协议配置enable: true,并配置协议端口ports
3.2.4
setup.dashboards.enabled: true
3.2.5
setup.kibana:
host: “localhost:5601”
3.2.6output.elasticsearch:
hosts: [“localhost:9200”]
3.3 启动Packetbeat
service packetbeat start
是的,到了这里你的“泰式”感知雏形就建立起来了,是不是很简单。下面,就到了配置使用阶段了。
(二)使用
访问Kibana,在Discovery页面中,可以看到正在监听的网络流量,说明整套系统已经开始运行。
Kibana中已经建立了各种检索、视图和仪表盘模板。在Discovery->open,可以检索“packetbeat”,选择使用检索模板。在Visualize和Dashboard,可以直接检索“packetbeat”,选择使用视图和仪表盘模板。
在Discovery中,可以发现一次网络访问会出现两条以上的记录,type为flow或其他已配置网络协议类型,分别是网络连接记录和协议分析记录。对于安全溯源工作,比如排查木马外联(C2),flow记录有重要意义,可以结合威胁情报直接排查失陷情况。
(三)定制仪表盘
1. Web站点
根据实际工作场景,可以对模版进行定制。以Dashboard/[Packetbeat] HTTP ECS为例。仪表盘中有HTTP status codes for the top queries和Top 10 HTTP requests两个视图,都是针对具体的url进行统计。
网站应用页面目录复杂,所以在统计结果中出现了css文件、图片等等元素,对日常分析参考价值有限。相比之下,我们更关心对站点的访问。
点击edit,然后在具体视图上点击右上角图标,选择edit visualization,对视图进行修改。将Buckets->Filed中url.full修改为url.domain,可以对站点访问量进行统计。
2. Web访问
在Visualize/DNS Client and Servers Pie Chart [Packetbeat] ECS中,将Buckets下的两个Fileds分别修改成source.ip和url.domainl;双击Linked to Saved Search DNS Protocol [Packetbeat] ECS最右边的图标取消链接,并将filter中networ.protocol:dns修改为http。可以看到客户端访问站点的统计情况。
3. 重新布置仪表盘
在原Dashboard/[Packetbeat] HTTP ECS基础上,整合修改和新建的视图,可以获得相对实用的Web监控仪表盘。
4. 能够根据实际网络环境,比较方便地组合不同的统计条件并定制图表,是Elastic Search+Kibana的优势。比如在刚刚定制的Web访问视图基础上,我们可以增加一个筛选条件,将source.ip指定为某个已知攻击IP,就可以看到该地址对所有站点的探测情况。
(四)运行监控和配置
1. Stack Monitoring页面中,可以开启对Elastic Search和Kibana的监控,持续监测各种性能指标。
2. 在Management页面中,可以对Elastic Search和Kibana进行配置。
2.1 Elastic Search
2.1.1 Index Management
可以查看和操作当前索引。
2.1.2 Index Lifecycle Policies
可以对索引策略进行配置,如索引最大占用空间、最长周期、删除周期等等。可以根据实际硬盘情况和数据检索、存储需求进行配置。
2.2 Kibana
2.2.1 Saved Objects
可以对当前存储对象进行管理,包括已建立和保存的检索、视图和仪表盘等等。
四、小结
对于千兆带宽以内的一般场景,上述系统基本能够胜任。其基于开源的架构给安全团队在具体使用中带来很大的灵活性。但这套系统的限制和缺点在于:
1. 支持的协议不够全面。尤其是对邮件等重要协议支持有限,需要对Packetbeat进行定制开发。当然,由于邮件协议本身交互过程比较复杂,从流量入手效果不好,可以考虑通过邮件服务器日志解决。
2. Flow信息量有限。网络流量监测对安全最重要的意义在于溯源分析。Flow能够支持对于网络连接行为的追溯,但是进一步追溯传输内容就无能为力了。采集、存储和检索原始报文(pcap)需要大量资源投入。
做这个事情的意义就像开赛车,你是愿意动手从基础定制你的车以适应路况还是购买成品车后向车厂不断提出改进,想一千遍不如先做一遍,见仁见智。
给自己挖个坑:下一期写基于Filebeat的端点安全“全家桶”(上传部分的主机侧安装配置)。
作者简介:董祎铖 资深网络安全工程师,就职于中国人民银行金融信息中心信息安全部,国家注册信息安全专家(CISP),国家注册信息安全渗透测试专家(CISP-PTE),银行科技发展奖获得者。负责开展互联网安全防护体系建设和安全运营工作,专注于渗透测试、WEB安全、PKI/CA领域。
声明:本文来自仙人掌情报站,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。