凌晨3点47分:一次开源SOC技术栈真实拦截入侵的全过程

大多数关于SOC的内容都在讲架构,这篇文章要讲的是一次真实发生的安全事件——在为一家中型企业客户运行的生产环境技术栈上,逐条告警地还原整个过程。检测层用Wazuh,案件管理用DFIR-IRIS,两者之间由自研的FastAPI集成服务连接。没有SaaS授权费,没有云端SIEM账单,每一个组件要么是开源的,要么是自己开发的。

客户特定信息已做泛化处理以保护机密,但检测逻辑、时间线和系统行为均为真实记录。

如果想先了解完整架构,我们之前已经单独写过:逐次提交记录还原的技术栈搭建过程,以及simpliSOC完整监控范围说明。这篇文章讲的是这套系统真正"值守"时发生了什么。

凌晨3点47分 —— 第一条告警

财务部门的一个账号在VPN集中器上登录成功。单看这条事件并不异常——远程办公意味着非工作时间登录未必就是可疑信号。Wazuh的身份规则集记录下这条事件,给出较低的风险评分,继续放行。

凌晨3点52分 —— 第二次登录,跨越半个地球

五分钟后,同一账号再次完成认证——这次来自一个住宅IP段,与第一次登录的地理位置相距约9000公里。单独看任何一次登录,大多数SOC都不会警觉。但两次放在一起,在物理上是不可能实现的。

这正是无状态规则引擎的天花板所在。Wazuh可以将"从新位置登录"标记为一条独立事件,但它不记得五分钟前的那次登录,也没有办法计算两者之间的距离与时间差。这个关联逻辑放在集成层:一个基于PostgreSQL的后台worker持续追踪每个用户最近的认证事件,并用haversine公式计算距离,再与经过的时间比对。任何一对需要超过商业航班速度才能完成的登录组合都会被自动标记——不需要分析师用肉眼发现这个模式。

关联引擎自动在DFIR-IRIS中开立案件,严重级别:严重(Critical),SLA计时开始:1小时内必须首次响应。

凌晨3点53分 —— 在人工介入前就完成的情报补充

案件出现在分析师队列时,上下文信息已经附加完毕。集成层的情报补充worker在后台已将第二次登录的来源IP提交给VirusTotal和AbuseIPDB查询——这个IP命中了三个社区黑名单,且与此前的撞库攻击(credential stuffing)存在关联。这个置信度评分作为结构化字段直接写入案件记录,而不是埋在一段需要分析师自己去翻找的文字里。

这一点比听起来更重要。在许多SOC体系中,情报补充发生在分诊之后,或者需要分析师切换到另一个工具查证。而在这里,由于IOC情报补充是异步执行、与告警创建并行运行的,这一步在案件到达人工之前就已经完成。

凌晨3点58分 —— 没有淹没队列的告警

接下来四分钟内,同一来源IP又尝试登录另外两个账号——均失败。按常规,每一次都会各自生成一条告警。如果没有去重机制,这正是让分析师逐渐忽视告警队列的典型模式:同一起底层事件产生三条相关告警,每条都要求单独处理。

集成层的去重worker利用按规则设置的冷却窗口,将这些事件归并到原始案件中——针对凭证盗用模式,系统按用户/主机设置了专属窗口,这个窗口是根据生产环境的真实告警量调优得出的,而非凭空猜测。最终结果是:一个案件、一条SLA计时线、三条数据点,而不是三条独立告警。

凌晨4点04分 —— 分析师接手处理

值班分析师通过PagerDuty收到寻呼——严重级别会自动路由到这里。打开IRIS案件后,分析师能在同一个界面看到:两次登录事件、地理位置计算结果、情报补充结果、对应的MITRE ATT&CK映射(T1078——有效账户滥用),以及从YAML加载的、针对该规则的专属分诊清单,而不必在凌晨4点凭记忆临时拼凑处置步骤。

账号被禁用,财务部门收到通知,会话令牌被撤销。从第二次登录到完成遏制,总耗时23分钟——落在1小时的严重级别SLA之内,进度条仍显示绿色。

