上周三凌晨两点十七分，公司监测系统弹出一条告警：财务部一台终端在十分钟内尝试连接境外IP的网络445端口，失败次数超过两百次。安全值班同事从床上爬起来，监测远程切断了那台机器的和处网络。第二天查清楚了，置情是公司员工装了盗版财务软件，里面捆绑了挖矿木马。网络这事不大，安全但足够说明问题——真正的监测威胁往往来自内部，来自那些看起来最普通的和处操作。

我们这套预警监测体系其实不算复杂。置情流量探针分布在核心交换机和出口路由上，公司终端Agent覆盖了百分之九十五的网络办公电脑。数据汇总到分析平台，安全规则引擎加威胁情报匹配，命中就触发告警。听起来挺标准，但实际跑起来，误报和漏报的平衡点特别难找。比如研发部门经常跑一些自动化脚本，扫描内网端口做测试，最初配置的规则一天能报三百多条，后来加了白名单和时段过滤才压下来。我的判断是，预警系统不是越灵敏越好，得跟业务节奏对齐，否则运维人员会陷入告警疲劳，真正的攻击反而被淹没。

处置流程分三级。低危事件——比如单次暴力破解尝试——系统自动封禁源IP半小时，同时发邮件通知管理员。中危事件——像上面说的挖矿木马——需要人工介入，先隔离终端，再取证分析，最后决定是重装还是清除。高危事件——数据外传或者横向移动迹象——直接触发应急响应，十五分钟内必须有人到岗。去年冬天有一次，销售总监的笔记本在咖啡厅连了公共WiFi，回来之后C2心跳包持续了四十分钟。我们通过EDR回溯发现，攻击者利用了一个Office漏洞，但没来得及提权就被切断了。那次之后，所有出差笔记本强制启用VPN分流，公共网络下禁止访问内网资源。

监测的难点不在技术，在人。员工总觉得安全是IT部门的事，直到自己的电脑被锁了才着急。上个月有个案例，行政同事收到一封伪装成“社保补贴申领”的邮件，附件是个带宏的Word文档。她点了启用内容，结果勒索软件开始加密共享盘。好在我们的备份策略比较激进——每小时增量备份，保留七天——恢复只用了二十分钟。事后我找她聊，她说“看着挺正规的，没多想”。这句话我听过太多次了。所以现在每季度搞一次钓鱼邮件演练，中招的人要去会议室看半小时安全视频。效果有，但别指望根治。

处置环节最怕的是信息不全。有一次告警显示某台服务器向外发送大量DNS请求，疑似隧道外传。查了半天，发现是运维同事在做DNS日志分析，脚本写错了循环条件。这种“自己人打自己人”的情况占了误报的三成左右。我的做法是，任何处置动作之前，先跟资产负责人确认最近有没有变更操作。没有确认就隔离，可能打断正常业务；确认了再动手，责任清晰，速度也快。

工具方面，我们用了开源的Suricata做流量检测，Wazuh做主机入侵检测，加上商业的威胁情报订阅。不是买不起全套商业方案，而是开源方案的可定制性更强。比如Suricata的规则，我可以根据内网的实际协议分布调整阈值，商业产品往往只给几个滑块让你拖。当然代价是维护成本高，每周要花半天时间更新规则和调优。但值得。

最后说一个观察：很多公司把预警监测当成一个项目来验收，上线了就完事。实际上它更像一个持续运营的服务。规则要跟着业务变，资产要跟着人员变，威胁要跟着行业变。上个月我们刚把一条老规则从“告警”降级为“记录”，因为那个漏洞三年前就没人用了，但每天还在产生几十条噪音。安全团队的时间应该花在真正有风险的地方，而不是给历史遗留问题擦屁股。