Pentbox、Defnet、Cowrie 蜜罐部署与端口转发避坑

简介：围绕 Defnet、Pentbox 与 Cowrie 三种蜜罐的搭建与使用，这份文档面向网络安全入门者、渗透测试学习者及实验教学人员，帮助读者理解蜜罐的基本原理、部署流程、监视方法与工具差异。包内共 1 个 docx 文件，压缩包约 7.96MB，内容以图文步骤、命令示例、配置说明和实验记录为主，适合按章节阅读，也便于在虚拟机或 Kali 环境中对照复现。文档按工具分节展开：Pentbox 部分涉及端口监听、访问告警与日志记录；Defnet 部分涉及 Web、FTP、Telnet 等服务伪装及连接监视；Cowrie 部分涉及 SSH 蜜罐安装、日志留存与攻击交互捕获。读者可借此建立从诱捕、监测到分析攻击行为的整体认知，并对比低交互与中等交互蜜罐的适用场景。目前已有 3085 人学习，适合作为课程实验、安全练习、靶场复现和工具选型时的参考材料。

1. 三台虚拟机摆开才发现：蜜罐装不好，演练就成了自欺欺人

蜜罐这类工具，装起来最反直觉的一点是：越老的越难跑。我印象最深的一次演练准备，三台虚拟机并排摆开，Pentbox 解压完敲./pentbox.rb，终端直接吐一屏语法错误；切到 Cowrie，pip install twisted卡在 cffi 编译上半天不动。这套环境看着简单——一个 Ruby 脚本、一个 Windows 图形工具、一个 Python 项目——真装起来全是版本、依赖和端口的坑。这篇记录写给要在一台 Kali 上把 Pentbox、Defnet、Cowrie 三种蜜罐都跑起来的人，也写给装到一半卡在依赖报错或者端口转发上的开发者。装之前把版本、网段、端口这三本账先算清，后面能省一大半时间。

2. 装前先把账算清：三套蜜罐的运行条件与端口分配

三种蜜罐来自三个不同的技术年代，硬塞进同一台机器之前，得先知道它们各自吃什么、抢什么。Pentbox 是 Ruby 写的单文件脚本，Defnet 是 Windows 上的图形化工具，Cowrie 是 Python 项目、跑在 Linux 上。我把它们放在同一张表里对比过一遍之后，后面每一步该在哪台机器上做就清楚了。

2.1 三套方案的运行条件对照

先把三者的账面对齐，避免装到一半才发现某台机器根本不满足条件。

这张表里最容易忽略的是「交互级别」那一列。Pentbox 和 Defnet 属于看着像、但经不起深入交互的类型，攻击者敲两条命令就能感觉出不对；Cowrie 能接住真实 SSH 会话，把攻击者输入的字典、命令、上传的文件都留下来。演练里三者不是互相替代的关系，而是从「有人扫我」到「有人在打我的 SSH」三个层次。

还有一列是端口。三者默认都想占 22、80 这种号，一台机器上全开必然打架。我的做法是先画一张端口账，把每个蜜罐的监听端口、转发端口、真实服务端口都单独列出来，写在纸上贴在显示器边，后面每改一处配置就回来对一次。

2.2 虚拟机与网段：先定 IP 再谈端口

原文给出的地址段是 192.168.44.x，宿主机的 VMnet 地址是 192.168.44.1。这套编址我沿用下来，再补上一台模拟攻击机，凑成一张完整的演练拓扑表：

网卡模式选 NAT 就够了。NAT 下虚拟机能访问宿主机，宿主机也能回连虚拟机，Defnet 这种跑在 Windows 上的工具才能被虚拟机里的 telnet 打到。如果选了仅主机模式，宿主机和虚拟机的互通照旧，但虚拟机访问外网会断，装依赖的时候会额外卡一阵。

动手前先把两边的地址确认一遍，别凭记忆：

# 虚拟机侧：确认本机地址和网卡名 ip a show # 或者用老命令 ifconfig -a

REM Windows 宿主侧：找到 VMnet 那块网卡的地址 ipconfig /all

ip a输出里要盯的是inet后面那一串地址，和网卡是不是处于 UP 状态。ipconfig /all里要看的是「VMware Network Adapter VMnet8」这类条目，它给出的地址通常就是 192.168.44.1，也就是虚拟机访问宿主时该填的地址。两边对不上，后面 Defnet 一定连不通，这个坑我在第 5 章还会再提一次。

