蜜罐部署实战：低交互、中高交互与分布式三类方案全解析

简介这份资源系统讲解蜜罐技术的三种搭建与使用方法重点涉及Defnet、Pentbox以及基于Kali Linux的Cowrie SSH蜜罐。面向网络安全学习者、渗透测试入门者及需要部署诱捕环境的运维人员既有图形化工具的操作演示也有命令行环境的完整配置流程。压缩包内共1个docx文档大小7.96MB内容以图文步骤为主适合对照实操。已有3082人学习下载文档从Pentbox快速自动配置与手动端口监听讲起再到Defnet虚拟Telnet、FTP等服务并配合真实连接捕获攻击记录最后深入Cowrie的安装、Python虚拟环境搭建、SSH端口修改与日志配置。其中对Cowrie依赖报错的排查过程记录详细能帮助读者避开常见环境坑点直接获得可复现的蜜罐部署经验。1. 蜜罐这潭水有多深三种形态各解一道题蜜罐这东西第一次接触的人容易把它当成“抓黑客的工具”实际它更像一面镜子把它放在网络里攻击者一旦碰了它手里的工具、敲过的命令、下载的样本就会原原本本留下来。三种蜜罐分别对应低交互、中高交互和分布式部署低交互像哨兵只接招不反击中高交互能记录完整 SSH 会话分布式蜜罐把前两种收进一个管理台适合攻防演练和告警联动。这份笔记给出一套可以直接照做的蜜罐部署方式从选型、编译、配置到日志读取和常见踩坑点新手能一步步复现熟手可以直接跳到参数调整和验证部分。2. 选型先于搭建三类蜜罐的边界、参数与适用场景2.1 低交互蜜罐用最少资源“接住”自动化攻击低交互蜜罐不提供真实操作系统它只是监听一堆端口对进来的连接做一次协议握手然后把 shellcode 或攻击载荷保存下来。常见的实现是 Dionaea一个用 C 和 Python 写的程序默认监听 21、23、42、53、69、80、135、139、443、445、1433、1723、2323、3306、5060、5061、8080 这些端口。每个端口对应一个协议仿真模块比如 SMB 模块负责 445FTP 模块负责 21MySQL 模块负责 3306。它的价值在于“接住”那些没有人为参与的自动化攻击蠕虫、扫描器、僵尸网络在互联网上随机扫端口扫到低交互蜜罐就触发一次完整的数据捕获。攻击者输入用户名密码低交互蜜罐也能记录但再往后的交互——比如执行命令、下载工具——它接不住。所以它适合放在公网 IP 段做抽样用很低的资源消耗换取一段区域内的攻击情报。资源占用是它最大的优点。一台 1 核 1G 的云主机就能起好几个低交互蜜罐实例日志落本地 SQLite不依赖外部数据库。缺点是攻击者很容易识别连续敲几条命令发现没有真实反馈就会断开连接。如果你要捕获的是“人”而不仅是“扫描器”低交互不够用。2.2 中高交互蜜罐攻击者的每一步都会被记下来中高交互蜜罐比低交互多了一层可交互的虚拟文件系统攻击者登录后敲 ls、cat、wget它都能返回内容整个过程被记录成会话。最具代表性的是 Cowrie基于 Twisted 框架实现的 SSH 和 Telnet 蜜罐。它模拟一个 Linux 环境自带的文件系统镜像fs.pickle里预置了 /bin/ls、/bin/cat、/usr/bin/wget 等常用命令的返回结果。Cowrie 记录的不只是用户名密码还有每次按键的时间戳、执行过的完整命令、下载文件的名称和大小、以及文件内容。攻击者在里面逛一圈等于把攻击习惯和工具集全部交了出来。这种信息粒度是低交互蜜罐给不了的。代价是部署复杂度上来了而且它仍是“模拟”不是真实漏洞。如果攻击者的目标是要打真实漏洞利用发现系统行为跟标准 Linux 对不上就会起疑。另一个代价是攻击者一旦识破蜜罐可能反过来利用它做跳板。所以中高交互蜜罐必须放在隔离网络里对外只开放蜜罐自身需要的端口出方向流量要卡死。2.3 分布式蜜罐管理端统一收口节点按需下发当蜜罐数量超过三五个逐个登录服务器翻日志就变得不现实。分布式蜜罐把“诱饵能力”和“数据收集”拆开节点端负责监听端口、模拟服务管理端负责下发配置、收集攻击记录、做威胁情报聚合和告警推送。HFish 是这个方向的常用方案管理端自带 Web 控制台节点端支持 MySQL、SSH、FTP、Nginx、Web 等几十种蜜罐模板也可以自定义端口。分布式蜜罐适合安全团队长期运营。节点挂在不同的网段管理端集中在一个内网服务器攻击数据统一入库再对接 SIEM 或告警平台。它和单机蜜罐的核心差异在“可管理性”你能在控制台上关闭某个端口、调整某个节点的诱饵类型、查看实时的攻击来源分布而不用登录每台机器敲命令。它也引入了新的依赖管理端挂了节点端就失去配置下发和日志回传的能力节点和管理端之间的通信通道如果被攻击者截获整个蜜网的情报等于白送。所以在部署时管理端要单独放在安全区节点端和管理端的通信要用 token 鉴权并限制来源 IP。对比维度低交互中高交互分布式交互深度只接协议握手完整虚拟 Shell视节点类型而定信息粒度连接、载荷、口令命令、会话、下载文件聚合全部节点数据被识别难度低中中资源消耗低中中高典型工具DionaeaCowrieHFish适合场景公网抽样、情报收集攻击行为分析攻防演练、常态化值守选型没有标准答案关键看你手上有多少 IP、多少人维护、要回答什么问题。只有一两段空闲 IP先跑 Dionaea有专人分析攻击行为再加一台 Cowrie团队要构建常态化监测直接上 HFish 这类分布式平台。3. 低交互蜜罐 Dionaea从编译到用 SQL 翻攻击记录3.1 依赖安装一次装齐五类库Dionaea 推荐用编译安装因为不同 Linux 发行版打包的版本会比较旧。编译前需要先把依赖装齐少一个库编译就会中断而且报错信息不直观容易让人误以为是代码问题。apt-get update apt-get install -y build-essential python3-dev libglib2.0-dev libssl-dev \ libcurl4-openssl-dev libsqlite3-dev libpcap-dev libloudmouth1-dev \ libnl-3-dev libemu-devlibemu 负责 shellcode 检测和模拟执行是 Dionaea 捕获恶意载荷的核心依赖漏掉它编译会直接失败。libpcap 用于抓取网络数据包libssl 用于处理 TLS 加密流量libsqlite3-dev 是日志存储需要。如果你在 CentOS 系系统上编译对应的包名是 glib2-devel、openssl-devel、libpcap-devel、sqlite-devel、libemu-devel用 yum 装即可。依赖装完后建议先用ldconfig -p | grep libemu确认 libemu 已经被系统识别。这一步很多人会忽略结果 configure 阶段提示找不到 emu.h又回头排查。3.2 编译与最小配置端口和下载目录先定好依赖就绪后从官方仓库拉代码进入目录依次执行三条命令。不建议直接用 root 运行编译普通用户加上 sudo 更安全因为 Dionaea 运行时不要求特权端口。cd /opt git clone https://github.com/DinoTools/dionaea.git cd dionaea ./configure --prefix/opt/dionaea --with-python/usr/bin/python3 make -j2 make install--prefix指定安装根目录所有二进制、配置、日志都会装到 /opt/dionaea 下面--with-python绑定 Python 解释器路径。make -j2表示用两个线程并行编译云主机 1 核就把-j2去掉。编译过程大约 5 到 10 分钟看到make install正常结束就说明编译成功。编译完成后最小的配置只需要改一处监听端口和下载目录。默认的 dionaea.conf 放在 /opt/dionaea/etc 下其中 download 模块决定恶意样本保存位置。mkdir -p /opt/dionaea/var/downloads chown -R nobody:nogroup /opt/dionaea/var/downloads我一般会在配置里把 downloads 目录单独指定到数据盘避免系统盘被恶意样本占满。配置项写法是downloads /opt/dionaea/var/downloads日志模块同时开启 sqlite 和 json 两种格式sqlite 方便查询json 方便对接后续的日志采集。出现权限问题的概率不大但如果出现 “Permission denied” 的报错基本就是 nobody 用户对这个目录没有写权限。启动方式可以用 systemd 托管这样重启后能自动拉起。cat /etc/systemd/system/dionaea.service EOF [Unit] DescriptionDionaea Honeypot Afternetwork.target [Service] ExecStart/opt/dionaea/bin/dionaea -c /opt/dionaea/etc/dionaea.conf -p /opt/dionaea/var/dionaea.pid Restarton-failure Usernobody Groupnogroup [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl start dionaea systemctl status dionaea-c指定配置文件路径-p指定 pid 文件位置。启动后先用systemctl status看进程状态再用ss -tlnp | grep dionaea确认端口在监听。如果进程起来了但端口没监听多半是配置里 listen 段写错了地址或者某个端口被其他服务占用。3.3 用 SQLite 读攻击记录字段比日志重要Dionaea 把攻击记录写进 SQLite 数据库默认位置在 /opt/dionaea/var/dionaea.sqlite。用 sqlite3 直接查表是最快的查看方式不需要额外装分析平台。sqlite3 /opt/dionaea/var/dionaea.sqlite \ SELECT connection_type, protocol, local_port, remote_host, remote_port, \ datetime(connection_timestamp,unixepoch) AS attack_time \ FROM connections ORDER BY connection_timestamp DESC LIMIT 20;connections 表里的核心字段是protocol 记录协议类型如 smb、ftp、mssqllocal_port 是蜜罐被触碰的端口remote_host 是攻击者来源 IPconnection_type 标识连接是否成功建立。攻击时间的 unix 时间戳要用 datetime 函数转成可读格式不然满屏数字看不出规律。恶意样本被保存到 downloads 目录后还可以在数据库里对照查询sqlite3 /opt/dionaea/var/dionaea.sqlite \ SELECT d.filename, d.sha256, c.remote_host, \ datetime(d.download_timestamp,unixepoch) FROM downloads d \ JOIN connections c ON d.connection_id c.id ORDER BY d.download_timestamp DESC;拿到 sha256 后可以丢到威胁情报平台比对确认样本归属哪个家族。这里有个习惯值得养成每次分析完一批日志把攻击来源 IP、端口、样本哈希汇总成一张表方便后面跟 Cowrie、HFish 的数据做交叉验证。Dionaea 只负责“接住”分析要自己来做。4. 中高交互蜜罐 Cowrie把 SSH 攻击回放成“剧本”4.1 Docker Compose 部署两条命令起服务Cowrie 有完整的 Docker 镜像比源码部署省去不少依赖问题。官方镜像已经包含了 Twisted 环境、fs.pickle 文件系统镜像和常用工具只需要挂载配置和日志目录。version: 3.3 services: cowrie: image: cowrie/cowrie:latest container_name: cowrie restart: unless-stopped ports: - 2222:2222 - 2223:2223 volumes: - ./cowrie/etc:/cowrie/cowrie-git/etc - ./cowrie/log:/cowrie/cowrie-git/var/log/cowrie - ./cowrie/downloads:/cowrie/cowrie-git/honeypot/downloads端口映射把宿主机的 2222 映射到容器的 SSH 端口2223 是 Telnet 端口。外部扫描器打的是宿主机 IP 的 2222 端口进到容器后由 Cowrie 接管。如果把宿主机的 22 直接映射进去就会占用真实 SSH 端口影响你登录服务器所以一律映射到高位端口。配置文件目录挂载到宿主机后编辑方便不用进容器改文件。第一次启动前先建好目录防止 Docker 帮你用 root 权限创建后续容器内写文件出现权限问题。mkdir -p cowrie/etc cowrie/log cowrie/downloads docker compose up -d docker compose logs -f cowrie启动后看日志里有没有出现Server listening on port 2222之类的行。然后从另一台机器执行ssh -p 2222 root蜜罐IP随便输个密码能登录进去看到一个模拟 Shell说明部署成功。4.2 关键参数主机名、账号库与文件系统Cowrie 的核心配置项在 cowrie.cfg大部分参数用默认值也能跑但有三项建议根据场景调整主机名、账号库、文件系统镜像。hostname svr03 [auth] auth_class UserDB [userdb] users root:123456,ubuntu:toor,admin:admin [shell] filesystem etc/fs.pickle [ssh] listen_endpoints tcp:2222:interface0.0.0.0 [telnet] listen_endpoints tcp:2223:interface0.0.0.0hostname会让攻击者登录后看到的 Shell 提示符像一台真实服务器比如rootsvr03:~#。auth_class改成 UserDB再用users字段定义允许登录的账号密码。这里故意放弱密码就是用来吸引攻击者的。filesystem etc/fs.pickle指定虚拟文件系统镜像文件系统里有哪些命令、哪些目录攻击者执行时就会看到什么。默认的 fs.pickle 包含了一部分常用命令但如果你想自定义比如加一个假的数据库配置文件需要重新生成文件系统镜像cd /cowrie/cowrie-git bin/createfs --addfile files/linux_commands/ls /bin/ls \ --addfile files/linux_commands/cat /bin/cat \ --user root --uid 0 --gid 0--addfile的参数是“本地文件 目标路径”把真实文件塞进镜像后攻击者执行 ls 就会有输出。如果不做这一步攻击者敲命令时返回空结果蜜罐就露馅了。生成新的 fs.pickle 后需要重启容器让配置生效。还有一个容易被忽略的参数是[shell] filesystem里可以加--sudo选项让它伪装成有 sudo 权限的账户。攻击者往往会先敲 sudo -l 试探当前账户权限如果返回 “user is not in the sudoers file”一部分攻击者会直接放弃反过来给出一个可用的 sudo 输出能钓住更多人机交互的试探。4.3 会话回放从 JSON 日志到攻击还原Cowrie 的日志默认分两种cowrie.log 是文本日志cowrie.json 是结构化日志。分析时我建议直接看 JSON字段完整能直接导入 SIEM 或写脚本统计。docker exec -it cowrie /cowrie/cowrie-git/bin/playlog \ --infile /cowrie/cowrie-git/var/log/cowrie/cowrie.json \ --outfile /tmp/cowrie_replay.txtplaylog 会把一次会话里的所有命令按时间顺序回放出来。回放文件里能看到攻击者登录后先执行了uname -a、cat /etc/passwd、wget http://xxx/1.sh这几个动作基本能判断出攻击目的。如果只关心密码爆破可以直接用 jq 从 JSON 里提取登录尝试grep eventid:cowrie.login.success cowrie.json | jq {src_ip, username, password}成功登录和失败登录的 eventid 不同cowrie.login.success 代表攻破了蜜罐账号。把这些成功登录的来源 IP 和密码拉出来你会发现很多攻击者用的是同一个密码字典甚至同一个 IP 在短时间内反复尝试——这就是自动化爆破工具的特征。文件下载事件也值得专门盯cowrie.command.file_download事件里记录了攻击者下载文件的 URL 和保存路径。下载下来的样本放在 honeypot/downloads 目录按时间戳命名。我一般会定期把这些样本打包转给病毒分析团队或者在本地用沙箱跑一遍。Cowrie 的价值在这里体现得最充分它不只是“记录攻击”而是把攻击者的完整动作链存了下来。5. 分布式蜜罐 HFish一个管理端管所有节点5.1 管理端安装一条脚本拉起控制台HFish 的管理端和节点端是分开的两个程序。管理端负责控制台、数据库、告警推送节点端负责真正监听端口。建议把管理端装在一台独立的内网服务器上不要跟业务服务器混用。wget HFish 官方下载地址 tar zxvf hfish-*-linux-amd64.tar.gz cd hfish ./install.shinstall.sh 会检查系统环境、初始化数据库并启动管理端。安装完成后浏览器访问https://管理端IP:4433/web用初始账号密码登录。登录后第一件事是改密码HFish 默认的初始密码在所有版本里都是一样的不改相当于裸奔。管理端本身不需要对外暴露端口它只对节点端开放通信端口。如果管理端被放到公网攻击者可能直接攻击管理端的 Web 服务那就得不偿失了。我一般会在管理端前面加一条安全组策略只允许节点端的 IP 访问通信端口控制台的 4433 只对运维网段开放。5.2 节点接入token 还是端口复用节点端是一个轻量客户端装好之后用 token 向管理端注册。在管理端的“节点管理”页面生成一个 token然后到节点服务器上执行./client -u https://管理端IP:4433 -t token -m 4333-u指向管理端地址-t是注册 token-m是节点与管理端的通信端口。节点端启动后管理端控制台上能看到节点状态变成在线然后就可以给这个节点下发蜜罐类型。新建节点时有个参数值得说明端口复用。同一个节点可以监听多个端口每个端口对应不同的蜜罐模板。比如用 2222 端口模拟 SSH用 3306 端口模拟 MySQL用 8080 端口模拟 Web 服务。这样一台节点服务器就能覆盖多种协议不用为每个协议单独起一台机器。端口复用模式下节点端要确保这些端口没有被其他进程占用。启动前用ss -tlnp检查一遍如果端口被占用了节点端的监听会失败但在管理端上看不到明确报错只会显示“节点在线但无攻击数据”。这是个很容易被忽略的坑。5.3 攻击数据怎么用列表、字段与告警推送节点接入完成后攻击者扫描或连接蜜罐端口事件会实时回传到管理端。控制台的“攻击列表”会展示每次攻击的记录核心字段包括攻击时间事件发生时刻来源 IP攻击者地址目标端口蜜罐被触碰的端口蜜罐类型SSH、MySQL、Web 等攻击载荷记录的攻击样本或命令威胁等级管理端内置规则打的分数据量上来之后建议把攻击列表导出或者通过管理端的 API 接口把数据拉到 SIEM 里做关联分析。我在实战中会把 HFish 的攻击记录和 Cowrie 的会话回放放在同一个时间轴上对比HFish 抓到的是“谁打了哪些端口”Cowrie 记录的是“登录进来后做了什么”两者互补才是一条完整的攻击链。告警推送是分布式蜜罐最实用的功能之一。在管理端配置 Webhook 地址对接钉钉、企微或飞书机器人当攻击来源 IP 命中威胁情报库时立即推送。curl -X POST https://webhook.example.com/send \ -H Content-Type: application/json \ -d {msg_type:text,content:蜜罐告警来源 IP 命中高危情报}这一段不是 HFish 自身的推送代码而是验证 Webhook 连通性的通用方式。配置完成后去节点上手动触发一次连接比如用nc -zv 节点IP 2222扫一下 SSH 端口几秒内管理端就会产生一条攻击事件并触发推送。如果没收到优先检查 Webhook 地址能否从管理端出网访问以及管理端所在服务器是否封了出方向的 443 端口。6. 蜜罐部署常见问题避坑与验证现象、原因和解决6.1 端口扫不到先查依赖和占用再查策略现象蜜罐进程启动了但从外部用 nmap 扫端口全是 closed。 原因常见的是依赖不完整导致监听失败或者端口被防火墙拦住了。 解决先在宿主机上执行ss -tlnp | grep 蜜罐端口确认端口确实在监听再检查云平台安全组和本机 iptables重点看入方向有没有放行对应 TCP 端口。如果本地能看到监听但外部扫不到问题基本不在蜜罐在你前面的防火墙策略上。6.2 只有内网攻击记录部署位置错了现象Dionaea 跑了一周日志里全是内网 IP 的扫描没有一条公网来源。 原因蜜罐被放在核心交换机的旁路互联网上的扫描流量根本到不了这个网段。 解决把蜜罐节点移到边界 DMZ 区或者单独申请一个公网 IP。没有公网 IP 的情况下可以用防火墙的 DNAT 规则把空闲公网地址的流量引到蜜罐上。注意只做目标地址转换不要把真实业务的 IP 引走。位置对了攻击来源分布会从清一色内网变成全球 IP。6.3 蜜罐被反噬成跳板出方向必须封现象攻击者识别出蜜罐后在里面装了一些工具继续扫描了内网其他主机。 原因蜜罐所在网段没有跟生产网隔离出方向的流量完全放开攻击者把它当跳板用了。 解决蜜罐服务器必须单独划 VLANiptables 上只放行到管理端和 NTP 的出方向流量其他出方向全部 DROP。这一步不做蜜罐就不是诱饵而是你亲手放进内网的暗门。高交互蜜罐尤其要小心Cowrie 虽然是模拟系统但宿主机出了问题就是另一回事。6.4 验证三连端口、日志、告警都通才算部署完部署完蜜罐后我习惯做三件事从外网扫一次端口确认服务可见手动打一次攻击确认日志里有记录触发一次告警确认通知能收到。三样都通这个蜜罐才算真正“上班”否则它只是一台吞流量的黑匣子。nmap -sV -p 2222 蜜罐IP nc -zv 蜜罐IP 2222nmap 用于确认服务 bannernc 用于快速验证端口连通性。之后回到日志目录确认产生了对应记录。这套流程看着简单但能避免大多数“装完就没管过”的状况。我自己的教训是最早搭 Dionaea 时装完只看进程状态没测端口结果防火墙规则一直没放行白白跑了一周零数据。那次之后验证三连就成了固定动作。希望帮到你。本文还有配套的精品资源点击获取