Why Honeypots Matter

Every probe, every credential guess, every payload dropped on a honeypot is intelligence. Production systems generate alerts you have to triage — most turn out to be noise. A web server logs a suspicious request and you spend twenty minutes determining it was a vulnerability scanner run by your own penetration testing firm. A firewall flags a port scan that turns out to be Shodan. The signal-to-noise ratio in production security monitoring is, on a good day, miserable.

Honeypots invert that ratio entirely. There is no legitimate reason for anyone to interact with a honeypot. No users rely on it. No applications call it. No monitoring systems poll it. If something touches a honeypot, it is either an attacker or a misconfigured system — and either way, you need to know about it. No false positives. No ambiguity. Every alert is, by definition, hostile activity or an operational error worth investigating.

I deployed my first honeyd instance in 1998. Back then, a honeypot was a single daemon on a spare machine, logging SSH brute-force attempts to a flat file you parsed with grep and awk. The intelligence was crude but valuable — you could see who was scanning your range, what credentials they tried, what exploits they threw at you. The problem was operational overhead. Each honeypot was a bespoke build. Each needed care and feeding. Scaling meant more machines, more maintenance, more time you were not spending on the threats that mattered.

The landscape has changed. The threat actors have industrialised. The tooling should match.

T-Pot changes that equation entirely.

What T-Pot Is

T-Pot is Telekom Security's all-in-one honeypot platform. It bundles over a dozen honeypot daemons behind a single deployment — all containerised with Docker, all feeding into an Elastic Stack with Kibana dashboards. One machine. One install. A dozen attack surfaces, each emulating a different service.

The honeypots included in a standard T-Pot deployment:

Behind these sits the Elastic Stack — Elasticsearch for storage and search, Logstash for log ingestion and parsing, Kibana for visualisation and dashboarding. T-Pot also ships with the Attack Map for real-time geographic visualisation of incoming attacks, CyberChef for payload analysis and deobfuscation, and Spiderfoot for OSINT enrichment of attacker infrastructure.

All of this runs on a single machine. Docker handles the isolation between services. The Elastic Stack aggregates everything into a unified view.

Requirements

Do not underestimate the resource requirements. T-Pot runs a dozen Docker containers simultaneously, each consuming memory and CPU. Elasticsearch alone, under sustained attack volumes, will consume several gigabytes of heap.

Minimum specifications:

Network Placement

This is the most important architectural decision in the entire deployment. Get it wrong and a captured payload phones home through your production network — or worse, pivots to your real infrastructure.

Place the honeypot in a DMZ or on a dedicated VLAN with no route to production networks. The honeypot must not be able to reach your real infrastructure if a payload executes inside a container. This means no default gateway pointing at your core router. No DNS servers on your internal network. No management interfaces accessible from the honeypot's subnet.

Firewall rules should be explicit — deny all outbound by default, then allow only what T-Pot needs to function.

Outbound allowlist:

Monitor everything else. Every outbound connection that is not on your allowlist is a signal. If you see unexpected outbound traffic from the honeypot, a captured payload is attempting to phone home — reaching out to command-and-control infrastructure, downloading second-stage payloads, or attempting to propagate. You need to know about it without letting it succeed. Your firewall blocks the connection. Your monitoring tells you it was attempted. That attempted connection is intelligence — it reveals the payload's C2 infrastructure.

Installation on Ubuntu 22.04 or 24.04

Start with a clean Ubuntu Server installation. Minimal install — no desktop environment, no unnecessary packages. Every additional package is additional attack surface, and on a honeypot, that distinction matters more than usual.

Update the system first:

sudo apt update && sudo apt upgrade -y
sudo reboot

Install git if it is not already present:

sudo apt install -y git

Clone the T-Pot repository:

git clone https://github.com/telekom-security/tpotce
cd tpotce

Run the installer:

sudo ./install.sh

The installer walks you through several prompts. Each matters.

Edition selection — choose Standard for a single-machine deployment with all honeypots running locally. The Hive edition is for distributed deployments — a central Hive node with remote Sensor nodes deployed at multiple locations, all reporting back to the central dashboard. The Sensor edition is the lightweight remote component of a Hive deployment. Start with Standard unless you are deploying across multiple locations or need to cover multiple network segments.

