企业官网建设流程全解析

简介：HFish 3.3.1 Linux 版是一套面向安全运维人员、渗透测试学习者与红蓝对抗演练团队的开源蜜罐系统部署包，可用于搭建内网威胁感知节点、捕获攻击行为并分析攻击手法。压缩包为 tgz 格式，共 139 个文件，整体约 111.6MB，其中 54 个 js 与 1 个 css 构成 Web 管理界面，35 个 png、5 个 svg 与 1 个 ico 提供图标资源，15 个 json、1 个 toml 与 1 个 version 承载配置与版本信息，4 个 sql 用于数据库初始化，另有 2 个 sh 脚本、2 个 pem 证书、2 个 client 与 2 个 exe 客户端程序，以及 docx 说明文档和 ipdb 地理库等。默认管理账号为 admin，密码 HFish2021，登录后即可体验蜜罐节点管理、攻击日志查看与告警配置等核心功能。目前已有 570 人学习下载，适合希望快速落地开源蜜罐、研究攻击诱捕与日志分析的安全从业者参考使用。

1. 开源蜜罐 HFish 3.3.1 Linux 版：一台闲置 VPS 能换回什么

手里有台 1 核 1G 的闲置 Linux 小鸡，除了挂个静态页吃灰，还能干点正事——把它变成一台蜜罐。HFish 就是干这个的开源蜜罐，3.3.1 是它比较成熟的一个版本，Linux 版直接跑在服务器上，不需要额外装一堆重型依赖。它的核心价值不是「防住攻击」，而是「让你看见攻击」：谁在扫你的 22 端口、用什么字典爆破、payload 长什么样，全给你记下来。适合谁？运维、安全运维、想给内网加个低成本感知节点的从业者，以及拿它练手做威胁情报分析的人。它不替代防火墙和 WAF，定位是诱饵和探针，别指望它拦流量，它负责把攻击者的动作录下来。

2. HFish 3.3.1 的架构与部署前选型：为什么不是随便找台机器就装

2.1 蜜罐的两种角色：管理端和节点端

HFish 是典型的 C/S 结构，拆成两个角色理解最省事。管理端（Server）负责收集数据、下发配置、展示 Web 界面；节点端（Node）负责在目标机器上监听端口、伪装服务、上报攻击记录。3.3.1 这个版本里，管理端和节点端可以装在同一台机器，也可以分开部署。单机部署适合个人和小团队，一台机器全包；分布式部署适合有多台公网 IP 的场景，管理端放内网，节点端撒到各个公网机器上。

选型上先问自己三个问题：你有几台公网 IP？你打算暴露哪些端口？你能接受多大的日志量？一台 1 核 1G 的机器跑单机版，管理端加几个节点够用，但如果节点开太多、日志量上来，SQLite 写入会成为瓶颈。常见做法是单机版先跑起来看效果，确认有价值再拆分布式。

2.2 部署前的系统准备与依赖检查

Linux 版对系统要求不高，但有几个前置条件必须确认，否则装到一半报错很折腾。先看系统版本和架构，HFish 3.3.1 的 Linux 包一般是 amd64，ARM 机器要确认有没有对应包。

# 查看系统架构，确认是 x86_64 还是 aarch64 uname -m # 查看系统版本，HFish 对 glibc 有要求，太老的系统可能跑不起来 cat /etc/os-release # 查看端口占用，HFish 管理端默认用 4433 和 4434，节点端会监听你配置的蜜罐端口 ss -tlnp | grep -E '4433|4434' # 查看防火墙状态，很多"装好了访问不了"都是防火墙没放行 systemctl status firewalld 2>/dev/null || ufw status 2>/dev/null

uname -m输出x86_64说明是常见架构，直接下对应包；输出aarch64就得找 ARM 版本。ss -tlnp是确认端口没被占，4433 是 Web 管理端口，4434 是节点通信端口，这两个被占会导致启动失败。防火墙这块是血泪经验，云服务器还有安全组，两层都要放行，只改一层等于没改。

提示：部署前先把机器时间同步好，timedatectl看一眼。蜜罐记录的攻击时间如果和真实时间对不上，后面做溯源分析全是错的。

2.3 下载与解压：包结构先看清楚

拿到 Linux 版压缩包后，别急着执行安装脚本，先解压看目录结构，心里有数再动手。

# 创建安装目录，养成好习惯，别在 /root 下乱解压 mkdir -p /opt/hfish && cd /opt/hfish # 解压，具体包名以你下载的为准 tar -zxvf hfish-3.3.1-linux-amd64.tar.gz # 查看解压后的目录结构 ls -la

解压后一般能看到server和node两个目录，或者一个统一的安装脚本。server目录里是管理端程序，node目录里是节点端程序。先ls看清楚再决定装哪个，单机部署两个都要。这一步不涉及复杂参数，但目录权限要注意，别用 root 解压完就不管了，后面程序写日志可能因为权限失败。

3. 单机部署实操：从启动管理端到节点上线

3.1 启动管理端并完成初始化

