TinyPot, My Small Honeypot

Published: 2017-07-27
Last Updated: 2017-07-27 13:02:38 UTC
by Xavier Mertens (Version: 1)
7 comment(s)

Running honeypots is always interesting to get an overview of what’s happening on the Internet in terms of scanners or new threats. Honeypots are useful not only in the Wild but also on your internal networks. There are plenty of solutions to deploy honeypots with more or less nice features (depending on the chosen solution). They are plenty of honeypots[1] which can simulate specific services or even mimic a complete file system, computer or specific hardware.

That’s cool but often such honeypots require a lot of dependencies (Python/Perl modules) or must be compiled. Sometimes, you just need to collect basic data to understand who’s knocking on your door. I was looking for a quick & dirty solution that does not require the installation of many packages or extra-tools. What are my basic requirements:

  • Run on any Linux distribution
  • Accept connections on ANY port
  • Collect basic protocol details
  • Log everything (of course!)

The first step is to capture the traffic on any TCP ports. To achieve this, we can use iptables to redirect any incoming connection to a specific port:

# iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 10000

Note: I limited the range to port 65534 to allow binding my SSH daemon to port 65535 (if you need to access the honeypot remotely).

The next step is to accept and establish a connection on any port (at least the TCP handshake). netcat[2] is the perfect tool for this and is usually installed by default with many Linux distribution. Let’s bind it to our collection port 10000 (see above) and log all the junk received:

# netcat -l -k -p 10000 | tee -a /tmp/netcat.log

Finally, a full packet capture is always nice to have, let’s collect all the traffic hitting our honeypot except the SSH management port:

# tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65534

Finally, we can put all the commands in a single script tinypot.sh. I'm using the "screen" command (also available in most distributions) to detach the tools from the console and to keep an eye on them later.

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 10000
/usr/bin/screen -S netcat -d -m /bin/netcat -l -k -p 10000 | tee -a /tmp/netcat.log
/usr/bin/screen -S tcpdump -d -m /sbin/tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65534
echo TinyPot running, use "screen -r [netcat|tcpdump] to access tools"

Here is an example of data dumped by netcat:

We can see classic stuff like bots scanning for open proxies, SMB shares or searching for admin interfaces. What's next? Wireshark can be used to export statistics (menu "Statistics -> Conversations"). The generated CVS file once indexed in Splunk gives us the classic top-20:

Nothing fancy here and  I'm sure that it can be improved but TinyPot just does the work!

[1] https://github.com/paralax/awesome-honeypots
[2] https://nmap.org/ncat/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

Keywords: honeypot
7 comment(s)


Nice guide! I was able to successfully set up this simple TinyPot.

Couple of things I noticed in your script - the first command includes "screen -S test -d -m su - username..." which I don't think is supposed to be there, and the last command contains port 655534 instead of 65534.
Good catch, thank you! (bad copy/paste).
I fixed it.
I'm using Ubuntu and netcat with the -k switch is not very stable and closes the netcat session.

I used ncat for stability and it works well:

/usr/bin/screen -S netcat -d -m /usr/bin/ncat -l -k -p 10000 -C -o /tmp/netcat.log
It did not happen on my side.
Good to know, thank you for sharing! They are so many versions of the "netcat" tool...
One more thing - you should be excluding 65535 not 65534 from tcpdump if your SSH listener is running on 65535.
Why be unimaginative for your SSH connection? After you have monitored the attacker profiles on your machine you should be able to notice some modest address ranges that have very few connection attempts. I did that here moving to [mumble mumble] about 3 years ago. That SSH port has not faced attack yet, which is mildly disappointing as I'd like to see how the other levels of defense are working such as the --recent option trickery. I had to simulate my own attack.

Nice honeypot setup, lightweight and perfect for testing and demonstration.

I went with CentOS 7 Minimal install.
- Had to "yum install nmap-ncat screen tcpdump".
- The netcat command is /bin/nc
- Cent OS wants to use firewall-cmd instead of (on top of?) iptables.
- I could not get netcat to tee off, so I used -o.
- Find your firewall zone and interface with "firewall-cmd --get-active-zones"
(public ens33 for me)

The following seems to work for me:


/usr/bin/firewall-cmd --zone=public --add-port=1-65534/tcp
/usr/bin/firewall-cmd --zone=public --add-masquerade
/usr/bin/firewall-cmd --zone=public --add-forward-port=port=1-65534:proto=tcp:toport=10000

#add timestamp and start netcat with logging
date > /tmp/netcat.log
/usr/bin/screen -S netcat -d -m /bin/nc -l -k -o /tmp/netcat.log --append-output -p 10000

/usr/bin/screen -S tcpdump -d -m /sbin/tcpdump -i ens33 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65535

echo Tinypot running, use "screen -r {netcat|tcpdump] to access tools"

Thanks for sharing!

Edit: Typo tap=>tcp

Diary Archives