Web interface credentials — set a username and password for the Kibana dashboard and the T-Pot web interface. Use a strong, unique credential pair. This is your primary analysis interface and the gateway to your attack data. Treat it accordingly.

SSH management port — T-Pot moves the system's SSH daemon to port 64295. This is not optional and it is not a suggestion. Port 22 must be free for Cowrie to listen on — Cowrie emulates a real SSH server to capture brute-force credentials and record full interactive shell sessions. Your real SSH access moves to 64295. Update your SSH client configuration, any jump host scripts, and your firewall rules accordingly.

ssh -p 64295 user@honeypot-ip

Update your ~/.ssh/config to avoid typing the port every time:

Host honeypot
    HostName honeypot-ip
    Port 64295
    User your-username

The installer configures Docker, pulls all container images from Docker Hub, sets up the Elastic Stack with appropriate memory limits, and configures systemd services for automatic startup. This takes time — depending on your connection speed, expect 15–30 minutes for the initial image pull. The total download is several gigabytes.

After installation completes, reboot:

sudo reboot

On reboot, T-Pot starts automatically. All containers launch via Docker Compose. The Elastic Stack initialises and begins accepting logs from the honeypot containers. Give it five to ten minutes to fully start — Elasticsearch needs time to initialise its indices and Kibana needs to load its dashboards and visualisations.

Firewall Considerations

The honeypot machine must expose its honeypot ports to the internet. This is the opposite of normal server hardening — you want attackers to find and interact with these services. That deliberate exposure is the entire point.

On the host firewall, allow inbound traffic to the honeypot ports. T-Pot manages its own iptables rules for the Docker container network, routing incoming connections to the appropriate container based on port. Do not interfere with Docker's iptables chains — modifying them will break the routing and leave containers unreachable.

On your perimeter firewall or cloud security group, allow inbound TCP and UDP to the honeypot's public IP on the standard service ports — 22 (SSH/Cowrie), 23 (Telnet), 25 (SMTP/Mailoney), 80 and 443 (HTTP/HTTPS), 445 (SMB/Dionaea), 502 (Modbus/Conpot), and others depending on which honeypots you want to expose. The full list is in the T-Pot documentation.

Restrict management access. SSH on port 64295 and the web interface on port 64297 should be accessible only from your administrative IP addresses. Never expose the management interfaces to the internet — that would make your analysis dashboard a target alongside the honeypots.

sudo ufw allow from YOUR_ADMIN_IP to any port 64295 proto tcp
sudo ufw allow from YOUR_ADMIN_IP to any port 64297 proto tcp

If your admin IP changes — a home connection, a VPN exit — update the rule before you lose access. Lock yourself out of a remote honeypot and you are arranging console access or a site visit.

The Kibana Dashboard

Access the T-Pot web interface at https://honeypot-ip:64297. The certificate is self-signed by default — accept the browser warning or replace it with a certificate from your own CA if your organisation's policy requires it.

The Kibana dashboard is where the intelligence lives. T-Pot ships with pre-built dashboards that present the data from all honeypots in a unified view.

Attack origins on a world map — geographic clustering of source IPs. You will see patterns emerge within days. Heavy scanning from specific autonomous systems — hosting providers popular with attackers, bulletproof hosting operations, compromised residential ranges indicating botnet activity. Regional concentrations shift over time, reflecting geopolitical events, law enforcement actions, and the migration of threat actors between infrastructure.

Credential pairs — the username and password combinations tried against Cowrie. The same lists have been circulating since the early 2000s. admin/admin, root/password, root/123456, admin/admin123, test/test, user/user. These are dictionary attacks, not targeted. Occasionally you see something more specific — credentials that suggest the attacker knows what software they expect to find, or credentials from a recent breach dump appearing in the wild within days of the dump's release. That timing is intelligence.

Malware samples — Dionaea captures binaries dropped by attackers. These are real, live malware samples. Handle them accordingly — do not extract them to an uncontained system. CyberChef, included in T-Pot, lets you analyse payloads without leaving the interface — decode base64 encoding, extract embedded URLs, deobfuscate JavaScript or PowerShell scripts, compute hashes for VirusTotal lookups.