管理端是入口，先把它跑起来。HFish 3.3.1 的启动方式通常是直接执行二进制或者用自带脚本。

# 进入 server 目录 cd /opt/hfish/server # 赋予执行权限 chmod +x hfish-server # 前台启动，先看日志确认没问题，别一上来就后台 ./hfish-server

前台启动能看到实时日志，如果报错会直接打出来。常见报错是端口被占、配置文件缺失、数据库文件权限不对。确认启动成功后，浏览器访问https://你的IP:4433，注意是 HTTPS，3.3.1 默认走加密。首次访问会有自签证书警告，继续访问即可。默认账号密码在安装文档里有，登录后第一件事是改密码，别用默认的。

初始化界面会让你确认一些基础配置，比如管理端地址、节点通信密钥。这个密钥后面节点端要用，记下来。Web 界面里能看到「节点管理」「蜜罐管理」「攻击记录」几个核心模块，先别急着配蜜罐，把节点加上再说。

3.2 添加节点并配置蜜罐端口

节点端是真正干活的，管理端只是大脑。单机部署时节点也装在同一台机器，但逻辑上要当成独立节点来加。

# 进入 node 目录 cd /opt/hfish/node # 赋予执行权限 chmod +x hfish-node # 启动节点，需要指定管理端地址和通信密钥 ./hfish-node -s 127.0.0.1:4434 -k 你的通信密钥

-s指定管理端地址，单机就是127.0.0.1:4434；-k是刚才记下的通信密钥。启动后回到 Web 界面，节点管理里应该能看到这台节点上线了。如果没上线，先看节点端日志，再看管理端 4434 端口通不通。

节点上线后开始配蜜罐。HFish 内置了多种蜜罐模板，SSH、HTTP、MySQL、Redis 这些常见服务都有。配置逻辑是：选模板 → 绑定节点 → 指定监听端口 → 启动。比如你想看谁在爆破 SSH，就加一个 SSH 蜜罐，监听 2222 端口（别用 22，22 留给真实 SSH）。这里有个关键点：蜜罐端口不能和真实业务端口冲突，否则要么蜜罐起不来，要么把真实服务顶掉。

3.3 验证蜜罐是否真的在工作

配完不是就完事了，得验证它真能抓到东西。最直接的办法是自己从另一台机器扫一下、连一下。

# 从另一台机器测试 SSH 蜜罐端口是否开放 nc -zv 蜜罐IP 2222 # 尝试用错误密码连一下，触发一次攻击记录 ssh test@蜜罐IP -p 2222 # 测试 HTTP 蜜罐 curl -I http://蜜罐IP:8080

nc -zv确认端口通，ssh用错误密码连会触发一次登录失败记录，curl访问 HTTP 蜜罐会留下访问日志。然后回 Web 界面看攻击记录里有没有这几条。如果有，说明整条链路通了；如果没有，按「节点是否在线 → 端口是否监听 → 防火墙是否放行 → 日志是否写入」的顺序排查。这个验证步骤别省，很多人配完以为好了，结果蜜罐根本没起来，白等好几天。

注意：验证时用自己控制的机器，别拿生产环境去扫，也别对别人的 IP 做测试，这是基本底线。

4. 蜜罐模板选择与参数调优：别把所有端口都开成蜜罐

4.1 常见蜜罐模板的适用场景

HFish 3.3.1 内置的模板不少，但不是开得越多越好。开太多端口，一是资源消耗大，二是攻击面反而变乱，三是日志噪音高。按场景选几个高价值的就行。

选模板的原则是：你的真实业务里有什么服务，就开对应的蜜罐。真实环境有 SSH，就开 SSH 蜜罐；有 Web，就开 HTTP 蜜罐。攻击者扫到蜜罐端口，会以为找到了真实服务，然后开始爆破，这些行为全被记录下来。反过来，你开一堆自己业务里根本没有的服务，攻击者一看就知道是蜜罐，反而没价值。

4.2 端口映射与真实业务隔离

蜜罐部署最容易翻车的地方是端口冲突和业务干扰。核心原则：蜜罐端口和真实端口必须错开，且蜜罐不能影响真实业务。

# 查看当前所有监听端口，确认蜜罐端口没被占 ss -tlnp # 如果真实 SSH 在 22，蜜罐 SSH 就换 2222 # 如果真实 Web 在 80/443，蜜罐 HTTP 就换 8080/8443

ss -tlnp列出的端口是已经被占用的，配蜜罐前先看一眼。如果蜜罐端口和真实端口撞了，启动会失败，日志里会写address already in use。另一个隔离点是资源隔离，蜜罐进程别和真实业务抢 CPU 和内存，1 核机器上蜜罐开太多会拖慢真实服务。常见做法是给蜜罐单独限个资源，或者干脆放独立机器。

4.3 日志与数据保留策略

蜜罐跑起来后日志会持续增长，不设保留策略，磁盘迟早满。HFish 的数据存在数据库里，3.3.1 单机版默认用 SQLite，数据量大了查询会变慢。

# 查看数据库文件大小 du -sh /opt/hfish/server/data/*.db # 查看磁盘剩余空间 df -h /opt/hfish

