三种蜜罐搭建实战：Pentbox、Defnet与Cowrie从入门到取证

简介：这份文档面向网络安全初学者与渗透测试爱好者，围绕 Defnet、Pentbox、Cowrie 三种蜜罐工具，讲解从环境准备到实际搭建、配置与使用的完整流程，帮助读者理解蜜罐的诱捕原理并动手完成实验。资源包内共 1 个 docx 文件，约 7.96MB，以图文步骤形式记录了 Pentbox 在 Kali 下的下载解压与端口监听设置、Defnet 虚拟 Telnet 服务及监视器配置、Cowrie 的依赖安装与 SSH 端口修改等关键环节，并附有访问测试与日志观察结果。内容兼顾快速自动配置与手动自定义两种方式，便于对照复现。目前已有 3083 人学习下载，适合作为课程实验、安全入门练习或蜜罐部署参考，读者可从中获得三种工具的配置思路、常见依赖报错的处理方向以及验证蜜罐是否生效的观察方法。

1. 三种蜜罐搭建实录：从 Pentbox 到 Cowrie，把攻击流量引进来

很多人对蜜罐的印象还停留在“装个软件、开个端口、等鱼上钩”，真到动手才发现，端口映射、日志权限、伪装盘符这些细节才是决定蜜罐能不能骗到人的关键。这份资源把 Pentbox、Defnet、Cowrie 三种蜜罐的搭建过程串成了一条线：Pentbox 用 Ruby 写、跨平台、几分钟就能在 80 端口立起一个低交互陷阱；Defnet 靠图形界面虚拟 Telnet、FTP、SMTP 等服务，还能伪造磁盘卷标和 MAC 地址；Cowrie 则是中等交互的 SSH 蜜罐，能记录暴力破解字典、攻击者输入的命令和上传的恶意文件。三种工具覆盖了从“快速验证”到“深度取证”的不同需求，适合做安全实验、内网威胁感知和攻击行为分析的人照着复现。

2. Pentbox：Ruby 写的低交互蜜罐，五分钟立起 80 端口陷阱

Pentbox 的定位很明确——它不是那种要调半天配置的重型蜜罐，而是一个把渗透测试流程化的小套件，蜜罐只是其中一个模块。用 Ruby 编写、面向 GNU/Linux，同时也能跑在 Windows、macOS 和任何装了 Ruby 的系统上。选它的理由就一个字：快。想验证“我这个网段有没有人在扫端口”，Pentbox 从下载到监听不超过五分钟，适合做第一层诱饵。

2.1 下载、解压与启动

在 Kali 环境下，整个准备过程就是三条命令。注意 Pentbox 1.8 的包在 SourceForge 上，下载链接会跳转，wget 要加--trust-server-names或者手动跟一次重定向，否则拿到的可能是个 HTML 页面而不是 tar.gz。

# 下载 pentbox-1.8，跟随重定向并保留服务器给出的文件名 wget --trust-server-names https://sourceforge.net/projects/pentbox18realised/files/latest/download/pentbox-1.8.tar.gz # 解压 tar -zxvf pentbox-1.8.tar.gz # 进入目录并查看内容 cd pentbox-1.8/ ls # 启动主程序 ./pentbox.rb

这里有个血泪经验：./pentbox.rb直接执行的前提是文件有可执行权限且 Ruby 解释器路径正确。如果报bad interpreter，先chmod +x pentbox.rb，再确认ruby -v能正常输出。Pentbox 对 Ruby 版本不挑，但老版本 Ruby 3.x 上部分语法会告警，能跑就先跑，别在版本上纠结太久。

启动后是菜单式交互：输入 2 进入 Network Tools，再选 3 进入 Honeypot。此时会出现两个选项——快速自动配置和手动配置。快速模式直接把监听端口定在 80 并开始监听，适合“先看看有没有流量”的场景；手动模式可以自定义端口、错误提示信息、是否保存 log、是否蜂鸣报警，适合需要区分服务类型的实验。

2.2 快速模式与手动模式的参数差异

