SOC日志收集实践：企业邮件服务日志收集

* 本文作者：xsecurity，本文属FreeBuf原创奖励计划，未经许可禁止转载

0x01.概要背景

这次我们举个接近实际生产的例子，来说明开源SOC系统如何采集数据，如果之前介绍系统是抽象的，现在就是实例具象的。平时我们利用日志系统收集了大量的各类的日志数据，如：Openresty访问日志、防护墙日志、VPN日志、邮件服务器相关日志、用户权限审计日志、路由器操作日志、甚至包括办公区AP的日志，DHCP日志。

这些不能一一列举，如果要选出一个比较典型的日志收集例子，企业邮件的日志收集可以作为例子。遍布国内相关业务城市，都有员工使用邮件服务，企业邮件服务是一种基础服务，在运营的过程中我们遇到用户相关各种问题的出现，不能第一时间取得更多用户一手的现场问题资料，通过分析用户日志，可以找出问题的发生当点，可能引起的问题根因。还可以得用日志系统数据：解决IP异地登陆检查，未备案设备暴力破解账号，账号被锁自动提醒，管理员操作审计等有之相关的功能操作，这一切都是建立在，构建日志收集系统前提下，如果没日志系统，这些数据和相应功能实现不了。

0x02.架构业务

我们整体上要理解业务架构和运作原理，才能有针对性的收集相关日志的数据，遇到问题时，可以通过有效的日志数据指导问题的解决。

一直以来都想找到一种比较好的表达方式来说明，企业邮件系统的构成，那种方式比较简单明了？找到了上面这种系统切面图方式，用2.5D的展示方法，展示从用户邮件客户端，到最后取得邮件的整个系统间的数据处理流程。如图所示，我们从整体上把系统交互分成6个切片，两次域名解析，两次负载均衡，并且第二次从mai_server.com解析到具体的邮件服务器时，可以不使用负载部署方案，使用DNS轮询的方式。如果采用负载的方式，一台机器挂掉也可以把流量负载到其它机器上，备机也可以正常工作，不受影响。如果使用域名轮询解析的方案，因为没有探活机制，需要在此之外建立报警机制，一定发现一台邮件服务器挂掉就要去掉到这机器的域名解析。mail_server.com在此处由一个内部的域名解析服务解析，邮件服务器可部署在公司机房，这种情况使用nat或是dr模式的负载均衡，可以缓解需要手动更改域名解析的尴尬，一旦出现问题不需要太多人工干预，这种根本机制上解决了服务的稳定性。

0x03.系统原理切片描述

我们简述一下这6个系统交互切片的含义。

第1层. 邮件客户端：用户收发邮件使用的邮件客户端程序。像Exchange这种邮件服务都支持针对PC端口和移动手机端的区分针对性配置。

第2层.域名解析：上面也说过，这个系统有两次负载均衡，有两次域名解析，问题是为什么有两个域名，mail_proxy.com和mail_server.com， mail_server.com是真正的邮件服务器的域名，在内网中可以直接访问，在某些场景下，我们希望在外网的员工也可以访问邮件服务，这时我们就用一个基于Openresty的代理服务，部署内网邮件服务的代理系统，将外网域名反代指向内网的mail_server.com。出于安全考虑，我们在服务器上添加了的用户设备ID的限制，让那些没有在册的设备不可以直接通过mail_proxy.com，这个代理访问内网的mail_server.com域名进行邮件收发。并且一旦手机发生丢失的情况下，去掉丢失自己的设备ID授权，被盗手机有用户名和密码，也不能正常使用邮箱服务，并且我们还可在代理服务器上限速，限制附件大小。这些的出发点都是为了安全出发。

第3层.mail_proxy.com的vip负载均衡：为了多点备份，我们在解析mail_proxy.com时，对应解析了三个机房的VIP，三个机房对应三个不同运营商的线路，优化线路后，让用户的访问效率更高。然后把对应运营商线路的请求负载到3台不同的邮件代服务器上，三台机器，其中一两台服务器挂掉，也不会影响邮件代理的整体运作服务。

