日志审计系统该过滤哪些流量？入口出口常弄反

采错了方向，日志采得越全反而越添乱。日志审计系统该过滤流量出口常弄反，这句话念着别扭，可它把现场最常见的状况说清楚了：规则写在入口侧，真正要盯的却是出口；或者反过来。方向一错，白名单越写越长，异常全在另一半网卡上躺着，翻日志到后半夜也找不出所以然。

日志审计系统该过滤流量出口常弄反，先弄清站在谁的位置看

采集点在哪，入口和出口的含义就跟着变。交换机镜像口上的 in/out 是相对端口说的，主机上 tcpdump -i eth0 的 in/out 是相对网卡说的，到了防火墙、NAT 设备、负载均衡，各有一套自己的定义。同一个数据包，在这三个位置能被贴上三种方向标签。所以别急着写过滤规则，先拿张纸把拓扑画一下：谁是谁的入口，谁是谁的出口，采集点站在哪一侧。图画不明白，规则写多细都是白费力气。

入口和出口，差的不是网卡名字而是体积

对外的 Web 服务，入口侧看到的多是请求，包小、频次高、字段短；出口侧看到的是响应，下载、视频、接口返回大 body，字节数能翻好几倍。审计要回答“谁在打我们”，就盯入口；要回答“数据往外流了多少”，就盯出口。这条弄反，报表曲线看着挺正常，真出事的时候一条能用的证据都拿不出来。

还有个细节，长连接和 HTTP/2 多路复用起来之后，同一个 TCP 会话里混着很多逻辑请求，按连接数统计会严重低估，得靠应用层日志补上。别指望网络层日志包打天下。

该过滤的几类噪声，减少掉再谈分析

第一类是组播和广播，224.0.0.0/4、255.255.255.255 这些；第二类 ARP；第三类是负载均衡的健康检查探针，隔几秒一次，量大又没信息量；第四类是内部监控自己的抓取；第五类是备份窗口里的整机同步；容器环境还得加上 pod 之间的心跳和 service 探针。

处理方式两种：采集端用 BPF 先筛，比如 tcpdump -i eth0 ‘not port 53 and not net 224.0.0.0/4’，省 I/O 也省磁盘；或者先全量入库，在解析阶段再过滤，好处是原始数据还在。预算够就分层，全量存短期、过滤后的存长期，两头都不亏。

白名单先写，黑名单后补，顺序别倒过来

不少团队一上手就是拉黑一批 IP，热闹两天，对面换个段又来了。稳一点的做法是先定义业务必需的五元组集合——源、目的、协议、端口、方向，白名单之外的先记下来，运行一段时间看噪声特征，再把确认无害的加进过滤名单。

反过来也要小心：别因为“吵”就一律过滤。SSH 爆破确实吵，但那恰恰是审计最该留的东西。判断标准不是音量大小，而是这条流量在出事的时候能不能当证据。

镜像口、单向流、NAT，三个把方向带歪的东西

SPAN 端口做聚合镜像时容易丢方向信息，有的交换机直接把双向揉成一路，事后看不出谁先发起。NetFlow、sFlow 这类单向流只报统计不报载荷，采样比一高就容易把抽样当全量，结论全靠猜。NAT 更典型：内网看到的源地址和公网出口看到的压根不是同一个人，得靠会话表或者时间戳把两边对上。

顺带一句，NTP 一定要统一。几台设备时间差那么几秒，串起来的链路就是错位的，排查的时候能让人怀疑人生。

保留周期和磁盘水位，别等写满才想起

日志平台最怕磁盘满。满了之后往往不是干脆停下来，而是开始丢最新的那一段——恰好是最该留的。周期怎么定，看合规要求和实际业务量，冷热分层是最省事的办法：近期全量，远期只留头部字段，五元组加时间和动作，够复盘就行。具体留存天数以服务商或官方页面说明为准，别照抄别人的配置。

上线前照着过一遍

几个检查项：采集点位置有没有标注清楚、方向的参照系写没写明白、噪声过滤规则有没有版本记录、白名单覆盖了哪些业务、NAT 和镜像场景谁负责还原、NTP 是否统一、磁盘水位告警阈值设了多少、过滤之后还剩多少写入量。这几条过一遍，大半方向问题能提前暴露。

方向这件事，画一次图就能定下来，比反复调规则省事得多。下次往审计系统里加规则之前，先问自己一句：这条规则是在哪台设备、哪个视角上生效的。答案说不清，就先别加。