企业官网建设流程全解析

简介：这份文档面向网络安全初学者与渗透测试爱好者，围绕 Defnet、Pentbox、Cowrie 三种蜜罐工具，讲解从环境准备到实际搭建、配置与使用的完整流程，帮助读者理解蜜罐的诱捕原理并动手完成实验。资源包内共 1 个 docx 文件，约 7.96MB，以图文步骤形式记录了 Pentbox 在 Kali 下的下载解压与端口监听设置、Defnet 虚拟 Telnet 服务的伪装参数配置，以及 Cowrie 的依赖安装、虚拟环境搭建与 SSH 端口修改等关键环节，便于对照复现。内容兼顾快速自动配置与手动定制两种思路，并附有访问测试与日志监视的观察方法，可作为课程实验或自学练习的参考材料。目前已有 3083 人学习下载，适合希望低成本搭建 SSH、Telnet 等仿真服务、积累攻防对抗认知的读者查阅。

1. 从一台“看起来能登进去”的假机器说起

去年帮一个做安全实训的实验室复现教学环境，需求很朴素：搭三台蜜罐，分别覆盖 Web 端口、Telnet 服务和 SSH 服务，让学员能真实地“攻”一次、看一次日志。结果第一轮就翻车——Pentbox 在 Kali 上跑起来后 80 端口没响应，Cowrie 的虚拟环境装到一半报cffi编译错误，Defnet 虚拟出来的 Telnet 登录界面因为盘符和 MAC 没配好，一眼假。蜜罐这东西，装不上是小事，装上了“不像真的”才是大事，攻击者三秒识破，日志里全是扫描器的噪声，等于白搭。

这篇笔记记录的就是这三种蜜罐（Pentbox 1.8、Defnet、Cowrie）从环境准备到跑通验证的完整过程，全部在 Kali Linux 上落地，Defnet 因为带图形界面放在物理机上操作。适合正在做安全课程实验、想搭一套可复现蜜罐靶场的开发者，也适合已经装过但卡在依赖和端口转发上的熟手对照排查。版本、端口、依赖包名我都会写死，照着敲能跑通。

2. 装前把环境列清：Kali 版本、Ruby 与 Python 依赖对照

2.1 三套蜜罐的运行环境差异

三种蜜罐的技术栈完全不同，混着装之前先把差异摆清楚，能省掉一半的“为什么这个能跑那个不能跑”的困惑。Pentbox 是 Ruby 写的，面向 GNU/Linux，理论上任何装了 Ruby 的系统都能跑，Kali 自带 Ruby 环境，所以它是最轻的一个；Defnet 是带 GUI 的 Windows 侧工具，靠虚拟服务伪装，不依赖 Linux 包管理；Cowrie 是 Python 写的中等交互 SSH 蜜罐，依赖链最长，Twisted、cryptography、pyopenssl、gmpy2 一个都不能少，还得单独建 virtualenv。

我一般会先确认 Kali 的版本和已装组件，避免后面重复踩依赖坑。执行下面几条命令摸个底：

# 确认系统版本与内核，Cowrie 的 cffi 编译对内核头文件有要求 uname -a cat /etc/os-release # 确认 Ruby 是否就绪（Pentbox 依赖） ruby -v # 确认 Python 版本与 pip（Cowrie 依赖） python --version pip --version # 确认编译工具链，后面装 cffi/libffi 要用 gcc --version

uname -a看内核，是因为 Cowrie 装python-cffi时要编译 C 扩展，内核头文件和 gcc 缺一个就报错；ruby -v确认 Pentbox 的运行基础，Kali 默认带 Ruby，但老版本镜像可能没有；python --version决定你后面 pip 装包时的兼容性，Cowrie 这套老依赖对 Python 3 的高版本并不友好，常见做法是优先用系统自带的 python2 系包名（python-twisted这种），而不是硬上 pip3。

2.2 依赖预装：把最容易报错的包一次装齐

Cowrie 的依赖是三种蜜罐里最容易翻车的，原文里就明确记录了pip install twisted cryptography pyopenssl gmpy2报错、需要补装python-cffi libffi-dev libssl-dev和libgmp-dev libmpfr-dev libmpc-dev的过程。与其装到一半再补，不如一开始就把系统级依赖装齐：

