在日常安全运营过程,常见的一个情景就是出现安全事件后,在调查时发现没有相关的日志可以用来分析溯源,对攻击路径进行还原。一是因为本来就没有开启相关的审计日志,或者是日志被攻击者删除。
作为SOC团队,一个关键的职能就是对企业网络环境中当前可用的所有类型的网络安全相关的日志数据进行收集和中心化地存储、分析。
一些日志来源类型的示例包括:
-
网络,包括网络基础设备及其承载的流量
-
软件(例如固件、操作系统和应用程序)
-
云环境,包括虚拟化和容器技术
-
技术管理解决方案(例如资产管理、配置管理、移动设备管理、补丁管理、漏洞管理)
-
身份验证和授权技术
-
威胁检测/防御技术(例如防恶意软件、数据丢失防护、电子邮件过滤)
下面我们将介绍一些常见的日志源的日志收集建议,供大家参考。
在Windows平台,建议收集如下日志:
日志源 | 日志位置 | 说明 |
Security log |
C:WindowsSystem32winevt LogsSecrurity.evtx |
记录与安全相关的事件,包括用户登录、权限更改、安全组更改等 |
Application log |
C:WindowsSystem32winevt LogsApplication.evtx |
包含应用程序生成的事件和错误,例如应用程序崩溃、服务启动、停止等。 |
System log |
C:WindowsSystem32winevt LogsSystem.evtx |
包含与操作系统相关的事件和错误,例如驱动程序加载、硬件故障等。 |
PowerShell log |
C:WindowsSystem32winevtLogsMicrosoftWindows PowerShellOperational.evtx |
PowerShell命令及脚本执行 |
WinRM log |
C:WindowsSystem32winevtLogsMicrosoft-Windows-WinRM%4Operational.evtx |
记录了Windows远程管理服务的相关操作日志。 |
AppLocker |
Microsoft-Windows-AppLocker%4MSI and Script.evtx, Microsoft-Windows-AppLocker%4EXE and DLL.evtx, Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx, Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx |
AppLocker相关的日志 |
Windows Defender |
Microsoft-Windows-Windows Defender%4Operational.evtx |
Windows Defender相关的日志 |
注:需要注意的是Windows日志比较复杂并且可能会随着时间发生变化。一些关键的日志可能默认未启用。这里我们的目标是提供基本的收集建议。要了解如何启用非默认的审计日志以及收集哪些事件ID的详细信息,请参考以下资源。
https://github.com/nsacyber/Event-Forwarding-Guidance/tree/master/Events
https://github.com/Yamato-Security/EnableWindowsLogSettings
对于针对域环境进行监测和分析的相关日志,我们会在【公益课程】Active Directory攻击与防御这门课程里面详细介绍。
在Linux平台,建议收集如下日志:
日志源 | 日志位置 | 说明 |
二进制登录日志 |
/var/run/utmp |
当前已登录的用户/会话。数据在系统关闭/重新启动时写入wtmp |
/var/log/wtmp |
历史 utmp 数据 | |
/var/log/btmp |
登录失败事件 | |
lastlog |
/var/log/ |
显示系统上用户的最后登录时间 |
授权和特权使用日志 |
/var/log/secure # Centos/RHEL /var/log/auth.log # Ubuntu |
包含用户登录和权限使用数据 |
Audit logs |
/var/log/audit/audit.log |
auditd创建,CentOS默认启用。audit守护进程主要记录两大类的事件:系统调用和文件活动 |
cron* |
/var/log |
包含计划任务的执行记录 |
全局System log |
/var/log/message # Centos/RHEL /var/log/syslog # Ubuntu |
这个文件包含系统启动期间记录的消息,包括来自 cron、auth、mail 等的数据 |
注:utmp位于/var/run而不是/var/log,在运行的系统上才有,而且一些日志采集方法可能采集不到这个文件的内容。
对于Linux rootkit安装,可以通过命令行审计进行检测:
insmod <module name>.ko
我们可以分析WEB应用日志来检测漏洞利用,Webshell,未授权访问或者其他的攻击活动。对于WEB应用,建议收集如下日志:
日志源 | 日志位置 | 说明 |
WEB访问日志 |
/var/log/apache2 /var/log/httpd <other App custom locations> |
包含对应用程序的所有访问日志,可能包括漏洞利用或 WebShell 访问日志。 |
系统管理日志 |
<Depends on application> |
包含用户或角色创建、删除相关的记录。 |
系统审计日志 |
<Depends on application> |
包含用户登录、添加、删除、查询、修改数据,以及系统配置修改等记录。 |
注:取决于应用设计,一些系统可能没有上述部分日志。
ESXi作为一个集权系统,深受攻击者尤其是勒索团伙偏爱,所以对ESXi主机的安全审计和加固也至关重要。对于ESXi主机,建议收集如下日志:
日志源 | 日志路径 | 说明 |
System messages |
/var/log/syslog.log |
包含所有常规的日志 |
Authentication |
/var/log/auth.log |
包含与本地系统身份验证相关的所有事件 |
Shell log |
/var/log/shell.log |
包含所有输入到 ESXi Shell 中的命令记录和 shell 事件 |
ESXi host agent log |
/var/log/hostd.log |
包含有关管理和配置 ESXi 主机及其虚拟机的 hostd agent的信息 |
vCenter Server agent log |
/var/log/vpxa.log | 包含与 vCenter Server 通信的agent的信息 |
VMKernel |
/var/log/vmkernel.log |
记录与虚拟机和 ESXi 相关的活动。 |
VMkernel warnings |
/var/log/vmksummary.log |
用于确定 ESXi 的运行时间和可用性统计 |
VMkernel warnings |
/var/log/vmkwarning.log |
记录和虚拟机相关的活动 |
注:ESXi 运行 syslog 服务,可以用于管理日志保留、轮换、拆分和将日志保存到远程服务器。
和ESXi类似,vCenter也是攻击者关注的高价值目标之一,建议对如下日志进行收集:
日志源 | 日志路径 | 说明 |
lastlog | /var/log | 用户账户最后一次登录系统 的时间 |
btmp | /var/log | 登录失败的日志 |
wtmp | /var/log | 登录的历史记录 |
Vpxd.og | /storage/log/vmware/vpxd | 主 vCenter Server 日志,包括所有 vSphere Client 和 Web 服务连接 |
websso.log |
/var/log/vmware/sso |
vSphere WEB门户登录的认证日志 |
message |
/var/log/vmware |
SSH登录 |
Postgresql-xx.log |
/var/log/vmware/vpostgres |
Postgresql日志 |
VIEvents |
vCenter portal->Monitor->Events |
vCenter Events |
对于防火墙、交换机这类设备,一般都支持通过Syslog直接发送日志,而Windows,或者Linux,可能需要专门的Agent对日志进行采集、过滤和发送,下面是一些开源的日志收集程序,大家可以作为参考。
-
NXLog:多平台的日志收集器,支持Windows,Linux等,地址-https://nxlog.co/
-
WinlogBeat:轻量型 Windows 事件日志采集器,支持基于事件ID进行过滤,地址- https://www.elastic.co/cn/beats/winlogbeat
-
Fluentd:是一个开源的日志收集器,由Treasure Data公司开发。Fluentd具有轻量级且高度可扩展的特点,可以在不同的环境中灵活部署,并支持多种数据源和输出格式。地址- https://www.fluentd.org/
-
Graylog:是一个开源的日志管理和分析平台,提供强大的搜索、分析和可视化功能,地址 - https://graylog.org/
-
...
因为相同数据源的部分日志可能对于安全监测和分析意义不大,我们可以在采集过程就过滤掉,以降低服务端的存储和检索压力,所以选择工具是否支持对日志数据进行过滤以及增强,也是需要的因素之一。
对于日志的收集、解析、中心化存储和检索,使用ELK栈问题也不大,国内的一些商业化产品可能还不如这些开源产品,所以大家根据自己的需求,选择最合适自己的即可。
本文并不是为了提供一个完整的列表,只是提供了一些常见的日志源的日志收集建议,大家可作为参考,作为一个起点。除了上面提到的日志,对于其他日志的收集,主要是两个考虑维度:
1)满足监管/合规要求
2)满足安全监测/分析需求
在收集了相关日志后,我们可以通过紫队评估的方式,对接入的日志质量和可用性进行检查。
此外,在应急响应过程,大家也可以参考这些信息,对相关的日志进行分析。
不足之处,希望大家多多包含和批评指正。
原文始发于微信公众号(Desync InfoSec):SOC日志收集建议
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论