3、端点数据采集：Windows事件日志、Linux系统日志、macOS统一日志
聊到EDR，大家首先想到的可能是那些花里胡哨的检测规则、AI模型。但说句实在话，没有底层的数据采集，一切都是空中楼阁。我经常跟团队里的新人讲：数据采集的质量，直接决定了EDR的天花板。
今天咱们就掰开揉碎了，看看三大主流操作系统——Windows、Linux、macOS——它们到底是怎么把“端点上发生了什么”这件事记录下来的。
3.1 Windows事件日志：EDR的“金矿”
Windows事件日志，我个人认为是目前最成熟、最丰富的端点数据源。你想想看，从用户登录、进程创建、网络连接，到注册表修改、计划任务注册，几乎你能想到的所有安全相关行为，Windows都会留下日志。
3.1.1 核心日志通道
Windows事件日志主要分为几个通道，每个通道关注的重点不一样：
| 通道名称 | 日志文件路径 | 典型事件ID | 关注点 |
|---|---|---|---|
| System | %SystemRoot%\System32\winevt\Logs\System.evtx | 7045, 7036 | 服务安装、系统启动/关闭 |
| Security | %SystemRoot%\System32\winevt\Logs\Security.evtx | 4624, 4625, 4688, 4656 | 登录、进程创建、对象访问 |
| Application | %SystemRoot%\System32\winevt\Logs\Application.evtx | 11707, 11724 | 应用程序错误、安装 |
| Microsoft-Windows-Sysmon/Operational | %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx | 1, 3, 7, 8, 11 | 进程创建、网络连接、进程注入 |
这里我要特别提一下Sysmon。它虽然不是Windows原生的，但几乎是每个EDR工程师的标配。我记得有一次排查一个APT攻击，攻击者用了白加黑的手法，普通的进程创建日志（4688）根本看不出异常。但Sysmon的事件ID 1记录了进程的命令行、哈希、父进程信息，一对比就发现父进程是Office，子进程却是powershell.exe，而且命令行里还带了base64编码的payload。嗯，这就很可疑了。
3.1.2 关键事件ID详解
做EDR，有几个事件ID你必须烂熟于心：
- 4688（进程创建）：记录了谁启动了哪个进程，命令行是什么。这是检测恶意软件执行的基础。
- 4624（登录成功）：记录了登录类型、登录账户、源IP。横向移动的检测就靠它。
- 4656（对象访问）：记录了谁访问了哪个文件或注册表。勒索软件加密文件时，这个事件会大量出现。
- 7045（服务安装）：系统安装了一个新服务。很多后门会通过服务实现持久化。
重要提示：Windows默认的日志策略可能不会记录所有细节。比如4688事件，默认是不记录命令行的。你需要通过组策略或注册表开启“命令行进程创建”的审计。我曾经见过一个客户，部署了EDR但发现检测不到横向移动，排查了半天才发现是日志策略没开。
3.2 Linux系统日志：简洁但信息量巨大
Linux的日志系统，说白了就是“文件”。大部分日志都写在/var/log/目录下。虽然不像Windows那样有结构化的Event ID，但它的信息量一点不差。
3.2.1 核心日志文件
| 日志文件 | 守护进程/来源 | 典型内容 |
|---|---|---|
| /var/log/messages | syslog/rsyslog | 通用系统消息、内核日志 |
| /var/log/secure | sshd, sudo, login | 认证日志、sudo命令执行 |
| /var/log/audit/audit.log | auditd | 系统调用审计、文件访问 |
| /var/log/wtmp | login | 用户登录历史（二进制） |
我个人最看重的是/var/log/audit/audit.log。auditd是Linux原生的审计框架，它可以记录几乎任何系统调用。比如你想知道谁在什么时候执行了chmod 777 /etc/shadow，auditd就能告诉你。
3.2.2 配置auditd规则
默认的auditd规则可能不够用。我建议你至少加上这些：
# 监控关键文件变更
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/crontab -p wa -k cron_changes
# 监控用户执行sudo
-w /usr/bin/sudo -p x -k sudo_exec
# 监控网络连接（需要配合其他工具）
-a exit,always -S connect -S bind -S accept -k network_connections实战技巧：我曾经在应急响应中遇到一个挖矿木马，它通过修改/etc/ld.so.preload实现隐藏进程。普通的ps命令根本看不到。但auditd的-w /etc/ld.so.preload -p wa规则，直接捕获到了这个修改行为。嗯，这就是审计日志的价值。
3.3 macOS统一日志：苹果的“黑盒”
macOS的日志系统，说实话，早期是个噩梦。传统的/var/log/system.log信息有限，而且格式混乱。但从macOS 10.12（Sierra）开始，苹果引入了统一日志（Unified Logging），情况才好转。
3.3.1 统一日志的核心概念
统一日志把系统所有的日志都集中到了一个地方，通过log命令来查询。它的特点是：
- 高压缩率：日志以二进制格式存储，占用空间小。
- 隐私保护：默认情况下，某些敏感信息（如进程参数）会被隐藏。
- 实时流式：可以像
tail -f一样实时查看日志。
3.3.2 常用log命令
做macOS的EDR，你至少得会用这几个命令：
# 查看所有实时日志
log stream
# 查看最近1小时的进程创建事件
log show --predicate 'eventMessage contains "process" AND process == "kernel"' --last 1h
# 查看某个特定进程的日志
log show --predicate 'process == "Safari"' --info
# 查看所有与网络相关的日志
log show --predicate 'eventMessage contains "network"' --debug注意：macOS的隐私保护机制可能会让EDR采集不到完整的进程命令行。你需要通过配置System Policy Control或使用ESF（Endpoint Security Framework）来获取更详细的数据。我遇到过几次，因为隐私保护导致检测规则失效，最后不得不调整采集策略。
3.4 数据采集的通用挑战
不管是什么操作系统，数据采集都会遇到几个共性问题：
- 日志量太大：一台服务器一天可能产生几GB的日志。EDR需要做过滤和聚合。
- 日志格式不统一：Windows是XML，Linux是文本，macOS是二进制。EDR需要做归一化。
- 时间同步问题：如果端点时间不准，关联分析就会出错。我建议所有端点都开启NTP。
- 日志丢失：日志缓冲区满了怎么办？EDR需要设计可靠的传输机制。
3.5 本章小结
数据采集是EDR的基石。Windows的Event Log、Linux的auditd、macOS的Unified Logging，各有各的特点，但目标一致：把端点上发生的一切记录下来。我个人建议，在部署EDR之前，先花时间把日志策略调优好。否则，再牛的检测模型也白搭。
下面这张图，是我自己总结的三大操作系统数据采集的核心逻辑，你可以参考一下：