# Cowrie 所需的 Python 相关包（Kali 下用 apt 的 python2 系包名） apt-get install -y python-twisted python-crypto python-pyasn1 \ python-gmpy2 python-mysqldb python-zope.interface # virtualenv，用于隔离 Cowrie 的 Python 环境 apt-get install -y virtualenv # 编译依赖：cffi 要 libffi，cryptography 要 libssl，gmpy2 要 gmp/mpfr/mpc apt-get install -y python-cffi libffi-dev libssl-dev apt-get install -y libgmp-dev libmpfr-dev libmpc-dev

这里每一行的作用要分清：第一组是 Cowrie 运行时直接 import 的模块，python-twisted提供异步网络框架，python-gmpy2是 SSH 密钥运算要用的高精度数学库；第二组virtualenv是为了把 Cowrie 的依赖和系统 Python 隔开，避免污染；第三组是编译期依赖，libffi-dev和libssl-dev缺了，pip install cffi和cryptography就会在编译阶段直接失败，这是原文里那次报错的根因。libgmp-dev这一组则是gmpy2的编译前提。

提示：Kali 新版本里 python2 系包名可能已经改叫python2-twisted之类，装之前用apt-cache search twisted确认一下实际包名，别照着老笔记硬敲。

3. Pentbox 1.8 安装与端口配置：从下载到 80 端口监听

3.1 下载解压与首次启动

Pentbox 的安装几乎没有门槛，难点全在启动后的菜单交互和端口选择上。原文给的下载地址是 sourceforge 上的 pentbox-1.8，用 wget 拉下来解压即可：

# 下载 pentbox-1.8 压缩包 wget 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

tar -zxvf里z是 gzip 解压、x解包、v显示过程、f指定文件名，这套参数是通用写法。./pentbox.rb直接执行 Ruby 脚本，如果提示权限不足，先chmod +x pentbox.rb。启动后进入的是交互式菜单，不是命令行参数模式，所以后面所有配置都靠数字选择完成。

3.2 快速模式与手动模式的参数取舍

进入主菜单后选2（Network Tools），再选3（Honeypot），会出现两个选项：快速自动配置和手动配置。快速模式直接把端口定死为 80 并开始监听，适合快速验证；手动模式可以自定义端口、错误提示信息、是否保存 log、是否蜂鸣报警。

快速模式的操作路径是选第一个选项，终端会打印HONEYPOT ACTIVATED ON PORT 80，此时浏览器访问http://你的IP会看到Access denied，同时终端出现INTRUSION ATTEMPT DETECTED。这一步验证的是“蜜罐活着且能记录访问”。

手动模式更适合真实靶场，因为 80 端口太显眼，扫描器一眼就认出来。手动配置的交互顺序是：输入开放端口 → 输入要显示的错误信息 → 是否保存 log 并指定文件名 → 是否开启蜂鸣警告。我一般会把端口设成 22、21、443 这类“看起来有服务”的端口，错误信息写成和目标系统风格一致的文案，比如伪装成 Apache 的 403 页面提示，而不是默认的通用拒绝语。

# 手动模式测试：另开终端 telnet 蜜罐的 23 端口 telnet 192.168.44.130 23

这条 telnet 是用来验证手动模式是否真的在监听指定端口。原文里用 23 端口测试，终端会记录到这次请求；同理换成 21、22、443 都能起同样作用。这里的关键认知是：Pentbox 的“蜜罐”本质是一个会记录连接并返回伪装响应的监听器，它不提供真实服务，所以任何端口都能挂，选端口的逻辑是“选目标系统上最可能被探测的端口”，而不是选 Pentbox 支持的端口。

注意：快速模式占用的 80 端口如果和本机已有 Web 服务冲突，会直接绑定失败，终端不一定给明确报错。装之前ss -lntp | grep :80看一眼端口占用，能省一次莫名其妙的“蜜罐没反应”。

4. Defnet 虚拟服务伪装：Telnet 蜜罐的盘符与 MAC 细节

4.1 虚拟 Telnet 服务的建立

Defnet 是图形化工具，操作在物理机上完成，核心是“虚拟出一个足够真实的 Telnet 服务器”。打开 Defnet 后点HoneyPot按钮进入设置，在对话框里可以虚拟 Web、FTP、SMTP、Finger、POP3、Telnet 多种服务。这里先只开 Telnet Server，用户名设root、密码设123456，这是教学场景的常用弱口令组合，目的是让攻击者“一猜就中”，从而完整走完登录流程、留下完整日志。

