Threat Intelligence Platform Series
    Part 2 of 6

    T-Pot Honeypot Platform Deployment

    Stand up T-Pot 24.04 as the deception layer, choose the right edition for VPS, and prepare its data for downstream consumption by Wazuh and MISP.

    75 minutes
    Premium 16 GB / 200 GB
    Prerequisites

    Part 1 complete; deception VPS in WireGuard mesh

    Time

    ~75 minutes (plus reboot cycles)

    Outcome

    T-Pot capturing live traffic and exporting EVE JSON

    T-Pot Architecture Overview

    T-Pot is a Debian-based ISO and installer that deploys an Elastic stack core (Elasticsearch, Logstash, Kibana) plus 20+ honeypot containers wired together with shared volumes and a Logstash pipeline. Every honeypot writes structured JSON; Logstash normalises events into Elastic; Kibana ships pre-built dashboards.

    The single biggest mental model: the honeypots only listen on the public interface, while the management UI, Elastic, and the Cockpit console live on a separate port range bound to the WireGuard interface. The two surfaces never overlap.

    Edition Selection

    • Standard — full honeypot suite + Elastic. ~16 GB RAM, ~200 GB disk. The default for this series.
    • Sensor — honeypots only, ships logs to a remote Hive. Use for satellite collectors.
    • Hive — Elastic + dashboards, no honeypots. Pair with multiple Sensors.
    • Hive-Sensor — both roles colocated. Useful for a single-VPS lab.
    • Mini — small subset of honeypots. Fits a 4 GB box but loses a lot of coverage.

    For this stack we deploy Standard. Wazuh and MISP take the role a Hive would otherwise play.

    Host Preparation

    T-Pot wants its own filesystem layout, an overlay-friendly Docker storage driver, and several sysctl tweaks for the high connection rates honeypots attract:

    /etc/sysctl.d/99-tpot.conf
    net.core.somaxconn = 4096
    net.ipv4.ip_local_port_range = 1024 65535
    net.ipv4.tcp_tw_reuse = 1
    fs.file-max = 2097152
    vm.max_map_count = 262144

    Mount block storage at /data with noatime before install — T-Pot creates its persistent volumes there.

    T-Pot Install Walkthrough

    apt update && apt install -y git
    git clone https://github.com/telekom-security/tpotce /opt/tpot
    cd /opt/tpot
    ./install.sh --type=user
    # Choose: STANDARD edition, set a strong web user password
    # The installer reboots; SSH moves to port 64295.

    Post-reboot, verify with systemctl status tpot and docker ps. Expect roughly 25 containers running.

    Honeypot Service Inventory

    • Cowrie — SSH and Telnet, full session capture.
    • Dionaea — multi-protocol malware capture (SMB, FTP, MSSQL, MySQL).
    • Honeytrap — low-interaction TCP fallback for unmapped ports.
    • Conpot — ICS/SCADA (Modbus, S7, BACnet).
    • ElasticPot — fake Elasticsearch.
    • RedisHoneypot — fake Redis with config-rewrite attack capture.
    • Heralding — credential collector for HTTP, FTP, IMAP, POP3, SMTP, VNC, RDP.
    • Tanner — web app honeypot with SNARE crawler bait.
    • • Plus Adbhoney, Citrixhoneypot, Ddospot, Dicompot, Hellpot, Ipphoney, Sentrypeer, and several others.

    The Mailoney Question on RamNode

    Mailoney is a low-interaction SMTP honeypot. It listens for inbound SMTP attack traffic; it does not send mail. RamNode's outbound mail policy is therefore not directly violated by running Mailoney.

    The risk is indirect: an open SMTP listener on a public IP can attract reputation hits even when it is a honeypot. If you would rather not deal with that, disable it cleanly:

    sed -i '/mailoney:/,/^[[:space:]]*$/d' /opt/tpot/etc/compose/standard.yml
    systemctl restart tpot

    The other honeypots are unaffected.

    Attack Map, Cyberchef, Spiderfoot, SecurityMeter

    T-Pot's web UI bundles four utility dashboards in addition to Kibana:

    • Attack Map — live geographic view of incoming connections.
    • Cyberchef — local instance for decoding captured payloads without leaking them externally.
    • Spiderfoot — OSINT enrichment for source IPs.
    • SecurityMeter — high-level risk scoring across the captured corpus.

    Firewall Posture: T-Pot iptables vs RamNode Edge

    T-Pot installs its own iptables rules that DNAT every public port 1–64000 to honeypot containers. Do not layer UFW on top — you will end up with NAT confusion and silent drops.

    At the RamNode edge, the only rules you need are: allow all TCP/UDP to the public IP, and drop everything to the management ports (64294–64297) except from the bastion.

    Exporting EVE JSON to the Detection Zone

    The Logstash pipeline already produces EVE-format JSON. Add a TCP output that ships to the detection zone for Suricata/Zeek enrichment and Wazuh consumption (Part 6):

    /data/elk/logstash/conf/output-detection.conf
    output {
      if [type] in ["Cowrie", "Dionaea", "Honeytrap"] {
        tcp {
          host => "10.88.0.20"
          port => 5170
          codec => json_lines
        }
      }
    }

    Restart only the Logstash container; the rest of T-Pot stays online.

    What the First 24 Hours Look Like

    Expect within the first day: tens of thousands of Cowrie SSH login attempts (mostly root/root, admin/admin, Mirai variants), several hundred HTTP scans for PHPUnit, Drupalgeddon, Log4Shell, and routine Conpot/Modbus probes from internet-wide scanners. Top source ASNs are usually a mix of cloud providers and residential proxies.

    Operational Maintenance

    • Index lifecycle — T-Pot ships an ILM policy that rolls indices at 50 GB and deletes after 30 days. Adjust to fit your disk.
    • Disk pressure — set an alert at 80% on /data; Elastic refuses writes at 95%.
    • Updates/opt/tpot/update.sh handles container updates; major version jumps are a re-image.

    Hardening the Management UI Behind the Bastion

    Bind the T-Pot UI to the WireGuard interface only and let Caddy on the management VPS handle public access:

    ufw allow in on wg0 to any port 64297 proto tcp
    ufw deny in on eth0 to any port 64297 proto tcp