企业官网建设流程全解析

简介：这份资源系统讲解蜜罐技术的三种搭建与使用方法，重点涉及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 模块负责 445，FTP 模块负责 21，MySQL 模块负责 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。

选型没有标准答案，关键看你手上有多少 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-dev

libemu 负责 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] Description=Dionaea Honeypot After=network.target [Service] ExecStart=/opt/dionaea/bin/dionaea -c /opt/dionaea/etc/dionaea.conf -p /opt/dionaea/var/dionaea.pid Restart=on-failure User=nobody Group=nogroup [Install] WantedBy=multi-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、mssql），local_port 是蜜罐被触碰的端口，remote_host 是攻击者来源 IP，connection_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:interface=0.0.0.0 [telnet] listen_endpoints = tcp:2223:interface=0.0.0.0

hostname会让攻击者登录后看到的 Shell 提示符像一台真实服务器，比如root@svr03:~#。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.txt

playlog 会把一次会话里的所有命令按时间顺序回放出来。回放文件里能看到攻击者登录后先执行了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.sh

install.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 蜜罐被反噬成跳板：出方向必须封

现象：攻击者识别出蜜罐后，在里面装了一些工具，继续扫描了内网其他主机。 原因：蜜罐所在网段没有跟生产网隔离，出方向的流量完全放开，攻击者把它当跳板用了。 解决：蜜罐服务器必须单独划 VLAN，iptables 上只放行到管理端和 NTP 的出方向流量，其他出方向全部 DROP。这一步不做，蜜罐就不是诱饵而是你亲手放进内网的暗门。高交互蜜罐尤其要小心，Cowrie 虽然是模拟系统，但宿主机出了问题就是另一回事。

6.4 验证三连：端口、日志、告警都通才算部署完

部署完蜜罐后，我习惯做三件事：从外网扫一次端口，确认服务可见；手动打一次攻击，确认日志里有记录；触发一次告警，确认通知能收到。三样都通，这个蜜罐才算真正“上班”，否则它只是一台吞流量的黑匣子。

nmap -sV -p 2222 蜜罐IP nc -zv 蜜罐IP 2222

nmap 用于确认服务 banner，nc 用于快速验证端口连通性。之后回到日志目录确认产生了对应记录。这套流程看着简单，但能避免大多数“装完就没管过”的状况。我自己的教训是：最早搭 Dionaea 时，装完只看进程状态，没测端口，结果防火墙规则一直没放行，白白跑了一周零数据。那次之后，验证三连就成了固定动作。希望帮到你。

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