安全审计里的流量分析可能是最容易被低估的一项工作。很多人一听“系统安全审计”脑子里先想到的是日志审计、漏洞扫描、基线核查流量分析往往被放在最后甚至干脆交给抓包工具跑一跑就完事。但真正常态化做过审计的人会告诉你基本网络流量分析恰恰是发现问题最快、定位最准的手段因为它不依赖主机上的日志是否完整也不依赖 Agent 是否装到位直接看网络上的实际行为就够了。这篇文章我打算把它们整理成一份能直接照着做的操作笔记。1. 流量分析在安全审计里的定位1.1 为什么审计不能只盯日志以前做过一个模拟项目X的安全审计当时目标系统的主机日志策略配置得不太合理很多关键操作没有记录到或者被日志轮转覆盖掉了单靠日志审计几乎推不出完整的攻击链路。后来切换思路在网络接入层做了一段时间的流量采集反而把问题链条补全了。原因不难理解日志是主机视角流量是网络视角。主机日志再全也只是这台机器“认为自己发生了什么”而流量是客观存在的数据报文无论中间发生了什么篡改、绕过、伪造报文本身不会说谎。审计里最怕的就是各说各话主机说没发生网络侧却有实质连接记录这时候流量分析的价值就出来了。所以做系统安全审计我现在的习惯是默认把“主机日志 流量记录”双轨并行。流量不一定要全量留存但至少要保证关键网段、关键服务的会话能落下来方便审计周期内回溯。1.2 基本流量分析能回答什么问题“基本”这两个字很容易被误解成“简单”其实它指的是分析对象和分析深度是基础层面的但能回答的问题一点不少。我在实际审计中基本流量分析至少能覆盖四类问题谁在访问谁源 IP、目标 IP、端口、协议这些最基本的信息能快速还原出一张通信关系图哪些资产在对外访问哪些资产被外部访问一目了然。访问是否合规比如数据库端口是否只对应用服务器开放运维终端是否在非工作时间批量连接服务器这些通过流量会话就能判断。是否存在可疑行为模式频繁的连接尝试、长时间的大流量传输、异常的端口扫描特征、非标准的协议行为这些即使不做深度检测靠统计特征也能发现苗头。恶意软件或入侵行为有无痕迹常见的 C2 通信、木马回连、数据外传往往在流量上有固定特征基本流量分析能做初步筛查。1.3 明确审计边界做基本流量分析一定要先明确边界否则很容易陷入“深度包检测”“全流量回溯”这种大工程里出不来回。我的做法是以会话和元数据为主以载荷分析为辅。也就是说重点看五元组信息、会话时长、流量大小、连接频率、协议类型只有在发现明确可疑行为时才会针对性提取数据包做深度解析。换句话说基本流量分析的目标是“发现可疑”而不是“证明入侵”。如果分析过程中发现某段流量高度可疑再去升级到全流量取证这样既控制成本又不会漏掉关键线索。审计不是做研究是要在有限时间里得出可执行的结论。2. 审计前必须摸清的静态资产底数2.1 穷举内网 IP 网段做流量分析之前先得有一份相对完整的 IP 资产清单。不然打开流量分析工具满屏都是不认识的主机你根本不知道哪些是正常的哪些是异常的。网络扫描可以帮你把网段摸清楚但注意做扫描前要确认好边界范围避免造成不必要的网络影响。我当时主要做了两类操作主动探测用 ICMP、ARP 请求探测存活主机再配合端口扫描确认开放服务。被动监听在交换机的镜像端口上纯被动收取一段时间的流量从实际报文中提取所有出现过的 IP。被动监听的效果往往比主动探测更好因为实际流量里出现的 IP 一定是“活跃的”不存在扫描盲区。但被动监听需要时间窗口通常要放 24 到 72 小时才能覆盖工作日和非工作日的差异。2.2 梳理端口和服务清单IP 清单出来之后逐个端口扫描然后手工整理一份“IP 开放端口 服务程序”清单。这个过程看着繁琐但审计效率的提升非常明显。比如我在某次审计中发现一台 Windows 服务器开放了 3389但管理文档里完全没有登记顺着这份清单一查发现是一台被遗忘的测试机而且存在弱口令问题。服务清单的价值不仅在于找问题更在于建立“正常基线”。流量分析时看到某个端口有连接先跟清单比对能对上的先放一边对不上的单独拿出来查效率翻倍。2.3 跨部门确认资产归属技术手段能拿到 IP 和端口但拿不到“这台机器是谁的、干什么用的”。所以我会把技术扫描的结果整理成表格发给各系统负责人确认归属。这一步不能省因为基本流量分析判断“是否异常”时很多时候要依赖业务语义数据库服务器在凌晨被访问如果它是备份系统那正常如果它只是订单库那就要警惕了。资产归属确认表一般包含IP 地址、所属系统、负责人、开放端口及用途、是否允许外联。拿到这份表后续流量分析才算有了“参照物”。3. 工具选型与部署位置选择3.1 常见工具组合基本流量分析的工具不需要很复杂关键是顺手、可控。我用过的组合里有两套比较省心轻量组合抓包工具 命令行工具。适合单机或小规模网段分析灵活快速能直接上手分析。中量级组合流量分析平台。支持持续采集、自动归类、可视化展示适合有一定规模的内网环境分析效率高很多。有读者可能会问直接用 Wireshark 看包不行吗说实话审计场景下 Wireshark 更适合做单包深度分析不适合做大范围会话梳理。几百 MB 的抓包文件打开一次要卡半天过滤条件要手写一堆效率太差。工具选型的核心是匹配场景小范围定性分析用轻量组合大规模基线对比用平台。3.2 采集位置决定数据质量同样一份流量采集位置不同分析结果可能是两回事。我在审计中通常选择三个位置之一核心交换机镜像端口能看到南北向和东西向的大部分流量适合全局审计。缺点是大流量场景下可能丢包需要关注端口利用率。边界出口镜像只能看到跨边界流量适合分析外联行为、数据外传但看不到内网横向移动。重点服务器前置端口专盯关键业务服务器的进出流量精度高成本低适合目标明确的审计。如果资源允许我会在边界和核心各放一个采集点。边界流量用于发现外联和异常出站核心流量用于分析内部横向移动两者互补覆盖面才完整。3.3 元数据留存策略基本流量分析的原始材料是抓包文件但没必要把所有 PCAP 都存下来成本太高。我推荐的做法是原始包按需留存元数据全量留存。也就是说通过流量分析平台把每一个会话的五元组、开始时间、结束时间、上下行流量、协议类型提取出来存成结构化的会话日志原始 PCAP 只在发现可疑会话时针对性保存。这样做的优势很明显日常审计查会话日志秒级出结果需要深入分析时再提取对应的原始包。审计结束后如果需要出具报告会话日志也足够支撑绝大部分结论。4. 基本流量分析的核心实操步骤4.1 第一步建立正常通信基线拿到流量数据后不要急着找异常先建基线。基线的意思就是在这个网络环境里“日常”长什么样。我从三个维度统计协议分布内网平时跑得最多的是 HTTP、HTTPS、DNS、数据库协议各自占比多少如果某天突然出现大量 SSH 或 FTP 流量本身就值得注意。会话节奏每日会话峰值时段在哪不同业务系统的活跃时间窗口是什么比如 OA 系统集中在工作时间备份系统在凌晨这些是规律性的可以沉淀成基线。外联目标内网主机平时会访问哪些外部 IP把经常出现的目标 IP 做成白名单剩下的逐一排查能省掉大量无效分析。基线不需要一开始就很精确先粗后细跑几天数据再修正。我在审计中会把基线做成表格后续每看一条新流量先跟基线对比命中基线的直接跳过偏离基线的单独列出来。4.2 第二步从会话数据中筛查异常会话基线建好后开始筛查。基本流量分析里效率最高的做法是先把所有会话导出来做成一张大表然后用各种排序和过滤条件反复刷。我常用的筛查维度有连接频率异常某个 IP 在短时间内向大量目标 IP 发起连接这是典型的扫描行为。同一源 IP 同一目标端口高频连接可能是暴力破解。流量大小异常某个会话上下行流量明显超出日常范围尤其是出站流量突增要重点查是不是数据外传。非工作时间活跃凌晨 2 点突然有运维终端批量连接服务器这个行为本身不一定是恶意的但必须查清楚原因。目标端口罕见内网机器访问外网的 443、80 很正常但如果访问外网的 21、22、3389就要高度警惕。筛查异常会话时我会始终问自己这个连接是否符合业务需要如果不符合管理员是否知道不知道的连接就是潜在风险点。4.3 第三步重点协议深度解析会话筛查能发现“谁在连谁”但要判断“连上去干了什么”还需要对关键协议做深度解析。基本流量分析阶段不需要所有协议都深挖重点抓几类DNS 查询内网主机都在解析哪些域名是否有疑似随机域名、高频率域名解析DNS 隧道行为往往以大量 TXT 记录查询为特征值得单列观察。HTTP 请求重点关注异常 UA、非常规路径、隐藏的隧道流量。审计中我习惯把 HTTP 请求的 URL 全部提取出来按访问频次排序然后筛掉正常业务路径剩下的逐条审视。数据库协议数据库连接来源、目标库、执行语句类型这些信息能从协议层解析出来。遇到大批量数据导出语句必须标记为高风险行为。这里要注意深度解析不等于全量分析。我一般只针对可疑会话提取原始包用抓包工具逐个看不会对全部流量做载荷分析。4.4 第四步威胁情报碰撞基本流量分析的最后一个常规动作是把会话中的外联 IP、域名、证书信息拿去跟威胁情报库做碰撞。现在很多平台都支持在线查询输入一个 IP 就能看到它是否命中恶意软件 C2、扫描源、钓鱼服务器等标签。情报碰撞的命中率通常不高但一旦命中基本就是重大发现。比如某次审计中我发现一台内部服务器每隔 30 分钟向外网某个 IP 发起一次 HTTPS 连接流量很小会话日志看不出问题但情报库显示该 IP 关联多个恶意软件样本。顺着这条线索深挖最终确认这台机器被植入了后门正在定期回连。4.5 第五步输出审计结论流量分析最后要落到一个明确结论上不能只说“我们发现了一些异常”要说清楚五件事异常会话的源 IP、目标 IP、端口、协议、时间戳该会话与业务基线的关系是偏离还是符合会话背后的资产归属责任人是谁判断结论是什么误报、可疑、待取证、确认违规建议处理措施是什么通知整改、阻断通信、升级为事件响应输出结论时我会把证据链补完整既包括会话日志截图也包括关键数据包的导出文件。审计报告如果只有结论没有证据后续推动整改的难度会大很多。5. 常见坑点和排查方法5.1 交换机镜像丢包导致数据不完整这是流量采集里最容易踩的坑。镜像端口数据量过大的时候交换机 CPU 处理不过来就会出现丢包你分析到一半发现会话缺失还以为是业务没流量。排查方法比较直接采集服务器上比较实际接收到的包速率和交换机端口统计的速率两者明显不一致就是丢包了。对策要么降低镜像流量比如按 VLAN、按业务分段镜像要么用专门分流设备不做过多解释。5.2 加密流量占比过高现在内网流量里 HTTPS 和加密协议占比越来越高基本流量分析只能看到会话元数据看不到内部内容。这是一个客观限制不用硬扛。我的处理方法是加密流量用“会话行为 TLS 指纹”辅助判断比如证书的来源、TLS 握手中的 JA3 指纹是否命中恶意库结合连接节奏还是能筛出不少问题。至于完全无法判断的如实写入审计报告说明基于现有条件存在盲区。5.3 误把正常业务当异常筛查异常会话时最容易翻车的是把正常业务当恶意行为。比如某系统定时任务每 5 分钟连一次数据库凌晨持续拉取数据如果审计人员不了解业务很可能直接判定为数据外传。这又回到了前面资产清单的重要性——审计之前先和业务部门对清楚定时任务清单、自动化脚本清单能减少大量的误报。5.4 抓包文件太大打不开小规模审计时可能一抓就是几个 GB 的包普通分析工具打开就卡死。我现在的习惯是抓包时就做限制按文件大小滚动保存同时只抓需要的端口和协议用捕获过滤器提前过滤。分析时再用显示过滤器缩小范围实在不行就先转成会话日志用文本方式刷比图形界面快得多。6. 实操心得与后续扩展思路6.1 打牢基础比追求大而全更关键做了一段时间流量分析审计后我最大的体会是基本流量分析做好比盲目上复杂系统更实在。先把会话、基线、异常筛查这套基本功练扎实再去碰深度包检测、用户行为分析思路会顺很多。很多人一上来就想做全流量回溯结果数据量太大存不起分析模型又建不起来最后不了了之。6.2 让流量分析成为常态化检查项安全审计不必等年度大项目才做流量分析。我建议有条件的话把流量采集常态化会话日志保留 30 天每隔一周自己刷一遍异常会话列表。这样每次审计时拿的都是已经分析过的数据重点放在近期增量上省时省力。如果是小规模环境哪怕只有一台服务器的镜像端口也足够积累出有价值的基线数据。6.3 后续可以扩展的方向流量分析后续可以往几个方向延伸但都要先打底从会话分析升级到文件还原重点看 HTTP、FTP、邮件附件传输的文件内容。引入威胁情报自动化查询把外联 IP 和域名批量做碰撞省去手工逐个查的时间。如果预算允许可以上网络检测与响应类产品在流量分析的基础上做实时告警。把流量分析结果和主机日志审计结果做关联打通“网络侧发现、主机侧验证”的闭环。最后分享一个小技巧做流量分析时先把所有外联目标 IP 整理成一张表按出现频次降序排列然后从频次最低的开始查低频连接往往是异常行为的多发区。查完低频再回头看高频基本不会漏。流量分析这件事难不在工具难在对业务的理解和对异常的敏感度。希望这篇整理能帮你在安全审计的路上少走几步弯路。