Protocol targeting — which services attract the most traffic. SSH and Telnet dominate the volume charts on any internet-facing honeypot. SMB sees periodic spikes — often correlating with newly disclosed Windows vulnerabilities. ICS protocols — Modbus, S7comm — attract a surprising and growing amount of traffic, much of it from researchers, security firms, and nation-state reconnaissance operations mapping exposed industrial infrastructure.

Time-series attack volume — the rhythm of the internet's background radiation. You will see daily patterns that correspond to working hours in major source regions, weekly cycles with reduced activity on weekends in some regions and increased activity in others, and sudden spikes that correlate with exploit publications, CVE announcements, or proof-of-concept releases on GitHub.

The Attack Map provides a real-time visualisation — lines arcing across a world map from source IPs to your honeypot. It is visually impressive and useful for demonstrations, but operationally limited compared to the filtered and faceted views in Kibana's Discover and Dashboard interfaces.

Forwarding to a SIEM

T-Pot's data becomes substantially more valuable when correlated with your production security telemetry. An IP address that appears in your honeypot logs and then shows up in your production authentication logs is a high-confidence indicator — you know the source is hostile because it interacted with a system that exists solely to identify hostile actors.

Send T-Pot's Logstash output to your SIEM — Wazuh, Graylog, Splunk, or whatever your organisation runs.

The simplest method is syslog forwarding from Logstash. Add an output block to the Logstash pipeline configuration:

output {
  syslog {
    host => "siem.internal.example.com"
    port => 514
    protocol => "tcp"
    facility => "local0"
    severity => "informational"
  }
}

For Elasticsearch-to-Elasticsearch replication — useful when your SIEM is also Elastic-based — configure cross-cluster replication or use a dedicated Logstash pipeline as an intermediary. Read from T-Pot's Elasticsearch indices, transform the events into your SIEM's expected format, and write to the destination cluster.

The Wazuh tutorial elsewhere on this site covers the receiving end. Wazuh's decoder and rule framework can parse T-Pot's log formats and generate alerts based on honeypot activity. The high-value correlation is a credential pair or source IP seen on the honeypot subsequently appearing in production authentication logs. That correlation — hostile actor confirmed by honeypot, now targeting production — is a high-confidence alert that justifies immediate investigation.

Operational Security

Running a honeypot is running a target. Treat the infrastructure accordingly.

Do not run production services on the honeypot machine. No web applications, no databases, no file shares, no jump hosts. The machine exists to be attacked. Its compromise — within the container boundaries — is expected and intentional. Container escapes are rare but not impossible. The machine should contain nothing of value beyond the attack data it collects.

Monitor outbound traffic continuously. A captured payload may attempt to phone home, download additional stages, join a botnet, or attempt to propagate to other systems. Your firewall should block this, but monitoring tells you it happened. That blocked outbound connection attempt is intelligence — it reveals the payload's command-and-control infrastructure, the URLs it attempts to download from, the protocols it uses.

Rotate the external IP periodically if you want fresh attacker populations. Persistent IPs get fingerprinted and added to honeypot blacklists — yes, attackers and their tools maintain lists of known honeypots. Greynoise, Shodan, and Censys all tag known honeypot IPs. A fresh IP, unknown to these services, attracts a different and often more interesting population of scanners and attackers.

Keep T-Pot updated. New honeypot signatures are added, Elasticsearch receives security patches, and container vulnerabilities are addressed. The update process pulls new images and restarts:

cd /opt/tpot
sudo docker compose pull
sudo docker compose up -d

Check the T-Pot GitHub repository for release notes before updating. Breaking changes are rare but possible — especially around major Elasticsearch version upgrades that change index mappings or Kibana dashboard formats.

Consider running multiple honeypots in different network positions. A T-Pot instance on a cloud VPS in Frankfurt attracts different traffic than one on a residential ISP in London. A Hive deployment — the distributed edition — lets you centralise the data from multiple Sensor nodes into a single Kibana dashboard. The geographic diversity of your sensor placement directly affects the breadth of intelligence you collect.

