A default SSH port exposed to the open internet draws roughly 1,900 connection attempts per day from automated bots, with root:root still the most-tried credential pair as of late 2025. That’s the background radiation a honeypot operator turns into intelligence — and the choice of platform decides whether you end up with a usable dashboard, a research dataset, or a maintenance burden.
Three projects dominate the open-source honeypot conversation in 2026: T-Pot, the all-in-one platform from Telekom Security; Cowrie, the SSH/Telnet workhorse maintained by Michel Oosterhof; and DShield, the lightweight SANS Internet Storm Center sensor that feeds a global threat-intelligence pool. They are not direct competitors. They sit at different points on the interaction, complexity, and contribution-versus-private-research axes, and picking the wrong one wastes weeks of setup time on a goal the tool was never built to serve.
What Each One Actually Is
T-Pot is a Dockerized multi-honeypot platform built on Debian Stable, currently at version 24.04.1. A single installer brings up 20+ honeypot containers behind a reverse proxy and pipes everything into an Elastic Stack with prebuilt Kibana dashboards, an animated attack map, CyberChef, Elastivue, and SpiderFoot. The 24.04.1 release added LLM-driven honeypots — Beelzebub for SSH and Galah for HTTP — alongside Go-Pot (an HTTP tarpit), Honeyaml (a configurable API honeypot supporting JWT bearer tokens), H0neytr4p (an HTTP/S honeypot with configurable vulnerability traps), and Miniprint (a medium-interaction printer honeypot). Editions — Standard, Hive, Sensor, Mini, LLM, and Tarpit — let you scope which stack runs on each host.
Cowrie is a single-purpose medium-to-high interaction SSH and Telnet honeypot, currently at 2.9.0 on PyPI. In shell mode it emulates a Debian filesystem in Python and logs every command, credential pair, downloaded payload, and SFTP transfer. In proxy mode it sits in front of a real backend so you observe attacker behavior against a live system. The 2.x line added an LLM mode that uses a language model to generate dynamic shell responses to commands the static emulator doesn’t handle. Cowrie is one component, not a stack — you bring your own log shipper, your own dashboard, and your own ingest pipeline.
DShield is the honeypot client distributed by the SANS Internet Storm Center. It’s a thin orchestration layer around Cowrie, a web honeypot (web.py), and a TCP honeypot (tcp-honeypot.py), plus firewall logging. Data ships to ISC every 30 minutes and joins a global feed used for the project’s threat reports, port-trend graphs, and Fightback abuse referrals. The supported install targets are Raspberry Pi OS and Ubuntu 24.04 LTS. You get a basic MyReports view of your own sensor’s traffic, but the heavy analytics happen at ISC, not on your box.
RAM: 8–16 GB+
Disk: 128 GB+
Best for: broad threat-intel labs
RAM: 512 MB+
Disk: 10 GB+
Best for: SSH credential and payload research
RAM: 512 MB+
Disk: minimal
Best for: contributing to a global feed
Installing T-Pot 24.04.1
T-Pot needs a clean supported host. The maintained list is Alma 9.5, Fedora 41, Rocky 9.5, Debian Stable, Raspbian, and Ubuntu 24.04.1. Provision a VM or bare-metal box with at least 8 GB RAM and 128 GB disk for the Standard edition — heavier workloads (full LLM honeypots, distributed Hive) want 16 GB. The installer needs outbound internet on all ports for container pulls and threat-intel sync. Run as a non-root user with sudo rights.
# 1. Update the base OS and install git
sudo apt update && sudo apt -y upgrade
sudo apt -y install git
# 2. Clone the repo (do NOT run as root)
git clone https://github.com/telekom-security/tpotce
cd tpotce
# 3. Run the installer and pick an edition when prompted
./install.sh
# 4. After install completes, reboot
sudo rebootThe installer asks for an edition (STANDARD, HIVE, SENSOR, MINI, LLM, or TARPIT), a web-UI username and password, and confirmation that it can rewrite SSH config to move real SSH to port 64295. After reboot, log in over SSH on the new port and confirm everything is up:
ssh -p 64295 <user>@<host>
systemctl status tpot
docker psHit https://<host>:64297 in a browser for the landing page — Kibana, Attack Map, CyberChef, SpiderFoot, and Elastivue are all linked from there. If you picked the LLM edition, install Ollama on the host or set the OPENAI_API_KEY in ~/tpotce/.env before the Beelzebub and Galah containers will respond intelligently. To switch editions later, re-run compose/customizer.py to regenerate docker-compose.yml. Expect 30–60 minutes from blank disk to working dashboard, longer on a slow link.
Installing Cowrie 2.9.0
The project documents three install paths: git clone (recommended for any real configuration work), Docker (fastest), and pip (still beta). Use git clone. The example below assumes Ubuntu 24.04 LTS.
# 1. Install dependencies
sudo apt update
sudo apt -y install git python3-virtualenv libssl-dev libffi-dev \
build-essential libpython3-dev python3-minimal authbind \
virtualenv
# 2. Create a non-privileged user for Cowrie
sudo adduser --disabled-password cowrie
sudo su - cowrie
# 3. Clone and set up the virtualenv
git clone https://github.com/cowrie/cowrie
cd cowrie
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install --upgrade pip
pip install --upgrade -r requirements.txt
# 4. Create the config from the dist template
cp etc/cowrie.cfg.dist etc/cowrie.cfg
# 5. Start Cowrie
bin/cowrie startBy default Cowrie listens on TCP 2222 for SSH and 2223 for Telnet. To capture traffic on the real ports without running as root, redirect with iptables on the host (as your sudo user, not as cowrie):
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222
sudo iptables -t nat -A PREROUTING -p tcp --dport 23 -j REDIRECT --to-port 2223
# Persist rules across reboots
sudo apt -y install iptables-persistent
sudo netfilter-persistent saveMove your real SSH daemon to a non-standard port (Port 2200 in /etc/ssh/sshd_config, then sudo systemctl restart ssh) before applying the redirect, or you’ll lock yourself out. Edit etc/cowrie.cfg to set the hostname, banner, and SSH version string the attacker sees — leaving these at defaults makes the honeypot trivially fingerprintable. Logs land in var/log/cowrie/cowrie.json, downloaded payloads in var/lib/cowrie/downloads/ keyed by SHA-256, and session replays in var/lib/cowrie/tty/ playable through bin/playlog.
To run the Docker version for a quick test:
docker run -d -p 2222:2222 -p 2223:2223 \
-v $(pwd)/cowrie-etc:/cowrie/cowrie-git/etc \
-v $(pwd)/cowrie-var:/cowrie/cowrie-git/var \
--name cowrie cowrie/cowrie:latestInstalling the DShield Sensor
DShield assumes a dedicated host. The installer rewrites firewall rules to route inbound traffic on ports 22, 23, and 80 into the honeypot and moves real SSH to TCP 12222. Don’t install it on a system you use for anything else. Supported targets are Raspberry Pi OS on a Pi 3/4/5 and Ubuntu 24.04 LTS on a VPS, cloud instance, or VM.
Before touching the host, register at isc.sans.edu, verify your email, enable two-factor auth, and copy your User ID and API Key from My Account.
# 1. Update the base OS
sudo apt update && sudo apt -y upgrade
sudo apt -y install git
# 2. Clone the DShield repo
cd /srv
sudo git clone https://github.com/DShield-ISC/dshield.git
cd dshield/bin
# 3. Run the installer
sudo ./install.shThe installer is interactive. It will ask for your ISC email, User ID, and API Key; the IP range you SSH in from (whitelisted for port 12222); whether to enable HTTPS honeypot listeners; and the email address for daily summary reports. It rewrites /etc/ssh/sshd_config to listen on 12222, installs Cowrie and the web/TCP honeypots into /srv/dshield/, configures cron jobs for log uploads and weekly self-updates, and rewrites iptables so 22, 23, and 80 redirect into the honeypot stack.
After the installer prints Please reboot your Pi now, reboot and reconnect on the new port:
ssh -p 12222 <user>@<host>
sudo /srv/dshield/bin/status.shA healthy install shows every check green. Add a weekly auto-update cron job to keep the sensor current:
sudo crontab -e
# add:
0 5 * * 1 /srv/dshield/bin/update.sh && rebootLogs flow to https://isc.sans.edu/myreports.html within an hour and split into Firewall, Web, and SSH/Telnet views. If your home IP changes and you lose access to the management port, you’ll need console access to the host to re-whitelist — a real failure mode on residential connections, less so on a cloud VM.
What Each Stack Actually Captures
T-Pot’s pipeline is the most elaborate. Each honeypot container writes JSON logs to a shared volume. Logstash parses them, Elasticsearch indexes them, and Kibana renders them across honeypot-specific dashboards. Attack Map (currently 2.2.6) pulls a separate event stream over WebSockets to animate live hits on a globe. SpiderFoot, CyberChef, and Elastivue are available as side tools for enrichment, decoding, and ad-hoc index inspection. Because everything terminates in Elasticsearch, you can ship the data out via the Elastic API, the Logstash output plugins, or by tapping the raw container logs.
Cowrie writes plain JSON to var/log/cowrie/cowrie.json plus session replay files in a UML-compatible format that the bundled playlog utility can reconstruct command-by-command. Downloaded payloads land in var/lib/cowrie/downloads/, hashed by SHA-256 so duplicate samples don’t re-download — useful when one IOC like 178.16.54.252/bins.sh gets tried 70 times in a row by the same Mirai-like loader. Each connection also captures the SSH version banner and the HASSH fingerprint, a hash of the client’s handshake parameters that survives banner spoofing and clusters bots that share the same SSH library.
DShield does double duty: full logs stay locally in /srv/dshield/ for the operator’s own analysis, while a sanitized subset uploads to ISC every half-hour. The ISC side feeds the public port-trend graphs, the Threat Feeds, and the Fightback abuse-notification program. The local MyReports view splits into Firewall, Web, and SSH/Telnet sections, but the depth of analytics is intentionally light — DShield is a collection node, not a SIEM.
Reference: Honeypots and Ports by Platform
Pitfalls and Operational Reality
Fingerprinting is the universal weakness. Cowrie’s default banner, the canonical fake Debian 5.0 filesystem, the consistent latency of Python-emulated shells, and the absence of standard utilities have been documented enough that any non-trivial attacker can detect Cowrie within a handful of commands. Research from late 2025 — including the Q-Cowrie reinforcement-learning variant published in early 2026 — exists precisely because static deception is increasingly identifiable. Customize banners, filesystems, hostnames, and SSH version strings before you let the honeypot collect data anyone will publish on.
T-Pot’s footprint is real. The Standard edition runs 20+ containers plus the Elastic Stack. On 8 GB RAM you’ll see Kibana lag during heavy ingest, and the daily cron prune job that the installer adds (41 3 * * *) is there because container churn fills the disk faster than people expect. The Mini edition exists for hosts that can’t carry the full stack.
DShield’s firewall rewrite locks in assumptions. The installer takes your current public IP as the allowed source for port 12222 management access. On a residential connection with a dynamic IP, the next ISP renewal locks you out. Cloud installs are easier; SANS publishes Terraform examples for AWS and Azure deployments.
Cloud-provider terms apply. AWS, Azure, GCP, and most VPS providers’ acceptable use policies prohibit running anything that solicits attacks. Honeypots typically pass because they don’t initiate malicious traffic, but if the box gets compromised — which is a non-zero risk on any high-interaction setup — and starts cryptomining or scanning, your account is the one that gets suspended. Set up billing alerts and egress monitoring before exposing anything.
Legal exposure varies. Logging credentials, payloads, and IP addresses of unsolicited inbound traffic is generally fine in most jurisdictions; running a high-interaction proxy that lets attackers pivot through your infrastructure to third parties is not. Read your jurisdiction’s wiretapping and computer-misuse statutes before enabling Cowrie’s proxy mode.
Frequently Asked Questions
Can I run T-Pot and DShield on the same host? No. Both want to bind ports 22, 23, and 80 and both rewrite the firewall. Run them on separate hosts or pick one.
Does T-Pot already include Cowrie? Yes. T-Pot ships Cowrie as one of its containers, alongside Beelzebub for LLM-based SSH. Running standalone Cowrie makes sense when you want a small footprint, a custom configuration the T-Pot bundle doesn’t expose, or you’re feeding a pipeline you’ve already built.
Will running a honeypot get me attacked more? The honeypot itself is what gets attacked, not the rest of your network — assuming you’ve isolated it properly. The actual risk is the honeypot being compromised through a bug in the emulator and used as a pivot. Network-segment the host, restrict outbound traffic to only what the honeypot legitimately needs, and monitor outbound connections.
Can I contribute Cowrie logs to DShield without installing the DShield wrapper? Yes, via Cowrie’s DShield output plugin, configured in cowrie.cfg. You’ll need an API key and user ID from isc.sans.edu. This is the right path if you want a tuned standalone Cowrie and still want to give back to the global feed.
How to Pick
If you want a research lab that exposes a broad attack surface — SSH, web, ICS, printer, API, SMB — and you have the hardware budget and the Elastic Stack tolerance, run T-Pot. The LLM edition is the most interesting development in honeypot software in years and worth a look even if you end up disabling it.
If you only care about SSH and Telnet, want full control over the deception layer, and plan to ship logs into a stack you already operate, run Cowrie standalone. It’s the building block the other two are made of.
If your goal is to contribute to a global threat-intelligence project, you want low maintenance, and a Raspberry Pi on your home network is acceptable infrastructure, run DShield. It’s the smallest commitment, gives back the most to the community, and the MyReports view is enough to feel the texture of internet background scanning without managing a SIEM.
The honeypots aren’t substitutes. They’re three different answers to three different questions about what an attacker on the open internet looks like.