凌晨4点31分 —— 闭环

这是很多技术栈容易省略的一步。分析师在IRIS中确认了这起案件——但如果关联确认仅停留在案件管理工具里,这只能算完成了一半的检测。集成层会向Wazuh回发一条syslog消息,把已确认的事件登记回SIEM本身。此时两个系统的记录才达成一致:这次关联不只是被调查过,而是被检测层真正记住了,今后会持续监视该账号是否出现同样的模式。

如果没有这套集成层会怎样

去掉关联引擎,这起事件会变成两条看似无关、严重级别较低的告警,分别躺在不同的队列里——很可能被逐条分诊后以"用户输入错误、VPN客户端缓存了旧位置"为由分别关闭,没有人会把两者联系起来。

去掉去重机制,告警数量会从两条变成五条,其中三条是对同一事件的重复记录,进一步加重告警疲劳,让真正的信号更难被发现。

去掉情报补充worker,分析师就要手动打开另一个标签页去查VirusTotal——每一次人工切换上下文,23分钟的遏制窗口都会被进一步拉长。

单独看,这些组件没有一个是特别新奇的技术。真正带来差异的,是它们被打通在一起,并且在人工介入之前就已经运行。

这套技术栈背后的数字

指标	数值
自定义检测规则	95条,覆盖8个类别
告警同步周期(Wazuh → IRIS)	每5秒一次
IOC列表刷新周期	每4小时一次
关联状态存储	基于PostgreSQL持久化
严重事件SLA	1小时内首次响应
本次事件:检测到遏制耗时	23分钟
部署方式	100%本地部署,不依赖云端

为什么这样设计

这套技术栈里的每一条检测规则都以两个版本发布:一个是基于合成测试数据触发的模拟规则,另一个是针对真实事件字段调优的生产规则。正因为有这样的配对,上文提到的关联逻辑早在监视任何真实登录之前,就已经在测试环境中完成了验证——凌晨3点52分的这条告警,并不是这条规则第一次被触发,而是它第一次真正产生了意义。

这也是为什么这套系统以独立的FastAPI服务运行,而不是依赖Wazuh内置的active-response脚本:关联逻辑需要在多个事件之间维持持久状态,情报补充需要异步执行、不能阻塞告警创建,而在这次事件之后调整阈值时,每一个决策都需要能通过REST接口被完整重放和验证。

对于需要满足等保2.0(尤其是涉及OT/工控系统场景)、《数据安全法》及PIPL要求的企业而言,日志与事件响应记录留存在境内本地基础设施上,而非境外云端SIEM,这让向监管部门报送和接受审计的流程都更加直接。

常见问题

这是真实发生的事件,还是演示场景?
检测逻辑、时间线和系统行为均取自真实生产环境。为保护机密,能够识别客户身份的信息已做泛化处理。

这套系统能检测凭证盗用之外的攻击吗?
可以——同一个关联引擎采用相同的持久化状态方法,同样能处理横向移动和权限提升类的攻击模式;凭证盗用只是最便于完整讲清整个流程的一个例子。

在我们自己的环境中部署这样一套系统需要什么条件?
这取决于现有的日志来源和合规要求。最快的了解方式,是让我们用一个接近贵司实际情况的场景演示给您看。

这套系统会取代我们现有的防火墙或终端安全工具吗?
不会。这套技术栈会接入贵司现有的边界和终端日志来源(防火墙syslog、Windows AD、Sysmon、虚拟化平台日志)——它是叠加在这些数据之上的检测、关联与案件管理层,而不是替代现有的日志采集体系。

亲眼看看这套技术栈如何拦截真实场景

读到"23分钟完成遏制"是一回事,亲眼看到关联引擎实时标记异常、IRIS案件自动生成、闭环回写到Wazuh,是另一回事。欢迎预约演示,我们会基于贵司实际的日志来源、合规要求和告警量,演示一个贴近您真实环境的场景。

hello@simplico.net

相关服务