2.3 解释器版本与专用用户：别拿 root 跑蜜罐

Pentbox 需要 Ruby，Cowrie 需要 Python。这两个解释器的版本决定了后面一半的报错长什么样。

# 先确认解释器在不在位、是什么版本 ruby -v python2 --version 2>/dev/null || echo "no python2" python3 --version virtualenv --version 2>/dev/null || echo "no virtualenv"

Pentbox 1.8 是 Ruby 1.8 时代的脚本，在 Ruby 3.x 上大概率直接报语法错误或者编码错误，ruby -v输出什么版本，决定了你后面是能一把跑通还是要绕路。Cowrie 这一套流程用的是 Python 2 的包名（python-twisted、python-crypto 这些），Kali 滚动更新之后默认仓库里可能已经拿不到 python2 系列包，python2 --version那行如果返回 no python2，就得提前决定是换一台旧镜像，还是改用 Python 3 版本的 Cowrie。

用户这块我的习惯很固定：Cowrie 单独建一个低权限账号跑，绝不用 root。

# -r 建系统账号，-m 强制建家目录，-s 指定登录 shell useradd -r -m -s /bin/bash honey passwd honey

参数说明：-r让它成为系统账号，不参与常规登录排名；-m一定要加，不加的话家目录不存在，后面 virtualenv 和日志目录全得手建；-s /bin/bash是为了能su honey进去操作。密码在演练环境里设成 123456 没问题，但别和生产环境的账号混用。专用用户的意义在于：蜜罐天生是给坏人打的，进程权限压到最低，被打穿了也不至于整台机器沦陷。

3. 两种轻量蜜罐落地：Pentbox 1.8 的端口改配与 Defnet 的虚拟服务伪装

这两个放在一章里讲，是因为它们的装法截然不同但用途接近：都属于「摆个假门」的层次。Pentbox 在 Kali 上用命令行跑，改端口改错误页全靠交互菜单；Defnet 在 Windows 上点鼠标，伪装细节靠 Advanced 那一页参数撑起来。两条路都走一遍，基本就明白低交互蜜罐的门槛在哪。

3.1 下载与解压：把 Pentbox 1.8 放到位

Pentbox 的包不大，一条 wget 就能拿下来。我一般放在 root 的家目录下操作。

# -O 指定落地的文件名，避免服务端返回的名字带一堆参数 wget -O pentbox-1.8.tar.gz "https://sourceforge.net/projects/pentbox18realised/files/latest/download/pentbox-1.8.tar.gz" # 解压：z 走 gzip，x 解包，v 显示过程，f 指定文件 tar -zxvf pentbox-1.8.tar.gz cd pentbox-1.8/ ls

-O这个参数值得单说一句。不指定的话，wget 可能把文件存成download或者带一串查询串的名字，后面解压时你还得回头ls找一遍。tar的四个参数里，-f必须放在最后紧跟文件名，位置写反了会报找不到文件。

ls出来应该能看到pentbox.rb这个入口脚本以及配套目录。如果 wget 拿下来的是一坨 HTML（文件大小只有几 KB，file pentbox-1.8.tar.gz显示 ASCII text），说明直链被跳转了，这属于第 5 章要讲的坑，先记着。

3.2 菜单路径：从主菜单进到 Honeypot 的 2 → 3

Pentbox 是纯交互式的，进去之后一路选菜单。第一次跑的人容易在主菜单上发懵，其实路径固定：主菜单选 2 进 Network Tools，再选 3 进 Honeypot。

# 必须在解压出来的目录里执行，脚本按相对路径读配置 cd ~/pentbox-1.8 ./pentbox.rb

进去之后的菜单结构大概是这样：

1) Auto Configuration 2) Network Tools 3) About 4) Exit 选择: 2 1) Ping 2) Traceroute 3) Honeypot 选择: 3

一定要在pentbox-1.8目录里执行./pentbox.rb。我试过在别的目录用绝对路径调它，菜单能出来，但某些子功能会因为找不到相对路径下的文件而中断。这种「能启动但跑不全」的状态最坑，排查的时候容易怀疑到别处去。

3.3 快速模式与手工模式：端口、错误页、日志三件事

进到 Honeypot 之后会给你两个选项：快速自动配置和手工配置。快速模式最省事，自动在 80 端口起监听，直接就能用浏览器验证。

