最近有个项目需要快速分析一批抓包文件同事推荐我用Brim和ZUI这套开源组合。Brim负责导入pcap、调用Zeek引擎做协议解析ZUI则提供交互式查询界面两个工具协同起来从下载安装到完成流量分析整个过程比我想象中顺滑很多。网上关于这两个工具的资料比较零散这篇就把我从零开始安装、配置再到实际分析流量的完整过程记录下来给需要做流量分析、安全应急、网络排障的朋友做个参考。这套组合最实用的地方在于它把“抓包文件”和“可检索日志”打通了。以前分析pcap文件要么用Wireshark一个一个包翻效率很低要么得自己搭Zeek环境再把日志导入ELK链路太长。Brim和ZUI直接把这套流程整合成桌面应用导入pcap之后自动生成连接日志、DNS日志、HTTP日志等再用类似SQL的查询语法快速过滤、聚合、统计分析效率能提升一个量级。1. 认识Brim与ZUI它们分别解决什么问题说到流量分析很多人第一反应是Wireshark。Wireshark擅长的是数据包级别的深度解析但面对动辄几个GB的pcap文件或者需要从海量连接里找出异常行为时纯手工点包就不太现实了。Brim和ZUI这套组合解决的就是这个痛点先用Zeek把pcap转成结构化日志再用ZUI的查询能力把日志变成可检索、可统计、可可视化的数据。1.1 Brim的核心定位Brim是一个开源的桌面应用程序它的核心能力是导入pcap文件并在后台调用Zeek引擎对流量进行协议解析。Zeek原名Bro是网络流量分析领域的老牌框架它不关心单个数据包的内容而是把网络会话抽象成连接记录。比如一次TCP三次握手、一次HTTP请求、一次DNS查询都会被拆解成结构化日志字段。Brim拿到这些日志后会将其存储在本地的索引数据库中。这一步非常关键因为日志一旦入库就不再需要重复解析pcap文件。后续所有查询、过滤、统计都是在数据库上完成的速度远快于直接翻包。Brim还有一个贴心的设计从查询结果中可以一键跳转到原始数据包也就是说当你在日志里发现可疑连接可以立刻切回Wireshark风格的数据包视图确认载荷内容。1.2 ZUI的查询界面与交互逻辑ZUI是Brim团队开发的Zeek日志查询界面早期作为独立组件存在现在已经深度集成在Brim中。它最吸引我的是查询语法接近SQL但更简洁学习成本很低。比如想查看所有HTTP请求只需要输入_pathhttp回车后立刻返回结果想统计每个源IP产生的连接数可以用_pathconn | count() by id.orig_h管道符后面还能接排序、筛选、字段提取等操作。ZUI的交互设计也考虑到了分析场景。左侧是字段面板展示当前数据集的字段名和取值分布右侧是结果表格支持按任意字段排序顶部还有时间范围选择器可以快速圈定某个时间段的数据。对于需要反复对比的分析任务ZUI支持把常用查询保存为“查询库”下次直接点选即可不需要重复输入语句。1.3 两个工具如何协同工作Brim和ZUI的关系可以理解为“后端引擎前端控制台”。Brim负责数据接入和存储ZUI负责查询展示和交互。实际使用中你只需要打开Brim导入pcap文件Zeek立刻开始解析解析完成后ZUI自动加载日志。整个过程不需要额外启动服务也不需要配置数据库连接对运维经验要求很低。这套组合还有几个对分析人员很友好的细节。一是支持同时导入多个pcap文件自动合并去重二是支持导入Zeek原生日志比如你已经用Zeek处理过的log文件不需要重新抓包三是导出结果非常灵活可以导出当前查询结果为CSV或pcap子集。这些功能叠加起来让Brim和ZUI成为我日常流量分析的主力工具。2. 安装前的准备与版本选择建议安装这类开源工具最怕的就是装到一半发现依赖缺失或者下载了一个不兼容的版本。Brim和ZUI的安装流程已经相当简化但准备工作做充分后面能省不少事。2.1 系统要求与硬件建议Brim官方支持Windows、macOS和主流Linux发行版。硬件方面官方没有给出特别高的要求但根据我的实际体验内存大小直接影响导入大pcap时的体验。Zeek解析pcap时内存占用比较明显如果pcap文件超过1GB建议至少8GB内存如果经常分析几GB的抓包文件16GB以上会更从容。磁盘空间也要预留充足。Brim导入pcap后Zeek生成的日志和索引数据通常会比原始pcap大2到5倍。比如导入一个500MB的pcapBrim的工作目录可能占用1.5GB左右。如果磁盘空间吃紧分析到一半报错“空间不足”那就很被动了。操作系统版本方面Windows建议10以上macOS建议Catalina以上Linux建议Ubuntu 20.04或同等版本。老版本系统上如果遇到图形界面启动异常优先考虑系统依赖问题这个在后面的排查章节会详细说。2.2 版本选择稳定版优先Brim的版本迭代比较快GitHub Releases页面会同时提供多个候选版本。我的建议是优先选择标记为“Latest release”的稳定版不要一看到新版本就追。开发版或预发布版通常包含新功能但也可能引入未知问题尤其在分析任务紧急的时候稳定压倒一切。另外要注意区分安装包格式。Windows平台一般提供msi和exe两种安装包推荐msi因为安装过程更规范权限处理更清晰。macOS提供dmg镜像Linux则区分debDebian/Ubuntu和rpmCentOS/Fedora格式。下载前确认好自己的系统架构x86_64还是ARM64避免下载后无法安装。2.3 依赖检查与常见误区Brim的桌面应用依赖一些系统组件。Windows上一般不需要额外安装什么macOS上如果遇到权限提示检查“系统设置-隐私与安全性”中的相关选项即可。Linux上容易踩坑的是缺少图形库或GTK相关组件安装后启动闪退往往就是这个原因。一个常见误区是认为Brim依赖Docker。实际上Brim是原生桌面应用不需要Docker环境。网上有一些旧教程引导用户先装Docker再跑Brim那其实是历史版本的部署方式现在已经不需要了。如果装了Docker也没关系不会冲突但没必要为了用Brim特意去装。另一个误区是混淆ZUI和Brim的关系。早期ZUI作为独立项目发布需要单独安装现在Brim发行版已经内置ZUI打开Brim就是ZUI界面不需要额外部署。所以安装时只需要关注Brim一个安装包即可。3. 三种主流系统的安装实操记录下面分别记录Windows、macOS、Linux三种环境下的安装过程。我按实际操作的顺序写包括下载、安装、启动、验证几个环节你照着做基本不会出问题。3.1 Windows环境安装步骤Windows上的安装是最省心的。从GitHub Releases下载Brim-Setup-x.x.x.msi或Brim-Setup-x.x.x.exe后双击运行。安装向导会引导你选择安装路径默认路径在C:\Program Files\Brim不建议修改免得后续权限问题。安装类型选择“只为我安装”或“为所有用户安装”都可以后者需要管理员权限。安装完成后从开始菜单启动Brim。首次启动会初始化数据目录这个过程可能需要一分钟左右界面可能会短暂空白耐心等待即可。如果长时间无响应可以检查任务管理器里是否有Brim.exe和zui.exe两个进程在运行这两个进程分别对应Brim主程序和ZUI界面进程。验证安装成功的方法很简单启动后导入一个pcap文件看ZUI能否正常显示日志数据。如果显示“Import Complete”并出现数据行说明安装成功。我建议用Brim官方示例pcap文件测试GitHub仓库和文档里提供了几个小体积样本避免用生产环境的抓包文件做首次测试。3.2 macOS环境安装步骤macOS安装包是dmg格式双击打开后把Brim图标拖到Applications文件夹即可。第一次打开时macOS的Gatekeeper可能会拦截未签名应用提示“无法打开因为无法验证开发者”。这个提示常见于开源软件处理方法是在“系统设置-隐私与安全性”底部点击“仍要打开”然后确认。安装完成后强烈建议先右键Brim图标选择“打开”而不是直接双击。因为右键菜单里的“打开”会触发一次安全复核确认后后续启动就不会再弹拦截提示了。如果已经双击打开并触发拦截按上面的方式处理一次即可。macOS上ZUI功能没有任何缺失但需要注意键盘快捷键和Windows版本略有差异。比如复制、粘贴用的是CommandC、CommandV查询编辑器的快捷键也以macOS惯例为准。初次使用如果发现快捷键不生效先确认不是系统输入法冲突。3.3 Linux环境安装步骤Linux安装稍微需要一点命令行操作但整体也不复杂。Ubuntu/Debian系统下载deb包后执行sudo dpkg -i brim_x.x.x_amd64.deb如果提示依赖缺失执行sudo apt-get install -f自动修复依赖。CentOS/Fedora系统类似下载rpm包后执行sudo rpm -ivh brim_x.x.x.x86_64.rpm部分Linux发行版尝试直接运行AppImage格式的包这需要在文件属性中勾选“允许作为程序执行文件”然后在终端里执行./Brim-x.x.x.AppImage。AppImage版本的好处是不需要安装解压即用适合想在U盘或临时环境里体验的用户。Linux启动后如果界面异常或闪退多半是缺少图形依赖库。在Ubuntu上可以通过安装libgtk-3-0、libnss3等包解决具体在后面的排查章节展开。3.4 验证协同安装成功的三个信号安装完成后怎么确认Brim和ZUI已经正确协同工作我总结了三个验证信号。第一个信号是启动时没有报错Brim主窗口正常打开左侧能看到数据导入区域右侧是查询编辑器。第二个信号是导入pcap后右下角状态栏显示导入进度完成后自动跳转到数据面板字段列表能正常显示_path、_start_time、duration等常见字段。第三个信号是执行一条简单查询比如_pathconn | count()能在一个多秒内返回统计结果。如果这三个信号都满足说明安装完全正常可以进入分析实战环节了。如果任何一个信号缺失先别急着分析对照后面的常见问题排查章节看看是哪里出了问题。4. 流量分析实战从导入pcap到定位异常安装只是开始流量分析才是重头戏。这一章我用几个实际场景演示Brim和ZUI的完整分析流程从导入数据、基础查询到典型异常发现每一步都给出可复现的操作。4.1 导入pcap并生成第一份日志打开Brim后主界面左侧有一个“Import”区域点击“选择文件”或直接把pcap拖拽进去。导入过程中Brim会调用内置Zeek引擎解析流量界面底部显示进度条。解析完成后ZUI自动切换到数据浏览模式你可以看到所有Zeek日志类型包括conn连接日志、dnsDNS日志、httpHTTP日志、sslSSL证书日志等。导入完成后第一步我通常先看整体连接概况。在查询编辑器输入_pathconn | count() by id.orig_h | sort -r这条查询统计每个源IP产生的连接数按数量倒序排列能快速识别哪些主机是“话痨”。如果某个IP的连接数明显高于其他主机优先级就很高值得进一步看它到底在干什么。如果发现某个源IP连接数异常接着查询它的目标端口分布_pathconn | id.orig_h172.16.0.8 | count() by id.resp_p | sort -r假设结果显示该IP主要访问少数几个目标端口且连接数不大可能是正常业务如果它连接了大量高位端口或者反复连接不存在的IP就要警惕扫描行为。4.2 ZUI查询语法速记ZUI的查询语法我总结为“三件套”筛选、聚合、导出。筛选是定位数据的必经步骤语法类似于字段值。比如orig_bytes 10000筛选发送字节数大于1万的连接id.resp_p53筛选目标端口为53的连接。多个条件用and、or连接还可以用not排除特定数据。聚合用于统计和分组语法通过管道符|连接。count()统计数量count() by 字段按字段分组统计count() by 字段 | sort -r排序输出。常见的还有sum()和avg()分别计算总和与平均值适合做带宽统计、延迟分析。导出操作在前面提到的语法后面加上导出动作即可。查询结果面板右上角有“Export”按钮可以把结果导出为CSV文件也能导出当前查询涉及的原始pcap子集。注意ZUI导出的是查询结果对应的数据不是整个pcap这对取证场景很有价值。4.3 典型场景一端口扫描行为识别端口扫描是流量分析中最常见的告警类型。假设你已经确认某个IP进行了大量连接尝试下一步就是确认它是不是扫描器。在ZUI中执行_pathconn | id.orig_h10.0.0.66 | count() by id.resp_h, id.resp_p | sort -r如果结果里有大量不同的目标端口且每个端口的连接数非常少通常只有1次或2次基本可以判定为端口扫描。再看duration字段如果每次连接的持续时长极小微秒级进一步印证了扫描特征——正常应用不会在这么短时间内发起像雨点一样的短连接。顺着这个思路再看扫描源IP发起连接的时间分布_pathconn | id.orig_h10.0.0.66 | count() by ts | sort ts如果连接时间呈密集爆发式分布短期内对大量端口发起请求这就是典型的水平扫描同一源IP扫多个端口。针对这类行为可以在防火墙或入侵检测系统里加一条阻断规则把该IP加入观察名单。4.4 典型场景二异常DNS请求排查DNS流量是安全分析的重点对象。ZUI里用_pathdns查看DNS日志字段里包含查询域名、查询类型、返回结果等。排查异常DNS我习惯先看有哪些域名被频繁查询_pathdns | count() by query | sort -r | head 20这里head 20限制只显示前20行避免结果刷屏。如果发现某个域名查询频率异常高且域名本身看起来很奇怪比如随机字符拼接的域名、非标准顶级域就要进一步确认这个域名解析到哪些IP是否属于恶意域名。还有一种常见异常是DNS隧道。特征表现为大量DNS查询指向同一个未知域名且查询类型为TXT或NULL正常业务大多数是A记录。在ZUI中筛选_pathdns | query*.example.com | count() by query, qtype_name如果看到大量TXT记录查询同时伴随较大的response长度需要关注是否存在数据外传行为。这类分析一旦确认通常需要结合其他安全设备做更深入的调查。4.5 典型场景三RADIUS认证流量与VoIP通话分析除了常规的HTTP和DNS分析Brim和ZUI也能处理特定业务协议的流量比如RADIUS认证和VoIP通话。这两个场景在目前的安全运营和CTF竞赛题里经常出现我简单说一下分析思路。RADIUS主要用于网络接入认证常见端口是1812认证和1813计费。ZUI中对RADIUS协议支持得不错日志字段包含用户名、NAS IP、认证结果等。如果想分析认证失败原因可以查询_pathradius | statusReject | count() by user_name, nas_ip排查时关注两个方面一是同一用户名在短时间内大量认证失败可能属于暴力破解尝试二是某个NAS IP频繁向认证服务器发起请求可能是该接入设备的配置问题。结合pcap回溯载荷能进一步确认是密码错误、账号锁定还是RADIUS共享密钥不一致。VoIP流量的分析重点是SIP会话初始协议和RTP实时传输协议。SIP负责通话建立和拆除RTP承载语音数据。在ZUI里_pathsip查看通话信令可以看到呼叫方、被叫方、通话状态等。排查案例中常见的需求是从SIP日志中还原通话起始时间、通话双方号码甚至从RTP流中提取通话内容。不过要提醒一下RTP流量分析涉及音频还原Brim主要做信令和元数据分析音频解码还原通常需要额外工具配合。如果遇到这样的需求可以从ZUI导出发起通话的pcap子集再用音频分析工具处理。Brim在这个环节的价值在于快速定位通话时间、参与方和媒体流信息为下一步取证提供索引。4.6 带宽异常与数据外传检测最后一个常见场景是带宽异常。企业内网出现大量外传流量时Brim能帮助快速锁定元凶。先看整体流量分布_pathconn | count() by id.orig_h | sort -r然后针对连接数最大的主机统计它的上下行流量_pathconn | id.orig_h10.0.0.88 | sum(orig_bytes) as send, sum(resp_bytes) as recv如果发送字节数远大于接收字节数且两者差距呈指数级增长说明数据外传的可能性偏高。这个时候可以从ZUI导出该主机的全部连接数据做更颗粒度的分析比如它访问了哪些端口、传输了大量数据的目标IP是哪些、传输方向是否单向上行。数据外传检测中还有一个隐藏技巧是关注非标准端口上的大流量连接。很多数据外传的行为会刻意选择高端口比如8080、8443、443等但在特定场景下也可能出现在随机高端口。ZUI中按orig_bytes降序排列能快速找到大流量连接再结合目的IP和端口做判断。5. 常见问题与排查技巧实录使用Brim和ZUI的过程中踩坑是难免的。这一章把我在实际使用中遇到的问题和对应的解决思路整理一下很多问题是新手容易卡壳的点。5.1 启动失败或窗口白屏这类问题在Windows和Linux上都有可能出现。Windows用户先检查是否安装了最新的Visual C运行库ZUI界面依赖这些组件。如果启动时提示缺少DLL文件去微软官网下载对应运行库安装即可。Linux用户白屏大概率是缺少图形依赖Ubuntu上执行sudo apt install libgtk-3-0 libnss3 libasound2安装后重新启动。如果还不行用命令行启动Brim查看终端输出里的具体错误信息brim错误信息里通常包含缺失库的名称搜索一下就能找到对应的包。5.2 导入pcap后没有生成任何日志这是比较容易让人慌的场景但多半不是软件故障。首先看pcap文件大小如果pcap文件过小比如几十KBZeek解析后可能只生成少量日志ZUI界面上看起来像“没有数据”。解决办法是查看左下角的日志统计面板确认导入的包数量和解析出的会话数量。第二种情况是pcap里都是加密流量或非标准协议Zeek默认解析器覆盖TCP/UDP/ICMP等常见协议如果流量全是私有协议或IPSec生成日志可能很少。这时可以尝试调整Zeek解析配置但需要修改Brim的配置文件操作门槛稍高。新手可以先确认pcap来源找一个包含HTTP或DNS流量的抓包文件做验证。5.3 查询速度突然变慢查询速度变慢一般有两个原因数据集过大或查询语句低效。数据集过大时合理做法是先用时间范围减少数据量ZUI界面顶部的时钟图标可以快速筛选时间段。插一句我的使用习惯分析大规模数据时我通常把日期维度拆到最小只保留需要关注的攻击时间窗口查询速度能提升好几倍。查询语句低效的表现是使用了全表扫描操作比如count() by 高基数字段。对于这种问题建议先做筛选再聚合尽量缩小扫描范围。例如先_pathconn | ts 某个时间 | count() by id.orig_h而不是直接对全量连接做分组。5.4 时间过滤不生效ZUI的时间类型字段格式比较严格直接输日期可能匹配不到数据。正确写法是使用标准时间格式比如ts 2024-01-01T00:00:00Z。如果你不确定字段格式可以用_pathconn | head 1查看第一行数据的_start_time字段复制它的格式来写时间条件。另外ZUI支持相对时间比如now-1h表示最近一小时now-1d表示最近一天。个人建议优先用相对时间排查实时数据场景更方便也避免时区换算带来的脑子转圈。5.5 数据备份与迁移Brim的工作数据存储在本地的数据目录里Windows上默认在%APPDATA%\BrimmacOS在~/Library/Application Support/BrimLinux在~/.config/Brim。目录里包含导入的pcap索引、Zeek日志和数据库文件。如果需要迁移到新机器或备份直接把整个目录拷贝过去就行。注意迁移时要保证Brim版本一致否则低版本可能无法读取高版本创建的数据库。迁移完成后启动Brim先确认数据导入记录还在再执行一次简单查询验证数据库是否完整。6. 一点个人经验与扩展思路最后聊几句使用体会。Brim和ZUI这套组合最让我满意的地方是“快”从导入pcap到第一条查询结果出来通常只需要几秒到十几秒根本不需要纠结部署和调优。相比搭建一套完整的SIEM系统这种轻量级的分析工作流在应急响应场景里非常实用。在实际项目中我通常把Brim和ZUI作为流量分析的第一站先通过快速查询缩小可疑范围再根据需求把数据导入到Wireshark或更专业的分析平台做深度检查。它的价值定位不是替代Wireshark而是帮你从海量数据中快速找到值得深入分析的那一小撮流量。一个小技巧分享给你Brim的导出功能很强大强烈建议在做完一轮分析后把关键查询结果导出为CSV并存档。一方面方便写报告时引用数据另一方面如果后续要对同一数据进行重新分析导出的CSV可以直接导入Excel或用脚本处理工作效率会高很多。如果后续有需要还可以尝试把Brim集成到自动化分析流水线里。它的底层数据是标准的Zeek日志格式可以对接其他日志分析平台导出pcap子集的功能也方便与其他取证工具联动。这块空间很大感兴趣的可以自己动手研究研究。