上周帮朋友排查一台业务服务器的问题现象是高峰期CPU直接飙到90%以上应用侧日志翻来覆去看不出异常。后来我在入口交换机做了个端口镜像抓了二十分钟流量真相很快浮出水面——不是应用代码的锅而是一段异常重试逻辑把同一批请求反复打到入口上。那一刻我特别确定流量分析是排查疑难杂症时最兜底、也最容易被忽视的一项技能。很多人把流量分析等同于打开Wireshark抓包看看甚至网上还有流量分析一把梭的说法。其实真正值钱的是技战法三个字。什么叫技战法就是先知道看什么、再知道怎么抓、最后知道怎么判。本文就结合Wireshark、tcpdump、tshark这些常用工具把自己这些年做流量分析积累的经验和方法做个系统梳理。不管是做运维排障、安全运营还是刚入门想做流量分析这篇文章都能给你一套可落地的思路。1. 流量分析前先做三件事定目标、选位置、开对开关1.1 先回答我要找什么再决定抓什么包我见过太多人打开Wireshark就点开始捕获抓了半小时几万条包然后盯着满屏的十六进制发呆。这属于典型的先开枪后画靶。流量分析的第一步不是打开工具而是把自己的分析目标用一句话写下来。比如确认这台机器是否在和外部IP通信定位某个接口为什么偶发超时找出内网扫描行为。目标定了后面所有的过滤、统计、排查才有方向。目标不同采集策略完全不同。如果是排查应用慢的问题你需要抓的是完整TCP会话最好在客户端和服务端两侧同时抓方便对比时间戳如果是找恶意外联抓包位置就要放在出口链路同时要把DNS流量和TLS握手信息都保留完整如果是分析内网横向移动单点抓包很可能看不全需要多点镜像汇合后再做关联分析。没有目标的抓包跟随手拍了张模糊照片就当作证据差不多后续分析成本会高得离谱。这里要强调一个概念流量分析不只看内容更看行为和元数据。很多时候你不需要解密数据包也能判断问题比如连接频率、包大小分布、时间间隔、目的IP的地域属性这些元数据本身就携带大量信息。目标设定阶段你就得想清楚自己依赖于哪一层信息——是指标层IP、端口、协议、内容层HTTP请求体、文件传输还是行为层时序规律、交互模式。1.2 抓包位置怎么选镜像口、TAP还是本机抓包抓包位置选错了后面全部白干。我这些年踩过的坑里有三分之一是位置问题。最常见的三个位置选择是本机抓包、交换机镜像口抓包、分光器或TAP串联抓包三者各有适用场景。本机抓包比如直接在服务器上跑tcpdump或Wireshark最灵活能看到环回口流量和本机进程产生的所有包适合排查应用自身问题。但它有个致命缺陷在高流量场景下抓包本身会消耗CPU和内存反而加剧要排查的问题。另外服务器上不一定有你想要的权限尤其在生产环境。交换机端口镜像SPAN/RSPAN是排障和安全的黄金方案。它把交换机某个端口或VLAN的流量复制一份出来送到分析口对现网业务零侵入抓包机放在旁边专门跑分析工具。要注意的是镜像口通常会有一定的流量丢包率如果交换机转发能力不足或者镜像会话配置不当抓到的高负载时段数据可能并不完整。TAP分光器属于物理层设备插在链路中间一份流量走业务、一份走分析口可靠性最高但部署成本和停机窗口都更大一般用在核心链路或合规要求高的场合。我的建议是日常排障优先选用镜像口真机实验用本机抓包关键链路或者安全审计场景再考虑TAP。另外无论选哪种方案都要确认抓到的流量方向包含了双向流量只抓到单向报文的排查体验会非常痛苦。1.3 时间窗口、采样与存储抓多久、抓多大才不会后悔抓包时长是一个典型的少了后悔、多了也后悔的问题。抓太短低频异常行为可能根本不会出现抓太长文件动辄几十个GB分析工具直接卡死。我的经验是分两种情况来处理。如果是实时性排障比如系统正在异常中那你需要做的是快照式分析先抓两到三分钟快速看一下全局特征定位到可疑会话后再用针对性过滤去抓细节。如果两到三分钟里找不到明显问题说明异常是低频或者触发式的这时候与其盲目延长抓包时间不如去查触发条件。如果是回溯式分析比如安全事件已经发生你需要的是重放式采集确定一个时间窗口一般是事件发生前后各30分钟到两小时在窗口内完整抓包不要中间暂停。存储上要提前算好账。一条普通HTTP请求大概产生几KB的流量但在万兆链路上每秒可能就是几百MB。Wireshark的默认设置是对文件大小无限制的如果你的磁盘只有50GB最好提前用环形缓冲。捕获选项里设置好环形缓冲区比如按50MB一个文件、共保存20个文件这样磁盘占用最多1GB而且始终保留最近一段时间的完整流量。这个技巧在应急响应场景里尤其救命——你不知道事件什么时候再次触发但环形缓冲能保证真正发生时你一定留到了证据。抓包结束前我还会顺手记录一下时间戳和当时现场情况做流量分析最怕没有现场笔记回头研判全靠它。2. Wireshark过滤语法与统计面板从看得见到看得懂2.1 捕获过滤器与显示过滤器两者作用完全不同Wireshark有两种过滤方式名字很像但底层逻辑完全不同搞混了会让你做很多无用功。捕获过滤器Capture Filter是在抓包动作发生前生效的它决定哪些报文进入缓冲区、哪些直接丢弃语法用的是libpcap表达式不支持逻辑判断协议字段内部的值。显示过滤器Display Filter是在抓包完成之后生效的它只是把已经抓进来的报文做临时筛选语法更强大可以精确到某个协议字段。举个典型例子你想抓N台主机中某一台的流量用捕获过滤器写成host 192.168.1.10那其他主机的包根本不会进文件如果你用显示过滤器写ip.addr 192.168.1.10其他报文依然躺在文件里只是暂时看不见。两者最大的区别是显示过滤可以随时改条件重新筛选而捕获过滤一旦漏了就只能重新抓。我的建议是除非流量非常大、抓包磁盘不够用否则宁可多用显示过滤器。因为捕获过滤器的规则是过滤后丢弃这意味着你在分析阶段无法再补救。实战里我一般只会在两种场景用捕获过滤器一是明确知道只要某个端口或主机的流量、其他都不看二是链路流量太大需要立即降低抓包负载。其他场景全部交给显示过滤。2.2 我日常使用频率最高的显示过滤规则显示过滤器是Wireshark的魂。下面这些规则不是我背出来的是这几年在排障和应急里实打实反复用的。我按场景列出来方便你直接抄作业。分析目标过滤表达式用途说明指定主机双向流量ip.addr 10.0.0.8任何方向包含源或目的即命中指定端口服务tcp.port 443过滤出443端口的TCP报文只看HTTP请求http.request只显示GET/POST等请求行只看HTTP响应异常http.response.code 400快速找出错误响应定位SYN重传tcp.flags.syn 1 tcp.analysis.retransmission发现握手阶段的重传看DNS查询dns.qry.name contains example.com分析域名解析行为找TLS握手tls.handshake.type 1只看ClientHello报文按响应时延排序点击tcp.analysis.ack_rtt列排序找出时延异常的TCP段定位慢请求frame.time_delta 0.5帧间隔大于0.5秒的包找应用停顿看特定协议tcp.payload contains password明文协议内容检索定位扫描源tcp.flags.syn 1 tcp.flags.ack 0SYN单独发出典型的探测特征这些过滤条件需要组合起来用才有效。比如找扫描行为你会先看IO Graph里SYN包有没有突然飙升再用上面的SYN过滤条件把所有SYN包拉出来按源地址做统计排序哪个IP的SYN数量异常多基本就是扫描源了。2.3 协议分级、会话列表与IO Graph的正确打开方式很多人过滤语法用得溜但对统计面板不屑一顾这挺可惜的。Wireshark的统计功能是快速定位问题的钥匙用好它们能让你在几十万条数据里五分钟缩小包围圈。协议分级Protocol Hierarchy是第一个要看的面板。它会按协议栈从物理层到应用层统计每个协议的帧数、占比和带宽。正常流量里TCP占比会比较高如果你看到ARP或者ICMP的占比异常大那就要警惕内网是否在做扫描或者ARP欺骗。端点Endpoints面板按IP/MAC聚合所有会话流量能看到每个节点收发字节数是找流量大户最快的途径。会话Conversations面板则把通信双方做映射配合IPv4页面里的字节排序能迅速找出是否是某两个IP之间在大量传输。IO Graph是我定位时间轴异常最依赖的工具。设置Y轴为Packets/tickX轴每1秒一个刻度正常情况下整条曲线相对平稳。如果某个时间段出现明显尖峰用鼠标框选那个区间Wireshark会自动把那个时间窗的报文筛选出来然后你再配合显示过滤器逐步收敛。这个过程就是流量分析里最好的思维链——先看整体统计再做区间切片最后做字段筛选。3. 五类高发异常流量从特征到行为的研判思路3.1 端口扫描与探测低频、离散、SYN重试端口扫描是所有安全事件的前奏识别它本身不算难难的是在正常流量中把它挑出来。扫描流量的核心特征是探测性一个源IP在短时间内向多个目的端口发起少量连接每个端口的报文数不多但目标端口高度离散。SYN扫描最典型的表现是没有完成三次握手只发出SYN收到SYN/ACK后不回ACK或者直接收到RST。用Wireshark分析时我会先按目的端口做统计排序观察有多少不同源地址在访问高端口或非常见端口然后单独过滤tcp.flags.syn 1看这些SYN包的目的IP和端口分布。如果同一个源IP在几秒种内访问了十几个IP的若干不同端口那基本可以确定是扫描行为。还有一种情况容易被忽略就是扫描工具为了绕过安全设备做低速扫描把速率降到每几分钟一个连接。这种场景下时间轴的检查变得尤为重要IO Graph里这类流量往往是平缓的背景噪声需要拉长窗口逐段回看。实际排查里我一般不去纠结扫描的源头是不是真恶意。只要发现内网有主机对其他网段发起大量探测就直接定位到该主机检查它是否失陷、是否有人跑着自动化脚本。扫描频率低不代表安全只要存在就说明网络里可能有人在踩点。3.2 暴力破解认证失败频率与来源集中度暴力破解的特征比扫描更好辨认因为它必须通过应用协议来完成认证尝试。常见的场景是SSH爆破、RDP爆破、Web登录爆破和数据库认证爆破。无论哪种流量侧都有共同规律短时间内大量POST请求或认证握手包来源IP集中目的账号或密码字段内容高度相似响应里大量出现认证失败的错误码。以SSH爆破为例流量特征是这样的同一个源IP先与目的主机的22端口建立大量连接每次连接都完成TCP三次握手然后立刻发送SSH版本协商包随之开始认证尝试。正常用户一条SSH连接建立后会维持很长时间爆破工具则是一条连接只试一两次就断开建立频率极高。用Conversations面板去排序你会看到该源IP与目标端口22的会话数是其他主机的几十倍这个数字本身就是铁证。Web登录爆破更直观——过滤http.request.method POST和http.response.code 401再按源IP统计通常会看到一个IP刷出成百上千条错误认证响应。这里有一个容易踩的坑有些站点的登录接口做了HTTPS加密你看不到HTTP层。解决办法是结合TLS握手的ClientHello数量来判断。爆破工具每次建立新TCP连接时都会发ClientHello所以有一个IP在短时间内向同一HTTPS站点发起了大量TLS握手这本身就值得警觉。3.3 数据外传DNS隧道与低频长连接数据外传是安全事件里最隐蔽的行为攻击者拿到数据后要送出去流量侧一定有痕迹关键是你会不会看。传统外传是在HTTP/HTTPS里做包太大容易被发现所以现在更多见的是DNS隧道和低频长连接。DNS隧道的本质是把数据伪装成域名查询进行双向通信。正常DNS查询是访问一个域名拿回一个IP隧道却会往一个特定域名的子域里填充编码数据比如c2.example.com正常只有几次解析但要外传文件时可能出现几百条skdjfklsdjf.c2.example.com的查询。用dns.qry.name过滤后你会发现子域名特别长、随机字符串特别多、响应类型多为TXT或CNAME这些特征在DNS流量里几乎不会误报。低频长连接则更难发现。攻击者控制失陷主机定时向C2服务器发送少量心跳包包大小只有几百字节频率可能是每五分钟一次。这种流量在协议分级里几乎不显眼但用IO Graph的Y轴改成Bytes/tick、把间隔拉大到30分钟或者一小时你就能看到一条极其规律的脉冲线。再配合流量的目的IP做归属判断如果发现失陷主机定时连接一个位于境外或IDC机房的地址那基本可以定性。3.4 Web攻击流量UA、参数畸形与响应码异常Web攻击流量的形态花样很多但万变不离其宗要么在请求里带了不正常参数要么UA异常要么响应码比例失衡。SQL注入会看到URL参数里有明显关键字比如union select、sleep、/*注释符号等XSS则会在参数里看到script标签扫描器/利用工具通常自带识别度很高的UA头比如sqlmap默认UA就是固定的字符串。我的分析习惯是第一步过滤所有http.request第二步按http.response.code做统计看500、403这类错误码占比有没有异常拉升。正常业务里响应码分布相对稳定如果某个时间段500突然变多十有八九有人在打接口。第三步再过滤http.request.uri contains union or select or script把这些疑似攻击报文全部摘出来。这里有个容易漏掉的点很多Web攻击是走HTTPS的你只抓流看不到内容但TLS握手仍然会暴露攻击目标。攻击者向某个接口持续注入payload每个请求都新建TLS会话于是该URL对应的SSL会话数和访问其他页面的SSL会话数形成鲜明反差。虽然不知道payload的具体内容但这个反常访问本身就足以拉响警报接下来要做的是翻Web服务日志做更细的确认。3.5 挖矿与僵木蠕的周期性通信特征挖矿类流量是这两年出镜率最高的异常流量之一。挖矿程序为了保证算力持续提交会跟矿池建立TCP长连接并按照一定周期提交算力任务。这个周期在流量侧会表现为非常稳定的包间隔比如每30秒一次提交包大小也基本固定。矿池通常走特定端口比如常见挖矿端口目的IP集中且多为IDC段。如果你看到某个内网IP对外的连接只有那么一两个但这两个连接在24小时内从未中断且持续有规律的小包交互就要往挖矿方向查。僵木蠕木马/蠕虫流量的第一大特征是传播性。蠕虫在内网扩散时会在短时间内向大量随机IP发起连接尝试会产生数量和模式都不同于扫描的流量——它不只是探测端口会尝试通过SMB、RDP等协议真正建立会话。第二大特征是唤醒机制很多木马会定期醒过来到某个固定的HTTP URL去拉取指令或更新。这类流量在非工作时段出现特别扎眼比如凌晨三点某主机向外部IP发HTTPS请求虽然包不大但每天同一时间必定出现。固定周期本身就是一种行为指纹比单看特征库更靠谱。4. 两个真实案件复盘失陷主机排查与慢请求定位4.1 案件一某内网主机持续外联30分钟锁定失陷范围有一回接到安全运营同事的求助终端管理平台提示某研发网段的一台Windows主机持续向外部IP发起连接但告警平台只给了IP和端口没有其他线索。我让同事从出口交换机镜像口抓了30分钟流量把pcap文件拿回来后一帧帧看。第一步是打开Conversations面板在IPv4页签里按字节数降序排列很快看到这台主机和一个境外IP之间的连接排在第三名总传输量不大但连接数非常多大约五分钟内建立了四五十个短TCP会话。第二步是把会话过滤出来看TLS ClientHello发现每个新会话都带着同一个SNI字段而这个域名注册时间还不到一个月。到这里外联这个事实基本坐实。第三步就关键了我想知道这台主机的流量是不是只有这一种。过滤该IP的所有对外通信后发现它还会在固定时间访问一个海外IP的80端口但只发一个HTTP GET请求就断开这个GET路径是一串无意义的随机字符串。结合前面短连接高频外联的情况基本判定是典型的C2心跳通信加指令拉取。全程只用了不到四十分钟没有接触那台主机就直接定性。后续终端团队过去取证用内存镜像提取到了与流量侧SNI完全匹配的木马通信配置双重印证。这个案子的核心经验是流量分析不用非等到拿到终端数据才能下结论。从观察到假设、到验证、再到行动流量侧的分析链路本身就足够指挥后续的处置动作了。4.2 案件二接口偶发超时靠ack_rtt逐跳定位瓶颈另一个印象深刻的案例是业务侧反馈某个对外API接口在晚高峰时偶发响应超时每次都超3到5秒但没有规律。运维团队查了后端服务的日志发现服务端收到请求后响应正常数据库也没有慢查询问题被推到了网络上。我在客户端和服务端两侧同时做了镜像抓包各抓了约一个小时的流量。第一步用IO Graph看全局时延分布发现超时时间点集中在晚间八点半到九点之间其他时段没有。第二步把超时请求的TCP流选出来重点看tcp.analysis.ack_rtt字段——这个字段代表从数据包发出到收到ACK确认的RTT时间直接反映链路传输耗时。结果发现一个有意思的反差客户端发出的请求到收到服务端首个响应包总耗时为3.8秒但服务端侧抓包显示请求到达后只用了30毫秒就返回了响应。也就是说问题不在服务端处理也不在客户端而在这两者之间的链路上。继续追踪ack_rtt后发现数据包到达服务端之前的TCP往返时间在超时期间从正常的8毫秒飙升到500多毫秒有几次直接出现连续重传。后来的结论是运营商的出口设备在晚高峰触发了限速策略对跨越区域的TCP连接做了优先级调低导致某些大包被延迟转发。虽然这个问题最终不是内网自己能解决的但流量分析把所有参与方都排除了个遍把问题准确圈定到了运营商段再去提工单时效率就高很多了。最重要的经验就是对比分析一定要做多节点同时抓包只看一端数据你会把网络问题栽赃到应用头上。4.3 复盘两个案件里最值钱的判断点这两个案子放在一起对比有几个通用的判断点特别值钱。第一个是流量侧的特征要互相印证单点特征容易被误判。比如案件一里如果只看短连接和境外IP可能是一个不那么确凿的结论但加上SNI域名注册时间短、HTTP GET路径随机、心跳周期规律这三个特征就形成了完整的证据链。第二个是时间维度的信息量大于数据量。很多流量分析新手过度关注这个包的内容是什么却忽略了这个包应该在什么时候出现。案例二里的晚高峰规律、案例一里的固定心跳周期都是靠时间维度发现的。用IO Graph把时间变化画出来比对着十六进制内容看要高效十倍。第三个是别怕没有结论。很多时候流量分析不能给你100%的定义——你只能指出这里有异常、那里有嫌疑但这就已经很有价值了。它会直接告诉你下一步应该去哪查、查什么把范围从整个网络缩小到几条连接、几个IP、几段时间。这是流量分析在所有技术手段里最独特的位置。5. 流量分析避坑指南四个大坑与我的应对5.1 抓包不全比不抓更致命流量分析里最可怕的不是抓不到包而是抓到了一部分、你误以为它是全部。我吃过一次大亏某次分析用户访问异常我直接在客户端抓包看到TCP包重传严重差点就下了链路差的结论。后来在服务端同时抓包对比才发现重传的包客户端根本没有收到问题其实出在中间的负载均衡设备。单点抓包的信息是片面信息这一点怎么强调都不为过。应对方法是培养抓包视野的概念。在条件允许的情况下至少要在链路的关键节点上安排两到三个抓包点。比如客户端入口、服务端入口、外部链路出口三处时间同步抓包。如果实在条件有限至少也要在报告的结论里写清楚本次分析基于哪个抓包点的数据避免误导后续判断。流量分析是要承担后果的一句草率的结论可能让几十个工程师白忙一周。另外抓包时要注意过滤方向问题。某些交换机镜像口默认只能镜像入方向或出方向如果你需要双向流量一定要在配置SPAN时指定both否则你抓到的永远是单向报文画面非常误导人——你看到请求发了但收不到响应像极了网络黑洞。5.2 跨节点抓包的时间同步问题做多点抓包对比时时间不同步是最大的隐性杀手。我见过有人从客户端和服务端分别导出了pcap两边时间戳差了十几秒还坚持说要做延迟计算这纯属算了个寂寞。跨节点抓包必须保证各抓包节点的系统时间一致最理想的是所有设备都通过NTP校准到同一时间源偏差应该控制在毫秒级。具体操作建议抓包前先确认每台抓包机的NTP状态在Linux上用ntpq -p查看时间同步情况在Windows上用w32tm /query /status检查。如果发现偏差超过几十毫秒先同步时钟再开始抓包。抓包结束后可以在输出里加入一个时间校验步骤在所有抓包点同时发起一个短促的ICMP请求包看这个包在每份pcap里的时间戳偏差有多大把这个值作为后续时延分析的修正量。这个小习惯能避免很多不必要的争论。这里还要提醒一句不要在分析过程中随意调整抓包机的系统时间。临时改时间会把后续抓包的时间戳搞乱甚至导致pcapng文件的元数据混乱就因为你动了不该动的东西。5.3 加密流量不是终点JA3、SNI与行为侧写遇到TLS/HTTPS加密流量很多人说抓了也白抓。这话只对了一半。流量分析面对加密流量时确实无法看到HTTP请求的内容但这不等于无计可施。TLS握手的元数据、公钥信息和连接行为本身就足够暴露大量线索。第一层看SNIServer Name Indication它在TLS握手时以明文传输指示客户端准备连接哪个域名。很多恶意软件不使用标准TLS库SNI字段会填充IP地址或者一个陌生的随机域名直接过滤tls.handshake.extensions_server_name就能把它们当异常挑出来。第二层看JA3/JA3S指纹这是TLS握手指纹由ClientHello中TLS版本、加密套件、扩展列表等字段拼接成一段哈希值正常浏览器的指纹是有限的十来种而自定义恶意客户端的指纹往往在公开库里查不到或者匹配到已知恶意工具。现在很多开源流量分析平台如silk、Zeek都在做JA3的实时提取与比对。第三层是行为侧写即不看一次握手的细节而观察加密连接的完整行为模式。比如一个IP在每分钟内发起10次TLS握手每次连接只传几百字节就断开这种模式无论加密与否都是可疑的。我参与过的加密恶意流量分析里绝大多数定罪依据不是解密内容而是行为模式加元数据交叉验证。加密只是隐藏了内容的字面含义藏不住通信的骨架结构。5.4 别学一把梭Wireshark、tcpdump、tshark的组合用法最后想泼一盆冷水Wireshark很强但它不是流量分析的唯一工具更不是所有场景的最佳解。真正的实战里我的工具组合通常是tcpdump负责采集、tshark负责批量处理和特征提取、Wireshark负责可视化交互分析和最终确证。三者各司其职而不是用Wireshark一把梭。远程服务器上抓包几乎不可能开图形界面tcpdump是最可靠的第一环。它的关键参数需要熟记-i指定网口-w输出文件-s设置抓取长度-C按大小切分文件-W限制文件数量-Z降权运行。一次比较稳妥的远程采集命令长这样tcpdump -i eth0 -s 0 -w /tmp/capture.pcap -C 200 -W 10 host 10.0.0.8意思是抓取该主机双向流量每200MB切割一次最多保留10个文件磁盘占用量控制在2GB以内。tshark的价值在于批量处理和脚本化。几个我高频使用的用法tshark -r capture.pcap -qz io,stat,10输出每10秒间隔的IO统计tshark -r capture.pcap -Y http.response.code 400 -T fields -e ip.src -e http.response.code提取异常响应的源IP和状态码tshark -r capture.pcap -qz conv,tcp输出TCP会话排行。这些输出在分析几GB的大pcap时比把文件拖进Wireshark要快一个量级。如果是要对大批量pcap文件做特征提取比如从一周的流量归档里找某个恶意DNS域名tshark可以一条命令搞定tshark -r week1.pcap -Y dns.qry.name contains malicious.com -T fields -e frame.time -e ip.src -e dns.qry.name输出干净利落。然后你只拿结果文件去Wireshark里做精细研判即可。这种命令行批量提特征 图形界面跑细节的流程才是我眼中的标准姿势。根据我个人的使用体会还有一个小习惯很值得培养平时抓取典型流量样本存起来。比如正常的DNS查询、正常的TLS握手、常见的端口扫描pcap各留几份按时间归档。等你真正遇到棘手的分析任务时拿出历史样本做对比差异点往往会自己跳出来。别有存样本没用的想法流量分析的能力很大程度是靠积累样本喂出来的你见过的模式越多下一次判断就越快越准。