蜜罐部署排障：Pentbox、Cowrie与Defnet端口日志实战

简介：《三种蜜罐的搭建与使用方法》是一份面向网络安全初学者、渗透测试入门者及实验教学场景的实操型文档，围绕 Defnet、Pentbox 与 Cowrie 三类蜜罐的部署和使用展开，帮助读者理解低交互与中交互蜜罐在攻击诱捕、行为监测和日志记录中的差异。资源包仅含 1 个 docx 文件，大小约 7.96MB，内容以图文记录和配置说明为主，便于在本地或 Kali 实验环境中对照阅读。文档覆盖 Pentbox 的端口监听与访问告警、Defnet 虚拟 Telnet 服务及连接过程监视、Cowrie 的 SSH 蜜罐安装配置与日志关注点，并涉及虚拟服务伪装、监听端口选择、运行环境依赖处理等常见问题。已有 3085 人学习，适合用于课程实验、安全练习和蜜罐方案选型参考，也可作为搭建与排错时的查阅材料。

1. 蜜罐挂上去三天零日志：不是攻击者不来，是你根本没收流量

蜜罐这类东西最容易给人错觉——搭完盯着控制台，空空如也，第一反应是“没人攻击我”。实际上九成情况是端口没监听、转发没生效、日志没写权限。我见过最典型的一次：某开发者把 Cowrie 的 listen_port 改成了 63333，iptables 却还 REDIRECT 到 2222，而真实 sshd 又被搬去了 62225，外部打进 22 的流量全落进一个没人监听的洞里，三天日志干干净净，他还以为是实验室网段太干净。Pentbox 更直接，Ruby 没装、脚本没加执行位，菜单都进不去；Defnet 图形界面点得飞快，结果监听在了错误的网卡上，攻击机连过去只会超时。这三套工具本身门槛都不高，坑几乎全集中在“运行环境、端口对齐、文件权限”这三件事上，下面按报错现场一个个拆。

2. Pentbox 起不来：Ruby 解释器、执行位与 80 端口占用

Pentbox 是个用 Ruby 写的安全套件，除了蜜罐还带一堆网络工具，所以它不像编译型程序那样丢个二进制就能跑，运行时依赖没配好，你连主菜单都看不到。这一章按“跑不起来 → 跑起来不监听 → 监听了收不到”三段来拆，基本覆盖了新手在这套工具上翻车的全部姿势。

2.1./pentbox.rb: No such file or directory其实是解释器缺失

第一次拿到 pentbox-1.8.tar.gz，很多人的操作顺序是解压、cd进去、直接./pentbox.rb，然后终端回一句bash: ./pentbox.rb: /usr/bin/env: bad interpreter: No such file or directory，或者干脆No such file or directory。这句话极具误导性，因为文件明明就在眼前。真实原因是脚本首行的 shebang 写的是#!/usr/bin/env ruby，而当前系统里根本没有 ruby 这个可执行文件，内核把“找不到解释器”报成了“找不到文件”。

常见做法是先确认解释器和执行位，再决定要不要换 Ruby 版本：

# 1. 确认 ruby 是否真的存在，以及版本 which ruby || echo "ruby 未安装" ruby -v 2>/dev/null # 2. Debian / Kali 系安装 ruby 与解压工具 apt-get update apt-get install -y ruby tar # 3. 解压并定位真正的入口脚本 cd /opt tar -zxvf pentbox-1.8.tar.gz find . -maxdepth 3 -name "pentbox.rb" # 4. 补上执行位，再运行 cd /opt/pentbox-1.8 ls -l pentbox.rb # 正常应带 x 位：-rwxr-xr-x chmod +x pentbox.rb ./pentbox.rb

which ruby用来确认 PATH 里有没有解释器，ruby -v顺带看版本；find -name pentbox.rb是因为有些压缩包会多套一层同名目录，直接cd容易进错地方；chmod +x补的是执行位，缺了它终端会报Permission denied，那是另一种错，别和解释器缺失混在一起。如果 ruby 装完仍然报语法错，比如syntax error, unexpected ...，多半是发行版自带的 Ruby 3.x 和新版语法检查更严格，而这个 1.8 版脚本年纪不小了。我一般的处理是装一个 2.x 的 Ruby 环境跑它，或者干脆把 Pentbox 丢进一个独立的容器里，别污染主机环境。

2.2 菜单进得去，选完快速配置却没监听：80 端口被人占了

