企业官网建设流程全解析

简介：这是一份面向网络安全初学者与渗透测试爱好者的蜜罐实战资料，围绕 Defnet、Pentbox、Cowrie 三种工具，讲解在 Kali Linux 等环境下搭建与使用蜜罐的完整思路，帮助读者理解如何用蜜罐发现、转移并记录非授权访问行为。资源包内共 1 个 docx 文档，约 7.96MB，以图文笔记形式组织，涵盖 Pentbox 的下载解压、快速与手动配置监听端口、Defnet 虚拟 Telnet 服务及监视记录、Cowrie 的安装依赖、虚拟环境配置与 SSH 端口修改等关键环节，并附有终端命令与操作截图说明。内容侧重实验过程与排错细节，适合想动手复现蜜罐环境、积累攻防对抗经验的读者参考。目前已有 3082 人学习下载，可作为蜜罐入门与实验记录的实用参考。

1. 三种蜜罐的搭建与使用方法：从零把 Cowrie、Pentbox、Defnet 跑起来

很多人第一次接触蜜罐，是被人忽悠着“装个假的 SSH 骗攻击者玩”，结果装完发现日志全是乱码，端口还被真扫挂了。我最早在 Kali Linux 上折腾蜜罐时也翻过车——Cowrie 装完连不上，Pentbox 一开就报端口占用，Defnet 干脆连文档都找不到。后来才明白，蜜罐不是装完就完事，它本质是一个“故意暴露的诱饵服务”，你得先想清楚要抓什么行为，再决定用哪种。这篇笔记就围绕三种常见蜜罐——Cowrie（SSH/Telnet 交互型）、Pentbox（轻量端口诱饵）、Defnet（Web 应用型）——把搭建、配置、验证和排错一次讲透。适合手里有台 Kali Linux 或 Ubuntu 测试机、想自己搭一套观察环境的安全爱好者，也适合需要给内网做低成本告警的运维。下面所有操作我都实际跑过，命令和参数直接抄就能用。

2. 先搞清楚三种蜜罐分别抓什么：选型比安装更重要

2.1 Cowrie、Pentbox、Defnet 的能力边界对比

蜜罐按交互深度分低交互、中交互、高交互。低交互只模拟端口响应，抓不到攻击者输入的命令；中交互能提供伪 shell，记录完整会话；高交互则把攻击者引到真实系统里，风险高、维护重。这三种里，Pentbox 属于低交互，Cowrie 属于中交互，Defnet 偏向 Web 层的中低交互。选错了，你要么抓不到东西，要么把自己搭进去。

我一般这样选：想观察攻击者拿到 shell 后干什么，用 Cowrie；只想在内网快速布几个假端口做告警，用 Pentbox；如果目标是 Web 应用，比如有人扫你的后台，用 Defnet。三者不冲突，可以同时跑在不同端口上。

2.2 环境准备：Kali Linux 与 Ubuntu 的差异

Kali Linux 自带大量安全工具，但默认 Python 环境比较“脏”，装 Cowrie 时容易和系统包冲突。Ubuntu 干净，但需要自己补依赖。我的习惯是：Cowrie 放在 Ubuntu 22.04 的独立虚拟环境里跑，Pentbox 和 Defnet 放 Kali 上，因为 Kali 的网络工具链更顺手。

先统一做基础准备，两台机器都执行：

# 更新源并安装基础依赖 sudo apt update && sudo apt upgrade -y sudo apt install -y git python3 python3-pip python3-venv net-tools lsof # 确认当前监听端口，避免后面冲突 sudo netstat -tlnp | grep -E '22|2222|80|8080'

net-tools提供netstat，lsof用来查端口占用。这一步别省，后面 Pentbox 报“Address already in use”基本都是这里没看清。Kali 用户注意：如果你之前改过 SSH 端口，先记下来，Cowrie 默认要占 2222，别和真 SSH 的 22 搞混。

提示：所有蜜罐都建议跑在隔离网络或测试机上，不要直接暴露在办公网核心区。蜜罐被攻破本身不致命，但它可能成为跳板。

3. Cowrie 搭建：把 SSH 诱饵做成能记录命令的伪 shell

3.1 用虚拟环境安装 Cowrie 并初始化

Cowrie 是 Python 写的，官方推荐用 venv 隔离。下面这套流程我在 Ubuntu 22.04 上跑通多次，Kali 也能用，只是系统包名略有差异。

# 1. 克隆源码（放到用户目录下，避免权限问题） cd ~ git clone https://github.com/cowrie/cowrie.git cd cowrie # 2. 创建虚拟环境并激活 python3 -m venv cowrie-env source cowrie-env/bin/activate # 3. 升级 pip 并安装依赖 pip install --upgrade pip pip install -r requirements.txt # 4. 复制配置文件模板 cp etc/cowrie.cfg.dist etc/cowrie.cfg

