T-Pot - The All In One Multi Honeypot Platform

T-Pot is the all in one, optionally distributed, multiarch (amd64, arm64) honeypot plattform, supporting 20+ honeypots and countless visualization options using the Elastic Stack, animated live attack maps and lots of security tools to further improve the deception experience.

TL;DR

1. Meet the system requirements. The T-Pot installation needs at least 8-16 GB RAM, 128 GB free disk space as well as a working (outgoing non-filtered) internet connection.
2. Download or use a running, supported distribution.
3. Install the ISO with as minimal packages / services as possible (ssh required)
4. Install curl: $ sudo [apt, dnf, zypper] install curl if not installed already
5. Run installer as non-root from $HOME:

env bash -c "$(curl -sL https://github.com/telekom-security/tpotce/raw/master/install.sh)"

• Follow instructions, read messages, check for possible port conflicts and reboot

• T-Pot - The All In One Multi Honeypot Platform
• TL;DR
• Disclaimer
• Technical Concept
  • Honeypots and Tools
  • Technical Architecture
  • Services
  • User Types
• System Requirements
  • Running in a VM
  • Running on Hardware
  • Running in a Cloud
  • Required Ports
  • LLM-Based Honeypots
    • Ollama
    • ChatGPT
• System Placement
• Installation
  • Choose your distro
  • Raspberry Pi 4 (8GB) Support
  • Get and install T-Pot
  • Unattended Installation
  • Testing a Branch
  • macOS & Windows
  • Red Hat Enterprise Linux
  • Installation Types
    • Standard / Hive
    • Distributed
  • Uninstall T-Pot
• First Start
  • Standalone First Start
  • Distributed Deployment
    • Planning and Certificates
    • Deploying Sensors
    • Removing Sensors
  • Community Data Submission
  • Opt-In HPFEEDS Data Submission
• Remote Access and Tools
  • SSH
  • T-Pot Landing Page
  • Kibana Dashboard
  • Attack Map
  • Cyberchef
  • Elasticvue
  • Spiderfoot
• Configuration
  • T-Pot Config File
  • Customize T-Pot Honeypots and Services
• Maintenance
  • General Updates
  • Update Script
  • Updating From an Older Release
  • Restore Script
  • Daily Reboot
  • Known Issues
    • Docker Images Fail to Download
    • T-Pot Networking Fails
    • Update Script Loops
  • Start T-Pot
  • Stop T-Pot
  • T-Pot Data Folder
  • Log Persistence
  • Factory Reset
  • Show Containers and Images
  • Blackhole
  • Add Users to Nginx (T-Pot WebUI)
  • Import and Export Kibana Objects
    • Export
    • Import
• Troubleshooting
  • Logs
  • RAM and Storage
• Contact
  • Issues
  • Discussions
• Licenses
• Credits
  • The developers and development communities of
  • The following companies and organizations
  • And of course YOU for joining the community!
• Testimonials
• Thank you 💖

Disclaimer

• You install and run T-Pot within your responsibility. Choose your deployment wisely as a system compromise can never be ruled out.
• For fast help research the Issues and Discussions.
• The software is designed and offered with best effort in mind. As a community and open source project it uses lots of other open source software and may contain bugs and issues. Report responsibly.
• Honeypots - by design - should not host any sensitive data. Make sure you don't add any.
• By default, your data is submitted to Sicherheitstacho. You can disable this in the config (~/tpotce/docker-compose.yml) by removing the ewsposter section. But in this case sharing really is caring!
  
  

Technical Concept

T-Pot's main components have been moved into the tpotinit Docker image allowing T-Pot to now support multiple Linux distributions, even macOS and Windows (although both limited to the feature set of Docker Desktop). T-Pot uses docker and docker compose to reach its goal of running as many honeypots and tools as possible simultaneously and thus utilizing the host's hardware to its maximum.

Honeypots and Tools

• T-Pot offers docker images for the following honeypots:
  adbhoney, beelzebub, ciscoasa, citrixhoneypot, conpot, cowrie, ddospot, dicompot, dionaea, elasticpot, endlessh, galah, go-pot, glutton, h0neytr4p, hellpot, heralding, honeyaml, honeypots, honeytrap, ipphoney, log4pot, mailoney, medpot, miniprint, redishoneypot, rdphoneypot, sentrypeer, snare, tanner, wordpot

Alongside the following tools:

• Autoheal a tool to automatically restart containers with failed healthchecks.
• Cyberchef a web app for encryption, encoding, compression and data analysis.
• Elastic Stack to beautifully visualize all the events captured by T-Pot.
• Elasticvue a web front end for browsing and interacting with an Elasticsearch cluster.
• Fatt a pyshark based script for extracting network metadata and fingerprints from pcap files and live network traffic.
• T-Pot-Attack-Map a beautifully animated attack map for T-Pot.
• P0f is a tool for purely passive traffic fingerprinting.
• Spiderfoot an open source intelligence automation tool.
• Suricata a Network Security Monitoring engine.

... to give you the best out-of-the-box experience possible and an easy-to-use multi-honeypot system.

Technical Architecture

The source code and configuration files are fully stored in the T-Pot GitHub repository. The docker images are built and preconfigured for the T-Pot environment.

The individual Dockerfiles and configurations are located in the docker folder.

Services

T-Pot offers a number of services which are basically divided into five groups:

1. System services provided by the OS
   • SSH for secure remote access.
2. Elastic Stack
   • Elasticsearch for storing events.
   • Logstash for ingesting, receiving and sending events to Elasticsearch.
   • Kibana for displaying events on beautifully rendered dashboards.