进到主菜单之后，路径是2（Network Tools）→3（Honeypot）→1（Fast Auto Configuration），这套快速模式会直接把监听端口定死成 80，并且立刻开始等待连接。问题是 80 是个兵家必争之地，Apache、Nginx、某些面板、甚至你之前跑挂没退出的 pentbox 进程，都可能已经蹲在上面。这时候表现有两种：一种是脚本直接抛Address already in use，另一种更阴——脚本不报错，但外部访问没有任何响应，因为绑定失败了但错误被吞了。

先确认端口占用情况再动手，不要盲猜：

# 看 80/23/22 三个常用端口被谁占着 ss -lntp | grep -E ':(80|23|22)\b' # 老系统没有 ss 就用 netstat netstat -lntp | grep -E ':(80|23|22)\b' # 确认 pentbox 进程是否已经在后台跑着 ps -ef | grep -i pentbox | grep -v grep # 需要腾出 80 就先停掉常见的两个 Web 服务 systemctl stop apache2 2>/dev/null systemctl stop nginx 2>/dev/null

ss -lntp里的-l只看监听态，-n不做域名解析（快），-t限 TCP，-p显示进程名和 PID，一眼就能看出 80 是被 httpd 还是被 ruby 占着。ps -ef | grep是防止上一次 pentbox 没退出还挂着——它前台跑的时候看着像卡住，很多人会开第二个终端再跑一遍，两个进程抢同一个端口，谁也别想监听成功。停服务这两条加了2>/dev/null，是因为机器上未必装了 apache2 或 nginx，报“unit not found”不影响后续操作。

如果你不想动主机上已有的 Web 服务，就别用快速模式，改走2（Manual Configuration），它会依次问你四件事：监听端口、返回给访问者的错误提示、是否保存日志以及日志文件名、是否开启蜂鸣报警。这一步选择高位端口更稳妥：

# Manual Configuration 之后自检 ss -lntp | grep ruby # 期望看到类似：LISTEN 0 128 0.0.0.0:8080 users:(("ruby",pid=...,fd=...))

注意0.0.0.0:8080这个绑定地址很关键。如果显示的是127.0.0.1:8080，说明它只监听本地回环，外部机器永远连不上，这时候要在配置里改用0.0.0.0或者直接监听指定网卡地址。手动模式下还有一个高频误操作：错误提示串里带了空格和特殊字符，脚本处理参数时会被截断，建议只写纯字母数字，比如Access denied。

2.3 浏览器访问不到 Access denied：先分清是网络不通还是蜜罐没应答

本地监听正常之后，从另一台机器打开http://<蜜罐IP>，理论上会看到一个Access denied页面，同时运行 pentbox 的终端刷出HONEYPOT ACTIVATED ON PORT 80和INTRUSION ATTEMPT DETECTED两行。看不到这两行，先别怀疑工具本身，按“本机自测 → 同网段他机测试 → 抓包”三层往下压。

# 第一层：在蜜罐本机自测，排除脚本本身问题 curl -v http://127.0.0.1:8080/ # 第二层：从同网段另一台机器测试 curl -v http://192.168.44.130:8080/ # 第三层：在蜜罐主机抓包，看请求到底有没有进来 tcpdump -i any -nn port 8080 -c 20

curl -v会打印完整握手过程，如果本机能拿到响应、他机超时，问题一定在网络层，跟 pentbox 没关系——常见的是虚拟机网卡设成了 NAT，攻击机在另一个网段，或者主机防火墙把入站 8080 拦了。tcpdump -i any -nn port 8080里-i any抓所有网卡，-nn不做主机名和端口解析，-c 20抓二十个包就停，避免刷屏。只要 tcpdump 里看不到 SYN 包，就说明流量根本没到这台机器，回头去查网段和防火墙，不要在蜜罐配置上浪费下一小时。

还有一个不那么明显的坑：用https://去访问一个只讲 HTTP 的蜜罐，浏览器会先尝试 TLS 握手，pentbox 收到一堆二进制直接当垃圾丢掉，页面上什么也没有，但终端里其实已经记录了入侵尝试。看到“终端有记录、浏览器没页面”这种组合，先确认地址栏协议。

3. Cowrie 装不上、起不动：pip 编译中断与缺失模块

Cowrie 是目前用得最多的中等交互 SSH 蜜罐，它能把攻击者暴力破解用的字典、敲进去的命令、上传下载的文件全部录下来，而且攻击者上传的可执行文件在蜜罐里跑不起来，对宿主机相对安全。但它对 Python 环境的挑剔程度也是三套里最高的，装一遍下来能踩到四五种不同的报错。