设置完账号密码还不算完，右下角的Advanced才是决定“像不像”的地方。里面要配伪装驱动器盘符（Drive）、卷标（volume）、目录创建时间、目录名、剩余磁盘空间（Free space in bytes）、MAC 地址、网卡类型。这些参数的意义在于：攻击者 telnet 进来后，通常会敲dir、vol、ipconfig之类的命令探底，如果盘符是默认的、剩余空间是个整数、MAC 是 00:00:00:00:00:00，三秒就识破。把盘符设成C:、卷标设成类似SYSTEM、剩余空间填一个不规则数字（比如 10737418240 字节附近），MAC 填一个符合厂商前缀规律的值，虚拟系统才立得住。

4.2 监听、连接与日志核对

配置完成后回到第一个对话框，点Monitore开始监听。此时在物理机命令行ipconfig拿到本机 IP（原文示例是 192.168.44.1），在虚拟机里telnet 192.168.44.1发起连接。连接成功后输入蜜罐的用户名密码，Monitore窗口会依次记录：有用户连接、输入用户名和密码、连接超时、登录成功，全过程可见。

# 物理机侧确认监听 IP ipconfig # 虚拟机侧发起 telnet 连接（替换为物理机实际 IP） telnet 192.168.44.1

这两条命令本身很简单，价值在于建立“攻击侧 → 蜜罐侧”的闭环。ipconfig确认的是蜜罐宿主机的地址，虚拟机 telnet 过去后，Defnet 的 Monitore 里应该能看到完整的交互记录。如果 Monitore 里只有连接没有后续，通常是 Advanced 里的虚拟服务参数填得不完整，导致会话在握手阶段就断了；如果登录一直超时，检查虚拟 Telnet 服务的端口是否和连接端口一致。

提示：Defnet 的虚拟服务参数是“一次性配置、长期生效”的，改完记得重新点一次 Monitore 让配置加载，否则改了半天还是旧参数在跑。

5. Cowrie 部署全流程：virtualenv、端口转发与依赖补装

5.1 建专用用户与拉取源码

Cowrie 是三种里最接近“生产可用”的，因为它有中等交互、能记录暴力破解字典和上传的恶意文件，而且攻击者在蜜罐里执行恶意文件会失败，对宿主机相对安全。原文的操作全部在 Kali 上完成，第一步是建一个非 root 的专用用户，这是安全基线：

# 建一个不可登录 shell 之外、带家目录的专用用户 honey useradd -r -m -s /bin/bash honey # 给 honey 设密码（教学环境用简单密码即可） passwd honey # 拉取 cowrie 源码到 /opt cd /opt git clone http://github.com/micheloosterhof/cowrie

useradd -r建的是系统用户，-m强制建家目录，-s /bin/bash给它一个可用 shell，因为后面要su honey进去跑蜜罐。专用用户的意义是：Cowrie 被攻破时，攻击者拿到的只是 honey 的权限，不是 root。源码放/opt是惯例，方便统一管理。

5.2 virtualenv 隔离与依赖补装

进入 cowrie 目录后建虚拟环境并激活，然后装 Python 依赖：

cd /opt/cowrie virtualenv env source env/bin/activate # 首次装依赖，这一步大概率报错 pip install twisted cryptography pyopenssl gmpy2

原文明确记录这里会报错，原因是cffi编译缺libffi-dev和libssl-dev。如果第 2 章已经预装了那批系统依赖，这一步就能过；如果没预装，补装后重跑即可：

# 补装编译依赖后重跑 apt-get install -y python-cffi libffi-dev libssl-dev apt-get install -y libgmp-dev libmpfr-dev libmpc-dev pip install twisted cryptography pyopenssl gmpy2

依赖装完后还有一步容易漏：改/opt/cowrie的属主，否则 honey 用户跑不起来：

chown -R honey:honey /opt/cowrie

-R递归改属主，把整个 cowrie 目录交给 honey，这样后面su honey启动时才有读写权限。这一步不做，启动时会报权限拒绝，而且报错信息不一定指向属主问题，属于典型的“黑匣子”式报错。

5.3 配置文件与 SSH 端口改造

