做流量分析这些年我最大的体会是一条看起来可疑的外连记录背后往往不是单一结论而是一连串需要交叉验证的事实。这次想记录一个比较综合的流量分析过程——从一条行为告警开始追踪一台主机在凌晨反复尝试连接多个外部地址的事件最后把网络流量、DNS日志、TLS握手特征和终端进程行为全部串起来才给出处置建议。我自己的分析原则始终是“添柴不加火”把该保存的原始数据保存好把能验证的结论验证到不因为某个IP在情报库被标记过就急着定性也不因为流量加密就说无从下手。这篇笔记适合刚接触流量分析的人也适合有一定经验、想整理一套可复用排查流程的同行参考。1. 告警是怎么来的从一条行为规则说起1.1 为什么“低成功率外连”值得查整个事件并不是从流量分析开始的而是先收到了一条行为告警某台内部业务主机在凌晨集中触发了“大量新建TCP连接、但握手成功率极低”的规则。这类规则在安全设备里很常见阈值一般是“单位时间内新建连接数超过N且完成握手的比例低于M%”。我一开始先确认了告警描述里的三个数字可疑主机在0点到5点之间发起了大约1500次对外TCP连接完成握手的只有80多次成功率约5%。正常业务对外通信不会长这样就算网络丢包成功率也不至于低到个位数。这种“广撒网、大部分失败”的形态常见于恶意程序在探测可达的控制器地址或者尝试连接一组存活率很低的临时域名。不过当时还只是判断不能直接下结论。1.2 先查资产归属和变更记录再动流量拿到告警后我没有立刻去抓包而是先做资产确认。这一步容易被新人跳过但非常关键。我查了这台主机的资产归属、运行角色、最近有没有变更窗口还问了负责这台机器的同事对方给出的答复是该主机不应该在凌晨有大规模外连行为最近的运维任务也没有涉及它。紧接着我拉了边界设备的会话日志把告警时间窗口里所有外连目的IP按次数排序发现目标地址分布得很散分布在多个不同网段没有任何一个IP占绝对多数。这种特征更像扫描探测而不是固定访问某个业务API。如果目的IP集中且请求有业务特征那可能是正常调用一旦目标分散且失败率高就要往异常方向想。到这里“需要做深度流量分析”这个判断已经成立。接下来说说我是怎么组织这次综合分析的。2. 综合型流量分析不是只抓包先理清数据源2.1 流量数据源的四个层级很多人以为流量分析等于“抓个包用Wireshark打开看”但在真实应急场景里尤其是时间跨度长的行为单靠一个PCAP文件根本不够。我习惯把数据源分成四个层级配合使用网络设备采样数据比如NetFlow或sFlow能提供连接五元组、起始时间、结束时间、字节数适合快速还原整体时间线边界抓包数据就是原始PCAP能给出载荷、TLS证书、应用层协议细节是最强的证据源DNS和HTTP代理日志能看到主机解析了哪些域名、请求了哪些URL这些日志通常保留时间更长终端EDR数据能关联到具体进程、命令行、父进程关系把流量行为坐实到程序层面。类比一下NetFlow是地图上的点线PCAP是现场照片DNS日志是通话记录EDR是人员轨迹。只用地图能看出“这个人移动轨迹奇怪”但不能证明他在做什么只有把几类数据对齐才能把整件事讲清楚。2.2 本次用到的抓包策略因为这次事件跨越了好几个小时直接到核心交换机镜像口打包文件会非常大。我的做法是分层抓先顺着会话日志里的目标IP在主机侧抓包只保留该主机和可疑目标IP之间的通信。这样抓包文件小很多也方便做纵深分析。tcpdump -i ens33 host 192.0.2.10 -w external.pcap这里只过滤了源IP或目的IP没有限制端口原因是异常通信端口未知限制端口容易漏。抓到一定量后再按时间段切片editcap -A 2025-06-10 00:00:00 -B 2025-06-10 05:00:00 external.pcap external_0000-0500.pcap同时在边界设备上开启sFlow采样用于对照主机侧抓包确认是否存在绕过主机的其他异常路径。这里有个容易忽略的细节主机侧抓包只能看到进出本机的流量看不到同一网段内其他主机访问它的流量所以在关键节点上采用镜像口或交换机采样来补盲区不要只盯着一台机器。2.3 时区对齐是第一个坑分析刚开始我就踩了一个时间不统一的坑。边界设备显示的可疑外连时间和主机本地抓包时间差了整整7个小时。一开始我以为是“凌晨”判断错了还怀疑存在两波独立活动后来才发现是各设备日志的时区配置不同。在做综合型流量分析之前第一步就应该把所有日志的时间戳统一换算到同一时区。我自己的习惯是全部转成UTC先对一遍再在展示时换算成本地时间。这个操作不涉及任何复杂工具Excel或SQL都能做但如果漏掉后续所有时间窗口判断都会乱。时间对齐之后我把0点到5点切成了每5分钟一段统计每段的新建连接数、成功连接数、收发字节数很快看到几个波峰。这几个波峰就是后续PCAP分析的切入重点。3. 关键证据从原始流量里抠出来的几条链3.1 用SYN/SYN-ACK统计还原连接“碰壁”过程当我把PCAP文件用tshark打开后第一件事不是看具体载荷而是先统计TCP标志位tshark -r external_0000-0500.pcap -Y tcp.flags.syn1 and tcp.flags.ack0 -T fields -e ip.dst | sort | uniq -c | sort -nr这个命令统计的是“只含SYN、不含ACK”的包也就是客户端发起的初始连接请求按目的IP计数。结果和会话日志一致有超过1400个SYN包发往各个可疑地址但只有少数地址能有后续响应。我又统计了返回RST的数量发现大部分目标直接回了RST。这说明对方主机在线但对应端口没有监听服务。恶意程序如果是在尝试连接一批随机的C2地址遇到端口不可达时就会出现大量RST。正常业务不会这样间歇性、大规模地试探多个未监听端口。在这一步我基本能确认“存在异常外连行为”但还不能判断它具体是什么程序、想要什么。接下来需要结合DNS日志和TLS特征继续追。3.2 DNS查询里藏着一个伪装成“更新”的域名继续翻主机侧的PCAP把DNS查询单独过滤出来tshark -r external_0000-0500.pcap -Y dns.flags.response 0 -T fields -e dns.qry.name | sort | uniq -c | sort -nr在查询列表里除了几个系统级域名有一个域名反复出现example-update.invalid。看名字很像“软件更新服务”但我查了资产基线这个域名从来不在该主机的业务访问白名单里也不属于企业内部后缀。更可疑的是它的解析行为同一域名在几个小时内反复查询但返回的A记录会变TTL还被设置得很短。正常系统更新域名的DNS记录不会这样频繁变动。我当时顺手查了一下该域名的历史解析发现它近期多次更换IP且没有对应HTTP服务的稳定指纹。这里我想强调一个容易被忽视的判断方法域名“看起来像不像正常业务”不重要重要的是它是否符合这台主机长期运行的基线以及它的解析结果是否稳定。很多恶意程序会故意选一个像“update-check”之类的名字来降低警惕性遇到这种情况一定要多问一句它为什么突然出现在这台从不需要更新的主机上。3.3 明文HTTP和TLS指纹的双重确认在分析过程中我注意到这台主机除TLS外还有少量明文HTTP请求请求路径是/p/v1/checkUser-Agent固定为一串很长的自定义标识。这个路径在内部业务系统里没有任何映射相关响应体也不是标准JSON结构倒像某种“探活”协议。对于大量TLS流量明文部分看不到我改用JA3指纹来做同源判断。JA3的原理是对TLS握手ClientHello里的“可用加密套件列表、扩展列表、椭圆曲线等信息”做哈希计算。不同的恶意工具通常会使用固定的加密套件组合因此即使证书和IP会变JA3指纹也往往一致。我在这次流量里提取出一个固定的JA3特征和本地的威胁特征库做比对后命中了一款公开渠道常见的下载器工具集。这里可以补充一点JA3指纹可以被恶意程序主动改造绕过所以它不能单独作为定案依据。但在IP、域名都在频繁变化的场景下指纹能帮助我们做“同源聚类”确认多段流量来自同一个程序。3.4 把行为节奏串成证据链每20分钟冒一次头最后让我敢向同事拍板的是把这个流量里的时间行为规律完整抽了出来。把会话日志按开始时间排序后发现异常外连并不是连续的而是存在明显节奏大约每20分钟触发一轮每一轮内会连续发起3到4次连接尝试分别对应DNS解析、TLS握手和HTTP探测。这种周期性的“心跳式”外连非常符合恶意负载的保活机制。它不需要一直在线只要定期确认控制器是否可达。与此同时我让负责终端的同事把EDR里该主机的进程执行时间拉出来对比结果发现有一个随机命名的进程正好也按这个周期启动并且它的网络连接记录和PCAP里的源端口变化能对上。到这里这件事的证据链才算闭合从告警特征到网络包从网络包到DNS域名再从DNS域名到TLS指纹最后从行为节奏到对应进程。每一环都有独立数据支撑而不是靠某一个威胁情报命中来定案。4. 排查阶段踩过的坑和误判4.1 把“外连”当“失陷”是常见误判整个过程中也有几次差点走岔路。最典型的一次是刚开始时我因为外连成功率低加上目的IP分散一度判断这是暴力破解扫描准备建议封禁大量地址。后来重新看会话日志才发现其中一部分连接目标其实是企业外部客户的服务端口只是因为对方网络策略限制导致握手失败并非主动扫描。这个误判提醒我一条经验异常外联不等于主机失陷也可能是监控探活、运维巡检、临时任务误配了目标地址。在定性之前要结合CPU占用、内存趋势、进程启动时间、登录会话等人为和系统状态一起判断。见到一个“外联”就强调要隔离很容易把正常业务停掉。所以我后来把“情报命中”的权重摆得很低。情报库显示某IP曾经活跃、或者被静态标记过恶意只能作为线索不能作为结论。一个IP不是永恒的恶意它被正常用户重新使用、由CDN托管的情况很常见这次的流量里也确实有几个“好IP”混在其中。4.2 加密流量并不是“看不懂”而是“看不够”很多同行一看到443端口就觉得没戏加密流量完全黑盒。但实际上即便无法解密仍然有大量元数据可以看TLS版本、SNITLS握手里的服务器名称、证书签发者、证书有效期、TLS记录长度分布、握手耗时、连接时长、上下行流量比例等。这次我通过TLS记录长度分布发现一个非常明显的规律每隔一段时间设备会从服务器下载长度接近固定值的块单块大小十分稳定像按固定缓冲区分块读取的数据。这种模式在正常网页浏览里很少出现更接近可执行文件分块传输。配合前面提取的JA3指纹即使不看明文也能判断这不是普通网页访问。所以我建议做流量分析的人不要把精力都花在“如何解密”上。先把手头未解密流量的元数据榨干再去想中间盒或私钥的问题这个顺序能节省大量时间。4.3 抓包文件太大打不开的三种绕过方式这次分析过程里也遇到PCAP文件过大的情况。一开始为了不留死角在镜像口上抓了3个多小时生成的文件快20GB。直接双击用Wireshark打开基本会卡死我后来改用三种方式避免“打不开”的尴尬。第一种是先用tshark直接在命令行做字段级统计不加载整个文件到界面比如统计会话前五、DNS查询前二十都能一秒钟出结果。第二种是用editcap把大包按时间段切小只保留异常波峰附近的时间片。第三种是针对性过滤比如只导出某个IP对的流量或者只导出HTTP请求相关字段到CSV避免在界面里滚几千行无关包。tshark -r huge.pcap -Y ip.addr192.0.2.10 tcp.port443 -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e tls.handshake.extensions_server_name filtered_tls.csv这个命令直接能拿到该主机所有TLS握手的SNI列表CSV用Excel打开即可效率远高于在图形界面里一个个看。4.4 别忘了东西向流量内网横向同样要查最初我所有注意力都放在“外联”上等到分析后半段我把同一窗口的内部流量也重新拉了一遍才发现被测主机还向几个内网网段发起了端口探测目标以445、3389为主。这些探测在外网视角完全没有体现但它恰恰是判断“是否已经横向扩散”的关键证据。综合型流量分析强调“综合”二字就是这个意思既要看南北向的出站流量也要看东西向的内网流量。只分析外联只能回答“它和谁通信”结合内网互访才能回答“它有没有正在感染其他机器”。所以遇到类似事件我会同时抓两个位置一是边界出口二是可疑主机所在网段的镜像口。只做一边都不算完整。5. 可复用的流量分析流程与排查清单5.1 这次分析沉淀的四步流程经过这次事件我把自己的流量分析流程收敛成了四步后面处理其他可疑外连事件也基本沿用这套。第一步是定位资产与时间窗。先确认告警涉及的主机、负责人、业务角色、近期变更再确定需要覆盖的时间范围宁可多取一段不要只取告警发生前后的几分钟。第二步是多源日志对齐。把NetFlow、会话日志、DNS日志、EDR进程日志全部按同一时区对齐画出一个时间线。这一步能发现纯抓包看不见的规律比如周期性、异常窗口、多主机同步触发。第三步是特征提取与同源比对。在PCAP里提取目标IP、域名、SNI、证书、JA3指纹、请求URL逐一和资产基线及威胁特征库比对但每条命中都只能作为线索不能作为定案条件。第四步是取证留存与处置。原始PCAP、日志切片、进程快照都要完整保存处置顺序上先隔离或暂停异常行为再评估影响范围最后才是清除或加固。每一步之间我都会写一个简短记录包括“判断依据是什么、排除依据是什么”。事后重看记录结论是否有据、是否有牵强的地方一目了然。5.2 一份适合日常巡检的流量排查清单这里把我常用的流量排查清单列出来适合日常对可疑主机做初筛检查项正常基线参考异常信号优先级新建连接总数与业务量相关波动小短时间暴涨且无明显业务原因高握手成功率通常大于90%低于50%且目标分散高目的IP分布集中在已知业务网段跨多网段、来源杂散高DNS查询变化访问域名长期稳定新增陌生域名、TTL异常短中触发周期无固定规律或偶发固定时间间隔、心跳式中TLS指纹业务应用指纹固定同一主机出现未知固定JA3中东西向探测极少扫描内网端口出现445、3389批量探测高流量大小与方向下载体积与业务相符突发大流量、定向下载明显中清单不是拿来逐条打钩的它更多是提醒你别漏掉维度。比如只看连接成功率可能漏掉DNS的周期变化只看外联可能漏掉内网横向探测。每类信号都有对应的下一步动作连接数变化对应会话明细DNS变化对应解析历史TLS指纹对应特征库比对东西向探测对应内网互访PCAP。5.3 一个关于基线的建议分析做得越多越觉得“基线”这东西比任何分析工具都重要。没有基线一个IP出现在凌晨、一个域名第一次被解析都是孤立事件无法判断是否异常。有了基线新的行为才可能被标记为偏离。对大多数团队来说并不需要立刻采购很贵的流量分析系统。先把边界设备已有的会话日志、DNS服务器查询日志、代理访问日志保存下来保留周期尽量长一些再定期导出统计特征形成一份最朴素的“正常通信基线表”就够分析大多数可疑事件了。我这次能快速判断“example-update.invalid”不对劲不是因为我认识这个域名而是因为白名单和长期统计里从来没有它的位置。最后再分享一点个人体会做流量分析心态很重要。很多时候你是顶着“是不是被攻破”的压力在工作但越是这样越要强迫自己只看证据不看情绪。那些看起来最像“攻击成功”的指标比如大量外联、情报命中往往只是噪声真正关键的反而是隐藏在时间节奏、TLS指纹、进程对应关系里的细节。添柴不加火——把该记录的东西完整记录下来表达清楚不夸大也不淡化这个原则在安全这件事上永远不过时。