要监控windows核心服务完整性，需聚焦system日志（如id 7036/7000）、security日志（如id 4670/4688）和application日志，结合xml筛选、nxlog过滤、visual syslog server汇聚，并通过非预期停止、启动失败链、账户篡改等规则触发告警，再联动prometheus指标与sysmon日志交叉验证。
要通过日志监控 windows 核心服务的完整性，关键不是泛泛查看所有日志，而是聚焦于能反映服务启动、停止、异常终止和权限变更的特定事件，并结合结构化筛选与自动化响应机制。visual syslog server 本身不直接采集 windows 事件日志（如 event log），但它可作为集中接收端，配合 windows 原生日志转发机制（如 windows event forwarding 或 nxlog）实现核心服务状态的可观测性。
定位核心服务的关键日志源
Windows 服务的生命周期行为主要记录在三类日志中：
- System 日志：记录服务控制管理器（SCM）操作，重点关注事件 ID 7036（服务状态变更，如“已启动”/“已停止”）、7000（服务启动失败）、7009（服务响应超时）
- Security 日志：反映服务账户权限变更，重点关注事件 ID 4670（权限修改）、4688（进程创建，含服务宿主进程如 svchost.exe 的子进程）、4697（计划任务创建，常被用于持久化）
- Application 日志：部分服务（如 SQL Server、IIS）会在此写入自身状态，需结合具体服务文档确认其关键事件 ID
配置精准筛选与实时捕获
避免信息过载，必须对原始日志做预处理：
- 使用 XML 筛选器 在 Windows 事件查看器或转发客户端中定义规则，例如只订阅 System 日志中 ID 为 7036 且服务名为 “Winmgmt” 或 “Dnscache” 的事件
- 若使用 Nxlog 采集，可在配置中添加
Exec if $EventID == 7036 and ($ServiceName == 'wuauserv' or $ServiceName == 'bits') drop(); else to_syslog();实现服务级过滤 - 在 Visual Syslog Server 中，利用其 IP 追踪 + 设施类型识别 功能，区分来自不同服务器（如 DC、SQL Server）的日志流，便于按角色归因
设置完整性告警规则
仅记录不够，需定义“异常模式”触发响应：
- 非预期停止：同一服务在 5 分钟内连续出现两次 7036（“已停止”）事件，且前一次状态为“正在运行”，触发邮件告警
- 启动失败链：7000（启动失败）后 10 秒内未出现 7036（已启动），且伴随 7010（依赖服务缺失），标记为高风险
-
账户篡改：Security 日志中 4670 事件目标对象为关键服务注册表项（如
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LSASS），立即高亮并保存至独立文件
关联分析提升可信度
单一事件易误报，需交叉验证：
- 将 Syslog 接收的 Windows 事件，与 Prometheus 通过 Windows Exporter 采集的
windows_service_state指标对比：若指标显示服务为 1（运行中），但日志却报告 7036 “已停止”，说明日志延迟或采集异常 - 检查 7036 事件中的 服务 SID 和 启动类型 字段，确认是否被人为改为“禁用”或“手动”，这比单纯看启停更反映完整性受损
- 对 LSASS、SAM、DnsCache 等核心服务，启用 Sysmon 规则（如 Sysmon Event ID 11 文件创建、ID 23 文件删除），与 Event Log 联动分析，识别无文件攻击或凭证转储痕迹
