T-Pot蜜罐平台故障排除手册：解决常见的安装和运行问题

T-Pot蜜罐平台故障排除手册：解决常见的安装和运行问题

【免费下载链接】tpotce🍯 T-Pot - The All In One Multi Honeypot Platform 🐝项目地址: https://gitcode.com/gh_mirrors/tp/tpotce

T-Pot 是一款一站式（All-in-One）多蜜罐平台，通过 Docker 同时运行 20 多个蜜罐，并内置 Elastic Stack、攻击地图等可视化工具。新手在安装和日常使用中经常遇到各种报错。这份 T-Pot 故障排除手册把最常见的安装失败、容器起不来、Kibana 无数据、登录失败等问题整理成一套按顺序自查的清单，帮你快速恢复 T-Pot 蜜罐平台的正常运行。

从上图可以看到，T-Pot 由蜜罐、工具、Elastic Stack 等服务组成，全部以容器形式运行在同一个主机上。排查问题前，先记住两条核心路径：

• 配置文件：~/tpotce/.env（所有可调参数都在这里）
• 编排文件：~/tpotce/docker-compose.yml（定义运行哪些容器）

安装失败：先排查这 5 个常见原因 ⚠️

端口冲突：T-Pot 安装失败的头号原因

T-Pot 的蜜罐会占用 22、25、80、443 等大量常用端口。如果系统上已经运行着其他服务（尤其是图形化桌面环境），安装会因端口冲突直接失败。官方明确警告：绝对不要安装 Gnome、KDE 等桌面环境。

排查步骤：

1. 安装系统时选择minimal / netinstall / server最小安装，只保留ssh
2. 查看当前已占用的端口，与 T-Pot 所需端口（README 中有完整端口表）逐一比对：

sudo netstat -tulpen

3. 若有冲突，停掉占用端口的服务后重新安装

Docker 镜像拉取失败：登录解除限流 🐝

T-Pot 默认在每次启动时都会检查并拉取最新镜像（配置项TPOT_PULL_POLICY=always，见 .env 第 167 行）。如果你的 IP 拉取过多镜像，会触发 Docker Hub 下载限流，表现为镜像卡住或拉取报错。解决办法是用 Docker 账号登录后提升限额：

sudo su - docker login

内存不足：按硬件选择合适的版本

Elastic Stack（logstash + elasticsearch）非常"吃"内存。若硬件偏弱，请对照系统要求或选择精简版编排文件：

精简版配置位于~/tpotce/compose/目录，如compose/mini.yml（迷你版）。切换方式：systemctl stop tpot后将对应 yml 复制为~/tpotce/docker-compose.yml，再systemctl start tpot。

系统不匹配：RHEL 订阅与 macOS/Windows 换行符

• RHEL 用户：没有 Red Hat 订阅就无法更新系统、安装软件包，T-Pot 安装会失败；且仅支持 RHEL ≥ 8
• macOS / Windows 用户：用 Docker Desktop 运行时需要两步关键操作——
  1. 克隆仓库后务必确认代码以LF（而非CRLF）换行检出，否则 Shell 脚本会报错
  2. 执行cp compose/mac_win.yml ./docker-compose.yml，再把.env中TPOT_OSTYPE改为mac或win

多网卡主机：网络配置失败

T-Pot 只设计为在单网卡主机上运行，它会自动选择拥有默认路由的网卡。多网卡环境下识别可能失败，导致 fatt、suricata、p0f 等流量类工具工作异常。最简单的方案：给 T-Pot 单独配一台单网卡（或虚拟机）主机。

运行异常：容器与数据问题速查 🔧

容器起不来或反复重启：4 条命令定位

T-Pot 内置了三个别名，是排障的第一步：

dps # 查看所有容器状态 dim # 查看本地镜像及构建时间 docker stats # 实时资源占用（或 htop） docker logs -f <容器名> # 跟踪单个容器日志

如果dps显示容器处于restart循环，用docker logs -f看具体报错；再查看初始化日志cat ~/tpotce/data/tpotinit.log。绝大多数"服务莫名消失"的问题都能在这一步定位到是端口、内存还是配置错误。

Kibana 和攻击地图看不到数据

这是运行期最高频的故障，按顺序排查：

1. 内存 / 存储耗尽（最常见）：如果 Elastic Stack 不可用、收不到日志或反复崩溃，大概率是 RAM 或磁盘问题。重点检查elasticsearch和logstash两个容器的日志中是否有内存告警，并用htop观察磁盘是否写满
2. 日志保留策略：Elasticsearch 索引由tpot索引生命周期策略管理（默认保留 30 天），可在 Kibana 中确认策略是否被误改

3. 验证数据链路：一切正常后，在 Kibana 仪表盘应能看到各蜜罐的攻击事件；攻击地图则提供全局动画视图（WebSocket 连接，切换时可能需重新输入 WebUI 账号）

4. 磁盘快满？：蜜罐日志默认持久化 30 天，保留周期由~/tpotce/.env中的TPOT_PERSISTENCE_CYCLES=30控制；临时清理日志可运行~/tpotce/clean.sh

WebUI 登录失败：分清两种账号 🔑

这是认证错误最常见的原因：T-Pot 有两套完全独立的账号，混用必然失败。

如果 Web 用户丢失或需要新增成员，运行~/tpotce/genuser.sh即可；删除用户则编辑~/tpotce/.env中的WEB_USER（base64 字符串），改完systemctl stop tpot && systemctl start tpot生效。

Sensor 无法向 Hive 上报日志（分布式部署）

传感器日志经 Logstash 回传 Hive，连接采用 SSL 校验。若 Hive 有多个可达 IP 或域名，自签名证书缺少对应 SAN 会导致校验失败、日志发不出去。解决方案二选一：

• 在 Hive 上用 openssl 重新生成包含所有 IP/域名的自签名证书（命令见 README 的 Distributed Deployment 章节），或
• 测试环境临时在.env中将LS_SSL_VERIFICATION改为none（仅限实验室）

传感器部署脚本为 deploy.sh，它会自动校验 SSH 密钥是否已通过ssh-copy-id -p 64295推送成功。

为什么 T-Pot 每天凌晨自动重启？

这不是故障！T-Pot 默认在每天 02:42 停止服务、清理容器后自动重启（用sudo crontab -e可修改该定时任务）。若你觉得频繁，直接调整或注释掉对应 cron 行即可。

终极方案：T-Pot 恢复出厂设置 💯

当系统"坏到无法修复"时，官方给出的方案永远是重装，流程如下：

systemctl stop tpot # 1. 停止服务 # 2. （可选）备份 ~/tpotce/data 到安全位置 sudo rm -rf ~/tpotce/data # 3. 删除数据目录 cd ~/tpotce && git reset --hard # 4. 重置到最近一次拉取的版本 ./install.sh # 5. 重新运行安装器

日常维护提醒：升级版本前先备份自定义配置（.env、ews.cfg），升级脚本~/tpotce/update.sh会无情覆盖本地改动，但会自动备份整个~/tpotce目录。

附：T-Pot 故障自查速查表 ✅

结语

T-Pot 的设计目标是"低维护、开箱即用"，绝大多数故障都集中在端口冲突、内存不足、账号混用这三类。按本文顺序自查，配合dps、docker logs -f、tpotinit.log三件套，基本可以在十分钟内定位问题。祝你的蜜罐平台早日"满巢"！🍯

【免费下载链接】tpotce🍯 T-Pot - The All In One Multi Honeypot Platform 🐝项目地址: https://gitcode.com/gh_mirrors/tp/tpotce