周四下午在客户现场一个三四个G的pcap包摆在我面前客户问能不能快速找出昨天的几条异常HTTP请求。Wireshark打开直接吃了8G内存差点当场宕机。我当时用Brim配合Zui导入、预处理再回到Brim里做可视化分析前后不到十分钟就定位到了问题。从那时起Brim加Zui这套组合就成了我处理流量分析的标准配置不管是几G的小包还是上TB的采集数据都能撑住。标题里提到的“Brim与ZUI协同安装”很多朋友看到会有个疑问Brim不是已经被Zui替代了吗为什么还要装两个其实这俩是同一套数据引擎的不同产品形态协同起来能兼顾桌面端操作体验和底层查询性能。这篇文章就从下载安装开始一步步带你装完两个工具再用实际流量包把分析链路完整走一遍最后把我踩过的坑和排查思路都交代清楚。1. 为什么要把Brim和Zui一起装先搞清楚分工再下载网上很多教程会把Brim和Zui说成“新老替代关系”这个说法有些片面。它们确实是同一个团队做的底层也共用同一套数据存储和查询引擎但产品定位完全不是一回事。在动手安装之前把二者的分工弄清楚后面协同用起来才顺。1.1 Brim并不是被淘汰了它只是变成了桌面壳还记得最早的Brim吗一个基于Electron的桌面应用最大的特点就是可以拖一个pcap进去自动调用Zeek把原始流量转成结构化日志然后直接拿类SQL语法去查询。对于单机分析和快速看包来说那个交互界面至今依然很高效拖拽、试错、看表格、点字段整个流程都在图形界面里完成。Brim的底层其实早就实现了数据湖Zed lake能力只不过它的侧重点一直在“桌面体验”上功能按钮都围绕高效浏览设计。我的使用感受是Brim适合做交互式探索——你先在图形界面上灌入一个pcap然后点几个字段看网络行为再写几条查询验证猜想这个过程特别顺手。大几千行的连接日志在Brim里翻起来比纯文本工具舒服得多。1.2 Zui到底是什么东西Zui命令行里通常叫 zui是同一个数据引擎的完整形态可以理解成把Brim底层的查询引擎抽出来做成了一组独立的命令行工具和服务端程序。主要包含三块能力创建和管理数据湖lake也就是我们存放pcap、日志、数据的池子高性能导入pcap或日志文件直接把原始网络数据转换成列式存储提供 Zed 查询语言服务支持交互式命令行查询、REST API查询还能以服务模式跑起来让其他客户端连接。简单说Zui是那个能扛大规模数据的“体力劳动者”数据的导入、转换、海量查询由它负责Brim是那个“门面担当”帮你把数据变成看得见摸得着的表格和统计。二者协同才是一个完整高效的流量分析工作流。1.3 协同安装到底解决了什么问题我实际工作中最常见的用法有三个每个场景单独用Brim或单独用Zui都会不太顺手配合起来就很理想大pcap包先用Zui导入和预处理形成lake后再用Brim打开避免直接在Brim里导大包导致内存炸掉远程服务器上用Docker跑一个Zui服务本地Brim连接这个服务查数据不用把所有原始包拉到本地批量日志文件用Zui命令行完成清洗和转换导出结果后用Brim做可视化确认。三个场景的共同逻辑是把“重活”交给Zui把“细活”交给Brim。所以在下面的安装环节我也会把两个工具装在同一台机器上让它们在同一个目录下工作。工具核心能力适合场景Brim桌面图形界面、交互式浏览、快速查询、Zeek日志可视化单机分析、快速验证、日常看包Zui命令行导入、列式存储、高吞吐查询、REST服务、Docker化部署大pcap预处理、远程分析、批量日志处理2. 安装前的环境准备版本、网络和依赖别搞错安装步骤其实不难但我在帮人排查时见过不少低级问题版本选错、系统依赖缺、Brim启动后弹不出来、Zui命令行明明装了却说找不到命令。这些坑大多在安装前可以规避所以环境准备阶段千万别跳过。2.1 版本号怎么选关于版本我的建议是先确认你的机器是64位系统然后到GitHub的官方Release页面找最新Release版本而不是下载Nightly版本。Nightly版本虽新但偶尔会有查询引擎改动导致Brim不兼容。对Brim来说它的最新稳定版通常能在 brimdata/brim 的Release页面找到对Zui来说要进 brimdata/zui 的Release页面下载。别在第三方“绿色版”站点下载这些工具更新非常频繁第三方包的版本往往滞后而且安全风险不值当。2.2 各操作系统的隐藏依赖WindowsBrim基于Electron新版Windows通常自带WebView2运行时。如果你还在用比较老的Win10版本比如LTSC安装完Brim后双击可能没反应。这时可以去微软官网装WebView2运行库。这个问题比较隐蔽因为Brim不会提示缺少依赖你只会看到一个“点图标没动静”的现象。macOSdmg安装包正常拖入Applications即可。如果首次打开提示“已损坏无法打开”通常是因为系统安全策略拦截了从网络下载的程序执行下面这条命令解除隔离再打开xattr -d com.apple.quarantine /Applications/Brim.appLinuxBrim提供deb、rpm和AppImage三种格式。deb/rpm安装比较省心依赖会自动处理AppImage很便携但要求系统有FUSE库部分服务器最小化安装时没有这个库启动时会报/dev/fuse相关错误需要手动安装fuse。Ubuntu系执行sudo apt install fuse libfuse22.3 什么时候考虑用Docker如果你和我一样经常需要在Linux服务器、内网环境或临时容器里执行数据导入任务那么用Docker跑Zui是非常扫平依赖的选择。本机上只需要有Docker环境即可命令如下docker pull brimdata/zui:latest镜像启动后Zui服务会监听指定端口你可以把宿主机的数据目录挂载到容器里这样容器内生成的lake数据在宿主机上也能访问。后面第3.2节我会给出更完整的启动命令。3. 一步一步装Brim桌面端和Zui CLI都能跑起来环境准备完了就可以正式安装。这一节我按“先装Brim桌面端再装Zui命令行最后让它们互相认识”的顺序推进每一个步骤都按我实际成功的路径来写。3.1 安装Brim桌面端Brim桌面端的安装其实非常简单真正的坑在“首次启动后”。Windows到GitHub Release页面下载最新的Brim-Setup.exe双击安装。如果没有特别需求保持默认路径即可。安装完不要急着导入pcap先打开一次让它初始化默认配置。如果打开后卡在启动界面很久大概率是它正在联网下载运行时组件或Zeek引擎保持网络畅通等一会儿。macOS下载Brim.dmg打开后把Brim图标拖进Applications。首次启动时会弹窗要求允许应用运行在“系统设置 - 隐私与安全性”里点“仍要打开”即可。Linux我这边Ubuntu环境最常用的是deb包cd ~/Downloads sudo apt install ./Brim-*.deb装完后在应用菜单里找到Brim启动。如果是AppImage方式执行chmod x Brim-*.AppImage ./Brim-*.AppImage首次启动时Brim会在用户目录下创建数据目录路径类似~/brim或~/Brim。这里有一个关键点之后Zui创建的lake如果能放在同一个父级目录下协同使用会更方便。我习惯把所有分析数据统一放到~/data/brim-zui/下这样不管是Brim还是Zui路径记忆成本都低。3.2 安装Zui CLI的三种方式Zui CLI的安装方式比Brim多我分别试过包管理器、二进制包和Docker三种这里把适用场景和踩坑点一起说。方式一HomebrewmacOSmacOS用户如果有Homebrew执行下面的命令最简洁brew install brimdata/tap/zui这个tap源是官方维护的版本更新速度不错。安装完成后在终端里执行zui version应当能看到类似zui version v1.x.x的输出。方式二GitHub Release二进制包Linux/macOS到brimdata/zui的Release页面下载对应系统的压缩包比如Linux版文件名通常是zui_版本_Linux_x86_64.tar.gz。解压后把可执行文件放到PATH目录中mkdir -p ~/zui-bin tar -xzf zui_*_Linux_x86_64.tar.gz -C ~/zui-bin sudo ln -s ~/zui-bin/zui /usr/local/bin/zui sudo ln -s ~/zui-bin/zq /usr/local/bin/zq注意Zui包通常同时提供zui和zq两个命令。zq是轻量级的Zed查询工具可以和标准输入输出一起配合zui则用来管理数据湖。两个都放到PATH里后面都用到。方式三Docker容器如果你要在一台没有GUI的服务器上跑Zui服务优先用Dockermkdir -p ~/data/brim-zui/lake docker run -d --name zui \ -p 9867:9867 \ -v ~/data/brim-zui/lake:/lake \ brimdata/zui:latest \ zui serve -lake /lake -L :9867起完容器后用docker logs zui能看到服务启动日志。设备宿主机上的~/data/brim-zui/lake就是实际存储lake数据的目录后续Brim打开这个目录就能看到数据。3.3 Brim和Zui的“握手”两个工具都装好后首次“握手”我推荐先从Brim端发起。打开Brim在菜单栏找“Open”或“Folder”入口定位到Zui的数据lake目录比如刚才Docker挂载的~/data/brim-zui/lake。如果Brim识别成功左侧池子里会列出所有pools。此时Brim和Zui已经共享同一份数据目录了。另一种握法是走网络连接先在Zui端启动服务zui serve -lake ~/data/brim-zui/lake -L :9867然后在Brim的“Connect to Lake”面板里填http://localhost:9867。这种方式的好处是不用管底层目录只要网络通就能查特别适合Brim跑在本机、Zui服务跑在远程服务器的场景。不过要注意走网络时Brim目前主要适合查询和浏览导入数据还是建议直接通过Zui完成图形界面里的导入功能在高延迟网络下容易超时。4. 第一次实战哪个工具负责干活哪个负责展示装完总得用起来。这一节我带大家从零走一遍造测试流量包、用Zui导入、用Brim浏览、再回到Zed查询。整个过程能直观看到“谁在干活、谁在展示”。4.1 先造一份测试流量手上暂时没有pcap文件的朋友最方便的造数方式就是用tcpdump抓一段自己电脑的HTTP/DNS流量。终端执行sudo tcpdump -i any -w ~/data/brim-zui/test.pcap -s 0 port 53 or port 80 or port 443 sleep 20 sudo kill %1等20秒期间用浏览器正常访问几个网站或者用curl发几条请求curl -I https://example.com curl http://example.com dig example.com 8.8.8.8这样生成的test.pcap里就有了DNS和HTTP流量足够后续练习。想用现成样本的也可以到公开流量包站点找一些CTF赛题pcap或MIT林肯实验室的经典样本下载下来分析。4.2 用Zui导入pcap到lake先创建一个全新的lake目录命令如下zui lake create ~/data/brim-zui/lake如果目录已存在会提示已初始化直接复用没问题。接着把test.pcap导入zui import -f pcap ~/data/brim-zui/test.pcap首次导入时它会对pcap按时间范围重新组织数据同时在后台调用Zeek生成连接日志和协议日志。导入结束后执行zui query * | count() by _path如果能看到类似下表这样的分组统计说明pcap已经被成功解析成Zeek结构化日志_pathcountconn236dns112http38ssl41这里要解释一下它经历了什么过程原始流量先被Zeek按协议识别并拆解成日志比如每个TCP连接会在conn日志里生成一条记录每个DNS请求会在dns日志里生成一条记录这些日志再以列式存储的形式落入lake查询时只扫需要的列而不是整个文件所以速度远快于直接读原始pcap。遇到几个GB的大包Zui导入阶段的优势非常明显慢没关系导入完成后查询就是毫秒级响应。4.3 用Brim打开同一份数据集现在打开Brim找到菜单里的“Open Folder”输入~/data/brim-zui/lake点确定。如果前面步骤都正确Brim界面左侧会出现几个对象对应刚才Zui导入后生成的池子。双击任意一个池子Brim会加载出连接日志列表字段包括时间戳、来源IP、目的IP、端口、协议等。此时你可以在Brim顶部的查询框里输入同样的Zed查询* | count() by _path点击执行右侧会以表格形式展示结果。Brim的优势就在这同样的数据命令行里要看需要手动排字段图形界面里点开就能浏览对某个字段感兴趣直接点排序或选中某一条记录看详情面板。你会发现即使没有写一条查询单纯看表格也能对网络流量有个初步概念。5. 流量分析实战从HTTP、DNS到VoIP录音定位工具跑通了真正有含金量的是查询思路。下面三个实战场景难度从基础到进阶覆盖了大多数流量分析工作的核心需求。5.1 快速摸清流量画像不管是分析自己抓的包还是处理CTF赛题第一步永远是“先看总体画像”。在Brim或Zui里执行* | count() by _path得到每种日志条目的数量分布能告诉我们流量里大部分是什么类型。接着按来源和目的IP统计* | count() by id.orig_h, id.resp_h | sort -count如果回答“哪个主机是流量最大的发起者”这类问题这一条就够用。注意Zed语言里sort默认升序加-count才是降序。这个细节很容易被忽略我第一次用的时候没加结果最想看的IP排到了最底下。5.2 分析HTTP请求与DNS解析比如怀疑某个内网主机在探测外网域名先查dns日志_pathdns | count() by query | sort -count如果看到出现频率明显异常的域名比如大量随机子域名很可能就是DGA域名。再跟进连接日志_pathconn | id.orig_h192.168.1.100 | sort ts这条查询能把这个IP所有连接按时间展开。结合HTTP日志_pathhttp | cut ts, id.orig_h, id.resp_h, method, uri, status_codecut的作用和SQL里的select差不多只保留关心的字段大幅减少干扰信息。我发现配合Brim界面浏览时每一步查询结果都能在视图里继续点选字段做二次筛选排查进程顺畅很多。5.3 VoIP场景从SIP日志定位通话并提取录音这里接住一个很多朋友都在搜的需求流量分析里抓到VoIP数据包后怎么还原出来通话录音。要注意只有在对你自己系统进行测试或者拿到合法授权、比赛赛题里明确允许的前提下才可以做还原操作不要拿这套方法去碰没有授权的流量。先查SIP协议日志定位一次SIP呼叫_pathsip | sort ts | cut ts, call_id, from, to, user_agent在结果里找到INVITE请求对应的call_id和时间段。接着用那段时间窗口过滤RTP流通常是在Wireshark里按刚才的时间窗口和两端IP做过滤通过“Telephony - VoIP Calls”菜单找到对应呼叫选中后点击“Play”就能听并导出通话录音。如果单纯在Brim/Zui环境中操作也可以用Zeek直接解析RTP但流程会更长一般还是建议和Wireshark配合定位和取流。这个场景的关键是先通过Brim快速定位到可疑呼叫的大致时间点再用Wireshark做精细提取。两个工具互相配合比用单个工具从头查到尾效率高很多。6. 协同安装和使用的常见坑帮你在20分钟内搞定最后这部分我把自己和身边朋友在Brim与Zui协同安装过程中踩过的高频问题整理成清单。如果你在安装后遇到奇怪现象先按这几个方向排查。6.1 Brim双击无反应或Linux AppImage打不开这问题八成出在WebView2或FUSE依赖上不考虑其他原因。Windows用户先检查WebView2运行库是否安装Linux用户确认FUSE可用执行fusermount --version如果提示找不到命令就按第2.2节补装。还有一个比较隐蔽的点AppImage文件放在挂载了noexec属性的分区上也会启动失败把它复制到~/AppImages目录再试。6.2 Zui导入pcap时报错或导入结果为空导入时报错先看文件权限确认pcap文件可读。导入结果为空则要确认pcap确实是完整抓包icmpv6或非标准端口流量不一定能生成丰富的日志。早期版本的Zeek对某些UDP流量的解析时间比较长耐心等待即可不要中途CtrlC中断导入任务中断极有可能留下一个不完整的lake目录。6.3 Zui lake权限问题导致Brim打不开用Docker跑Zui时容器内进程默认以root运行会在挂载目录里生成root所有制的文件。宿主机上Brim以普通用户打开这些文件就可能报权限拒绝。解决办法是启动容器时指定当前用户IDdocker run -d --name zui \ -p 9867:9867 \ -u $(id -u):$(id -g) \ -v ~/data/brim-zui/lake:/lake \ brimdata/zui:latest \ zui serve -lake /lake -L :9867这样容器内生成的lake文件归当前用户所有Brim打开时不会再被权限卡住。6.4 大pcap直接拖进Brim内存起飞我的建议是大于500MB的pcap一律不要直接拖进Brim先交给Zui导入成lake再用Brim打开lake目录。否则Brim在内存里组织数据时很容易吃满内存界面卡死只能强杀进程。按4.2节的流程走一遍整个过程平稳很多。6.5 版本不匹配的小贴士Brim某个旧版本打开新版本Zui创建的lake时偶尔会提示格式不支持。最稳妥的方案是同时更新升级Brim的时候顺手把Zui CLI也升到同期的Release版本不要只升其中一个。我现在的日常节奏是pcap落盘后先跑一条Zui导入命令接着打开Brim去看结果。整套流程从下载安装到分析跑通熟练之后20分钟完全够用。这篇文章里所有命令和查询语法都来自实际踩坑后的稳定版本你按顺序执行应该能避开绝大多数新手问题。如果装完之后还有奇怪报错建议先看官方Release页面的Issue区很多启动类问题在GitHub上都有现成解决方案。