第4层.mail_server.com域名解析：前三层的服务并没用直正的涉及到邮件服务器的核心服务器，从各个域名解析mail_server.com开始，下面都是邮件服务相关的服务，从mail_server.com解析到真实的邮件服务器有两种方式，如上所述，第一种是域名解析轮询，另一种就是加负载均衡层。

第5层.邮件负载均衡与邮件真实服务器：如果我在内网机房，使用基于tcp协议的负载均衡，一旦遇到机房或是服务本身的原因造成一台服务断掉也不会影响整体邮件服务。

第6层.邮件：经过前面阶段的处理才能到真实地的邮件，其实还有更深的一层交互没有在图上画出来就是附件服务器，正常的邮件服务，还会配置2或是3台邮件附件服务。

0x04.关键的日志数据收集

在整个系统的层次上，很多服务器都会相应的产生日志数据，刨除负载均衡的日志数据，我们真正关心的是真实服务器的产生的日志(Real Server)，这些日志的收集才能完成最开始概要里所的那些功能：

1.邮件代理服务器日志：代理服务器使用的是基于Openresty的反向代量服务器。其中最主要的日志，其实就是WEB访问日志。

日志形式：形式上可以是标准文本格式，也可以是JSON格式。

log_format accessjson escape=json ‘{“source”:”192.168.0.8″, “ip”:”$remote_addr”,”user”:”$remote_user”,”time_local”:”$time_local”,”statuscode”:$status,”bytes_sent”:$bytes_sent,”http_referer”:”$http_referer”,”http_user_agent”:”$http_user_agent”,”request_uri”:”$request_uri”,”request_time”:$request_time,”gzip_ration”:”$gzip_ratio”,”query_string”:”$query_string”}’;

日志协议：可以使用syslog协议直接发送JSON形式的日志到syslog服务器，也可以通过catkafka将JSON文体推送到Kafka队列上。

syslog方式：

access_log syslog:server=192.168.0.8:10001;

catkafka方式发送：

tail -F -q access-json.log | kafkacat -b 1.kafka1.yqfy.net:9091,2.kafka1.yqfy.net:9091,3.kafka1.yqfy.net:9091,4.kafka1.yqfy.net:9091 -t candylab_topic

2.邮件服务器日志：邮件服务的日志种类相对就比较多了，1.Exchange IIS日志。2.Exchange Server系统日志。3. IMAP邮件协议日志。4.POP3邮件协议日志。5.管理员审计日志。

因为邮件服务器是基于Windows的，所以我们有一种日志发送方案是使用nxlog发送客户端代理服务，把邮件服务器上系统日志和文本文件日志发送到syslog服务器上。

典型nxlog发送文本日志配置举例，以下：

<Extension _syslog>
Module      xm_syslog
</Extension>
<Input in>
Module    im_file 
file    'C:\\rlog\\*.log'
SavePos    TRUE
</Input>
<Output out>
Module      om_udp
Host        192.168.0.8
Port        10001
Exec parse_syslog(); 
</Output>
<Route 1>
Path        in => out
</Route>

0x05.日志的收集与转存

之前我们说的都是系统构成和日志的普通形式的存储，而这次比较特别的是，我们将日志通过nxlog这种syslog日志发送代理发送数据到syslog server，再由syslog server转发到graylog的syslog udp监听。再由Graylog收集发送过来的文本存到ES中，因为ES的索引是有生命周期的，可以指定邮件日志的存活时间，比如说某个指定时间长度，然后数据被挥发掉，释放出来的空间存放新的日志。但同时，当Graylog收到日志的同时，通过Graylog Kafka的Output插件，可以把数据复制转发到Kafka上，然后由Kafka消费者程序，消费这些日志数据复制一份到Clickhouse中，只要服务运转良好，没人天灾人祸，服务不被莫名重装、机房空调温度不过高、Raid硬盘不坏，网络不抖，数据就会安然的保存住。

1.SyslogNG服务器：Syslog服务器在那种数据需要落地，并且数据需要转发的场景，是必选服务，Graylog也可以打开udp监听，但不会保存文本文件到本地，直接存到了es里。