3.1Unable to locate package python-twisted：Python 2 时代的老依赖

照着老文档走，第一条 apt 安装命令就会卡住：apt-get install -y python-twisted python-crypto python-pyasn1 python-gmpy2 python-mysqldb python-zope.interface，终端返回一串E: Unable to locate package。根因不是源配错了，而是这套包全是 Python 2 时代的产物，新版本系统已经默认只保留 Python 3，对应的 python-xxx 包被整体移除，你在源里翻多久都翻不出来。

正确的做法是跳过系统包，用 Python 3 的虚拟环境装依赖，别和系统包管理器硬碰：

# 1. 建立专用低权限账号，蜜罐绝不能拿 root 跑 useradd -r -m -s /bin/bash honey passwd honey # 交互输入密码 # 2. 装 Python3 基础工具链 apt-get install -y python3 python3-pip python3-venv git # 3. 拉取源码到 /opt 下 cd /opt git clone <cowrie 仓库地址> cowrie cd /opt/cowrie # 4. 建虚拟环境并激活 python3 -m venv env source env/bin/activate python -V # 确认进的是 3.x 而不是系统 python # 5. 在虚拟环境里装运行时依赖 pip install --upgrade pip pip install twisted cryptography pyopenssl gmpy2 configparser service_identity pycryptodome tftpy

这里几个选择值得说明：useradd -r -m里的-r建的是系统账号，-m保证有家目录，-s /bin/bash是给它一个能登录的 shell，因为后面要用su honey切过去启动服务；用python3 -m venv而不是老的virtualenv，是因为前者随 Python 自带，少一个依赖少一个坑；pycryptodome顶替老文档里的pycrypto，后者在 Python 3.8 之后基本编译不过。激活虚拟环境之后所有 pip 操作都落在env/目录里，系统 Python 一点不受影响，这一点在蜜罐这种“装一堆冷门包”的场景下特别重要。

3.2 pip 装到一半报ffi.h: No such file or directory：缺的是开发头文件

虚拟环境建好后执行pip install twisted cryptography pyopenssl gmpy2，很容易在编译cffi或cryptography时中断，报fatal error: ffi.h: No such file or directory或者openssl/opensslv.h: No such file or directory。这是 C 扩展在编译期找不到系统头文件，pip 本身没问题，缺的是发行版级别的开发包。

# 补齐 C 扩展编译所需的头文件和链接库 apt-get install -y build-essential python3-dev apt-get install -y libffi-dev libssl-dev apt-get install -y libgmp-dev libmpfr-dev libmpc-dev # 装完回到虚拟环境重跑 source /opt/cowrie/env/bin/activate pip install twisted cryptography pyopenssl gmpy2

build-essential提供 gcc 和 make，没有它连编译都启动不了；python3-dev提供Python.h，是 Python C 扩展的入口；libffi-dev对应ffi.h，libssl-dev对应 OpenSSL 头文件，这两个是最常见的两个“编译中断点”；libgmp-dev、libmpfr-dev、libmpc-dev是给gmpy2用的，缺了它在大整数运算相关的编译上会挂。

装完依赖还是失败的话，看 pip 输出的最后二十行，真正的原因就在那儿，前面大段是编译日志噪音。我一般会加--no-cache-dir重试一次，排除半成品缓存导致的诡异失败：

pip install --no-cache-dir twisted cryptography pyopenssl gmpy2

3.3 启动报ModuleNotFoundError：少哪个补哪个，别整套重装

终于到了启动环节，bin/cowrie start一执行，日志里刷ModuleNotFoundError: No module named 'configparser'，或者 TLS 相关的service_identity缺失告警。这类错误信息非常明确，缺什么装什么就行，不需要推倒重来：

# 补装启动阶段报缺的模块 pip install configparser service_identity pycryptodome tftpy # 用 honey 身份启动，避免生成 root 属主的文件 chown -R honey:honey /opt/cowrie su honey cd /opt/cowrie bin/cowrie start # 启动结果看日志，不要只看终端 tail -f var/log/cowrie/cowrie.log

configparser在 Python 3 里其实是标准库，但老版本 Cowrie 的代码路径是import configparser的兼容写法，某些分支下会去 site-packages 找同名包，补一个能直接绕过去；service_identity不装，Twisted 在 TLS 校验时会抛警告甚至拒绝连接，表面现象是“蜜罐起来了但 SSH 连不上”；tftpy只在开 TFTP 服务时才用到，不开可以跳过。