快速模式选完后，终端会打印HONEYPOT ACTIVATED ON PORT 80。此时用浏览器访问http://<你的IP>，页面返回Access denied，同时终端出现INTRUSION ATTEMPT DETECTED。这条记录就是蜜罐的核心产出——它证明有人碰到了这个端口。

手动模式的配置项值得逐项说清楚，因为这几个参数直接决定蜜罐的“可信度”：

手动模式配完后，用 telnet 测 23 端口，终端会实时打印连接记录。同理可以开 21、22、443，Pentbox 对端口不挑，同一个进程换个端口就是另一个诱饵。这里要注意：Pentbox 是低交互蜜罐，它只记录“有人连进来了”，不会模拟完整的服务握手，攻击者用 nmap 一探就能看出服务指纹不对。所以它适合做流量感知，不适合做深度取证。

提示：Pentbox 监听 80 端口时如果本机已有 Web 服务占用，会直接绑定失败。先ss -lntp | grep :80确认端口空闲，再启动蜜罐。

3. Defnet：图形化虚拟服务，把 Telnet 伪装做得像真的

Defnet 和 Pentbox 走的是两条路。Pentbox 是命令行、轻量、快；Defnet 是图形界面、重伪装、配置项细。它的核心能力是虚拟 Web、FTP、SMTP、Finger、POP3、Telnet 六类服务，并且在 Advanced 里能伪造驱动器盘符、卷标、目录创建时间、剩余磁盘空间、MAC 地址和网卡类型。这些参数不是花架子——攻击者连上 Telnet 后第一件事往往是dir或ls看目录，如果盘符和剩余空间明显是默认值，老手一眼就识破。

3.1 虚拟 Telnet 服务的配置流程

整个流程分两步：先在 HoneyPot 按钮里配服务，再在 Monitore 里开监听。以虚拟 Telnet 为例，用户名设root、密码设123456（实验环境用弱口令是故意的，为了吸引暴力破解），然后在 Advanced 里把伪装参数填上：

配完后按 Monitore 开始监听。此时在另一台机器上telnet <蜜罐IP>，输入 root/123456，Monitore 窗口会完整记录连接、用户名、密码输入和超时/成功状态。这套记录的价值在于：你能看到攻击者尝试了哪些用户名、密码组合，以及连上之后执行了什么命令。

3.2 监听记录怎么读

Defnet 的 Monitore 记录是按会话组织的，每条包含时间、源 IP、目标服务、交互内容。实际使用时重点看三样：一是登录尝试的账号密码对，这是暴力破解字典的直接来源；二是登录成功后的命令序列，能看出攻击者的意图（是找文件、提权还是横向）；三是连接超时和断开的时间点，用来判断是人工操作还是自动化扫描。

有个容易翻车的地方：Defnet 跑在物理机上，虚拟机里的攻击流量要能路由到物理机 IP。实验时先ipconfig确认物理机地址，再在虚拟机里telnet过去，如果连不上，先查物理机防火墙有没有放行对应端口，而不是怀疑 Defnet 配置错了。另外 Defnet 的虚拟服务是“应答式”的，它不会真的执行命令，攻击者执行cat /etc/passwd只会得到预设的假输出，这一点在分析记录时要心里有数，别把假回显当成真实文件泄露。

4. Cowrie：中等交互 SSH 蜜罐，抓字典、抓命令、抓恶意文件

Cowrie 是三种里交互层级最高的一个。它模拟一个完整的 SSH 服务，攻击者能真正登录进来、执行命令、上传下载文件，但所有操作都在受控的假文件系统里，执行恶意文件也不会真的落地运行。它产出三类高价值数据：暴力破解用的字典、攻击者输入的命令序列、上传或下载的恶意样本。对做威胁情报和攻击链分析的人来说，这三样比“有人连进来了”有用得多。

4.1 安装与 Python 虚拟环境

Cowrie 装在 Kali 上，全程用非 root 用户跑，这是安全基线。先建用户、设密码，再装依赖。注意原文里的包名是 Python 2 时代的写法，实际环境里如果系统默认 Python 3，python-twisted这类包名要换成python3-twisted，或者直接用 virtualenv 隔离，避免污染系统 Python。

