Logster防火墙AI检测：5/5检出0误报

　　端点代理擅长看清一台机器上发生了什么。但大量攻击发生在机器与机器之间：扫描暴露的服务、漏洞利用落地、恶意软件下载、回连、数据外流。而网络里还有一堆永远不会装代理的东西——打印机、摄像头、家电、未纳管的笔记本，以及防火墙本身。

　　防火墙把这些全记下来了。每一个会话、每一次被拒绝的连接、每一次IPS命中、每一次管理员登录。问题从来不是缺数据，问题是数据太大、格式各家不同、噪音太多，所以大多数时候它只在事后被翻出来读，而不是在攻击进行时。

　　Logster过去几周在做的事，是把原本用于解释Windows和Linux端点攻击的AI检测，扩展到防火墙和流量日志上。它还没有正式开放，但已经能端到端跑通，团队想分享它如何工作、表现如何，以及过程中哪里出了故障。

　　它到底做什么

　　一句话概括：读取防火墙和路由器已经产生的日志，找出看起来像攻击的活动，并用平实的语言告诉你发生了什么、以及它为什么这么判断。

　　具体能力包括：摄入防火墙syslog和NetFlow/IPFIX，自动识别厂商，把每种格式转成统一的网络事件。FortiGate和Cisco ASA已在真实数据上测试，Palo Alto和Juniper的解析器还在推进中。

　　它看的是行为而不只是签名：扫描、漏洞利用、恶意软件下载、信标回连、异常数据量、隧道应用、暴力破解，以及对防火墙本身的篡改。每个判定都附带解释：攻击还是良性、置信度、按编号排列的攻击阶段叙述，以及对应的MITRE ATT&CK技术。

　　证据以图的形式呈现：谁和谁通信、走哪些端口和应用、双向各传了多少字节、会话如何结束（正常完成、重置、无响应、被拒绝），以及防火墙自己的IPS标记了什么。当网络告警和端点告警指向同一台机器时，两者会被关联起来。

　　为什么不能直接把日志丢给大模型

　　最朴素的做法是把每一行日志都送给大语言模型。这在真实网络里活不下来：一台繁忙的工作站几分钟内就能产生数千个会话。所以整条流水线是分层的，便宜且确定性的工作放在前面，AI只用在真正能增值的地方。

　　第一步是归一化。每家厂商说自己的方言：FortiGate说close、server-rst、ip-conn，Cisco ASA说TCP FINs、TCP Reset-I、SYN Timeout，NetFlow只给你TCP标志位。这些都被映射到一套很小的连接状态词汇上：正常关闭、已建立、客户端重置、服务端重置、无响应、超时、主动拒绝、策略拒绝、威胁阻断。

　　方向同样重要。每个事件都记录谁发起了会话、字节数属于哪一侧、两侧各在哪个区域，以及NAT转换，这样针对公网地址背后Web服务器的入站攻击，会被归到内网服务器而不是那个公网IP。

　　第二步是开窗。活动按IP地址分组，进入三分钟的滑动窗口，每30秒重新评估一次。防火墙管理员和配置事件则归到防火墙自身名下，对设备的篡改因此有独立判定。

　　第三步是用确定性信号做筛查。每个窗口跑一组快速、可解释的检查，每个信号有强度分级。完全没有信号的窗口记为良性，根本不会送到AI面前。测试中这类窗口占96%到98%，这正是AI网络检测在网络规模下成本可控的原因。

　　筛查本身也是风险：一个不触发任何信号的攻击永远不会被AI看到。所以他们对此做了度量——对测试数据里每一个有标注的攻击，追踪它的窗口有多少被筛查放行。后续要加的保障手段（把富余的AI预算花在已放行的窗口上、随机抽查、定期按主机复核）正是为了让筛查不能悄悄藏起东西。

　　第四步才轮到AI推理。有信号的窗口被压成一张紧凑的图：涉事主机、它的对端、带状态和应用与字节数的流边、IPS告警边。图和信号一起，配上网络场景专用的提示词交给AI。

　　下面是一条未经编辑的真实判定，对象是一台正在被攻击的Web服务器：外部主机进行了大范围漏洞扫描，扫描器随后成功投递了多个高危漏洞利用，包括Bash远程代码执行、PHP CGI参数注入和HTTP XXE，而这些全部被防火墙放行。

　　另一条来自一台恶意软件下载后几分钟的受感染工作站：该主机通过UDP端口6892和端口137对上万个外部IP发起大规模扫描，6892端口的流量被识别为Cerber僵尸网络，同时该主机新建了6421个外部对端连接。