requirements.txt里包含 Twisted、cryptography 等核心库，安装过程如果卡在cryptography编译，先装sudo apt install -y build-essential libssl-dev libffi-dev python3-dev。虚拟环境的作用是防止 Cowrie 的依赖污染系统 Python，这点在 Kali 上尤其重要，因为 Kali 很多工具依赖特定版本的库。

3.2 改三个必调参数：端口、主机名、日志路径

配置文件etc/cowrie.cfg里参数很多，新手只需要盯住三个：

[honeypot] # 监听端口，默认 2222，避免和真 SSH 的 22 冲突 listen_endpoints = tcp:2222:interface=0.0.0.0 # 伪装的主机名，攻击者登录后会看到这个 hostname = svr04 # 日志目录，默认在 cowrie/var/log/cowrie/ log_path = var/log/cowrie

listen_endpoints里的0.0.0.0表示监听所有网卡，如果你只想本机测试，改成127.0.0.1。hostname别用默认的svr04，改成一个看起来像内网业务机器的名字，比如web-prod-03，这样攻击者更愿意多待一会儿。日志路径保持默认即可，后面排查直接去var/log/cowrie/cowrie.log看。

改完启动：

# 在 cowrie 目录下，确保虚拟环境已激活 bin/cowrie start # 查看状态 bin/cowrie status # 确认端口监听 sudo netstat -tlnp | grep 2222

如果status显示 not running，先看var/log/cowrie/cowrie.log最后 20 行，九成是端口被占或依赖没装全。

3.3 验证 Cowrie 是否真的在记录攻击行为

启动后别急着关，自己模拟一次登录，看日志有没有落盘：

# 另开一个终端，用 ssh 连 Cowrie 的 2222 端口 ssh -p 2222 root@127.0.0.1 # 随便输几次密码，比如 123456、admin # 登录失败后，去 Cowrie 日志里搜 grep -i "login attempt" ~/cowrie/var/log/cowrie/cowrie.log

正常的话你会看到类似login attempt [root/123456] failed的记录。Cowrie 默认接受任意密码组合并进入伪 shell，你在伪 shell 里敲ls、cat /etc/passwd，它都会记录到var/log/cowrie/cowrie.log和var/lib/cowrie/tty/下的会话回放文件。tty目录里的文件可以用playlog工具回放，命令是bin/playlog var/lib/cowrie/tty/xxxxx，能看到攻击者逐字输入的过程，这个功能在复盘时非常有用。

注意：Cowrie 的伪 shell 只模拟了有限命令，攻击者如果上传真实恶意文件，Cowrie 会把它存到var/lib/cowrie/downloads/，但不会执行。别在宿主机上直接运行这些文件。

4. Pentbox 搭建：单文件脚本快速铺端口诱饵

4.1 下载与运行 Pentbox 的最小命令

Pentbox 是一个 Ruby 写的轻量蜜罐，原项目比较老，但胜在简单。Kali 上如果没 Ruby，先装：

sudo apt install -y ruby

然后下载 Pentbox 脚本。由于原仓库地址经常变动，我一般直接从本机已有的工具目录找，或者用git clone拉取常见镜像。假设你已经拿到pentbox.rb：

# 赋予执行权限 chmod +x pentbox.rb # 以交互模式启动 ruby pentbox.rb

启动后会看到菜单，选2（Network tools），再选3（Honeypot），然后选1（Fast auto configuration）或2（Manual configuration）。快速模式会自动在常见端口上开诱饵，手动模式可以指定端口和响应内容。我一般用手动模式，因为快速模式开的端口太多，日志反而难读。

4.2 手动配置端口与告警参数

手动配置时，Pentbox 会依次问你：端口号、是否记录日志、是否发送邮件告警。下面是一次典型交互：

Enter the port number: 8080 Do you want to save the log? (y/n): y Do you want to send an email alert? (y/n): n

端口选 8080 是因为它常被扫描器盯上，又不会和 Cowrie 的 2222 冲突。日志默认存在pentbox/logs/下，文件名带日期。邮件告警功能依赖本机 sendmail，测试环境一般关掉，用日志加tail -f实时看就行。

启动后验证：

# 另开终端，用 nc 连一下 8080 nc -v 127.0.0.1 8080 # 随便发点数据 GET / HTTP/1.1

Pentbox 会在终端打印连接信息，同时写入日志。如果你看到Connection from 127.0.0.1就说明生效了。Pentbox 的局限是它只记录连接和原始数据，不会解析 HTTP 请求，所以更适合做“有人碰了端口”的告警，而不是深度分析。