du -sh看数据库涨得多快，df -h看磁盘还剩多少。如果日志量很大，建议在 Web 界面里设置数据保留天数，比如只留 30 天，超期的自动清理。SQLite 单文件在数据量大时写入会锁，如果发现攻击记录写入延迟，考虑换 MySQL 或者拆分布式。这个策略要提前设，别等磁盘满了再处理，那时候蜜罐已经停了，攻击记录也断了。

5. 避坑与排查：HFish 部署中最容易翻车的五个点

5.1 现象：Web 界面打不开，浏览器一直转圈

原因：4433 端口没放行，或者管理端根本没启动成功。云服务器有两层防火墙，系统防火墙和安全组，只放行一层等于没放。

解决：先ss -tlnp | grep 4433确认端口在监听，再检查系统防火墙firewall-cmd --list-ports或ufw status，最后去云控制台看安全组规则。三层都确认了再访问。

5.2 现象：节点显示离线，管理端看不到节点

原因：节点端启动时指定的管理端地址或密钥不对，或者 4434 端口不通。单机部署时有人把-s写成公网 IP，结果回环不通。

解决：单机部署-s用127.0.0.1:4434，分布式部署确认节点能访问管理端的 4434。密钥要和管理端初始化时的一致，复制粘贴别带空格。节点端日志里会写连接失败的原因，先看日志。

5.3 现象：蜜罐端口起来了，但攻击记录里什么都没有

原因：蜜罐模板没绑定节点，或者绑定了但没启动。还有一种情况是端口虽然监听，但蜜罐进程没真正接管，流量没被记录。

解决：Web 界面里确认蜜罐状态是「运行中」，不是「已停止」。然后从外部实际连一下端口，看有没有记录。如果端口通但没记录，检查蜜罐模板配置里的监听地址是不是0.0.0.0，绑成127.0.0.1的话外部连不进来。

5.4 现象：磁盘很快满了，蜜罐自动停止

原因：没设数据保留策略，攻击记录无限增长。公网蜜罐一天被扫几千次很正常，日志量比想象中大。

解决：Web 界面里设置数据保留天数，同时加个磁盘监控。如果已经满了，先清理旧数据，再改策略。SQLite 数据库文件不能直接删，要通过界面或命令清理，直接删文件会导致数据库损坏。

5.5 现象：蜜罐被攻击者识别出来，不再有攻击记录

原因：蜜罐伪装不够真，比如 SSH 蜜罐的 banner 和真实 OpenSSH 差异太大，或者响应时间异常。攻击者扫到之后标记为蜜罐，就不来了。

解决：选模板时优先用高交互模板，banner 尽量贴近真实服务版本。别把所有端口都开成蜜罐，留一些真实服务做掩护。蜜罐的价值在于混在真实业务里，不是单独摆在外面。

6. 进阶：用 HFish 攻击记录做威胁情报分析

蜜罐跑一段时间后，攻击记录里会积累大量数据，这些数据本身就有分析价值。我一般会定期导出记录，做几个维度的统计：攻击来源 IP 的分布、被尝试最多的用户名密码、payload 里的特征字符串。这些能帮你判断当前针对你这类业务的攻击趋势。

具体操作上，HFish 的 Web 界面支持导出攻击记录，导出后可以用脚本做聚合。比如统计 Top 10 攻击源 IP：

import csv from collections import Counter # 读取导出的攻击记录 CSV，字段名以实际导出为准 with open('hfish_attacks.csv', 'r', encoding='utf-8') as f: reader = csv.DictReader(f) ips = [row['source_ip'] for row in reader if row.get('source_ip')] # 统计出现次数最多的 IP counter = Counter(ips) for ip, count in counter.most_common(10): print(f'{ip}: {count} 次')

这段脚本读 CSV，用Counter统计每个源 IP 出现的次数，输出 Top 10。source_ip字段名要按实际导出的列名改，不同版本可能不一样。拿到 Top IP 后，可以进一步看这些 IP 用了哪些用户名密码，判断是不是针对性的爆破。

另一个有价值的分析是看 payload 里的 URL 路径。HTTP 蜜罐记录里会有大量扫描路径，比如/admin、/wp-login.php、/.env，这些路径反映了攻击者在找什么漏洞。把路径聚合一下，能看出当前流行的扫描器在打什么。

验证蜜罐是否有效，不能只看「有没有记录」，要看「记录有没有分析价值」。如果记录里全是无意义的扫描，说明蜜罐伪装不够，或者端口开得太明显。我习惯每隔一段时间把攻击记录导出来跑一遍，看看攻击手法有没有变化。有一次发现某个 IP 连续几天用同一套字典爆破，换了端口还在扫，说明是被针对性盯上了，这种信息比单纯看防火墙日志有用得多。

从那以后我每次部署完蜜罐，都强制走一遍「外部验证 → 记录确认 → 导出分析」的流程，不跳过任何一步。蜜罐这东西，配好只是开始，持续看数据才有价值。希望帮到你。

本文还有配套的精品资源，点击获取