# 创建非 root 用户 honey，-r 表示系统用户，-m 建家目录，-s 指定 shell useradd -r -m -s /bin/bash honey passwd honey # 实验环境设为 123456 # 安装 Python 相关依赖（Python 3 环境把 python- 前缀换成 python3-） apt-get install -y python3-twisted python3-crypto python3-pyasn1 \ python3-gmpy2 python3-mysqldb python3-zope.interface # 安装 virtualenv apt-get install -y virtualenv # 下载 cowrie 到 /opt cd /opt git clone https://github.com/cowrie/cowrie.git # 建虚拟环境并激活 cd /opt/cowrie virtualenv env source env/bin/activate # 在虚拟环境里装依赖 pip install twisted cryptography pyopenssl gmpy2

pip install这一步大概率会报错，缺的是编译依赖。补上python3-cffi libffi-dev libssl-dev libgmp-dev libmpfr-dev libmpc-dev再重跑即可。这类报错不是 Cowrie 的问题，是 cryptography 和 gmpy2 需要本地编译工具链，装完依赖就过。

4.2 配置文件与端口转发

装完依赖后改属主、建配置、调 umask、改监听端口。这几步的顺序不能乱，尤其是 umask，默认 0077 会导致日志文件只有属主可读，后续分析脚本用别的用户跑就会读不到。

# 把 cowrie 目录交给 honey 用户 chown -R honey:honey /opt/cowrie # 从模板生成配置文件 cp cowrie.cfg.dist cowrie.cfg # 修改 start.sh 里的 umask，从 0077 改为 0022 cd /opt/cowrie sed -i 's/umask 0077/umask 0022/' start.sh # 修改蜜罐 SSH 监听端口，默认 2222，改成 63333 避开常见扫描 sed -i 's/^listen_port.*/listen_port = 63333/' cowrie.cfg

端口选 60000 以上是有讲究的：nmap 默认只扫前 1000 个常用端口，蜜罐端口放高位能减少被自动化扫描直接命中的概率，让真正的人工攻击者先碰到伪装端口。接下来做端口转发，把公网访问 22 的请求重定向到蜜罐端口，同时把真实 SSH 挪到另一个端口，避免自己把自己锁在外面。

# 把进入 22 端口的流量重定向到蜜罐的 63333 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333 # 真实 SSH 改到 62225，改完重启服务 sed -i 's/^Port 22/Port 62225/' /etc/ssh/sshd_config service ssh restart

注意：iptables 规则重启后会丢失，实验环境用iptables-save存一下，或者写进开机脚本。改真实 SSH 端口前先确认新端口能连上，再关旧端口，否则就是自己给自己上锁。

4.3 启动、验证与日志解读

切到 honey 用户启动蜜罐，缺依赖就补configparser service_identity pycrypto tftpy。启动成功后用另一台机器ssh -p 63333 honey@<蜜罐IP>连接，能看到蜜罐返回的欢迎信息。此时cowrie.log记录原始文本，cowrie.json记录结构化事件，后者更适合做后续分析。

# 切用户并启动 su honey cd /opt/cowrie bin/cowrie start # 查看实时日志 tail -f var/log/cowrie/cowrie.log # 结构化事件按行解析，提取登录尝试 python3 -c " import json with open('var/log/cowrie/cowrie.json') as f: for line in f: e = json.loads(line) if e.get('eventid') == 'cowrie.login.failed': print(e['timestamp'], e['username'], e['password']) "

这段脚本的作用是把 JSON 日志里登录失败的事件抽出来，username和password字段就是攻击者尝试的字典。跑一段时间后，这些账号密码对可以直接喂给防护规则做黑名单。cowrie.log里还能看到攻击者登录后执行的命令，比如ping www.baidu.com这类探测，说明对方在确认网络连通性——这是蜜罐环境里很典型的“踩点”行为。

5. 避坑与排查：三种蜜罐最容易翻车的五个地方

5.1 端口被占用导致蜜罐静默失败

现象：Pentbox 选完快速模式，终端没打印HONEYPOT ACTIVATED，浏览器访问也没反应。原因：80 端口已被本机 Web 服务占用，绑定失败但部分版本不报错。解决：启动前ss -lntp | grep :80确认空闲，或改用手动模式换端口。