chown -R honey:honey和su honey这两步的顺序千万别颠倒。如果先用 root 启动一遍再看日志，日志目录和主机密钥文件都会变成 root 属主，之后切回 honey 用户启动，直接报权限拒绝，而且报错信息里不一定提到权限，很容易误判成配置问题。踩过一次之后我固定成“先改属主，再切用户，最后启动”的顺序。

3.4 改端口把自己改断了：listen_port、iptables、sshd 三处必须对齐

为了让攻击者打到 22 端口的流量进蜜罐，标准做法是改蜜罐监听端口、做本机端口重定向、把真实 sshd 挪走。这三步任何一步的数字对不上，结果就是“蜜罐在跑，但一个连接都收不到”。原文里就出现过转发目标端口和实际监听端口不一致的情况，这类问题在真实环境里极其常见。

# 1. 改蜜罐监听端口（默认 2222），用高位端口降低被扫描器直接发现的概率 cd /opt/cowrie vi cowrie.cfg # listen_port = 63333 # 2. 修正日志 umask，默认 0077 会让日志只有属主可读 vi start.sh # umask 0077 -> umask 0022 # 3. 把外部打到 22 的流量重定向到蜜罐端口（注意 to-port 要和 listen_port 一致） iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333 # 4. 真实 sshd 挪到另一个端口，别和自己抢 22 vi /etc/ssh/sshd_config # Port 62225 systemctl restart ssh # 5. 核对三方端口是否自洽 ss -lntp | grep -E ':(22|63333|62225)\b'

REDIRECT是 nat 表里的本机重定向目标，--dport 22匹配进入本机 22 的连接，--to-port 63333把它改写到蜜罐端口，蜜罐只需监听本机任意地址即可收到。这里最容易犯的错是“转发目标写成 2222，蜜罐监听改成 63333”，两个数字各改各的，谁也不知道对方变了。ss -lntp那一行是最后的保险：22 上不该有 sshd 监听（因为流量要走 NAT 跳转），63333 上应该有 cowrie，62225 上应该有 sshd。三者对不上，就别往下测了。

还有一条容易被忽略：REDIRECT只对“进入本机”的流量生效，从本机自己发起ssh -p 22 127.0.0.1走的是 OUTPUT 链，压根不经过 PREROUTING。很多人拿本机自测，发现转发“没生效”，其实配置是对的，必须从另一台机器发起才算数。

4. Defnet 连上就断：客户端、网段与伪装参数

Defnet 是图形化的 Windows 蜜罐，能虚拟出 Web、FTP、SMTP、Finger、POP3、Telnet 服务，还提供一个 Advanced 面板专门调伪装细节，让虚拟出来的系统看着更真。它的操作门槛看着最低——点几下鼠标就行——但正因为不涉及命令行，出问题时反而没有日志可看，只能靠外围手段定位。

4.1telnet 不是内部或外部命令：客户端本身就没装

打开命令行敲telnet 192.168.44.1，终端回一句'telnet' 不是内部或外部命令，也不是可运行的程序。这不是蜜罐的问题，是新版本 Windows 默认不安装 telnet 客户端。三条路可选，我按推荐顺序给：

# 方案一：用 PowerShell 自带的端口探测，不需要额外装东西 Test-NetConnection -ComputerName 192.168.44.1 -Port 23 -InformationLevel Detailed # 方案二：启用 Windows 内置 telnet 客户端（需要管理员权限） dism /online /Enable-Feature /FeatureName:TelnetClient /NoRestart # 方案三：直接用 PuTTY 或任意 SSH 客户端选 Telnet 协议

Test-NetConnection的-Port 23会给出TcpTestSucceeded : True/False，这是个比 telnet 更干净的连通性判断，因为它不涉及协议协商，只要 TCP 握手成功就算通。也就是说，如果它返回 False，问题在端口或网络；返回 True 但 telnet 一登录就断，问题在协议层或蜜罐的交互逻辑，两者排查方向完全不同。dism那条是在线启用系统功能，/NoRestart避免直接重启。

4.2 连接超时而不是拒绝：监听网卡选错、权限不足或防火墙拦截

在 Defnet 里设好 Telnet 服务、填了用户名密码、点了 Monitore，从虚拟机发起连接却一直卡在“正在连接”，最后超时。超时和拒绝是两种完全不同的信号：拒绝（Connection refused）说明包到了机器但没有进程监听；超时说明包根本没到，或者被中间设备丢了。

先确认物理机上的监听状态和防火墙：