选 1（Fast Auto Configuration）之后，终端会打出HONEYPOT ACTIVATED ON PORT 80。这时候在另一台机器上打开浏览器访问http://192.168.44.130，页面上会是Access denied。这个报错是蜜罐故意返回的假错误页，不是你的配置出了问题。同一时间，跑 pentbox 的那个终端会紧跟着输出INTRUSION ATTEMPT DETECTED，一次访问就被记下来了。

手工模式给的控制权多得多。选 2（Manual Configuration）之后会依次问四件事，我用 22 端口做过一次演示，问答序列长这样：

Insert port number: 22 Insert false message: Access denied Do you want to save log? (y/n): y Insert log filename: pentbox_22.log Do you want beep? (y/n): n

四个问题的含义分别是：监听哪个端口、访问者看到什么错误提示、要不要把记录落成文件、检测到访问时要不要蜂鸣提醒。开关蜂鸣这条看场景，演练现场人多的时候我会关掉，否则一声一声响容易干扰讲解；自己一个人测的时候开着，能立刻知道有没有人踩进来。

日志文件默认落在当前目录下，用tail -f挂着看：

# 挂着看实时记录，同时另开一个终端去触发访问 tail -f pentbox_22.log

换端口这件事比想象中重要。80 端口一个蜜罐就够了，再开 22、21、443 是为了铺开覆盖面：22 骗 SSH 扫描器，21 骗 FTP 爆破，443 骗 HTTPS 探测。这里有个必须提前知道的点——Pentbox 在 443 上并不做真正的 TLS 握手，浏览器访问会先弹一个证书/协议错误，然后才轮到蜜罐记录。别看到浏览器报错就以为没生效，去看终端和日志有没有对应记录才算数。

3.4 Defnet 的部署位置：为什么它要待在 Windows 侧

Defnet 是图形化工具，装在 Windows 物理机上，靠虚拟机里的系统去连它。这个部署位置不是随便定的：它要虚拟出 Telnet、FTP、SMTP 这些老服务，还要伪造盘符、卷标、MAC 地址这些偏系统的细节，跑在它熟悉的 Windows 环境里最省事。

先在物理机上打开 Defnet，主界面上有个「HoneyPot」按钮，点进去就是服务配置对话框。里面能勾选虚拟的服务类型：Web、FTP、SMTP、Finger、POP3、Telnet。演练里我一般先勾 Telnet，因为它的验证过程最直观——一条 telnet 命令连上去，输账号密码，全过程都能在界面里看到。

3.5 虚拟 Telnet 的账号与 Advanced 伪装项

Telnet Server 这一项要填用户名和密码。这里的原则是「故意好猜」：蜜罐的账号本来就是要让攻击者登进来的，设成复杂密码反而拦住了数据采集。我把 login 设成 root，密码设成 123456，攻击者一试就进，进来之后的所有操作才有得看。

右下角有个「Advanced」按钮，点开是伪装参数。这一页才是 Defnet 的价值所在，填得越像真的，攻击者停留的时间越长。

这张表里最容易被忽略的是最后两行。MAC 地址的前三位是厂商标识，如果你选了一块 Intel 网卡却填了个别的厂商前缀，稍微懂行的人一眼就能看穿。剩余磁盘空间也一样，填成 8G 整这种数字，反而暴露了人工痕迹。这类细节做不做，直接决定蜜罐能骗住谁。

3.6 监听与回连：从虚拟机 telnet 到宿主

参数填完，回到第一个对话框按「Monitore」按钮开始监听。接下来从虚拟机发起连接：

REM 先在 Windows 宿主上确认地址 ipconfig REM 再到 Kali 虚拟机里发起 telnet telnet 192.168.44.1

宿主机地址是 192.168.44.1，虚拟机是 192.168.44.132。telnet 连上之后会提示输入用户名和密码，敲 root / 123456。这时候 Defnet 的 Monitore 窗口里会依次出现「监听到有用户连接」「输入用户名和密码」「连接超时」「登录成功」这几条记录，整个过程被完整抓下来。

注意：Windows 10 和 11 默认不装 telnet 客户端，直接敲 telnet 会提示不是内部或外部命令。在「启用或关闭 Windows 功能」里勾上 Telnet Client，或者用管理员命令行执行dism /online /Enable-Feature /FeatureName:TelnetClient装上。

如果 telnet 一直停在 Connecting 不返回，八成是 Windows 防火墙把入站连接挡了，或者虚拟机的网段和宿主 VMnet 不在一个段上。这两条都在第 5 章的排查清单里。