3. Tools
   • NGINX provides secure remote access (reverse proxy) to Kibana, CyberChef, Elasticvue, GeoIP AttackMap, Spiderfoot and allows for T-Pot sensors to securely transmit event data to the T-Pot hive.
   • CyberChef a web app for encryption, encoding, compression and data analysis.
   • Elasticvue a web front end for browsing and interacting with an Elasticsearch cluster.
   • T-Pot Attack Map a beautifully animated attack map for T-Pot.
   • Spiderfoot an open source intelligence automation tool.
4. Honeypots
   • A selection of the 23 available honeypots based on the selected docker-compose.yml.
5. Network Security Monitoring (NSM)
   • Fatt a pyshark based script for extracting network metadata and fingerprints from pcap files and live network traffic.
   • P0f is a tool for purely passive traffic fingerprinting.
   • Suricata a Network Security Monitoring engine.
     
     

User Types

During the installation and during the usage of T-Pot there are two different types of accounts you will be working with. Make sure you know the differences of the different account types, since it is by far the most common reason for authentication errors.

System Requirements

Depending on the supported Linux distro images, hive / sensor, installing on real hardware, in a virtual machine or other environments there are different kind of requirements to be met regarding OS, RAM, storage and network for a successful installation of T-Pot (you can always adjust ~/tpotce/docker-compose.yml and ~/tpotce/.envto your needs to overcome these requirements).

T-Pot does require ...

• an IPv4 address via DHCP or statically assigned
• a working, non-proxied, internet connection ... for a successful installation and operation.
  
  If you need proxy support or otherwise non-standard features, you should check the docs of the supported Linux distro images and / or the Docker documentation.
  
  

Running in a VM

All of the supported Linux distro images will run in a VM which means T-Pot will just run fine. The following were tested / reported to work:

• UTM (Intel & Apple Silicon)
• VirtualBox
• VMWare Fusion and VMWare Workstation
• KVM is reported to work as well.

Some configuration / setup hints:

• While Intel versions run stable, Apple Silicon (arm64) support has known issues which in UTM may require switching Display to Console Only during initial installation of the OS and afterwards back to Full Graphics.
• During configuration you may need to enable promiscuous mode for the network interface in order for fatt, suricata and p0f to work properly.
• If you want to use a wifi card as a primary NIC for T-Pot, please be aware that not all network interface drivers support all wireless cards. In VirtualBox e.g. you have to choose the "MT SERVER" model of the NIC.
  
  

Running on Hardware

T-Pot is only limited by the hardware support of the supported Linux distro images. It is recommended to check the HCL (hardware compatibility list) and test the supported distros with T-Pot before investing in dedicated hardware.

Running in a Cloud

T-Pot is tested on and known to run on ...

• Telekom OTC using the post install method ... others may work, but remain untested.

Some users report working installations on other clouds and hosters, i.e. Azure and GCP. Hardware requirements may be different. If you are unsure you should research issues and discussions and run some functional tests. With T-Pot 24.04.0 and forward we made sure to remove settings that were known to interfere with cloud based installations.

Required Ports

Besides the ports generally needed by the OS, i.e. obtaining a DHCP lease, DNS, etc. T-Pot will require the following ports for incoming / outgoing connections. Review the T-Pot Architecture for a visual representation. Also some ports will show up as duplicates, which is fine since used in different editions.

Ports and availability of SaaS services may vary based on your geographical location.

For some honeypots to reach full functionality (i.e. Cowrie or Log4Pot) outgoing connections are necessary as well, in order for them to download the attacker's malware. Please see the individual honeypot's documentation to learn more by following the links to their repositories.

LLM-Based Honeypots

We think LLM-Based Honeypots mark the beginning of a game change for the deception / honeypot field. Consequently, starting with the release of T-Pot 24.04.1, two LLM-based honeypots, Beelzebub and Galah, have been introduced. These honeypots require an installation of Ollama, which needs to be configured in the T-Pot configuration file. You can also adjust the settings in this file for ChatGPT support, but note that changes will also be required in the docker compose file (~/tpotce/compose/llm.yml) to accommodate these adjustments.

Follow the links in the Honeypots and Tools section to find out more about Beelzebub and Galah.

Ollama

🚨 CPU-based usage is not recommended, not even for testing.