5.2 Cowrie 日志读不到或权限拒绝

现象：分析脚本报Permission denied，但文件明明存在。原因：start.sh里 umask 还是 0077，日志只有 honey 用户可读。解决：按 4.2 改成 0022，重启蜜罐后新日志才生效，旧日志要手动chmod。

5.3 iptables 转发后自己连不上真实 SSH

现象：配完 22 到 63333 的重定向，自己的 SSH 会话断开后再也连不上。原因：真实 SSH 端口改了但服务没重启，或者新端口被防火墙拦了。解决：改端口后先ss -lntp | grep 62225确认监听，再从另一台机器验证，最后才关旧会话。

5.4 Defnet 虚拟服务被 nmap 识破

现象：nmap 一扫就标出“不是真实服务”。原因：Defnet 的应答指纹和真实服务有差异，低交互蜜罐的通病。解决：接受这个边界，Defnet 用来抓人工交互和弱口令尝试，别指望它骗过自动化指纹识别；要更深交互就上 Cowrie。

5.5 蜜罐把攻击流量引到自己生产环境

现象：蜜罐和真实业务在同一网段，攻击者从蜜罐横向摸到了真实主机。原因：网络隔离没做，蜜罐成了跳板。解决：蜜罐单独放一个 VLAN 或实验网段，只允许 inbound，限制 outbound，别让蜜罐有访问内网其他主机的路由。

6. 进阶：把三种蜜罐的日志汇到一起看

单看一种蜜罐的日志，信息是碎的。Pentbox 告诉你“有人在扫 80”，Defnet 告诉你“有人用 root/123456 连 Telnet”，Cowrie 告诉你“这个人登录后跑了 ping 和 whoami”。把三份日志按源 IP 和时间窗口对齐，才能拼出一次完整攻击的轮廓。我一般会写个小脚本做归一化：Pentbox 的文本日志按行正则提取 IP 和时间，Defnet 的记录导出成 CSV，Cowrie 直接读cowrie.json，统一成timestamp, src_ip, honeypot, event, detail五列，再按src_ip分组排序。

import json, re, csv from datetime import datetime rows = [] # Cowrie：结构化 JSON 直接取字段 with open('var/log/cowrie/cowrie.json') as f: for line in f: e = json.loads(line) if e.get('eventid', '').startswith('cowrie.login'): rows.append([e['timestamp'], e['src_ip'], 'cowrie', e['eventid'], f"{e.get('username')}/{e.get('password')}"]) # Pentbox：文本日志按正则抽 IP 和时间 pat = re.compile(r'(\d+\.\d+\.\d+\.\d+).*?(\d{2}:\d{2}:\d{2})') with open('pentbox.log') as f: for line in f: m = pat.search(line) if m: rows.append([m.group(2), m.group(1), 'pentbox', 'connect', line.strip()]) # 按源 IP 聚合，同一 IP 跨蜜罐出现就是高优先级线索 rows.sort(key=lambda r: (r[1], r[0])) with open('merged.csv', 'w', newline='') as f: csv.writer(f).writerows(rows)

这段脚本的关键在最后一步排序：按src_ip再按时间排，同一个 IP 在 Pentbox 上扫完 80 又去 Defnet 试 Telnet、最后在 Cowrie 上登录成功，这条时间线就是一次完整的攻击链。参数上唯一要调的是时间格式，Pentbox 的日志时间戳可能不带日期，跨天分析时要补上日期字段，否则排序会乱。

验证蜜罐有没有真正起作用，别只看“有没有记录”，要看记录里有没有“交互深度”。只有连接记录说明是扫描器；有登录尝试说明是暴力破解；有登录成功后的命令序列说明是人工攻击者。三种蜜罐分别对应这三个深度，Pentbox 抓第一层，Defnet 抓第二层，Cowrie 抓第三层。从那以后我每次搭蜜罐，都会先问自己这次要抓哪一层，再决定用哪个工具、端口开在哪、日志往哪落，而不是三个一起上把日志搅成一锅粥。希望帮到你。

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