4. Cowrie 部署：Python 环境、listen_port 与 iptables 重定向怎么对齐

Cowrie 是三者里唯一能拿到「真东西」的：攻击者敲的每条命令、试的每个密码、上传的每个文件都会留下来。代价是它的安装链路最长，从系统包到虚拟环境到端口转发，中间任何一环没对齐都起不来。这一章按我实际装下来的顺序写，每一步都给出验证方式。

4.1 专用用户与系统依赖：别拿 root 跑蜜罐

先建用户，再装依赖。

# 建低权限账号，密码在演练环境里设成 123456 useradd -r -m -s /bin/bash honey passwd honey # 装 Cowrie 需要的 Python 系列包 apt-get update apt-get install -y python-twisted python-crypto python-pyasn1 \ python-gmpy2 python-mysqldb python-zope.interface apt-get install -y virtualenv git

这一串包名分开说：python-twisted是 Cowrie 的网络事件框架，没有它主程序起不来；python-crypto和python-pyasn1负责加密和协议编码；python-gmpy2是 SSH 密钥运算要用的高精度数学库；python-mysqldb只有在你打算把日志写进数据库时才用得上，暂时用不到也留着不碍事；python-zope.interface是 twisted 的依赖项，单独点名装是为了避免 apt 自动解析顺序出问题。

这一串装完如果报「无法定位软件包」，别急着换源，先回头看第 2 章那行python2 --version的输出。Kali 新版本里 python2 系列包已经陆续下线，遇到这种情况只能换镜像或者换 Cowrie 版本，硬凑会更浪费时间。

4.2 virtualenv 与 pip：cffi、gmp 两处编译报错怎么补

Cowrie 我放在/opt下，用 git 拉源码。

cd /opt git clone <Cowrie 仓库地址> cowrie cd /opt/cowrie # 建 Python 虚拟环境并激活 virtualenv env source env/bin/activate # 在虚拟环境里装 Python 层依赖 pip install twisted cryptography pyopenssl gmpy2

virtualenv env会在当前目录下建一个叫 env 的隔离环境，激活之后pip install装的东西都落在 env 里，不会污染系统 Python。这一步的价值在于：Cowrie 的依赖和系统包管理器装的包版本容易打架，隔离之后出问题直接把 env 删了重来，不用回滚系统。

pip install这一行大概率会报错，最常见的是 cryptography 在编译 cffi 时找不到头文件：

# cffi 编译失败，补 libffi 和 openssl 的开发头文件 apt-get install -y python-cffi libffi-dev libssl-dev # gmpy2 编译失败，补 gmp 和 mpfr 系列 apt-get install -y libgmp-dev libmpfr-dev libmpc-dev # 补完依赖回到虚拟环境重跑 source env/bin/activate pip install twisted cryptography pyopenssl gmpy2

这两组包是我踩过的血泪经验。libffi-dev和libssl-dev缺一个，cryptography 就编不过；libgmp-dev、libmpfr-dev、libmpc-dev三个是一组，gmpy2 的编译脚本要同时找它们。报错的表面信息通常是「command 'gcc' failed」加一大段看不懂的日志，往上看两三行才能找到真正缺的那个.h文件。

4.3 配置文件改动：listen_port、umask 与目录属主

依赖装完，先把目录属主交出去，再改配置。

# 目录属主改成 honey，否则后面用 honey 身份启动会写不了日志 chown -R honey:honey /opt/cowrie # 用示例配置生成正式配置 cd /opt/cowrie cp cowrie.cfg.dist cowrie.cfg

接着改两处。第一处是启动脚本里的 umask：

# 编辑 start.sh，把 umask 从 0077 改成 0022 cd /opt/cowrie vim start.sh # 找到 "-- umask 0077" 这一行，改成 "-- umask 0022"

默认的 0077 意味着新建的日志文件只有属主能读，别人（包括你用另一个账号去查日志）一律读不了。改成 0022 之后，属主可读写、其他人可读，排查日志的时候不用每次都su honey。

第二处是监听端口：

# /opt/cowrie/cowrie.cfg # 默认 2222 太显眼，扫一遍端口就能认出来，改成 60000 以上 listen_port = 63333

端口选 60000 以上是有讲究的：常规端口扫描默认只扫 1-10000，落到这个区间之外，蜜罐的暴露面反而更可控。这条经验在原文里就提过，我沿用了 63333 这个值，后面 iptables 转发和 sshd 改端口都要跟它对齐。