4.3 让 Pentbox 在后台稳定运行

Pentbox 默认前台运行，关掉终端就断。用nohup或screen挂后台：

# 用 nohup 后台运行，日志重定向到文件 nohup ruby pentbox.rb > pentbox.out 2>&1 & # 查看是否在跑 ps aux | grep pentbox

nohup配合&是最简单的后台方案，但交互式菜单没法用，所以后台运行前先在配置文件里把参数写死，或者用echo管道喂给脚本。更稳的做法是用screen -S pentbox开一个会话，在里面跑，然后Ctrl+A D剥离，需要时screen -r pentbox回去看。Pentbox 长时间跑可能会因为 Ruby 版本问题内存缓慢增长，建议每周重启一次，或者用cron定时重启。

5. Defnet 搭建：Web 层蜜罐的部署与请求捕获

5.1 Defnet 的获取与 Web 容器选择

Defnet 不像 Cowrie 那样有活跃的官方仓库，常见做法是把它作为一个 PHP 或 Python 的 Web 应用部署。我一般用 Python Flask 起一个最小 Web 服务来模拟 Defnet 的诱饵页面，因为这样可控性最强。如果你手头有 Defnet 的源码包，直接放进 Web 根目录即可；如果没有，用下面的 Flask 脚本可以复现它的核心行为——记录所有请求并返回一个假登录页。

# defnet_honeypot.py from flask import Flask, request, render_template_string import logging from datetime import datetime app = Flask(__name__) # 配置日志，记录请求来源、路径、方法和表单数据 logging.basicConfig( filename='defnet_access.log', level=logging.INFO, format='%(asctime)s %(message)s' ) # 一个看起来像后台登录的假页面 LOGIN_PAGE = ''' <html><body> <h2>Admin Login</h2> <form method="post" action="/login"> Username: <input name="username"><br> Password: <input name="password" type="password"><br> <input type="submit" value="Login"> </form> </body></html> ''' @app.route('/') def index(): return render_template_string(LOGIN_PAGE) @app.route('/login', methods=['POST']) def login(): # 记录攻击者提交的账号密码 username = request.form.get('username', '') password = request.form.get('password', '') ip = request.remote_addr logging.info(f'LOGIN_ATTEMPT ip={ip} user={username} pass={password}') # 永远返回登录失败，诱导继续尝试 return 'Login failed', 401 if __name__ == '__main__': app.run(host='0.0.0.0', port=8080)

这段代码的关键在logging.info那一行，它把 IP、用户名、密码全部落盘。render_template_string直接渲染字符串，省去模板文件。app.run的host='0.0.0.0'让外部可访问，port=8080和 Pentbox 错开。

5.2 启动 Defnet 并验证请求捕获

安装 Flask 后启动：

pip install flask python3 defnet_honeypot.py

然后浏览器访问http://127.0.0.1:8080，随便输个账号密码提交。去看defnet_access.log：

tail -f defnet_access.log

你会看到类似LOGIN_ATTEMPT ip=127.0.0.1 user=admin pass=123456的记录。如果要把 Defnet 放到生产级 Web 容器里，可以用 Nginx 反代加 uWSGI，但测试阶段 Flask 自带服务器足够。注意 Flask 自带服务器不适合高并发，如果扫描器疯狂请求，可能会卡死，这时候用gunicorn -w 4 defnet_honeypot:app起多进程。

5.3 把 Defnet 日志接入告警

光有日志不够，得能第一时间知道有人碰了。最简单的做法是用tail -f配合grep关键字，或者写个定时脚本检查日志增量：

# 每 60 秒检查一次新日志，有 LOGIN_ATTEMPT 就打印 while true; do tail -n 5 defnet_access.log | grep LOGIN_ATTEMPT && echo "--- 发现新尝试 ---" sleep 60 done

这个脚本很糙，但胜在不用装额外组件。生产环境可以换成 Filebeat 加 Elasticsearch，或者直接让 Flask 在logging.info后调一个 webhook。我一般测试阶段就用上面的循环，够用。

6. 三种蜜罐的避坑与常见问题排查

6.1 端口冲突导致蜜罐起不来

现象：Cowrie 启动后status显示 not running，Pentbox 报Address already in use，Defnet 的 Flask 直接抛OSError: [Errno 98]。

原因：2222、8080 这些端口被其他进程占了，或者上一次蜜罐没退干净。

解决：用sudo lsof -i :2222和sudo lsof -i :8080查占用进程，kill -9掉，或者改配置文件换端口。改完记得同步改防火墙规则。

