把主动防御做成一条能日常跑的流水线

做安全的都听过「主动防御」这个词，但真正把它做成一条能日常跑的流水线，中间要填的坑比想象中多。

我去年把自己维护的一套检测链路重做了一遍，从「定期跑扫描」改成「持续采集 + 自动判断 + 人工确认」。跑了大半年，把有用的部分记下来。

先分清两件事：边界防御和主动防御

边界防御的思路是「堵」：防火墙、访问控制、补丁。它的假设是「外面是坏的，里面是好的」。

主动防御的假设正好相反：假设已经有人进来了。所以它要回答的不是「能不能进来」，而是「进来之后在干什么」。

这个转变带来一个直接后果——关注的对象从「端口和漏洞」变成「行为」。而行为数据量极大，这才是主动防御真正难的地方。

整条链路是三个环节

顺序不能乱，而且每个环节都有各自的翻车点：

很多人卡在第一步就放弃了，因为全量采集的量级很吓人。但真正的问题不在存储，而在第二步做不做得好。

采集：先想清楚要回答什么问题

我最初的做法是「能采的都采」，结果一周之后数据堆了几十 G，真出事的时候还是查不出来。

后来改成从问题倒推：

• 想知道「有人动了我的配置吗」→ 采文件变更，带哈希
• 想知道「有异常外连吗」→ 采网络连接，带进程归属
• 想知道「有账号被撞吗」→ 采登录失败序列，带来源 IP
• 想知道「有东西常驻了吗」→ 采开机自启与定时任务

改完之后数据量降了一半，可用性反而上去了。采集清单应该是一份问题清单，不是一份技术清单。

关联：误报的根源在这里

孤立地看，一条「凌晨三点有人登录」的日志什么都说明不了——可能真是运维在加班。

主动防御的价值在于把多件事串起来：凌晨登录 + 立刻改配置 + 随后建立外连。三件事单独看都正常，连成一条链就是事故。

我的做法是给每条事件打上「主体」标签（哪个账号、哪个进程、哪台机器），再按主体和时间窗口聚合。这样一来，判断的对象从「单条日志」变成「一段时间内某个主体的行为序列」，准确率提升很明显。

响应：绝对不能全自动

这是我最想强调的一条。

高危自动处置听起来很帅，但误杀一台生产机器的代价，可能比放过一次攻击更高。我见过因为自动封禁规则写错，把自己的运维通道封掉的事故。

我的分级是这样的：

• 只读类告警：记录，进日报
• 中危：阻断可疑外连，保留现场
• 高危：先隔离网络，但**隔离动作要人工点确认**

自动化可以推进到「准备好了处置方案」，最后按下去的那一下留给人。

三个我踩过的坑

坑一：没有基线就报警。 刚上线时把「出现新进程」当告警条件，结果每次系统更新都报一片。必须先跑两周只记录不报警，攒出正常基线。

坑二：告警不落责任。 没人负责看的告警等于没有。每条告警都要有明确的处理人和时限，否则一周之后就全是已读不回。

坑三：只做检测不做演练。 真出事那天手忙脚乱，多半是因为从没演练过。至少每季度按一条模拟剧本走一遍全流程。

说点实在的

主动防御不是买一套工具就有的事，它更像一件长期的基础设施：采集要持续、基线要维护、规则要调、演练要排。

如果团队刚开始做，我的建议是从最窄的一件事入手——先把「登录异常」这一路做扎实，跑顺了再扩到进程和网络。一次铺开，多半会因为告警太多而放弃。

本文不构成任何安全方案建议，具体部署请结合自身环境评估。