4.4 端口搬家：先改 sshd 再上 iptables

这一步是整个安装里最容易把自己关在门外的环节，顺序错了就得进救援模式。原则只有一条：先把真实 SSH 搬到新端口并验证能登，再去劫持 22。

# 第一步：把真实 sshd 挪到 62225 vim /etc/ssh/sshd_config # 把 Port 22 改成 Port 62225 # 重启 ssh 服务 service ssh restart # 第二步：另开一个终端，用新端口登一次，确认能进 ssh -p 62225 root@192.168.44.132

新端口能登进去之后，才轮到 iptables 把 22 流量重定向给蜜罐：

# 把发往本机 22 端口的 TCP 请求重定向到蜜罐的 63333 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333

参数拆开看：-t nat指定用 NAT 表，-A PREROUTING表示在路由决策之前处理，-p tcp限定协议，--dport 22是匹配目标端口，-j REDIRECT是动作，--to-port 63333是重定向目标。这四段里任何一个数字和 cowrie.cfg 里的listen_port对不上，表现就是「连 22 没反应，连 63333 才有蜜罐信息」。

原文在这里出现过端口号前后不一致的情况，转发目标写的是另一个数，和配置文件里的监听端口对不上。这种不一致不会报错，只会让你在排查时多绕半小时，所以每次改完都要回头对一遍三处：cowrie.cfg 的 listen_port、iptables 的 --to-port、sshd_config 的 Port。

4.5 启停与日志：cowrie.log 和 cowrie.json 各看什么

切到 honey 用户启动蜜罐。

# 切用户，切换后当前目录会变，记得 cd 回去 su honey cd /opt/cowrie # 启动蜜罐 bin/cowrie start

启动时如果报缺模块，按提示补装就行：

# 常见缺失：configparser、service_identity、pycrypto、tftpy pip install configparser service_identity pycrypto tftpy

补完再bin/cowrie start，看到启动成功的提示就算起来了，停止用bin/cowrie stop，改完配置要重启才生效。

日志有两个文件要看：cowrie.log是人类可读的文本流水，谁在什么时候连进来、敲了什么命令都在里面；cowrie.json是结构化记录，方便后面做统计和导入分析平台。原文里用 xshell 连了一次，cowrie.log里立刻多出对应的登录记录，再在蜜罐里 ping 一下外网，日志里同样能抓到这条命令。这两个文件都在/opt/cowrie/log/cowrie/目录下。

提示：验证蜜罐是否真在工作，别只看启动成功的提示。用另一台机器 ssh 到 192.168.44.132 的 22 端口，看到的是蜜罐的欢迎信息而不是真实系统的，同时日志里有新增记录，三条同时成立才算真的跑通。

5. 避坑排查：三套蜜罐翻车现场与补救顺序

装这三套东西的过程中，我遇到的报错能凑一页纸。挑出五条最有代表性的，按「现象 → 原因 → 解决」写下来，下次遇到直接照着对。

5.1 装的时候最容易翻的两处

Pentbox 报语法错误或编码错误。现象是敲完./pentbox.rb，终端甩出一屏syntax error, unexpected，或者invalid byte sequence in UTF-8，脚本一行都没执行。原因是 Pentbox 1.8 是 Ruby 1.8 时代的产物，用的是老语法，而现代系统上的 Ruby 已经是 3.x，语法解析直接过不去；编码报错则是因为终端 locale 是 UTF-8，脚本里混着非 UTF-8 字符。解决办法有两条：一是临时把 locale 降下来，用LANG=C ./pentbox.rb跑，能绕过编码那一类报错；二是干脆留一台装老版本 Ruby 的镜像专门跑它。我一般选第二条，因为语法层面的不兼容靠环境变量绕不过去。

wget 下来的 Pentbox 是个网页。现象是解压时报gzip: stdin: not in gzip format，file pentbox-1.8.tar.gz显示的是 ASCII text。原因是下载站对直链做了跳转，wget 跟到了中间页而不是文件本体。解决方式是手动在浏览器里把包下下来，再传进虚拟机；或者在 wget 上加-U伪装浏览器标识重试。判断标准很简单：正常的包有几 MB，网页只有几 KB。

5.2 跑起来之后的坑