　　第五步是守门。AI说“攻击”不算最终结论。一条告警还需要满足：要么有一个强信号，要么来自至少两个独立信号族。一条奇怪的连接永远不足以把人叫醒。

　　一次事件，两个视角

　　当端点代理标记了一台机器，防火墙又标记了这台机器的IP，这其实是同一起事件的两种视角。在多数安全运营中心里，把两者连起来意味着有人得手动去查那个时间点哪个主机占用了那个IP。

　　Logster自动完成这件事。它从端点自身的网络活动中学习哪台机器拥有哪个地址——一个出现在某主机大多数连接里的地址就是该主机的地址——并结合DHCP租约日志。当某个IP的网络告警到达时，它会被双向关联到该IP背后那台机器上尚未关闭的端点告警。

　　在一次真实风格感染的测试回放中，端点告警（“这台桌面的进程看起来可疑”）和网络告警（“这个IP下载了恶意软件，正在向互联网喷洒流量”）相隔24秒到达，并且已经作为一起事件关联好了。分析人员拿到的是并排的进程树和网络全景，不需要手动匹配任何东西。

　　性能与三个静默故障

　　他们搭了一套回放装置，把有标注的公开数据集推过完整的AI网络检测流水线——和生产环境跑的是同一套服务——并对检测率、首次告警时间、误报和AI成本打分。其中两个数据集完全留出，从未用于调参。

　　结果是：5个攻击全部检出，0误报，2%到4%的窗口被送到AI。需要说清楚这是什么：公开数据集，通过真实流水线回放。在真实网络上的验证是下一步，而暴力破解、横向移动、信标回连、数据外泄这几类检测虽然已经构建并做了单元测试，但尚未在真实数据集上得到验证，因为跑过的数据集里都不含这些攻击。

　　最可怕的bug是安静的那种：攻击就在日志里，什么都没报错，也什么都没被检出。回放装置找出了三个。

　　第一个，从未进入窗口的攻击。窗口按事件时间滑动。当日志到达速度快于窗口评估速度时（突发流量、重启后的积压），事件可能在任何东西看到它之前就滑出了窗口。在一次回放中，恶意软件下载本身就在被评估看到之前被裁掉了。修复方式是：网络窗口会保留事件，直到某个已评估的快照确实包含过它们，同时设硬上限防止无限增长。

　　第二个，“扫描”了网络的DNS服务器。NetFlow经常把一次会话的两个方向报成两条独立记录，判断哪一侧发起会话出奇地难。第一版从端口号猜测，结果立刻把一个代理和一台DNS服务器标成了端口扫描器：它们对数百个客户端的回复，看起来就像是对数百个主机的出站连接。修复靠分层证据：先看扫描特征的TCP标志，再看知名端口，再看每个端口被多少个不同对端使用，最后才做猜测。

　　第三个，倒着走的时钟。窗口会淘汰比“最新事件时间减去窗口长度”更旧的事件。如果设备时钟向后跳——比如NTP校正之后，或者两台时钟有偏差的设备上报了同一个IP——最新时间戳就卡在未来，每个新事件都显得太旧而被静默丢弃。只有等流量出现一段空闲才能恢复，而繁忙主机从不空闲。他们是在按日期倒序回放两个数据集时发现的：一台服务器对某个攻击给出了零判定，而这个攻击单独回放时检测得好好的。现在向后跳变会重启窗口，每个窗口长度最多一次，两台不同步的时钟无法让它反复抖动。

　　还有一个关于回放装置本身：有一段时间，“等流水线安静下来”这一步立即返回，因为一个查询错误被吞掉了。那次修复之前的所有数字都重新测过。如果你要搭评估装置，先测装置本身。以上每一个问题现在都有自动化测试钉住。

　　接下来

　　这条流水线今天已经能端到端运行。后续计划包括：仪表盘里的告警视图，把关联好的端点和网络事件放在一起展示；网络规则白名单，让已批准的扫描器、备份任务和管理主机保持安静；采集器与部署打包，以及在真实实验流量上的验证；更多厂商覆盖，以及暴力破解、横向移动、信标回连和数据外泄的真实场景验证；更精细的输出，包括对照ATT&CK目录核验技术编号，以及更丰富的图边（包数量、入站数据窃取检测）。

　　Logster起步于解释你的机器上发生了什么。接下来它要解释机器之间发生了什么，并在两种视角描述同一起攻击时告诉你。