HFish蜜罐部署实战：从环境准备到排错全流程

简介开源蜜罐系统HFish 3.3.1 Linux版本面向安全运维、红蓝对抗团队及企业安全建设者用于快速部署蜜罐环境诱捕扫描探测与攻击行为并采集威胁情报。整套资源打包为tgz格式共139个文件包含前端管理界面js、css、svg、png、数据库初始化与查询脚本sql、服务端核心程序server、hfish、部署脚本sh、跨平台客户端工具client、exe、证书文件pem以及报告模板docx等文件类型压缩包约111.6MB从环境搭建、功能配置到日志分析均有对应内容。内置admin默认账号与初始化登录密码便于首次登录体验管理后台附带的docx报告与csv数据可直接用于攻击记录汇报。当前已有567人学习该版本适合需要自建蜜罐平台、开展攻防演练或验证检测响应能力的初中高级安全工程师。1. 为什么在一堆安全工具里我最后还是把蜜罐选型定在 HFish 上1.1 蜜罐在防御体系里的真实位置先说说我做蜜罐选型时的一个真实感触。很多团队总觉得把防火墙、WAF、EDR 部署齐了就够了蜜罐可有可无。但实际上这些防护手段的目标都是“挡住攻击”而蜜罐做的事完全不同——它是主动制造诱饵等攻击者自己撞进来。真正的价值不在于拦截而在于观察观察攻击者用什么工具扫、走什么流程、想摸哪个端口这些信息用传统安全设备很难拿到。我做的最初一次蜜罐实验是在一个几乎没有业务流量的测试网段放了一台 SSH 蜜罐。结果呢上线不到 6 个小时后台就收到了几百条来自不同地区的扫描记录。那个瞬间我突然意识到身边网络里扫描探测的活跃程度远比你想象的高得多。有了这些数据不管是溯源还是加固方向感都清晰了。1.2 中心端 节点的架构优势HFish 让我觉得最顺手的一点是它的“中心端 节点”架构。你不需要每台服务器上都装一套独立的管理端而是部署一个中心端做管理和数据汇总再把轻量级的节点散落到各个网段。节点只负责运行蜜罐服务和上报数据中心端统一展示攻击事件。这种架构贴合了大多数企业的实际网络情况。比如你有办公网、生产网、测试网每个网段里丢一个节点所有攻击数据都回流到中心端不需要挨个登录服务器看日志。而且节点资源消耗非常小塞在虚拟机里跑完全没问题。对于安全研究或红队溯源场景也可以通过临时部署高交互蜜罐节点快速扩展诱捕范围。1.3 3.3.1 这个版本值得关注的理由版本号这个东西不是越新越好关键是适合自己的部署环境和需求。我选 3.3.1 作为演示和落地版本主要基于三个原因3.x 系列整体架构稳定3.3.1 属于修复了一些兼容性问题之后的版本踩坑概率相对低网上的教程、社区问答、插件资源大多围绕 3.x 系列展开遇到问题更容易找到现成答案官方对 Linux 环境和国产化系统的适配在 3.3.1 版本里已经比较完整。当然如果你是从零开始拉官方最新版也可以但如果你对这套系统还不熟悉从一个有大量参考资料沉淀的版本入手会更顺利。2. 实际动手前环境和端口的准备能省掉你后面一半的排查时间2.1 服务器配置与系统选型蜜罐系统对硬件的要求真不算高但千万别以为“随便一台机器就能跑”。我见过不少人在低配环境下装了蜜罐结果攻击量一上来数据库写入延迟后台页面卡死节点心跳丢失。这很影响判断。我自己习惯的参考配置是这样的项目最低要求实际部署建议CPU1 核2 核及以上节点视情况可以放宽到 1 核内存1 GB2 GB 及以上中心端建议 4 GB磁盘10 GB40 GB 独立分区日志量增长有时候会超出想象系统版本CentOS 7 / Ubuntu 16.04Ubuntu 20.04/22.04 LTS、CentOS 7.9数据库SQLite默认攻击量大时切换 MySQL操作系统选型上如果你用的是公司内部统一管理的 CentOS 或者 Ubuntu LTS直接装就行。如果涉及国产化环境比如麒麟、统信 UOS需要确认有没有对应的适配包。HFish 3.3.1 对部分国产系统做了适配但不同 CPU 架构x86、ARM、MIPS对应的二进制包不一样下载时千万别选错。2.2 基础依赖和工具检查HFish 是 Go 语言写的二进制基本都是静态编译常规情况下不需要装什么运行库。但它安装过程依赖 bash、tar、wget 或 curl这些工具在绝大多数 Linux 发行版里都自带不过保险起见我每次部署前还是会先检查一遍which bash which tar which wget which curl空的结果就补装对应工具包。另外还有一点容易忽略glibc 版本。如果你的系统比较老比如 CentOS 6 或者更早的 Debian二进制可能跑不起来报错信息类似version GLIBC_2.14 not found。遇到这种问题要么升级系统要么换兼容包要么直接用容器方案。2.3 端口规划与防火墙放行HFish 3.3.1 默认需要用到的端口不算多但每一个都不能漏4433管理端 Web 页面HTTPS 访问4434节点与中心端之间的通信端口TCP各蜜罐服务的监听端口取决于你要开哪些服务比如 SSH 蜜罐通常监听 22HTTP 蜜罐监听 80 或 8080。在部署之前先把这些端口在防火墙和云安全组里放行。我见过很多新手在服务器本地测通了但外网就是访问不了最后发现云控制台的安全组根本没开。以 firewalld 为例firewall-cmd --permanent --add-port4433/tcp firewall-cmd --permanent --add-port4434/tcp firewall-cmd --reload如果用 ufw则执行ufw allow 4433/tcp和ufw allow 4434/tcp。这里有个细节值得记住云安全组和系统防火墙是两层两边都要放行缺一不可。3. 下载、解压、装完从安装包到管理后台能访问的全过程3.1 从官方仓库获取 3.3.1 安装包HFish 的 Linux 版本安装包在 GitHub 的 Releases 页面能找到。进入项目主页后找到 v3.3.1 的 release 记录展开 Assets 列表选择对应的系统架构压缩包。常见文件名格式类似hfish-3.3.1-linux-amd64.tgzARM 平台则是arm64结尾。下载这一步我建议的两种方式# 方式一直接用 wget 拉取注意将地址替换为 release 页面实际展示的下载链接 wget https://github.com/hackxf/hfish/releases/download/v3.3.1/hfish-3.3.1-linux-amd64.tgz # 方式二先在本地下载再通过 scp 传到服务器 scp hfish-3.3.1-linux-amd64.tgz rootyour-server-ip:/opt/无论哪种方式下载完成后都建议校验一下文件哈希确认下载过程没有损坏。GitHub 的 release 页面一般会附带 SHA256 校验值用sha256sum命令比对即可sha256sum hfish-3.3.1-linux-amd64.tgz3.2 执行安装脚本时发生了什么解压和执行安装步骤不复杂tar -zxvf hfish-3.3.1-linux-amd64.tgz cd hfish-3.3.1 chmod x install.sh ./install.sh很多新手看到脚本刷屏就慌了其实正常情况下脚本主要帮你做了四件事把服务端和节点端二进制文件安装到指定目录通常是/usr/local/hfish创建独立的运行账号确保蜜罐服务不用 root 身份跑减少被攻击后的提权风险初始化默认数据库默认是 SQLite注册 systemd 服务并设置开机自启动。安装完成后可以用systemctl edit或直接编辑 service 文件调整启动参数但初次部署不建议乱改保持默认先跑通再优化。3.3 首次启动和地址确认安装脚本正常结束后服务应该已经自动启动了。查看状态systemctl status hfish如果一切正常浏览器访问https://服务器IP:4433/web/。这里必然会出现一个证书警告因为 HFish 默认用的是自签名证书浏览器没法校验合法性。这个警告点“高级 - 继续前往”即可毕竟是你自己的环境。注意管理端地址一定要用 HTTPS端口是 4433不是 80 也不是 8080。很多人习惯性输入http://IP:4433结果访问不通其实是因为 HTTP 和 HTTPS 协议不匹配。4. 管理端配置与蜜罐服务上线的第一课4.1 登录安全与账号初始化首次登录的管理员账号是admin初始密码是hfish。登录成功后系统会强制要求修改密码这一步必须认真对待。蜜罐管理端如果直接暴露在公网默认密码就是给攻击者送人头的。我遇到的几个环境里负责部署的同事习惯性地把密码改成简单组合比如Admin123结果没过几天就被爆破攻击。其实蜜罐本身的目的就是吸引攻击者管理端更要做好防护。建议修改后的密码至少 12 位包含大小写字母、数字和特殊符号。如果有条件最好额外配置登录 IP 白名单。4.2 节点接入从中心端下发到节点上线节点接入是 HFish 部署里最有技术含量的步骤之一。登录管理端后进入“节点管理”页面点击新增节点会生成一段令牌token和对应的安装命令一般是这样的形态curl -sSL https://中心端IP:4434/install.sh?tokenxxxxxxxx | bash把这段命令在节点服务器上执行节点就会拉取安装脚本自动配置好中心端地址和令牌然后启动节点服务。执行完成后回到管理端的“节点管理”页面刷新一下正常状态下节点状态会显示“在线”。这里有个比较隐蔽的坑节点和中心端之间的时间必须同步。如果节点系统时间比中心端偏差过大证书校验和通信都会失败节点会反复连接不上日志里还会出现 TLS 相关的报错。所以节点部署前我用ntpdate或者chronyc做一次时间同步已经成了习惯。4.3 常用蜜罐服务的配置组合节点上线之后就可以在管理端给节点分配蜜罐服务了。以一台典型的 Linux 节点为例我通常会这样组合SSH 蜜罐监听 22 端口模拟真实 SSH 登录流程HTTP 蜜罐监听 80模拟一个后台管理系统登录页MySQL 蜜罐监听 3306诱捕横向移动时尝试数据库连接的行为Redis 蜜罐监听 6379这种情况在真实攻击链里很常见。在后台的操作路径是节点管理 → 选择目标节点 → 添加蜜罐服务 → 选择协议类型 → 填写端口 → 保存。配置完成后蜜罐服务会随着节点的心跳自动下发并启动。实际操作中还有个小技巧不要把蜜罐的服务端口设置在 1000 以外的大端口因为攻击脚本默认扫描的还是 22、3306、6379、8080 这些常见端口。如果蜜罐监听在 6379防护效果远好于监听在 63330 这种冷门端口。判断一个蜜罐配置是否合理就看“攻击者扫到你节点的概率高不高”。5. 部署和运行中的多个常见病以及对应的排查链路5.1 管理页面访问不了按这个顺序查如果浏览器访问管理端超时或连不上不要急着重装。我的排查顺序是第一步看本机端口是否在监听ss -lntp | grep 4433没有输出说明服务没起来或者端口不对。看服务状态和日志systemctl status hfish journalctl -u hfish -n 100 --no-pager日志里最常见的几种情况端口被占用、数据库初始化失败、运行目录权限不对。端口被占用的话先用ss -lntp | grep 4433找到占用进程决定是换端口还是停掉冲突服务。第二步如果端口在监听考虑防火墙。先在本机测试curl -k https://127.0.0.1:4433/web/本机能通外网不通基本就是安全组或系统防火墙的问题回到第 2 节检查防火墙的两层规则。第三步如果是云主机还要检查安全组入方向规则。很多云厂商的安全组默认只放行 80、443 等常用端口其他端口一律拒绝这就解释了为什么本机能访问但外网不能。5.2 节点一直不在线问题可能出在哪节点显示“离线”或者反复“连接中”是部署时最容易遇到的问题。定位思路要先看通信链路再分析日志。在节点机器上查看节点进程ps -ef | grep hfish tail -f /usr/local/hfish/agent/logs/hfish-agent.log日志里如果出现connection refused说明中心端的 4434 端口没监听或者防火墙拦截了节点访问。如果是token invalid或unauthorized说明节点配置的 token 和管理端不一致需要回到节点管理页面重新生成安装命令。还有一个很隐蔽的坑是节点上跑着多个 hfish-agent 实例。有时候安装脚本执行了两次系统里会有两个 agent 进程抢同一个端口导致心跳上报异常。这时候用ps -ef | grep hfish-agent查看进程数量如果有重复全部 kill 再重启一个实例。5.3 蜜罐端口被系统服务占用最典型的是 SSH 蜜罐绑定 22 端口但节点服务器本身也开着真实的 sshd 服务。这种情况下蜜罐无法绑定端口后台会提示启动失败。解决思路有两个方向调整节点真实 sshd 的监听端口比如改到 2222把 22 完全留给蜜罐或者蜜罐不使用 22改到 22222 等自定义端口。我的建议是前者因为攻击者扫描默认扫描 22 端口把真实 SSH 移到不常用端口既降低了真实服务暴露面又方便蜜罐占住 22。修改 sshd 端口后记得重启sed -i s/#Port 22/Port 2222/ /etc/ssh/sshd_config systemctl restart sshd然后确认防火墙也放行了新端口否则会把自己锁在服务器外面。5.4 SELinux / AppArmor 的隐形拦截很多 Linux 服务器默认开启了 SELinux 或者 AppArmor服务端和节点的二进制文件如果没有对应策略会被系统安全模块拦截产生类似Permission denied或Operation not permitted的报错。处理方式比较直接临时验证环境可以先设置 SELinux 为宽松模式setenforce 0确认问题由 SELinux 导致后再决定是长期关闭、给二进制添加策略还是把服务放到容器环境。在 CentOS 7 上我通常这样检查getenforce如果返回Enforcing可以先临时宽松测试确认无误再配置正式策略。AppArmor 的检查在 Ubuntu 上通过aa-status查看加载的配置文件。生产环境直接关掉 SELinux 不是最好的方案但蜜罐的二进制更新频率不高配置好对应的文件上下文context就能稳定运行。5.5 容器化部署的补充经验如果你所在的团队基础环境是 DockerHFish 也可以扔进容器跑。容器化带来的好处是摆脱宿主机 glibc 版本、SELinux 等环境差异问题坏处是端口映射和网络模式要额外注意。我比较推荐用host网络模式让容器直接共享宿主机网络。这样蜜罐绑定端口的行为和裸机部署基本一致不会出现端口映射遗漏导致蜜罐不可达的情况。唯一要做的是通过-v把数据目录挂载出来防止容器重建后数据丢失docker run -d --name hfish --network host -v /data/hfish:/usr/local/hfish hfish:v3.3.16. 上线不代表结束——日志、告警和升级那些事6.1 攻击日志的体量和磁盘规划蜜罐上线后的第一周是最能感受到“安全世界”真实压力的阶段。只要管理端口或蜜罐端口暴露在公网上扫描流量几乎是 7×24 小时不间断的。后台的攻击列表会快速增长单条记录虽然只有几 KB但数量多了以后磁盘占用很快会飙上来。我自己的经验是为 HFish 数据目录单独挂载一块数据盘并且开启日志轮转或者定期清理过期数据。在管理后台可以设定攻击记录的保存时长比如保留 90 天或 180 天太旧的记录建议导出发票后清理避免数据库膨胀导致查询变慢。6.2 告警推送别让告警疲劳毁掉主动感知HFish 支持把攻击告警推送到钉钉、企业微信、飞书等平台的群机器人 Webhook配置入口在“告警配置”里。这里我想分享一个经验不要对每一条攻击都开告警。高危漏洞扫描、全网背景扫描、随机端口探测这些噪声占了攻击流量的 90% 以上。如果你把这些都推到企业微信群里用不了一天群里就变成高频骚扰之后真出了高危事件也没人认真看了。我的告警策略是只对命中特定高价值蜜罐比如 MySQL、Redis、OA 模拟的事件告警同一源 IP 在短时间内命中多个蜜罐时触发聚合告警监控节点离线事件节点掉线本身就是一个值得关注的信号。6.3 数据库备份和版本升级要做在真正出问题之前HFish 默认使用 SQLite攻击数据其实就在一个数据库文件里。备份的思路很简单定期把数据库文件拷贝到独立存储即可cp /usr/local/hfish/db/hfish.db /backup/hfish_$(date %Y%m%d).db如果数据量很大建议切换 MySQL 存储。切换时在管理后台或者配置文件中指定 MySQL 连接信息攻击数据就会写入 MySQL。用 MySQL 的好处是容量大、查询方便、备份体系成熟适合攻击流量大、需要长期留存数据的场景。版本升级我吃过一次亏。当时 3.x 版内一个子系统更新我直接覆盖了二进制结果原有的 SQLite 数据因为表结构变化读取失败历史攻击记录全丢了。从那之后无论升级哪个开源系统我都会先做两件事备份数据库查看升级文档中关于数据迁移的说明。HFish 的升级包或者 release 说明里一般会写明是否需要执行数据库迁移脚本照着做不会出大问题。写了这么多很多经验都是从踩坑里攒出来的。蜜罐这套东西部署本身不复杂难的是把它真正放到网络里持续运转起来。希望这篇过程记录能让你少走几步弯路。本文还有配套的精品资源点击获取