To set up and run Ollama, refer to the Ollama GitHub repository for instructions. For entry-level or testing purposes, results can be achieved using a Nvidia RTX 4060 Ti 16GB or equivalent (AMD's ROCm is also supported by Ollama), with models like openchat and Llama3. As a general rule with LLM-based systems, the better and more hardware you use, the faster and more accurate the results will be, especially when tasks are offloaded to multiple GPUs and larger models.

ChatGPT

ChatGPT support for these honeypots will remain untested in relation to T-Pot.

System Placement

It is recommended to get yourself familiar with how T-Pot and the honeypots work before you start exposing towards the internet. For a quickstart run a T-Pot installation in a virtual machine.

Once you are familiar with how things work you should choose a network you suspect intruders in or from (i.e. the internet). Otherwise T-Pot will most likely not capture any attacks (unless you want to prove a point)! For starters it is recommended to put T-Pot in an unfiltered zone, where all TCP and UDP traffic is forwarded to T-Pot's network interface. To avoid probing for T-Pot's management ports you should put T-Pot behind a firewall and forward all TCP / UDP traffic in the port range of 1-64000 to T-Pot while allowing access to ports > 64000 only from trusted IPs and / or only expose the ports relevant to your use-case. If you wish to catch malware traffic on unknown ports you should not limit the ports you forward since glutton and honeytrap dynamically bind any TCP port that is not occupied by other honeypot daemons and thus give you a better representation of the risks your setup is exposed to.

Installation

Download one of the supported Linux distro images, follow the TL;DR instructions or git clone the T-Pot repository and run the installer ~/tpotce/install.sh. Running T-Pot on top of a running and supported Linux system is possible, but a clean installation is recommended to avoid port conflicts with running services. The T-Pot installer will require direct access to the internet as described here.

Choose your distro

Steps to Follow:

1. Download a supported Linux distribution from the list below. T-Pot follows the current release of each distribution, the installer will stop on an older one. (NOTE: Red Hat Enterprise Linux 10 is supported, but omitted from the list below due to its subscription-based nature. See Red Hat Enterprise Linux for details).
2. During installation choose a minimum, netinstall or server version that will only install essential packages.
3. Never install a graphical desktop environment such as Gnome or KDE. T-Pot will fail to work with it due to port conflicts.
4. Make sure to install SSH, so you can connect to the machine remotely.

Raspberry Pi 4 (8GB) Support

Get and install T-Pot

1. Clone the GitHub repository: $ git clone https://github.com/telekom-security/tpotce or follow the TL;DR and skip this section.
2. Change into the tpotce/ folder: $ cd tpotce
3. Run the installer as non-root: $ ./install.sh:
   • ⚠️ Depending on your Linux distribution of choice the installer will:
     • Abort if a service occupies the DNS or SMTP ports the honeypots need, before anything is changed
     • Change the SSH port to tcp/64295
     • Disable the DNS Stub Listener to avoid port conflicts with honeypots
     • Set SELinux to Monitor Mode
     • Set the firewall target for the public zone to ACCEPT
     • Add Docker's repository and install Docker
     • Install recommended packages
     • Remove packages known to cause issues
     • Add the current user to the docker group (allow docker interaction without sudo)
     • Add dps, dpsw and dim aliases for formatted container and image overviews
     • Add la, ll and ls aliases (for exa, a improved ls command)
     • Add mi (for micro, a great alternative to vi and / or nano)
     • Display open ports on the host (compare with T-Pot required ports)
     • Add and enable tpot.service to /etc/systemd/system so T-Pot can automatically start and stop
4. Follow the installer instructions, you will have to enter your user (sudo or root) password at least once
5. Check the installer messages for errors and open ports that might cause port conflicts
6. Reboot: $ sudo reboot

On Ubuntu 26.04 sudo is sudo-rs, which formats its password prompt differently. Ansible does not recognise that prompt and privilege escalation times out, a fix exists upstream but is not released yet. The installer detects this and runs Ansible against the traditional sudo that Ubuntu still ships as /usr/bin/sudo.ws - nothing to do, it says so when it happens. If you would rather have it system wide, switch the alternative: $ sudo update-alternatives --set sudo /usr/bin/sudo.ws.

Unattended Installation

The installer can run without any interaction, i.e. for automated tests or cloud provisioning:

./install.sh -s -t <type> [-u <webuser>] [-p <password>]

⚠️ -s requires passwordless sudo for the user running the installer. Ansible would otherwise ask for the BECOME password and the run would stall, so the installer stops right away and tells you so. Grant it before you start:

echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/$(whoami)
sudo chmod 440 /etc/sudoers.d/$(whoami)

Remove /etc/sudoers.d/<user> after the installation if you do not want to keep it. On Debian without sudo installed the installer creates this rule itself, because it has to add sudo anyway - it says so when it does.

Testing a Branch

By default T-Pot installs from master. To test changes to the installer itself, the installer, the Ansible playbook and the T-Pot repository can be taken from any branch, tag or commit - and from a fork:

# from a local clone, the checked out branch is used automatically
git clone -b my-feature https://github.com/telekom-security/tpotce ~/tpotce
~/tpotce/install.sh

# explicitly, works the same for an unattended run
./install.sh -b my-feature -r https://github.com/someuser/tpotce -s -t h -u user -p pass

# as environment variables, i.e. for the one-liner or cloud provisioning
TPOT_BRANCH=my-feature env bash -c "$(curl -sL https://github.com/telekom-security/tpotce/raw/my-feature/install.sh)"

The installer takes the first of these it finds: the options, the environment variables, the branch and origin of the local clone it runs from, and finally master of https://github.com/telekom-security/tpotce. It prints what it settled on before it changes anything. Two things to keep in mind:

• With the one-liner the branch appears twice, in the URL you download install.sh from and in TPOT_BRANCH - they have to match, the script cannot tell where it was downloaded from.
• An existing ~/tpotce is always used as it is, so the installer stops if it is on a different repository or branch than the one requested. Remove it (sudo rm -rf ~/tpotce) and run the installer again.

update.sh takes the same two options, so an existing installation can be moved to another branch or fork to test the update procedure itself:

# update an existing installation from a branch, -y is still required
~/tpotce/update.sh -y -b my-feature

# the same from a fork, this replaces the URL of 'origin' in ~/tpotce
~/tpotce/update.sh -y -b my-feature -r https://github.com/someuser/tpotce

# back to the released version
~/tpotce/update.sh -y -b master

The branch is checked out for good, so every following update.sh -y keeps updating from it. Here -b names a branch, not a tag or commit, and there are two more differences to the installer:

• Without -b and -r nothing changes, the branch and origin of ~/tpotce are kept - a plain update.sh -y behaves as it always has.
• If a branch has moved the version tag on, update.sh only warns about it as long as -b or -r is given. On such an installation keep passing the option, a plain update.sh -y refuses to update a version it does not know.
  
  

macOS & Windows

Sometimes it is just nice if you can spin up a T-Pot instance on macOS or Windows, i.e. for development, testing or just the fun of it. As Docker Desktop is rather limited not all honeypot types or T-Pot features are supported. Also remember, by default the macOS and Windows firewall are blocking access from remote, so testing is limited to the host. For production it is recommended to run T-Pot on Linux.
To get things up and running just follow these steps:

1. Install Docker Desktop for macOS or Windows.
2. Clone the GitHub repository: git clone https://github.com/telekom-security/tpotce (in Windows make sure the code is checked out with LF instead of CRLF!)
3. Go to: cd ~/tpotce
4. Copy cp compose/mac_win.yml ./docker-compose.yml
5. Create a WEB_USER by running ~/tpotce/genuser.sh (macOS) or ~/tpotce/genuserwin.ps1 (Windows)
6. Adjust the .env file by changing TPOT_OSTYPE=linux to either mac or win:

   # OSType (linux, mac, win)
   #  Most docker features are available on linux
   TPOT_OSTYPE=mac
   

7. You have to ensure on your own there are no port conflicts keeping T-Pot from starting up.
8. Start T-Pot: docker compose up or docker compose up -d if you want T-Pot to run in the background.
9. Stop T-Pot: CTRL-C (it if was running in the foreground) and / or docker compose down -v to stop T-Pot entirely.

Red Hat Enterprise Linux

Red Hat Enterprise Linux (RHEL) is a somewhat unique case in that:

1. Connections to Red Hat repositories depend on a Red Hat subscription. You will not be able to update the OS or install new packages if the targeted machine is not subscribed. If your server is not attached to a Red Hat subscription, installation will fail!
2. Ansible is installed from a RHEL-specific repository by the installer. Do not attempt to install it from the upstream repositories.
3. Docker is installed from EPEL, which is installed by the installer script. Do not attempt to install it from the community installer script.
4. T-Pot will only install successfully on RHEL 10. The convenience dependency grc is not available for RHEL and is omitted from the RHEL installation of T-Pot.

Installation Types

Standard / Hive

With T-Pot Standard / Hive all services, tools, honeypots, etc. will be installed on to a single host which also serves as a Hive endpoint. Make sure to meet the system requirements. You can adjust ~/tpotce/docker-compose.yml to your personal use-case or create your very own configuration using ~/tpotce/compose/customizer.py for a tailored T-Pot experience to your needs. Once the installation is finished you can proceed to First Start.

Distributed

The distributed version of T-Pot requires at least two hosts

• the T-Pot Hive, the standard installation of T-Pot (install this first!),
• and a T-Pot Sensor, which will host only the honeypots, some tools and transmit log data to the Hive.
• The Sensor will not start before finalizing the Sensor installation as described in Distributed Deployment.
  
  

Uninstall T-Pot

Uninstallation of T-Pot is only available on the supported Linux distros.
To uninstall T-Pot run ~/tpotce/uninstall.sh and follow the uninstaller instructions, you will have to enter your password at least once.
Once the uninstall is finished reboot the machine sudo reboot

First Start

Once the T-Pot Installer successfully finishes, the system needs to be rebooted (sudo reboot). Once rebooted you can log into the system using the user you setup during the installation of the system. Logins are according to the User Types:

• user: [<OS_USERNAME>]
• pass: [password]

You can login via SSH to access the command line: ssh -l <OS_USERNAME> -p 64295 <your.ip>:

• user: [<OS_USERNAME>]
• pass: [password, ssh key recommended]

You can also login from your browser and access the T-Pot WebUI and tools: https://<your.ip>:64297

• user: [<WEB_USER>]
• pass: [password]
  
  

Standalone First Start

There is not much to do except to login and check via dps if all services and honeypots are starting up correctly. You can use dim to review the installed Docker images including their CREATED age, then login to Kibana and / or Geoip Attack Map to monitor the attacks.

Distributed Deployment

Planning and Certificates

The distributed deployment involves planning as T-Pot Init will only create a self-signed certificate for the IP of the Hive host which usually is suitable for simple setups. Since logstash will check for a valid certificate upon connection, a distributed setup involving Hive to be reachable on multiple IPs (i.e. RFC 1918 and public NAT IP) and maybe even a domain name will result in a connection error where the certificate cannot be validated as such a setup needs a certificate with a common name and SANs (Subject Alternative Name).
Before deploying any sensors make sure you have planned out domain names and IPs properly to avoid issues with the certificate. For more details see issue #1543.
Adjust the example to your IP / domain setup and follow the commands to change the certificate of Hive:

sudo systemctl stop tpot

sudo openssl req \
    -nodes \
    -x509 \
    -sha512 \
    -newkey rsa:8192 \
    -keyout "$HOME/tpotce/data/nginx/cert/nginx.key" \
    -out "$HOME/tpotce/data/nginx/cert/nginx.crt" \
    -days 3650 \
    -subj '/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd' \
    -addext "subjectAltName = IP:192.168.1.200, IP:1.2.3.4, DNS:my.primary.domain, DNS:my.secondary.domain"
    
sudo chmod 774 $HOME/tpotce/data/nginx/cert/*
sudo chown tpot:tpot $HOME/tpotce/data/nginx/cert/*

sudo systemctl start tpot

The T-Pot configuration file (.env) does allow to disable the SSL verification for logstash connections from Sensor to the Hive by setting LS_SSL_VERIFICATION=none. For security reasons this is only recommended for lab or test environments.

If you choose to use a valid certificate for the Hive signed by a CA (i.e. Let's Encrypt), logstash, and therefore the Sensor, should have no problems to connect and transmit its logs to the Hive.

Deploying Sensors

Once you have rebooted the Sensor as instructed by the installer you can continue with the distributed deployment by logging into Hive and go to cd ~/tpotce folder. Make sure you understood the Planning and Certificates before continuing with the actual deployment.

If you have not done already generate a SSH key to securely login to the Sensor and to allow Ansible to run a playbook on the sensor:

1. Run ssh-keygen, follow the instructions and leave the passphrase empty:

   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/<your_user>/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/<your_user>/.ssh/id_rsa
   Your public key has been saved in /home/<your_user>/.ssh/id_rsa.pub
   

2. Deploy the key to the Sensor by running ssh-copy-id -p 64295 <Sensor_SSH_USER>@<Sensor_IP>):

   /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/<your_user>/.ssh/id_rsa.pub"
   The authenticity of host '[<Sensor_IP>]:64295 ([<Sensor_IP>]:64295)' can't be stablished.
   ED25519 key fingerprint is SHA256:naIDxFiw/skPJadTcgmWZQtgt+CdfRbUCoZn5RmkOnQ.
   This key is not known by any other names.
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
   <your_user>@172.20.254.124's password:
   
   Number of key(s) added: 1
   
   Now try logging into the machine, with:   "ssh -p '64295' '<your_user>@<Sensor_IP>'"
   and check to make sure that only the key(s) you wanted were added.
   

3. As suggested follow the instructions to test the connection ssh -p '64295' '<your_user>@<Sensor_IP>'.
4. Once the key is successfully deployed run ./deploy.sh and follow the instructions.
   
   

Removing Sensors

Identify the TPOT_HIVE_USER ENV on the Sensor in the $HOME/tpotce/.env config (it is a base64 encoded string). Now identify the same string in the LS_WEB_USER ENV on the Hive in the $HOME/tpotce/.env config. Remove the string and restart T-Pot.
Now you can safely delete the Sensor machine.

Community Data Submission

T-Pot is provided in order to make it accessible to everyone interested in honeypots. By default, the captured data is submitted to a community backend. This community backend uses the data to feed Sicherheitstacho. You may opt out of the submission by removing the # Ewsposter service from ~/tpotce/docker-compose.yml by following these steps:

1. Stop T-Pot services: systemctl stop tpot
2. Open ~/tpotce/docker-compose.yml: micro ~/tpotce/docker-compose.yml
3. Remove the following lines, save and exit micro (CTRL+Q):

# Ewsposter service
  ewsposter:
    container_name: ewsposter
    restart: always
    depends_on:
      tpotinit:
        condition: service_healthy
    networks:
     - ewsposter_local
    environment:
     - EWS_HPFEEDS_ENABLE=false
     - EWS_HPFEEDS_HOST=host
     - EWS_HPFEEDS_PORT=port
     - EWS_HPFEEDS_CHANNELS=channels
     - EWS_HPFEEDS_IDENT=user
     - EWS_HPFEEDS_SECRET=secret
     - EWS_HPFEEDS_TLSCERT=false
     - EWS_HPFEEDS_FORMAT=json
    image: ${TPOT_REPO}/ewsposter:${TPOT_VERSION}
    pull_policy: ${TPOT_PULL_POLICY}
    volumes:
     - ${TPOT_DATA_PATH}:/data
     - ${TPOT_DATA_PATH}/ews/conf/ews.ip:/opt/ewsposter/ews.ip

4. Start T-Pot services: systemctl start tpot

It is encouraged not to disable the data submission as it is the main purpose of the community approach - as you all know sharing is caring 😍

Opt-In HPFEEDS Data Submission

As an Opt-In it is possible to share T-Pot data with 3rd party HPFEEDS brokers.

1. Follow the instructions here to stop the T-Pot services and open ~/tpotce/docker-compose.yml.
2. Scroll down to the ewsposter section and adjust the HPFEEDS settings to your needs.
3. If you need to add a CA certificate add it to ~/tpotce/data/ews/conf and set EWS_HPFEEDS_TLSCERT=/data/ews/conf/<your_ca.crt>.
4. Start T-Pot services: systemctl start tpot.
   
   

Remote Access and Tools

Remote access to your host / T-Pot is possible with SSH (on tcp/64295) and some services and tools come with T-Pot to make some of your research tasks a lot easier.

SSH

According to the User Types you can login via SSH to access the command line: ssh -l <OS_USERNAME> -p 64295 <your.ip>:

• user: [<OS_USERNAME>]
• pass: [password]
  
  

T-Pot Landing Page

According to the User Types you can open the T-Pot Landing Page from your browser via https://<your.ip>:64297:

• user: [<WEB_USER>]
• pass: [password]

Kibana Dashboard

On the T-Pot Landing Page just click on Kibana and you will be forwarded to Kibana. You can select from a large variety of dashboards and visualizations all tailored to the T-Pot supported honeypots.

Attack Map

On the T-Pot Landing Page just click on Attack Map and you will be forwarded to the Attack Map. Since the Attack Map utilizes web sockets you may need to re-enter the <WEB_USER> credentials.

Cyberchef

On the T-Pot Landing Page just click on Cyberchef and you will be forwarded to Cyberchef.

Elasticvue

On the T-Pot Landing Page just click on Elasticvue and you will be forwarded to Elasticvue.

Spiderfoot

On the T-Pot Landing Page just click on Spiderfoot and you will be forwarded to Spiderfoot.

Configuration

T-Pot Config File

T-Pot offers a configuration file providing variables not only for the docker services (i.e. honeypots and tools) but also for the docker compose environment. The configuration file is hidden in ~/tpoce/.env. There is also an example file (env.example) which holds the default configuration.
Before the first start run ~/tpotce/genuser.sh or setup the WEB_USER manually as described here.

Customize T-Pot Honeypots and Services

In ~/tpotce/compose you will find everything you need to adjust the T-Pot Standard / Hive installation:

customizer.py
llm.yml
mac_win.yml
mini.yml
mobile.yml
sensor.yml
standard.yml
tarpit.yml
tpot_services.yml

The .yml files are docker compose files, each representing a different set of honeypots and tools with tpot_services.yml being a template for customizer.py to create a customized docker compose file.

To activate a compose file follow these steps:

1. Stop T-Pot with systemctl stop tpot.
2. Copy the docker compose file cp ~/tpotce/compose/<dockercompose.yml> ~/tpotce/docker-compose.yml.
3. Start T-Pot with systemctl start tpot.

To create your customized docker compose file:

1. Go to cd ~/tpotce/compose.
2. Run python3 customizer.py.
3. The script will guide you through the process of creating your own docker-compose.yml. As some honeypots and services occupy the same ports it will check if any port conflicts are present and notify regarding the conflicting services. You then can resolve them manually by adjusting docker-compose-custom.yml or re-run the script.
4. Stop T-Pot with systemctl stop tpot.
5. Copy the custom docker compose file: cp docker-compose-custom.yml ~/tpotce and cd ~/tpotce.
6. Check if everything works by running docker-compose -f docker-compose-custom.yml up. In case of errors follow the Docker Compose Specification for mitigation. Most likely it is just a port conflict you can adjust by editing the docker compose file.
7. If everything works just fine press CTRL-C to stop the containers and run docker-compose -f docker-compose-custom.yml down -v.
8. Replace docker compose file with the new and successfully tested customized docker compose file mv ~/tpotce/docker-compose-custom.yml ~/tpotce/docker-compose.yml.
9. Start T-Pot with systemctl start tpot.
   
   

Maintenance

T-Pot is designed to be low maintenance. Since almost everything is provided through docker images there is basically nothing you have to do but let it run. We will upgrade the docker images regularly to reduce the risks of compromise; however you should read this section closely.

Should an update fail, opening an issue or a discussion will help to improve things in the future, but the offered solution will always be to perform a fresh install as we simply cannot provide any support for lost data!

General Updates

T-Pot security depends on the updates provided for the supported Linux distro images. Make sure to review the OS documentation and ensure updates are installed regularly by the OS. By default (~/tpotce/.env) TPOT_PULL_POLICY=always will ensure that at every T-Pot start docker will check for new docker images and download them before creating the containers.

Update Script

T-Pot releases are offered through GitHub and can be pulled using ~/tpotce/update.sh.
If you made any relevant changes to the T-Pot config files make sure to create a backup first!
Updates may have unforeseen consequences. Create a backup of the machine or the files most valuable to your work!

The update script will ...

• mercilessly overwrite local changes to be in sync with the branch the installation follows, master by default
• write a backup to ~/tpot_backups/<date>_tpot_backup.tar before it touches anything
• update all files in ~/tpotce to be in sync with that branch
• restore the T-Pot configuration (~/tpotce/.env) from that backup and carry its image tag (TPOT_VERSION) forward to the one this release ships, so the new compose file does not ask for images of the old version. A tag you pinned yourself - dev, a branch name - is left alone.
• move TPOT_REPO from dtagdevsec to ghcr.io/telekom-security if it is still on that old default, which avoids the Docker Hub rate limits. A registry you set yourself is left alone.
• remove docker images of earlier versions, keeping the tag your .env now names
• detect the installed T-Pot edition (i.e. SENSOR, MINI, LLM, TARPIT, MOBILE) and restore it, using this release's ~/tpotce/compose/<edition>.yml so that new honeypots and changes of the release are included.
• keep your previous docker-compose.yml in the backup archive. If you made changes to it (i.e. removing the ewsposter section or a docker-compose.yml built with ~/tpotce/compose/customizer.py) you need to add them again - the run tells you how to compare the two.

The backup holds what git cannot bring back: ~/tpotce/.env, your docker-compose.yml, a patch of your changes to tracked files, your untracked files, the commit to roll back to, and the files under ~/tpotce/data that exist nowhere else - the installation uuid, the nginx certificate your sensors depend on, hive.crt, the ews configuration and the honeypot host keys. Everything else in ~/tpotce is tracked and comes back from git, and the honeypot data under ~/tpotce/data is never touched by an update. That keeps the archive at roughly a megabyte, which is why it is not compressed - on a Raspberry Pi compression would cost time for nothing. Add --full if you want ~/tpotce/data in there as well; be aware that on a busy hive this turns a megabyte into tens of gigabytes.

Your own Kibana objects and the ILM policy live in Elasticsearch rather than in a file, so they are exported into the same archive before T-Pot is stopped. You no longer need to export them by hand ahead of an update.

Backups rotate: the last ten regular and the last two --full archives are kept, counted separately, and the newest is never removed. Before writing, the script checks that the archive still leaves 10% of the partition free - ~/tpot_backups usually sits on the same filesystem as your honeypot data. If that does not work out it drops the oldest archives and degrades --full to a regular backup; if even that does not fit it stops before touching anything, leaving T-Pot up and running rather than filling the disk.

Updating From an Older Release

When update.sh finds a newer version of itself it pulls, restarts, and the new script finishes the job. Scripts older than this release do not hand anything over when they restart, so the new script starts from a checkout that has already been reset - your .env and your edition are gone by then, and it will happily restore the upstream defaults instead. Fetch the current update.sh first and run it with -b master, then the backup is taken before anything is reset and everything survives.

cd ~/tpotce
curl -fsSL -o update.sh https://raw.githubusercontent.com/telekom-security/tpotce/master/update.sh
chmod +x update.sh
./update.sh -y -b master

-b master is what makes this work, and switching the branch by hand beforehand is not an alternative: .env is tracked, so git refuses to leave a branch while your configuration differs from it. The script does the switch itself, after the backup has been written, and puts your configuration back afterwards. It is also what keeps the update.sh you just fetched in place - that file is tracked as well, so resetting the checkout discards it, and only a switch to master brings the very same file back.

Without -b master the run stops after restoring your configuration and says so. It has to: your checkout would still be on the older release, and finishing there would pull that release's images and remove the ones your installation is running on.

This is only needed once, coming from a release that predates this behaviour. Afterwards a plain ./update.sh -y carries everything across on its own.

To update from a different branch or fork, i.e. to test changes before they are merged, see Testing a Branch.

Restore Script

~/tpotce/restore.sh puts a backup back.

restore.sh -l                     # list the backups and what they hold
restore.sh                        # restore from the newest one, asking per group
restore.sh -f <archive> -y        # restore everything from this archive, no questions

Without -y every group is offered separately, so you can bring back just the configuration without touching anything else. The groups are the rollback of the git checkout, your changes to tracked files, the configuration, your untracked files, the files under data/, and the Kibana objects with the ILM policy.

T-Pot is stopped for the file part and started again for the Kibana import, because that one needs a running instance. The files under data/ are restored with the owner and mode from the archive (tpot:tpot, uid/gid 2000) - without those the containers will not start.

If you would rather do it by hand, the archive is a plain tar: tar tvf <archive> lists it, MANIFEST says which edition and commit it came from, and rollback.txt holds the commit to go back to with cd ~/tpotce && git reset --hard $(cat rollback.txt).

Daily Reboot

By default T-Pot will add a daily reboot including some cleaning up. You can adjust this line with sudo crontab -e

#Ansible: T-Pot Daily Reboot
42 2 * * * bash -c 'systemctl stop tpot.service && docker container prune -f; docker image prune -f; docker volume prune -f; /usr/sbin/shutdown -r +1 "T-Pot Daily Reboot"'

Known Issues

The following issues are known, simply follow the described steps to solve them.

Docker Images Fail to Download

Some time ago Docker introduced download rate limits. If you are frequently downloading Docker images via a single or shared IP, the IP address might have exhausted the Docker download rate limit. Login to your Docker account to extend the rate limit.

sudo su -
docker login

T-Pot Networking Fails

T-Pot is designed to only run on machines with a single NIC. T-Pot will try to grab the interface with the default route, however it is not guaranteed that this will always succeed. At best use T-Pot on machines with only a single NIC.

Update Script Loops

The update.sh shipped with 24.04.0 decides whether to restart itself by comparing its own file against origin/master. That comparison only ever clears on master: on any other branch, and on a detached HEAD after a git checkout <tag>, its update.sh differs from the one on master no matter how often it pulls, so it keeps restarting itself and writes a backup on every pass. Current versions restart on a checksum of their own file instead, stop on a detached HEAD before anything is touched, and never restart into an older script.

Interrupt the loop with CTRL-C. Every pass resets the checkout before it restarts, so your .env is back at the branch default by now, and the pass that still had your configuration is the first one. Recover it before doing anything else:

ls -ltr ~/*_tpot_backup.tgz
tar xOf ~/<the oldest archive of this run>_tpot_backup.tgz .env > ~/tpotce/.env
grep -E "^(WEB_USER|TPOT_TYPE)=" ~/tpotce/.env

Those archive names carry the time down to the minute only, so a loop that stayed within one minute wrote every pass to the same file and the last one won - if WEB_USER comes back empty, the login has to be created again with ~/tpotce/genuser.sh. Then update with the current script, which stops rather than loops:

curl -fsSL -o update.sh https://raw.githubusercontent.com/telekom-security/tpotce/master/update.sh
chmod +x update.sh
./update.sh -y -b master

Start T-Pot

The T-Pot service automatically starts and stops on each reboot (which occurs once on a daily basis as setup in sudo crontab -l during installation).
If you want to manually start the T-Pot service you can do so via systemctl start tpot and observe via dpsw the startup of the containers.

Stop T-Pot

The T-Pot service automatically starts and stops on each reboot (which occurs once on a daily basis as setup in sudo crontab -l during installation).
If you want to manually stop the T-Pot service you can do so via systemctl stop tpot and observe via dpsw the shutdown of the containers.

T-Pot Data Folder

All persistent log files from the honeypots, tools and T-Pot related services are stored in ~/tpotce/data. This includes collected artifacts which are not transmitted to the Elastic Stack.

Log Persistence

All log data is stored in the T-Pot Data Folder and will be persisted for the number of cycles set for TPOT_PERSISTENCE_CYCLES=<1-999> in the T-Pot configuration file ~/tpotce/.env. It defaults to 30.
Elasticsearch indices are handled by the tpot Index Lifecycle Policy which can be adjusted directly in Kibana (make sure to "Include managed system policies").

By default the tpot Index Lifecycle Policy keeps the indices for 30 days. This offers a good balance between storage and speed. However you may adjust the policy to your needs.

Factory Reset

All log data stored in the T-Pot Data Folder (except for Elasticsearch indices, of course) can be erased by running clean.sh. Sometimes things might break beyond repair and it has never been easier to reset a T-Pot to factory defaults (make sure to enter cd ~/tpotce).

1. Stop T-Pot using systemctl stop tpot.
2. Move / Backup the ~/tpotce/data folder to a safe place (this is optional, just in case).
3. Delete the ~/tpotce/data folder using sudo rm -rf ~/tpotce/data.
4. Reset T-Pot to the last fetched commit:

cd ~/tpotce/
git reset --hard

5. Now you can run ~/tpotce/install.sh.
   
   

Show Containers and Images

You can show all T-Pot relevant containers by running dps or dpsw [interval]. The interval (s) will re-run dps periodically. Use dim to show locally available Docker images including the CREATED column.

Blackhole

Blackhole will run T-Pot in kind of a stealth mode manner without permanent visits of publicly known scanners and thus reducing the possibility of being exposed. While this is of course always a cat and mouse game, the blackhole feature null routes all requests from known mass scanners while still catching the events through Suricata.
The feature is activated by setting TPOT_BLACKHOLE=ENABLED in ~/tpotce/.env, then run systemctl stop tpot and systemctl start tpot or sudo reboot.
Enabling this feature will drastically reduce attackers visibility and consequently result in less activity. However as already mentioned it is neither a guarantee for being completely stealth nor will it prevent fingerprinting of some honeypot services.

Add Users to Nginx (T-Pot WebUI)

Nginx (T-Pot WebUI) allows you to add as many <WEB_USER> accounts as you want (according to the User Types).
To add a new user run ~/tpotce/genuser.sh.
To remove users open ~/tpotce/.env, locate WEB_USER and remove the corresponding base64 string (to decode: echo <base64_string> | base64 -d, or open CyberChef and load "From Base64" recipe).
For the changes to take effect you need to restart T-Pot using systemctl stop tpot and systemctl start tpot or sudo reboot.

Import and Export Kibana Objects

Some T-Pot updates will require you to update the Kibana objects. Either to support new honeypots or to improve existing dashboards or visualizations. Make sure to export first so you do not loose any of your adjustments.

Export

1. Go to Kibana
2. Click on "Stack Management"
3. Click on "Saved Objects"
4. Click on "Export <no.> objects"
5. Click on "Export all" This will export a NDJSON file with all your objects. Always run a full export to make sure all references are included.

Import

1. Download the NDJSON file and unzip it.
2. Go to Kibana
3. Click on "Stack Management"
4. Click on "Saved Objects"
5. Click on "Import" and leave the defaults (check for existing objects and automatically overwrite conflicts) if you did not make personal changes to the Kibana objects.
6. Browse for NDJSON file When asked: "If any of the objects already exist, do you want to automatically overwrite them?" you answer with "Yes, overwrite all".
   
   

Troubleshooting

Generally T-Pot is offered as is without any commitment regarding support. Issues and discussions can be opened, but be prepared to include basic necessary info, so the community is able to help.

Logs

• Check if your containers are running correctly: dps
• Check locally available Docker images and their age: dim
• Check if your system resources are not exhausted: htop, docker stats
• Check if there is a port conflict:

systemctl stop tpot
grc netstat -tulpen
mi ~/tpotce/docker-compose.yml
docker-compose -f ~/tpotce/docker-compose.yml up
CTRL+C
docker-compose -f ~/tpotce/docker-compose.yml down -v

• Check individual container logs: docker logs -f <container_name>
• Check tpotinit log: cat ~/tpotce/data/tpotinit.log
  
  

RAM and Storage

The Elastic Stack is hungry for RAM, specifically logstash and elasticsearch. If the Elastic Stack is unavailable, does not receive any logs or simply keeps crashing it is most likely a RAM or storage issue.
While T-Pot keeps trying to restart the services / containers run docker logs -f <container_name> (either logstash or elasticsearch) and check if there are any warnings or failures involving RAM.

Storage failures can be identified easier via htop.

Contact

T-Pot is provided as is open source without any commitment regarding support (see the disclaimer).

If you are a security researcher and want to responsibly report an issue please get in touch with our CERT.

Issues

Please report issues (errors) on our GitHub Issues, but troubleshoot first. Issues not providing information to address the error will be closed or converted into discussions.

Use the search function first, it is possible a similar issue has been addressed or discussed already, with the solution just a search away.

Discussions

General questions, ideas, show & tell, etc. can be addressed on our GitHub Discussions.

Use the search function, it is possible a similar discussion has been opened already, with an answer just a search away.

Licenses

The software that T-Pot is built on uses the following licenses.
GPLv2: conpot, galah, dionaea, honeytrap, suricata
GPLv3: adbhoney, elasticpot, ewsposter, log4pot, fatt, heralding, ipphoney, miniprint, redishoneypot, rdphoneypot, sentrypeer, snare, tanner
Apache 2 License: cyberchef, dicompot, elasticsearch, go-pot, h0neytr4p, logstash, kibana, docker
MIT license: autoheal, beelzebub, ciscoasa, ddospot, elasticvue, glutton, hellpot, honeyaml, maltrail
Unlicense: endlessh
Other: citrixhoneypot, cowrie, mailoney, Elastic License, Wordpot
AGPL-3.0: honeypots
Public Domain (CC): Harvard Dataverse

Credits

Without open source and the development community we are proud to be a part of, T-Pot would not have been possible! Our thanks are extended but not limited to the following people and organizations:

The developers and development communities of

• adbhoney, beelzebub, ciscoasa, citrixhoneypot, conpot, cowrie, ddospot, dicompot, dionaea, docker, elasticpot, elasticsearch, elasticvue, endlessh, ewsposter, fatt, galah, glutton, go-pot, h0neytr4p, hellpot, heralding, honeyaml, honeypots, honeytrap, ipphoney, kibana, logstash, log4pot, mailoney, maltrail, medpot, miniprint, p0f, redishoneypot, rdphoneypot, sentrypeer, spiderfoot, snare, tanner, suricata, wordpot
  
  

The following companies and organizations

• docker, elastic.io, honeynet project
  
  

And of course YOU for joining the community!

Testimonials

One of the greatest feedback we have gotten so far is by one of the Conpot developers:
"[...] I highly recommend T-Pot which is ... it's not exactly a swiss army knife .. it's more like a swiss army soldier, equipped with a swiss army knife. Inside a tank. A swiss tank. [...]"

And from @robcowart (creator of ElastiFlow):
"#TPot is one of the most well put together turnkey honeypot solutions. It is a must-have for anyone wanting to analyze and understand the behavior of malicious actors and the threat they pose to your organization."

Thank you 💖