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:
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. #!/bin/bash /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:
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 Xavier Mertens (@xme) |
Xme 687 Posts ISC Handler Jul 27th 2017 |
Thread locked Subscribe |
Jul 27th 2017 4 years ago |
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. |
expertsnipo 4 Posts |
Quote |
Jul 27th 2017 4 years ago |
Good catch, thank you! (bad copy/paste).
I fixed it. |
Xme 687 Posts ISC Handler |
Quote |
Jul 27th 2017 4 years ago |
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 |
Anonymous |
Quote |
Jul 27th 2017 4 years ago |
It did not happen on my side.
Good to know, thank you for sharing! They are so many versions of the "netcat" tool... |
Xme 687 Posts ISC Handler |
Quote |
Jul 27th 2017 4 years ago |
One more thing - you should be excluding 65535 not 65534 from tcpdump if your SSH listener is running on 65535.
|
expertsnipo 4 Posts |
Quote |
Jul 27th 2017 4 years ago |
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.
{^_-} |
JD 13 Posts |
Quote |
Jul 28th 2017 4 years ago |
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: #!/bin/bash /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! dotBATman Edit: Typo tap=>tcp |
dotBATman 70 Posts |
Quote |
Jul 28th 2017 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!