tpotce: T-Pot: The Honeypot OS That Turns Attack Traffic Into a Live Intelligence Pipeline
A deep dive into Telekom Security’s containerized deception platform, where read-only honeypots, distributed sensors, and ELK dashboards turn intrusion attempts into a high-signal map of hostile behavior.
- T-Pot turns deception into a managed sensing system, with filtering, storage, and visualization stitched into one deployable platform.
- Its read-only containers and blackholing logic are not cosmetic hardening, they are the mechanism that keeps noisy internet traffic useful.
- The Hive and Sensor model makes distributed honeypot deployments feel operational instead of fragile.
- The project stays relevant because it now spans classic decoys, ICS simulation, and experimental LLM-based honeypots.
A honeypot stack that behaves like infrastructure
Most honeypot projects stop at the decoy. T-Pot goes further. It packages the decoys, the filtering layer, the log pipeline, and the dashboards into one system that feels closer to an appliance than a pile of containers.
That matters because the hard part is not making an attacker knock on a fake SSH port. The hard part is turning that knock into something you can search, compare, and act on. T-Pot is built for that second job.
T-Pot 24.04.1 brings significant updates and exciting new honeypot additions, especially the LLM-based honeypots Beelzebub and Galah!
Why read-only containers matter
T-Pot does something that sounds simple and is actually subtle: it makes the honeypot service reachable, but not mutable. In the compose files, many services are marked read_only: true, which means the attacker can interact with the decoy, but not easily alter the container filesystem itself.
That changes the security posture. Downloads and samples can still be captured, but they are pushed into persistent volumes instead of a writable container layer. The service stays alive, the evidence stays useful, and the blast radius stays small.
services:
cowrie:
read_only: true
volumes:
- ${TPOT_DATA_PATH}/cowrie/downloads:/data/downloads
- ${TPOT_DATA_PATH}/cowrie/log:/data/log
The hidden brain: tpotinit, host networking, and blackholing scanners
The real trick sits below the honeypots. T-Pot uses tpotinit as a bootstrap and control layer, and it gives that layer enough privilege to shape the host network itself. That is why you see host networking and NET_ADMIN in the stack. In a normal app, those choices would be alarming. In a deception appliance, they are the point.
The blackhole logic is even more interesting. Known mass scanners can be null-routed, which trims away low-value noise and leaves a cleaner stream of behavior. The result is not invisibility. It is triage.
| Layer | Normal container app | T-Pot control layer |
|---|---|---|
| Network mode | Bridge networking | Host networking for host-level control |
| Privileges | Minimal caps | NET_ADMIN for filtering and routing |
| Filesystem | Usually writable | Many services are read-only |
| Traffic handling | Collect then log | Collect, filter, then triage |
| Goal | Run a service | Run a deception system |
T-Pot stands out from other honeypot solutions because of its flexibility and ease of use. It includes a wide range of pre-configured honeypots, such as Dionaea, Cowrie, and Glastopf, as well as other security tools like Suricata and the ELK stack.
Hive and Sensor: one brain, many traps
T-Pot’s distributed model is what makes it feel like a system, not just a host. Sensors sit at the edge and collect interaction locally. The Hive centralizes the analysis so the operator gets one place to search, visualize, and compare attacks across deployments.
That is also why the deployment tooling matters. Scripts like deploy.sh and the Ansible flow are not decoration. They make a distributed security lab reproducible, which is the difference between a demo and an operational practice.
| Dimension | Sensor | Hive |
|---|---|---|
| Role | Edge collection | Central analysis |
| Data path | Local capture plus forwarding | Indexing and visualization |
| Resource profile | Lighter footprint | Heavier ELK stack |
| Best use | Placement near exposed surfaces | Cross-site correlation |
| Operational feel | Remote trap | Command center |
The payoff is obvious when you look at the stack as a whole. A sensor can be cheap, disposable, and geographically close to the traffic you care about. The Hive turns those isolated traps into a coherent picture.
Why T-Pot is more than a honeypot museum
T-Pot is not a random gallery of decoys. It is curated around attack surfaces that matter: SSH, web applications, malware ingestion, industrial control systems, and protocol-specific traps. That breadth is what makes the dashboards interesting. You are not just seeing one kind of attacker, you are seeing a changing mix of hostile behavior.
The ICS angle is especially strong. Conpot templates for protocols like IEC104, guardian_ast, and IPMI push the project beyond commodity brute-force telemetry. It can stand in for infrastructure that actually matters to real defenders.
Marco and I created a preconfigured SD card, which would bootstrap and register at a puppet server for configuration management. ... It was then, when Marco (@t3chn0m4g3), the brainchild of T-Pot, joined our team.
The new frontier: AI-powered deception
The experimental llm.yml profile is easy to dismiss as a novelty until you think about the use case. Traditional honeypots catch scripted behavior well. LLM-based honeypots are trying to stretch the interaction far enough that a human or a more adaptive tool keeps talking.
That does not replace the classic traps. It extends them. T-Pot now spans old-school credential scraping, protocol simulation, and newer conversational decoys, which is a good sign that the project is evolving with the threat surface instead of fossilizing.
profiles:
- standard.yml
- sensor.yml
- llm.yml
services:
beelzebub:
enabled: true
galah:
enabled: experimentalHow T-Pot compares to MHN, CHN, and OpenCanary
The clean way to think about the comparison is this. T-Pot optimizes for breadth, visualization, and distributed collection. Other projects optimize for different cuts of the problem.
| Project | Deployment model | Bundled services | Visualization | Distributed sensing | Best fit |
|---|---|---|---|---|---|
| T-Pot | Docker-based appliance | Very broad | ELK dashboards | Yes | Research labs, SOCs, homelabs |
| MHN | Central server plus sensors | Broad for its era | Older dashboard model | Yes | Legacy distributed honeypot setups |
| CommunityHoneyNetwork | Docker and microservices | Moderate | Functional | Yes | Lighter distributed collection |
| OpenCanary | Single-purpose canary | Narrow | Minimal | Not the focus | Internal detection |
| Cowrie or Dionaea | Standalone honeypot | Single service | External tools required | No | Targeted experiments |
OpenCanary is quieter by design. Cowrie and Dionaea are building blocks, not orchestration layers. T-Pot is the thing you use when you want the building blocks, the surrounding controls, and the dashboards in one place.
Why this repo keeps winning
Mature open-source security projects survive by being boring in the right places. T-Pot keeps the architecture cohesive, the deployment path repeatable, and the surface area broad enough to stay useful. That combination explains why it shows up in researcher labs, SOC workflows, and homelabs that want to watch the internet hit back.
The central contributor pattern is also part of the story. A strong maintainer core gives the project direction, which is especially valuable in a security tool where integration quality matters as much as feature count.