Cowrie 起来之后自己 SSH 登不进去了。现象是 ssh 连 22 端口，提示信息是蜜罐的，输真实密码怎么都不对。原因是 iptables 的重定向规则先生效了，而 sshd 还占着 22 端口没搬走，所有到 22 的请求全被送进了蜜罐。正确的处理顺序在 4.4 已经写过：先改sshd_config的 Port 并重启，用新端口验证能登，最后才加 iptables 规则。已经把自己关在门外的，通过虚拟机的控制台进去执行iptables -t nat -F清掉规则就能恢复。

蜜罐日志读不了，或者启动报 Permission denied。现象是bin/cowrie start报权限错误，或者日志文件存在但cat提示 Permission denied。原因有两个：一是/opt/cowrie的属主没改成 honey，二是start.sh里的 umask 还是 0077，新生成的文件只有属主能读。解决就是把 4.3 那两步补上——chown -R honey:honey /opt/cowrie，再把 umask 改成 0022。改完记得把已生成的日志文件也 chown 一遍，光改配置对老文件不生效。

Defnet 的 telnet 连不上，一直停在 Connecting。现象是在虚拟机里telnet 192.168.44.1之后没有任何返回，Monitore 窗口一条记录都没有。原因通常是两个：Windows 防火墙拦了入站连接，或者虚拟机的网段和宿主 VMnet 根本不在一个段。排查顺序是先ipconfig确认宿主地址确实是 192.168.44.1，再看虚拟机的ip a是不是 192.168.44.x，两边对得上再去临时关掉防火墙试一次。防火墙关了能通，就说明要在防火墙里给 Telnet 的 23 端口放行，而不是一直关着。

iptables 规则重启后消失。现象是当天配好能用，第二天开机再测，22 端口直接连到真实系统了。原因是 iptables 的规则默认只存在内存里，重启就清空。解决是用iptables-save把规则导出到文件，再在开机脚本里iptables-restore回去。演练环境里我一般会额外写一张纸条贴在机器上，提醒自己每次重启后先跑一遍iptables -t nat -L -n确认规则还在。

6. 装完怎么验证：三层检查确认蜜罐真的在收数据

装完不等于跑通。我的习惯是从外到内做三层检查：端口在不在听、请求能不能进来、日志有没有落地。三层全过，这套环境才算能交付。

第一层看监听面。三个蜜罐各自的端口必须处于 LISTEN 状态。

# 一次性看几个关键端口有没有在听 ss -lntp | grep -E ':(80|22|23|63333)\b'

-l只看监听态，-n不做域名解析（快且不受 DNS 影响），-t限定 TCP，-p显示占用进程。输出里每一行都应该能看到对应的进程名：80 端口对应 ruby，63333 对应 python。如果某个端口压根没出现，别往下走了，先回去看那个蜜罐的启动日志。

第二层主动触发。光看端口在听没用，得制造一次真实访问，让蜜罐记一笔。

# 触发 Pentbox 的 80 端口 curl -s -m 3 http://192.168.44.130/ >/dev/null # 触发 Pentbox 的 22 端口 telnet 192.168.44.130 22 # 触发 Cowrie：连 22 会被重定向到蜜罐 ssh -p 22 root@192.168.44.132

curl的-s静默掉进度条，-m 3设三秒超时，避免卡住。这三条命令执行完，跑 Pentbox 的终端应该出现 INTRUSION ATTEMPT DETECTED，Cowrie 那边则应该多出一条登录记录。

第三层看日志落地。日志是蜜罐唯一有价值的产出，不落盘的蜜罐等于白装。

# Pentbox 的日志（手工模式指定过文件名才有） tail -n 20 ~/pentbox-1.8/pentbox_22.log # Cowrie 的两份日志 tail -n 20 /opt/cowrie/log/cowrie/cowrie.log tail -n 20 /opt/cowrie/log/cowrie/cowrie.json

把三层检查压成一张表，交付前照着走一遍：

还有一条容易被跳过的验证：在 Cowrie 蜜罐里ping一下外网。这条命令会被日志原样记下来，说明蜜罐不只是接住了连接，还接住了会话里的命令。原文里就是这么验的，我沿用了这个做法，因为它比看连接数更能说明问题。

从那以后我每次搭完蜜罐，都强制走一遍「端口、触发、日志」这三步，一步都不省。有回赶时间只看了启动成功的提示就交差，结果演练当天发现日志目录属主是 root，采到的数据一条都读不出来，现场补权限补了二十分钟。蜜罐这东西，装完那一刻是它最像样的时候，也是它最容易被误判为正常的时候。希望帮到你。

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