Cowrie 的配置从模板复制，然后改两处关键项：日志 umask 和监听端口。

# 从模板生成配置文件 cp cowrie.cfg.dist cowrie.cfg # 改 start.sh 里的 umask，默认 0077 会导致日志文件权限过严 vim start.sh # 把 "-- umask 0077" 改成 "-- umask 0022" # 改蜜罐 SSH 监听端口，默认 2222 太显眼 vim cowrie.cfg # 把 listen_port 改成 63333（高于 60000 更不容易被默认端口扫描命中）

umask 从 0077 改 0022 的原因：0077 会让新建日志文件只有属主可读，后续分析脚本或别的用户读不到日志，排查时以为“没记录”，其实是权限挡住了。监听端口改到 60000 以上，是为了避开扫描器对 2222 这类常见蜜罐端口的默认探测，原文建议高于 60000，我一般取 63333 这种不规整的值。

端口改完还要做转发，把公网访问 22 的请求重定向到蜜罐端口，同时把真实 SSH 挪走：

# 把访问 22 的请求重定向到蜜罐端口 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 62223 # 把真实 SSH 端口改成 62225，避免和蜜罐抢 22 vim /etc/ssh/sshd_config # 修改 Port 62225 service ssh restart

iptables -t nat走的是 NAT 表，PREROUTING在路由前拦截，REDIRECT把目标端口改写。这里有个细节：原文转发目标写的是 62223，而 cowrie.cfg 里监听端口是 63333，两者要对齐，否则转发过去没人接。我一般会把转发目标和listen_port设成同一个值，减少一处对不上的可能。真实 SSH 改到 62225 是为了保住管理通道，改完必须service ssh restart并用新端口验证能登，别把自己锁在外面。

5.4 启动与首次连接验证

切到 honey 用户启动蜜罐：

su honey cd /opt/cowrie bin/cowrie start

原文记录这里还会报一次错，缺configparser service_identity pycrypto tftpy，补装即可：

pip install configparser service_identity pycrypto tftpy bin/cowrie start

启动成功后，另开终端用 SSH 连蜜罐端口，会看到蜜罐返回的伪装 banner，cowrie.log和cowrie.json里会记录这次登录。在蜜罐会话里ping www.baidu.com，返回的也是蜜罐伪造的信息，而不是真实网络结果——这正是 Cowrie 中等交互的体现：它接住了命令，但给的是假结果。

6. 装完怎么验证跑通：三套蜜罐的日志与行为核对

三种蜜罐装完，验证不能只看“进程起来了”，要看“攻击行为有没有被正确记录”。我一般按下面这张核对表逐项过一遍，任何一项对不上就回到对应章节查配置。

Pentbox 的验证重点是“告警是否触发”，浏览器访问后终端必须出现INTRUSION ATTEMPT DETECTED，只看到 Access denied 而终端没动静，说明 log 或告警选项没开。Defnet 的验证重点是“会话完整性”，Monitore 里要能看到从连接到输入账号密码到登录成功的整条链路，缺环节就是 Advanced 参数没配全。Cowrie 的验证重点是“日志双写”，cowrie.log是文本流水、cowrie.json是结构化记录，两个都要有内容，且蜜罐会话里ping返回的是伪造信息而不是真实网络响应。

# Cowrie 日志核对：确认登录记录和命令记录都落盘 tail -f /opt/cowrie/log/cowrie.log tail -f /opt/cowrie/log/cowrie.json # 确认蜜罐端口在监听 ss -lntp | grep 63333 # 确认 iptables 转发规则生效 iptables -t nat -L PREROUTING -n --line-numbers

tail -f实时盯日志，是为了在触发连接的同时看到记录写入，比事后翻文件直观；ss -lntp确认监听，iptables -t nat -L确认转发规则在链上且顺序正确——规则顺序错了，后面的规则会覆盖前面的，这是端口转发最常见的坑。

血泪经验是：我第一次搭 Cowrie 时，cowrie.log一直空的，查了半天以为是蜜罐没工作，最后发现是 start.sh 的 umask 没改，日志文件建出来了但权限 600，分析脚本读不到。从那以后我每次装完 Cowrie，都强制先ls -l log/看一眼权限，再tail -f确认写入，最后才去连端口。这套顺序走下来，三种蜜罐的“装没装上”和“装得像不像”就都有据可查了。希望帮到你。

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