# Windows 侧查看 23 端口监听情况（管理员权限的 PowerShell） netstat -ano | findstr :23 # 临时放行入站 23 端口（测试完记得删规则） netsh advfirewall firewall add rule name="honeypot-23" dir=in action=allow protocol=TCP localport=23

netstat -ano的-a列全部连接和监听，-n数字形式，-o带 PID，拿到 PID 可以去任务管理器确认是不是 Defnet 本体；如果压根看不到 23 的 LISTENING 行，说明监听没起来，最常见的原因是 Defnet 没以管理员身份运行，绑定低于 1024 的端口被系统拒绝，而图形界面往往只是弹一句提示就过去了。netsh advfirewall那条是临时开洞，测试完记得delete rule name="honeypot-23"删掉，别留着一个长期敞开的入站规则。

网段这一层也经常翻车。物理机跑蜜罐，虚拟机当攻击机，如果虚拟机网卡是 NAT 模式，它能访问物理机的地址往往不是ipconfig里那个 192.168 开头的地址，而是虚拟网卡所在的另一个网段。稳妥的做法是两边都改成桥接，或者干脆在虚拟机里用ping先确认能通到蜜罐主机，再谈 Telnet。

4.3 Advanced 里的盘符和剩余空间随手填，蜜罐一眼就假

Defnet 的 Advanced 面板可以设伪装驱动器盘符、卷标、目录创建时间、剩余磁盘空间、MAC 地址、网卡类型。这些参数看着是锦上添花，实际上决定了蜜罐能不能骗过稍有经验的对手。常见的敷衍填法：盘符写C，卷标写test，剩余空间填0，MAC 地址随手敲一串11:22:33:44:55:66。

这样虚拟出来的系统自相矛盾——一个装着C:盘却剩余空间为零的 Windows，一个 MAC 前缀不属于任何网卡厂商的设备，一个目录创建时间是 1970 年的系统盘。攻击者敲两条命令就能判定这是蜜罐，接下来的所有交互都是演给你看的假数据，日志价值归零。

参数设置上我一般遵守三条：剩余空间填一个合理量级（几十 GB，不要是整数）、目录创建时间早于当前时间但不要跨年代、MAC 地址前三字节用真实网卡厂商前缀。网卡类型和盘符要和宣称的操作系统版本自洽，别在一个声称是老版本系统的蜜罐上挂着新型号虚拟网卡。

4.4 Monitore 记录一片空白：不是没记录，是你没让它落盘

设置完点 Monitore 开始监听，攻击机连上来、输了用户名密码、甚至登录成功了，回头一看记录窗口还是空的。Defnet 的监视窗口是实时刷新的，如果连上之后马上断开，有些版本会来不及渲染；更常见的原因是监听启动顺序反了——先让攻击机连，再点 Monitore，中间那一段自然没被捕获。

正确的操作顺序是：设好 HoneyPot 参数 → 点 Monitore 进入监听态 → 再从攻击机发起连接 → 观察窗口里的连接、用户名、密码、超时、登录成功几个阶段的记录。原文里那次实验，记录里完整出现了“输入用户名和密码 → 连接超时 → 登陆成功”的序列，这说明监听确实在工作，只是需要按时间顺序看。

如果顺序对了还是空白，回到 4.2 节，用netstat确认 23 端口上到底有没有进程在听。图形化工具最大的问题是它不给你黑匣子，出问题只能从外部一点点逼近。

5. 蜜罐实验避坑记录：五条把两小时拖成通宵的问题

下面这五条是我在这三套工具上反复踩过的，现象都很像“工具坏了”，实际上全是配置或环境问题。每条按“现象 → 原因 → 解决”写，遇到类似的直接对号入座。

第一条：日志文件全是 600 权限，后面的分析脚本一个都读不到。

现象是蜜罐跑了一整天，日志确实生成了，但换个用户或者用日志采集脚本去读，直接Permission denied，而ls -l看文件是-rw-------。原因是 Cowrie 的start.sh里默认umask 0077，进程创建的所有文件都剥掉了组和其他人的读写位。解决是把start.sh里的umask 0077改成umask 0022再重启，改完记得确认新生成的日志权限是-rw-r--r--；已经生成的老日志不会自动跟着变，需要单独chmod一次。

第二条：iptables 转发配好了，本机测试却怎么都不生效。

