网络监测预警

凌晨三点，网络某省政务云平台的监测流量监控大屏突然跳红。安全运维工程师李工被电话叫醒，网络屏幕上一条加密流量正以每秒数千次的监测频率向境外IP地址发送数据包——这不是攻击，是网络数据泄露。预案启动，监测防火墙策略下发，网络流量被阻断，监测前后耗时四分钟。网络事后溯源发现，监测攻击者早在两周前就利用某业务系统的网络一个低危漏洞植入了后门。

这四分钟背后，监测是网络过去五年国内网络安全建设投入的缩影。很多单位建了防火墙、监测买了态势感知平台、网络装了终端杀毒软件，但真正出事时，监测系统往往只给出“有异常”的提示，至于异常是什么、影响范围多大、该切哪台服务器——全凭运维人员的临场经验。说白了，大部分网络监测还停留在“看见”阶段，离“预警”差了十万八千里。

我见过一个真实的案例。某金融机构的监测系统每天产生两万多条告警，安全团队只有三个人，根本看不过来。他们索性把告警级别调高，只处理“严重”以上的，结果某次攻击恰恰伪装成了“中危”告警混了过去，数据被拖走几十GB才被发现。这哪是预警？这是事后验尸。

真正的预警，得能回答三个问题：发生了什么、意味着什么、该做什么。现在大多数系统只做到了第一点，甚至第一点都做得含糊。日志记录里堆着海量半结构化数据，规则引擎匹配的是已知攻击特征，对未知威胁基本抓瞎。有个做安全的朋友跟我吐槽：“我们买的设备，报警最多的不是攻击，是员工上班时间访问视频网站。”

问题出在哪儿？我个人的看法是，行业过度迷信“堆设备”了。硬件买齐、软件装全，就觉得高枕无忧。可网络环境是动态的，业务系统每两周迭代一次，新接口一个接一个上线，而监测策略往往半年才更新一回。规则跟不上变化，预警就成了空谈。

另一个被忽视的点是“人”的环节。再聪明的监测系统，最后都得靠人来决策和执行。但现在很多单位的告警处置流程是：一线工程师先看一遍，确认不是误报，再上报给组长，组长联系业务方确认影响，然后才能决定下一步动作。这套流程走下来，快则半小时，慢则半天——黄花菜都凉了。预警系统的响应速度，被组织流程拖成了龟速。

倒是有些小团队的做法值得借鉴。他们不买昂贵的商用平台，自己写脚本把关键业务日志、网络流量、身份认证记录汇总到一个消息队列里，用简单的统计模型做基线比对。一旦偏离基线，自动给值班人员手机发推送，推送里直接写了可能的攻击路径和处置建议。虽然简陋，但胜在快、准、贴合自身业务。有个创业公司的CTO告诉我，这套自研系统成本不到十万块，但已经帮他们拦下三次勒索软件尝试。

说到底，网络监测预警不是买来的，是长出来的。它得长在具体业务上，长在运维团队的日常习惯里。那些真正的预警信号，往往藏在被忽略的角落——比如凌晨两点某个老员工账号的异常登录，比如核心数据库突然多了一条查询记录。系统再高级，也得有人愿意在半夜被叫醒时多问一句：“这流量正常吗？”

(责任编辑：焦点)