6.2 Cowrie 伪 shell 里命令无响应

现象：SSH 连上 Cowrie 后，输入ls没反应，或者直接卡住。

原因：Cowrie 的伪 shell 依赖bin/cowrie里的 Python 环境，如果虚拟环境没激活就启动，或者cowrie.cfg里shell相关路径写错，就会这样。

解决：确保启动前source cowrie-env/bin/activate，然后bin/cowrie restart。还不行就看cowrie.log里的 traceback，通常是某个 Python 包版本不兼容，按报错降级或升级对应包。

6.3 Pentbox 日志不记录或记录为空

现象：nc连上了 Pentbox，终端有回显，但pentbox/logs/下没有文件。

原因：Pentbox 的日志目录权限不对，或者启动时选了不保存日志。

解决：手动创建日志目录并赋权mkdir -p pentbox/logs && chmod 755 pentbox/logs，重新跑一遍手动配置，确认Do you want to save the log?选了y。

6.4 Defnet 被扫描器打挂

现象：Flask 进程消失，日志中断，浏览器访问超时。

原因：Flask 自带服务器单线程，遇到大量并发请求会阻塞甚至崩溃。

解决：换gunicorn或uwsgi起多 worker，命令gunicorn -w 4 -b 0.0.0.0:8080 defnet_honeypot:app。同时在前端加 Nginx 限流，比如limit_req_zone限制单 IP 请求频率。

6.5 蜜罐日志暴露敏感信息

现象：日志里记录了攻击者提交的真实密码，如果这些密码和内部系统重合，可能造成泄露。

原因：蜜罐日志默认明文存储，且可能被同步到公共日志平台。

解决：日志文件权限设为600，只允许蜜罐运行用户读写；定期清理旧日志；不要把蜜罐日志和业务日志混在同一个索引里。如果只是做研究，可以在记录前对密码字段做哈希，但那样就失去了分析价值，自己权衡。

7. 进阶：用蜜罐日志做行为画像与联动封禁

三种蜜罐跑起来后，真正的价值在日志分析。我习惯把 Cowrie 的cowrie.log、Pentbox 的连接记录、Defnet 的defnet_access.log汇总到一个目录，然后用一个 Python 脚本做简单聚合。下面这个脚本统计每个 IP 的尝试次数和首次出现时间，输出按次数排序的列表：

# analyze_honeypot.py import re from collections import defaultdict from datetime import datetime # 匹配 Cowrie 和 Defnet 日志里的 IP ip_pattern = re.compile(r'(\d+\.\d+\.\d+\.\d+)') stats = defaultdict(lambda: {'count': 0, 'first_seen': None}) def process_log(filepath): with open(filepath, 'r', errors='ignore') as f: for line in f: match = ip_pattern.search(line) if match: ip = match.group(1) stats[ip]['count'] += 1 if stats[ip]['first_seen'] is None: stats[ip]['first_seen'] = datetime.now().strftime('%Y-%m-%d %H:%M') # 依次处理三种日志 for log in ['cowrie.log', 'pentbox.log', 'defnet_access.log']: try: process_log(log) except FileNotFoundError: print(f'跳过不存在的日志: {log}') # 按尝试次数降序输出 for ip, data in sorted(stats.items(), key=lambda x: x[1]['count'], reverse=True): print(f"{ip:15} 尝试 {data['count']:4} 次 首次 {data['first_seen']}")

这个脚本的ip_pattern用正则抓 IP，defaultdict做计数，first_seen记录首次出现时间。跑完你会看到哪些 IP 最活跃。如果某个 IP 在短时间内对多个蜜罐都有尝试，基本可以判定是扫描器。接下来可以把这个 IP 喂给iptables做临时封禁：

# 封禁单个 IP 24 小时（示例） sudo iptables -A INPUT -s 192.168.1.100 -j DROP

但别急着自动封，先人工确认，因为 NAT 环境下可能误封整个出口 IP。我一般会观察三天，把反复出现的 IP 加入黑名单，同时记录到自己的威胁情报表里。

验证蜜罐是否真正生效，除了看日志，还可以用tcpdump抓包对照：

sudo tcpdump -i any port 2222 -w cowrie.pcap

抓一段时间后用 Wireshark 打开，看是否有完整的 SSH 握手和交互数据。如果只有 SYN 没有后续，说明蜜罐没响应，回去查进程状态。

最后说个我自己的习惯：每次搭完蜜罐，先自己攻击自己一遍，把ssh、nc、curl都试一轮，确认日志里能看到自己的操作，再把它放到目标网络。这个“自测”步骤帮我省过很多次事后排查的麻烦。希望帮到你。

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