现象是iptables -t nat -L PREROUTING里规则明明白白，但从蜜罐主机自己ssh -p 22 127.0.0.1连过去，进的还是真实 sshd，不是蜜罐。原因是本机发起的连接走 OUTPUT 链，不经过 PREROUTING，nat 重定向对它们无效。解决办法是从另一台机器发起测试，或者临时加一条 OUTPUT 链的对应规则专门用于自测。这个坑最坑的地方在于它会让你误以为整套转发都是坏的，然后去乱改本来正确的配置。

第三条：切换用户后蜜罐起不来，日志里只有一行看不懂的密钥错误。

现象是su honey之后执行bin/cowrie start，进程秒退，日志里是加载 host key 失败之类的信息，看不出和权限有关。原因是之前用 root 跑过一次，var/下的主机密钥和日志文件属主变成了 root，honey 用户没有写权限。解决是chown -R honey:honey /opt/cowrie把属主整体刷回来，然后固定“先改属主、再切用户、最后启动”的顺序，别用 root 试跑。

第四条：蜜罐日志里全是自己的扫描流量，真实攻击被淹了。

现象是日志量很大，仔细一看源地址全是自己实验室的网段，全是端口扫描和漏扫工具的探测。原因是搭建过程中为了验证效果，顺手拿扫描器对着蜜罐扫了几轮，这些记录和真实攻击混在一起。解决办法是搭建验证阶段用单独的测试网段，或者在分析时按源地址先过滤掉已知的测试机；更彻底的做法是蜜罐上线前重建一次日志目录，把调试期数据清干净。

第五条：虚拟机重启后蜜罐“自己关了”，规则和进程全没了。

现象是昨天还好好的，今天开机发现 22 端口又回到了真实 sshd，蜜罐日志停止增长。原因是 iptables 的 nat 规则默认不持久化，Cowrie 也不是系统服务，重启即失效。解决是把规则落盘（iptables-save 之后在启动时恢复），把 Cowrie 注册成系统服务，两者都做一遍再谈“长期观察”。这一步不做，你的蜜罐永远只能活在当次开机的几个小时里。

6. 快速定位：从一条 tcpdump 开始的排查顺序

三套工具、十几种报错，真到了现场不可能一条条回忆。我现在固定按一条链路往下压，从“包有没有到”开始，倒推到“服务有没有起”，基本五分钟内能定位到层。

第一步永远是抓包，它回答的是最底层的问题：流量到底有没有到达这台机器。

# 在蜜罐主机上抓目标端口，先看有没有 SYN 进来 tcpdump -i any -nn -c 30 'tcp and port 23' # 有 SYN 但没有 SYN-ACK，说明本机没人监听或被防火墙丢包 # 有 SYN 也有 SYN-ACK，说明服务在跑，问题在协议层或应用层

看完抓包结果，按下面这张表对号入座，比凭感觉乱改配置快得多：

抓包/端口现象	最可能的层	下一步动作
完全抓不到 SYN	网络层	查网段、虚拟网卡模式、上游防火墙
有 SYN，回 RST	传输层	端口没监听，查进程和绑定地址
有 SYN，无响应	主机层	本机防火墙 DROP，查 iptables/firewalld
握手成功，随即断开	应用层	看蜜罐日志、协议协商、密钥或认证配置
握手成功，日志无记录	文件层	查日志目录权限和 umask

第二步查监听，用ss -lntp一次看全所有相关端口。Pentbox 看它选的那个端口上是不是 ruby，Cowrie 看listen_port上是不是 python，Defnet 在 Windows 上用netstat -ano看 23 上是不是 Defnet 本体。绑定地址是0.0.0.0还是127.0.0.1，这一栏比端口号更容易出事。

第三步查日志落盘。Pentbox 的日志写在它运行目录下，手动模式才会生成；Cowrie 在var/log/cowrie/下，同时有纯文本和 JSON 两份，JSON 那份更适合后续做分析；Defnet 只有界面里的监视窗口。日志目录的属主和权限每次都要顺手看一眼，ls -l一秒钟的事，能省掉半小时的“为什么没记录”。

第四步才是回头看工具配置。这一步放到最后，是因为前面三步能排除掉八成问题，而配置改动是有副作用的——你改了一个自认为可疑的参数，可能把本来正常的转发链路弄断，然后又多出一个新故障。

从那以后我每次搭蜜罐，都强制走一遍“抓包 → 端口 → 日志 → 配置”这个顺序，不管多急都不跳步。跳过一次，就是拿一个通宵去换十分钟的省事。这套顺序写在便签上贴在显示器边，比记十几个具体命令管用得多。希望帮到你。

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