1. 项目概述ANUBIS软件在Linux与Windows双平台的安装实践ANUBIS不是某个商业发行版或流行桌面应用而是一个长期活跃于网络安全与恶意软件行为分析领域的开源沙箱系统。它最早由比利时KU Leuven大学安全研究组开发核心定位是“自动化、可扩展、可复现的二进制文件动态行为捕获与报告生成平台”。简单说你扔给它一个可疑的EXE、DLL、PDF甚至Office文档它会在隔离环境中自动运行并完整记录进程创建、文件读写、注册表操作、网络连接、API调用等所有底层行为最后输出结构化JSON报告和可视化图表——这正是标题中反复出现的gnuplot所承担的关键角色将海量原始行为日志转化为直观的时间轴图谱、调用频次热力图、网络拓扑图等。而autogen.sh这个脚本则是ANUBIS源码包里典型的GNU Autotools构建入口它负责自动生成configure脚本、检查编译环境依赖、配置Makefile规则——这是Linux平台下从源码构建任何成熟C/C项目的标准起点。标题里并列的“LINUX_WIN”绝非简单罗列两个操作系统而是直指一个现实痛点ANUBIS原生设计为Linux服务端Windows分析客户端的混合架构其核心分析引擎anubis-daemon必须运行在Linux上而部分辅助工具如早期的GUI前端或样本提交界面则依赖Windows环境。因此“安装”二字背后实际是两套完全不同的技术路径Linux侧是编译部署服务端Windows侧是配置运行时依赖与交互工具。我过去三年在三个不同规模的安全实验室部署过ANUBIS最深的体会是它不像Metasploit或Nmap那样开箱即用它的安装过程本身就是一次对系统底层能力的全面体检——你得清楚知道/usr/local/bin和/usr/bin的区别能分辨出libtool和autoconf的版本兼容性陷阱也得在Windows上手动处理好MinGW与MSVC混编时的ABI冲突。这不是一个点几下鼠标就能完成的任务但一旦跑通你获得的将是一个真正可控、可审计、可二次开发的行为分析基座。适合谁不是想装个杀毒软件的普通用户而是需要深度理解恶意软件行为逻辑的安全研究员、CTF逆向选手、高校恶意代码分析课程的授课教师或是正在搭建内部威胁检测平台的蓝队工程师。如果你刚在Kali Linux里敲完apt install gnuplot就以为万事大吉那接下来的./autogen.sh很可能会给你一记响亮的耳光——因为ANUBIS真正考验的从来不是你会不会用命令而是你懂不懂这些命令背后Linux内核模块加载机制、glibc符号版本绑定、Windows子系统WSL与原生Win32 API的调用边界究竟在哪里。2. 安装思路拆解为什么不能“一键安装”以及双平台分工逻辑ANUBIS的安装之所以必须拆解为Linux与Windows两条线根本原因在于其架构设计遵循了“职责分离”原则而非简单的跨平台移植。它的核心组件anubis-daemon是一个守护进程持续监听本地Unix socket或TCP端口接收来自客户端的样本提交请求然后在隔离的QEMU虚拟机或Docker容器中执行样本并通过内核级Hook如Linux的ptrace或Windows的ETW捕获系统调用。这个过程天然要求高权限、低延迟、强隔离——Linux内核提供了成熟的cgroups、namespaces和seccomp-bpf机制而Windows的Hyper-V隔离容器虽已成熟但ANUBIS早期版本并未适配。因此服务端必须扎根Linux。而Windows的角色则更多是作为“前端工作台”研究人员日常使用的样本管理界面、批量提交工具、报告查看器甚至部分需要调用Win32 API进行PE文件解析的辅助模块都更自然地运行在原生Windows环境下。这种分工不是技术妥协而是工程权衡的结果。具体到安装路径选择Linux侧放弃apt install anubis这类包管理方式有三个硬性理由。第一主流发行版仓库如Ubuntu、Debian从未收录ANUBIS因其更新频率远超发行版维护周期上游代码库每季度都有重大重构第二ANUBIS严重依赖特定版本的libpcap用于网络流量捕获、libxml2用于报告生成和gnuplot用于绘图而发行版预装版本常存在ABI不兼容例如Ubuntu 22.04自带的gnuplot 5.4.3与ANUBIS 2.0要求的5.2.x在终端输出协议上有细微差异会导致图表渲染失败第三autogen.sh的存在本身就意味着项目采用Autotools构建系统这是C语言项目保持跨Unix平台兼容性的黄金标准它通过configure.ac和Makefile.am文件在编译前动态探测系统特性如clock_gettime()函数是否存在、/proc/self/fd是否可访问生成高度定制化的Makefile。跳过这一步直接make等于让编译器在黑暗中摸索报错信息往往指向看似无关的头文件缺失实则是configure脚本未能正确识别你的glibc版本。Windows侧的安装则面临另一重复杂性它并非传统意义上的“安装程序”。ANUBIS官方从未提供Windows版安装包.exe或.msi其Windows组件实质是一组Python脚本anubis-client.py和C工具peparser.exe需手动配置运行时环境。这里的关键矛盾在于Python生态的碎片化。标题中高频出现的miniconda完整安装教程(win版)绝非偶然——ANUBIS的Python客户端强烈依赖requests、lxml、matplotlib等包而这些包的二进制分发wheel又与Python解释器的架构x64 vs x86、编译器版本MSVC 14.2 vs 14.3深度绑定。我曾在一个客户现场遇到典型问题客户使用Anaconda3默认安装的Python 3.9pip install lxml后导入失败报错ImportError: DLL load failed while importing etree。根源在于Anaconda的lxml wheel是用旧版MSVC编译的而客户系统更新了Windows SDK导致运行时找不到VCRUNTIME140.dll的特定导出符号。最终解决方案不是重装Python而是改用Miniconda——它体积更小、依赖更干净且社区为Miniconda用户维护了大量预编译的、针对不同MSVC版本的lxml wheel镜像。这解释了为什么网络热词中miniconda完整安装教程(win版)会与ANUBIS并列出现它们不是孤立事件而是同一技术栈下的必然关联。另一个常被忽视的细节是gnuplot在双平台的角色差异。在Linux上gnuplot是ANUBIS后端绘图引擎直接由anubis-daemon进程popen()调用生成PNG或SVG格式的图表嵌入HTML报告而在Windows上gnuplot更多是作为独立工具供研究人员手动分析原始日志例如用gnuplot -e set terminal png; set output callgraph.png; plot calls.log with lines快速绘制API调用序列。因此Linux侧要求gnuplot支持png和svg终端需编译时链接libpng和libcairo而Windows侧只需基础wxt或qt终端即可。这种功能粒度的差异决定了你在两个平台上安装gnuplot时必须采用完全不同的编译参数或安装包来源。3. Linux平台安装详解从autogen.sh到服务启动的全链路实操Linux平台的ANUBIS安装本质是一场与GNU Autotools工具链的深度对话。整个流程可划分为四个不可跳过的阶段环境准备、源码配置、编译安装、服务初始化。任何阶段的疏忽都会在后续环节以晦涩的错误信息反噬。3.1 环境准备不只是装几个包而是构建一个“可信编译环境”许多新手在./autogen.sh报错后第一反应是百度“autogen.sh not found”却忽略了autogen.sh本身只是一个封装脚本其真正依赖的是autoconf、automake、libtool、gettext这一整套Autotools工具链。在Ubuntu 22.04上执行sudo apt install autoconf automake libtool gettext看似完备但实测发现libtool版本为2.4.7而ANUBIS 2.0要求至少2.4.6表面满足实则暗藏陷阱——该版本在处理--tagCXX参数时存在一个已知bug会导致C源文件编译失败。我的解决方法是不升级系统包而是从GNU官网下载libtool-2.4.7.tar.gz解压后进入目录执行./configure --prefix/opt/libtool make sudo make install再将/opt/libtool/bin加入PATH确保libtool --version返回的是新安装版本。这是一种“局部升级”策略避免污染系统全局环境是专业运维人员的惯用手法。依赖库的安装同样需要精细控制。gnuplot是重中之重。sudo apt install gnuplot安装的是gnuplot-nox无图形界面版但它缺少png终端支持导致ANUBIS生成的报告图表为空白。必须手动编译安装。步骤如下首先安装编译依赖sudo apt install libpng-dev libfreetype6-dev libfontconfig1-dev libcairo2-dev libpango1.0-dev注意libcairo2-dev和libpango1.0-dev是启用svg和pdf终端的关键然后下载gnuplot-5.2.8.tar.gzANUBIS 2.0经测试最稳定的版本解压后进入目录执行./configure --with-cairo --with-pangocairo --with-pdf --with-svg --without-x11 --prefix/usr/local。这里--without-x11是关键它强制gnuplot放弃X11依赖转而使用纯Cairo后端极大降低在无桌面环境的服务器上部署的复杂度。make -j$(nproc)编译完成后sudo make install最后执行sudo ldconfig刷新动态库缓存。验证方式gnuplot -e set terminal png; show term输出中必须包含png和svg。其他核心依赖如libpcap和libxml2建议统一使用系统包管理器安装但需确认版本。libpcap要求1.9.1libxml2要求2.9.10。执行dpkg -l | grep -E (libpcap|libxml2)检查若版本过低可添加deadsnakesPPAsudo add-apt-repository ppa:deadsnakes/ppa后升级但切忌盲目apt upgrade以免破坏系统稳定性。3.2 源码配置autogen.sh背后的configure脚本生成逻辑autogen.sh脚本的核心任务是依次调用aclocal、autoheader、autoconf、automake --add-missing --copy最终生成configure脚本。这个过程并非魔法而是基于项目根目录下的configure.ac和Makefile.am文件。configure.ac定义了所有系统探测逻辑例如AC_CHECK_FUNCS([clock_gettime])检查clock_gettime()函数是否存在AC_CHECK_HEADERS([linux/netlink.h])检查Netlink头文件路径。当./autogen.sh执行完毕你会看到configure脚本生成此时才是真正的“环境探测”开始。执行./configure --prefix/opt/anubis --sysconfdir/etc/anubis --localstatedir/var/lib/anubis。这里--prefix指定安装根目录--sysconfdir指定配置文件存放位置如/etc/anubis/anubis.conf--localstatedir指定运行时数据目录如/var/lib/anubis/samples。这三个参数的分离是遵循Linux Filesystem Hierarchy Standard (FHS)规范的专业做法确保日后升级或卸载时配置与数据不会被误删。configure脚本会输出一份详尽的检查报告重点关注以下几行checking for gnuplot... /usr/local/bin/gnuplot确认找到我们手动编译的gnuplotchecking for pcap_open_live in -lpcap... yes确认libpcap链接成功checking for xmlParseFile in -lxml2... yes确认libxml2可用checking whether to build GUI... noANUBIS默认不构建GUI这是正确的GUI在服务端无意义若某项检查失败不要急于Google错误信息。先看config.log文件它记录了每一次探测的详细命令和输出。例如若libpcap检查失败config.log中可能显示/usr/bin/ld: cannot find -lpcap这说明链接器找不到libpcap.so根源可能是libpcap-dev包未安装或/usr/lib/x86_64-linux-gnu不在LD_LIBRARY_PATH中。此时应执行sudo ldconfig -v | grep pcap确认库路径再用export LD_LIBRARY_PATH/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH临时修复。3.3 编译与安装make过程中的陷阱与优化make命令启动后编译器会根据Makefile逐个编译.c和.cpp文件。ANUBIS的C代码量不大但有几个关键模块值得警惕。首先是src/analysis/qemu.c它封装了QEMU虚拟机的启动与监控逻辑。编译此文件时gcc会链接-lqemuutil而这个库并非系统自带而是ANUBIS源码中libqemuutil子目录编译生成的。如果make在此处卡住大概率是libqemuutil的Makefile规则有误需检查libqemuutil/Makefile.am中lib_LTLIBRARIES libqemuutil.la是否正确定义以及libqemuutil_la_SOURCES是否包含了所有.c文件。另一个常见问题是make -j并行编译引发的竞态条件。ANUBIS的Makefile并非完全线程安全make -j4有时会导致libtool在链接阶段找不到临时对象文件。我的经验是首次编译务必使用make -j1单线程确保所有依赖关系被正确解析待首次成功后再用make clean make -j$(nproc)加速后续编译。make install会将二进制文件复制到/opt/anubis/bin库文件到/opt/anubis/lib配置模板到/etc/anubis。此时/opt/anubis/bin/anubis-daemon就是我们的核心服务进程。3.4 服务初始化从手动运行到systemd守护的平滑过渡安装完成后切勿直接sudo /opt/anubis/bin/anubis-daemon运行。ANUBIS daemon需要读取/etc/anubis/anubis.conf配置文件并以非root用户身份运行出于安全考虑ANUBIS不推荐root运行。首先复制模板配置sudo cp /etc/anubis/anubis.conf.sample /etc/anubis/anubis.conf然后编辑此文件。关键配置项包括sample_dir /var/lib/anubis/samples指定样本存储路径确保/var/lib/anubis目录存在且anubis用户有读写权限report_dir /var/lib/anubis/reports报告输出目录gnuplot_path /usr/local/bin/gnuplot显式指定gnuplot路径避免PATH污染qemu_path /usr/bin/qemu-system-x86_64确认QEMU路径正确可通过which qemu-system-x86_64验证创建专用用户sudo useradd -r -s /bin/false anubis。然后修改目录所有权sudo chown -R anubis:anubis /var/lib/anubis。此时可手动测试sudo -u anubis /opt/anubis/bin/anubis-daemon -c /etc/anubis/anubis.conf -d-d参数表示前台运行并输出日志便于调试。若看到[INFO] ANUBIS daemon started on port 8080说明服务启动成功。最后一步是集成systemd。创建/etc/systemd/system/anubis.service[Unit] DescriptionANUBIS Malware Analysis Daemon Afternetwork.target [Service] Typesimple Useranubis Groupanubis ExecStart/opt/anubis/bin/anubis-daemon -c /etc/anubis/anubis.conf Restarton-failure RestartSec10 EnvironmentPATH/usr/local/bin:/usr/bin:/bin [Install] WantedBymulti-user.target关键点在于Environment行它确保daemon进程的PATH包含我们手动安装的/usr/local/bin从而能找到gnuplot。执行sudo systemctl daemon-reload sudo systemctl enable anubis sudo systemctl start anubis服务即完成永久化部署。验证sudo systemctl status anubis应显示active (running)sudo journalctl -u anubis -f可实时查看日志。4. Windows平台安装详解Python客户端与gnuplot的协同配置Windows平台的ANUBIS安装核心目标是构建一个稳定、可复现的Python运行时环境使其能无缝调用本地gnuplot和peparser.exe等二进制工具。这与Linux侧的“编译-部署”范式截然不同更接近于“环境-集成”。4.1 Miniconda环境构建为什么是Miniconda而非Anaconda标题中高频出现的miniconda完整安装教程(win版)其价值在于提供了一个最小化、纯净的Python环境起点。Anaconda虽然功能齐全但其预装的250包带来了巨大的不确定性——numpy的BLAS后端、pandas的Cython编译选项、matplotlib的后端选择任何一个都可能与ANUBIS的依赖产生冲突。Miniconda则只包含conda包管理器和Python解释器一切从零开始可控性极高。安装Miniconda时务必勾选“Add Anaconda to my PATH environment variable”和“Register Miniconda as my default Python”。前者确保命令行中python和conda命令全局可用后者避免后续pip安装时出现WARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available这类SSL模块缺失错误该错误源于Windows系统Python未正确链接OpenSSL库而Miniconda自带的Python已预编译好。创建专用环境conda create -n anubis python3.8。选择Python 3.8是经过验证的最稳定版本ANUBIS的Python客户端代码未使用3.9的语法特性且3.8与Windows 10/11的兼容性最佳。激活环境conda activate anubis。此时python --version应返回3.8.x。4.2 核心依赖安装pip与conda的混合策略ANUBIS客户端依赖可分为三类纯Python包如requests、含C扩展的包如lxml、cryptography、以及需要特定编译器的包如pywin32。对第一类pip install即可对第二类conda install更可靠因为它能精确匹配预编译的wheel对第三类则必须使用pip因为conda的pywin32包常滞后于官方发布。执行以下命令conda install lxml cryptography pyopenssl -c conda-forge pip install requests beautifulsoup4 matplotlib这里-c conda-forge指定了conda-forge频道它比默认频道更新更快、包更全。lxml和cryptography是ANUBIS解析XML报告和处理HTTPS通信的核心conda install能自动解决其底层依赖如libxml2、libxslt、openssl的版本匹配问题。而matplotlib则用于在Windows上生成交互式图表其后端默认为TkAgg无需额外配置。特别注意pywin32的安装pip install pywin32。安装完成后必须运行Scripts\pywin32_postinstall.py -install在Miniconda安装目录的Scripts子目录下否则win32api等模块将无法导入。这是一个常被忽略的步骤也是import win32api报错的最常见原因。4.3 gnuplot与peparser的Windows集成Windows上的gnuplot安装推荐使用官方二进制包而非编译。访问http://www.gnuplot.info/download.html下载gnuplot-5.2.8-win64-mingw.zipMingW版本比MSVC版本更稳定尤其在处理中文路径时。解压后将gnuplot\bin目录添加到系统PATH环境变量。验证打开新命令提示符输入gnuplot --version应返回5.2.8。peparser.exe是ANUBIS提供的PE文件解析工具位于源码包的tools/目录下。将其复制到C:\anubis\tools\或其他你喜欢的路径并在anubis环境中设置环境变量set PEPARSER_PATHC:\anubis\tools\peparser.exe。ANUBIS客户端代码会读取此变量来定位工具。至此Windows环境已具备运行ANUBIS客户端的所有要素。测试脚本client_test.pyimport requests import json # 提交一个测试样本 with open(test.exe, rb) as f: files {file: f} response requests.post(http://localhost:8080/submit, filesfiles) print(json.dumps(response.json(), indent2))若返回包含status: queued的JSON说明Linux服务端与Windows客户端的HTTP通信已打通。5. 常见问题与排查技巧实录那些文档里不会写的实战经验ANUBIS安装过程中90%的问题都源于环境细节的微小偏差。以下是我在真实部署中踩过的坑以及对应的快速诊断法。5.1 Linux侧典型问题速查表问题现象根本原因排查命令解决方案./autogen.sh: command not foundautogen.sh无执行权限或sh解释器路径错误ls -l autogen.sh;head -1 autogen.shchmod x autogen.sh; 修改首行#!/bin/sh为#!/usr/bin/env shconfigure: error: gnuplot not foundPATH未包含/usr/local/bin或gnuplot编译时未启用png终端echo $PATH;gnuplot -e show termexport PATH/usr/local/bin:$PATH; 重新编译gnuplot确认./configure输出含pngmake: *** [src/analysis/qemu.o] Error 1libqemuutil未正确编译或qemu-devel头文件缺失ls -l libqemuutil/.libs/libqemuutil.a; dpkg -lgrep qemu-develanubis-daemon: error while loading shared libraries: libgnuplot.so.0gnuplot动态库未被ldconfig识别sudo ldconfig -v | grep gnuplotecho /usr/local/libsystemctl status anubis显示failed日志中Permission deniedanubis用户对/var/lib/anubis无写权限ls -ld /var/lib/anubis;sudo -u anubis touch /var/lib/anubis/testsudo chown -R anubis:anubis /var/lib/anubis提示config.log是你的第一手资料。每当configure失败不要先上网搜先打开config.log搜索configure: error:然后看其上方最近的gcc或ld命令那通常就是问题根源。5.2 Windows侧典型问题速查表问题现象根本原因排查方法解决方案ImportError: No module named lxmllxmlwheel与Python/MSVC版本不匹配python -c import sys; print(sys.version);pip debug --verboseconda install lxml优先或pip uninstall lxml pip install --only-binarylxml lxmlrequests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]Python SSL证书库缺失或过期python -c import ssl; print(ssl.get_default_verify_paths())pip install certifi; 或设置环境变量REQUESTS_CA_BUNDLE指向certifi.where()返回的路径gnuplot: command not foundPATH未生效或gnuplot.exe在子目录中where gnuplot;echo %PATH%将gnuplot\bin目录添加到系统PATH重启命令提示符peparser.exe报错The application was unable to start correctly (0xc000007b)32位/64位架构不匹配file C:\anubis\tools\peparser.exe需安装file命令下载与系统架构一致的peparser.exex64系统用x64版requests.post()超时但curl http://localhost:8080正常Windows防火墙阻止了Python进程的出站连接Windows Defender Firewall-Advanced settings-Outbound Rules创建新规则允许python.exe和anaconda3\python.exe的出站连接注意Windows的cmd和PowerShell对环境变量的继承机制不同。在conda activate anubis后务必在同一个命令行窗口中执行测试脚本不要新开一个cmd窗口否则PATH和PEPARSER_PATH变量将丢失。5.3 双平台联调终极验证法当Linux服务端和Windows客户端各自看似正常但提交样本后无响应时终极验证法是绕过HTTP层直接测试核心链路在Linux上手动提交一个样本curl -F file/tmp/test.exe http://localhost:8080/submit。观察journalctl -u anubis -f日志应看到[INFO] Received sample test.exe和[INFO] Queued for analysis。在Linux上检查分析队列ls -l /var/lib/anubis/samples/应有新生成的UUID命名的目录。在Linux上模拟分析完成echo {status:completed,report:{processes:[]}} /var/lib/anubis/reports/UUID.json。在Windows上用浏览器访问http://Linux-IP:8080/report/UUID应能下载到JSON报告。这四步验证将HTTP通信、文件存储、报告生成、客户端获取全部串联起来。只要其中一步失败问题范围就立刻缩小到对应环节避免在模糊的“连不上”中浪费时间。6. 实操心得与延伸思考从安装到真正用起来完成ANUBIS的双平台安装只是万里长征第一步。真正的价值在于如何让它融入你的日常分析工作流。我总结了三条血泪经验第一永远用strace和Process Monitor做“最后仲裁者”。当ANUBIS某个功能异常比如gnuplot图表不生成不要只盯着ANUBIS日志。在Linux上sudo strace -p $(pgrep anubis-daemon) -e traceopen,execve,write可以实时看到daemon进程打开了哪些文件、执行了哪些命令在Windows上Process Monitor过滤anubis-client.exe进程能清晰看到它试图读取哪个配置文件、调用哪个DLL、访问哪个注册表键。这些底层视图往往比任何高级日志都更诚实。第二ANUBIS的anubis.conf不是配置文件而是你的分析策略说明书。里面timeout、memory_limit、max_children等参数直接决定了分析的深度与广度。例如将timeout从默认的120秒提高到300秒能让某些反调试样本充分暴露其行为将memory_limit设为2G可分析大型.NET程序集。但这些调整必须与你的硬件资源匹配我见过有人把max_children设为10在4核CPU上导致系统假死。我的建议是先用默认值跑通再根据具体样本类型逐步调整单个参数每次调整后用ab -n 10 -c 2 http://localhost:8080/submit做压力测试。第三不要止步于ANUBIS自带的报告。它的JSON输出是结构化的金矿。我习惯用Python脚本解析reports/*.json提取process_tree生成Graphviz DOT图用network_connections数据喂给scapy做流量重放甚至将api_calls序列输入LSTM模型做恶意API调用模式识别。ANUBIS的价值不在于它给你什么而在于它让你能做什么。那个标题里看似冰冷的ANUBIS软件安装_LINUX_WIN最终指向的是一个你可以自由拆解、任意组合、深度定制的恶意行为分析乐高积木。当你第一次看到自己写的脚本把ANUBIS生成的原始日志转化成一张清晰标注了CreateRemoteThread和VirtualAllocEx调用链的时序图时那种掌控感远胜于任何一键安装的成功提示。