2.Graylog服务：如果说Superset是Clickhouse的灵魂伴侣，Graylog也是ES一个很好应用，Graylog可以轻松开启各种数据监听服务，当然也包括UDP Syslog日志监听。并且，Graylog是内置了Kafka队列和MongoDB，简化了ELK系统的构件成本。

3.Kafka队列：当数据量特别大的时候，用队列缓存数据（Queue），上图的Kafka，其实是为Clickhouse写入数据服务的，我们用Graylog把日志数据推到Kafka上，相当于把到Graylog里的日志数据，复制ClickHouse上一份，只是这个存的动作，是由后续的消费程序插入数据完成的，Clickhouse里的日志数据可以存的时间较长，SQL聚合的效率也更高。

4.Clickhouse数据库：ClickHouse的效率强大的令人发指，我们可以用Clickhouse操作上亿的数据量。

0x06.如何拿到数据

之前介绍都是，如何把邮件代理的数据存到Graylog和Clichouse里，后续的操作就是针对数据的分析操作。

1.数据输入处理：对于我们的分析模块程序来说，有两个强大的数据源，Graylog和Clickhouse， Graylog提供REST查询服务，Clickhouse提供多种访问驱动，python,java,c++，go的数据驱动都有。

2.黑白名单处理：这个是业务处理，我们在同时的威胁情报处理中，一定会遇到很多的误盼和数据噪音，使用黑白名单机制可以改善噪音对我们的影响。对于企业邮箱的日志服务来说，最重要的白名单管理，其实是在nginx中，对特定用户设备的限制管理，这个和本文无关，不表。

3.威胁检查：核心威胁分析策略模块（略）。如果邮箱服务，可以通过数据分析，分析出账号被锁用户是谁，正在爆破邮箱的人谁，密码错误，恶意提交访问请是谁，等等操作。

最近，当我们面临DDOS攻击时，基于Clickhouse构建监控分析策略，可以敏捷的应临时监控统计需求，只要前期有数据，构建分析策略速度经人。

而Clickhouse操作其数据很简单，以下举例，具体复杂度看后续需求。

docker客户端：

docker run -it –rm yandex/clickhouse-client -h yqfy.net –port 9006 -m -u yqfy–password nicaishisha -d yqfy

Python客户端：

from clickhouse_driver import Client
client = Client(host='yqfy.net', port=9006, user='yqfy', database='yqfy',password='nicaishisha')
client.execute('INSERT INTO threat_table (date,hour,ts,src_ip,src_port,dst_ip,dst_port,threat,level,type,payloads,message) VALUES', threat_infos)

新版的Clickhouse加入了更强大的功能，而我们驱动如此大的数据库引擎，只需要区区几行代码，大大的提高安全人员的生产率。

4.数据输出处理：我们可以通过syslog协议和Clickhouse，对经过处理的数据，再转存回去。并且，有很多可视化软件和BI处理程序对数据源数据进行分析和展示。

0x07.总结

上文介绍的内容中，关于服务器负载均衡、WEB服务器与客户端数据采集、ES到Clickhouse迁移数据，这些都可以到Freebuf中找到更具体的文章。至此，不同以住，我们介绍了更真实的日志存储的案例。生产环境中，我们存储了海量的日志数据，用邮件的例子是因为邮件的业务相对好理解，不涉及到更多的术语业务，而关于数据Agent分类及部署方式。Graylog的高级使用技巧，Clickhouse聚合数据，这些软件实际操作使用，后续介绍，那些让人意想不到飘逸操作，让数据分析更高效，强大的工具将我们从繁重的脑力劳动中解救出来，这也是我们可以战胜普通猿人以及北京猿人，成为智人的原因之一，放弃香蕉，从树上下来，我们学会了使用工具。

* 本文作者：xsecurity，本文属FreeBuf原创奖励计划，未经许可禁止转载

来源：freebuf.com 2018-06-15 08:30:03 by: xsecurity

文章版权归作者所有，未经允许请勿转载。

THE END