What the Data Tells You

After a few weeks of operation, patterns emerge that are invisible from any other vantage point. The internet's background radiation — the constant wash of automated scanning and exploitation attempts — is remarkably consistent in its composition but reveals meaningful signals when you track its evolution.

Attack patterns over time reveal campaign activity. A sudden spike in Conpot traffic might indicate a new ICS exploit in circulation — sometimes days before the corresponding CVE is published. A shift in credential lists suggests a new breach dump has been released and integrated into automated attack tools. Geographic clustering changes reflect real-world events — sanctions regimes, armed conflicts, law enforcement takedowns of hosting providers.

Credential reuse trends are particularly revealing. When you see a credential pair on your honeypot that matches something in your production environment — even an old, decommissioned account — that is an indicator worth investigating immediately. Cross-reference honeypot credentials with your Active Directory, LDAP directory, or identity provider. The match might be coincidence — common defaults appear everywhere. But a specific, unusual credential appearing on both systems is a signal.

Integration with threat intelligence amplifies the value of every data point. Feed honeypot IOCs — source IPs, malware hashes, C2 domains extracted from captured payloads — into your blocklists and detection rules. Correlate with ipinsights.io data for enrichment — ASN ownership, historical reputation, association with known threat actor infrastructure, prior activity across other sensors.

This is where passive observation becomes active defence. The honeypot is not just a sensor — it is a source of intelligence that feeds your detection and prevention stack. Every IP that touches the honeypot and later appears in your production logs is a confirmed hostile actor, not a probabilistic risk score.

Fail2Ban, covered in a separate tutorial, blocks attackers at the gate. The honeypot tells you what they were trying to do once inside. Together, they form two halves of a defensive picture — one prevents, the other informs.

Maintaining the Deployment

T-Pot is not a deploy-and-forget system. Elasticsearch indices grow. Disk fills. Containers need updates. Captured malware accumulates. Allocate time for maintenance — an hour a week is sufficient for a single-node deployment.

Monitor disk usage. Elasticsearch indices can be pruned with index lifecycle management policies or T-Pot's built-in housekeeping, but verify the retention is running. A full disk stops Elasticsearch, which stops log ingestion, which makes your honeypot blind — it is still attracting attacks but no longer recording them.

Review the dashboards regularly. Weekly is the minimum useful cadence. Daily is better if the honeypot is feeding a production threat intelligence programme. Look for anomalies — unusual protocols being targeted, new credential patterns emerging, traffic from unexpected source regions, sudden volume changes that do not correlate with known events.

Back up the Elasticsearch data if you want historical analysis beyond the retention window. T-Pot's data directory contains the Elasticsearch indices, the Kibana saved objects, and the captured samples. A compressed archive on a weekly schedule provides a reasonable baseline:

sudo tar czf /backup/tpot-data-$(date +%Y%m%d).tar.gz /data

Store backups on a separate system. The honeypot is a target — its backups should not be.

Document your T-Pot deployment — the network segment it sits on, the firewall rules that govern it, the SIEM integration configuration, the update procedure, and the credentials for the web interface. If you leave the organisation or are unavailable, someone else needs to maintain it. A honeypot that falls out of maintenance does not just stop providing intelligence — it becomes a liability. An unpatched Elasticsearch instance with months of accumulated data, exposed to the internet, is exactly the kind of target attackers look for.

The return on investment from a honeypot deployment is proportional to the effort you put into analysing the data and integrating it with your broader security operations. A deployed and forgotten T-Pot instance collects dust and disc space. A deployed and monitored instance — with IOCs flowing into blocklists, credential pairs cross-referenced against production directories, and anomaly reports triggering investigations — is a genuine force multiplier for a defensive security programme.

Deploy T-Pot on a dedicated machine in an isolated network segment, configure your firewall to expose honeypot ports whilst restricting management access to administrative IPs only, forward the logs to your SIEM for correlation with production telemetry, feed the extracted IOCs into your blocklists and detection rules, and review the dashboards weekly at minimum — a honeypot that nobody looks at is just another neglected server on the internet, contributing nothing to your defensive posture.