I’ve written several times about honeypots in the past. Those who have read my previous blog posts will recall that I typically run both a Dionaea multi-purpose honeypot and a Cowrie SSH honeypot. These both collect a lot of useful data which can be visualized with a variety of tools. As an aside, I’ve gone back to using DionaeaFR as a front-end for my Dionaea data and Kippo-Graph as the visualization solution for my Cowrie honeypot. Both Visualization front-ends are running on a separate local machine in my lab. I periodically download the data from the Digital Ocean droplet on which I’m running my honeypots and view the results locally in my lab.
Dionaea and Cowrie are nice for a number of reasons but one primary reason is that they both emulate the specific services that they are pretending to provide. This is nice because it really encourages further interaction on the part of attackers who think that they’ve actually connected to a vulnerable computer.
But what if you really don’t need that degree of interaction? What if you just want a really quick and dirty way to answer all requests made to an internet-facing computer and perform some logging of the interactions? This is where minimalist honeypots can be used.
I’ll use an analogy to contrast the two types of honeypots. Consider an example where you live in a house with a handful of people. Now let’s say that a stranger comes knocking at the door. One of the people living in the house answers. The stranger asks for someone who lives in the house by name. The person answering the door goes and gets that individual and the two parties interact. That’s representative of the first type of honeypot – Dionaea or Cowrie.
Now imagine the same house. This time when the stranger knocks, the door just opens and the stranger walks into the house. He can look around and try to interact with whomever he finds inside. I suppose that we could extend our analogy to say that the people in the house don’t fluently speak the same language as the visitor and in a short time the stranger will either leave in frustration or someone in the house will show him out. This is similar to the second type of honeypot.
Minimalist Honeypots
I’ve experimented with two types of minimalist honeypots. The first one was mentioned by Internet Storm Center Incident Handler Xavier Mertens in a blog post that can be found here:
He aptly named this honeypot TinyPot. Here, I’ll summarize his blog post and give some detail on setting up this honeypot:
The conditions that he set out for his minimalist honeypot were as follows:
** Run on any Linux distribution
** Accept connections on ANY port
** Collect basic protocol details
** Log everything (of course!)
He does this in 3 simple steps.
1. Capture traffic on all ports. To do this, he uses iptables to redirect all incoming connections to a single port (10000 in this case):
# iptables -t nat -A PREROUTING -p tcp –dport 1:65534 -j REDIRECT –to-ports 10000
He limited the upper range to port 65534 because he used port 65535 to bind his SSH daemon in order to access the honeypot remotely.
2. Accept and establish a connection on any port (at least the TCP handshake). He uses netcat to do this. This is great because, like iptables in the first step, it’s installed by default with many Linux distributions. So, basically, he sets up netcat to listen on the collection port that we specified in the first step (port 10000). We’ll log all the traffic we receive to a file called netcat.log.
# netcat -l -k -p 10000 | tee -a /tmp/netcat.log
3. We meet the final condition by using tcpdump to collect all the traffic hitting the honeypot (with the exception of the SSH management port (port 65535).
# tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65535
Xavier put all of these commands into a single script called tinypot.sh for ease of use. He also used the “screen” command (also available in most distributions) to detach the tools from the console and to allow you to go back in later and keep an eye on what’s being captured.
Here’s his script:
#!/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 65535
echo TinyPot running, use “screen -r [netcat|tcpdump] to access tools”
I ran into a few problems using this script “out-of-the-box”. I didn’t spend a lot of time trying to troubleshoot his script. Here’s what I did to get this to work:
I created two script files:
tinypot.sh
———-
#!/bin/bash
iptables -t nat -A PREROUTING -p tcp –dport 1:65534 -j REDIRECT –to-ports 10000
tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65535
echo TinyPot running…
ncpot.sh
——–
#!/bin/bash
while [ 1 ]; do echo “Started”; /bin/nc -l -p 10000 >> /tmp/netcat.log; done
I started tinypot.sh first with the following command:
./tinypot &
You can either hit Enter or use CTRL-C to get back to a command prompt and then I started ncpot.sh using:
nohup ./ncpot.sh &
Again, hit Enter or CTRL-C to get to the command prompt.
From there I could monitor the growth of the log files with:
ls -lt /tmp
And I could get a sneak peek into their contents using:
tail -n 300 /tmp/netcat.log
or
tail -n 300 /tmp/tcpdump.pcap0
One thing I noticed about the logging is that both log files seem to be deleted as soon as the listeners are stopped. I’m not sure why yet. That said, you can transfer the log files to another computer for analysis while the listeners are running. Of course, to really get a good overview of the traffic to your honeypot, one should load the captured pcap file into Wireshark or a similar program.
I also encountered the second minimalist honeypot in an ISC handler blog. This one was by Guy Bruneau and it can be found here:
https://isc.sans.edu/forums/diary/INetSim+as+a+Basic+Honeypot/21055/
If you’re not familiar with it, InetSim is a software package that will simulate some of the most common internet services in a lab environment. I’ve always used it “from the inside out”. In other words, to provide fake services to computers in my lab that have been infected and want to reach out to another computer somewhere on the internet. InetSim will even let you fake downloading any file from any website. But, as a honeypot, we would be using it “from the outside in”, so to speak. We would be faking various services to computers that are hitting our honeypot from the outside world across the internet. InetSim will also provide logging.
So, while this honeypot is still lighter than Dionaea and Cowrie, it’s going to require just a bit more setup than our first lightweight honeypot. Here’s how I set it up:
1. First, edit the following file on your VPS:
nano /etc/apt/sources.list.d/sources.list
and add the following line:
deb http://www.inetsim.org/debian/ binary/
Save and exit.
2. Add the signature key by:
wget -O – http://www.inetsim.org/inetsim-archive-signing-key.asc | apt-key add –
Next run: apt-get update
3. Now you should be ready to install using:
apt-get install inetsim
This should install InetSim and its perl dependencies.
At this point, you should be done with the installation.
4. Now a few configuration tweaks. First, we need to tell InetSim where to listen for connections:
nano /etc/inetsim/inetsim.conf
By default InetSim binds to the loopback address. Look for the service_bind_address and change it to the IP address of your VPS:
service_bind_address 10.10.10.1 (or whatever the external IP address of your honeypot is)
Save and exit.
Incidentally, this is also the file where you enable and disable services. If there’s a service that you don’t want enabled, just comment it out with a #.
5. Set up persistence. We want iNetSim to to start as soon as the VPS boots up (in other words to survive a reboot). To do this we need to edit the init.d file:
nano /etc/default/inetsim
Change ENABLED from 0 to 1
Save and exit.
If you reboot your VPS, INetSim will start when the server comes back up.
You can look through the data files folder (see below) to modify some of the files that are served up to visitors. You can also run the following to see what traffic has been logged:
cat /var/log/inetsim/service.log
Here are the locations of a few key InetSim files.
init.d config file – /etc/default/inetsim
Main Config – /etc/inetsim/inetsim.conf
Data Files – /var/lib/inetsim/
Main Log – /var/log/inetsim/
Reports – /var/log/inetsim/reports
While these minimalist honeypots don’t have all of the bells and whistles as their bigger cousins, they also have their place. They’re very fast and easy to set up, they take very little resources and they allow a quick insight into the malicious traffic hitting your VPS.
Article Link: http://executemalware.com/?p=448