An interesting cyber security project I have researched is a honeypot. In simple terms, a honeypot is a computer that is deliberately left insecure and on an unprotected, segmented section of the network. The purpose of having a honeypot is to gain knowledge on attackers, such as the attacker’s origin, attack methods, and more. This strategy works because the attacker thinks he’s found an insecure machine, but in reality, he has just found our honeypot, which is what we want. We can now track his every attempt to crack our honeypot.
I decided a honeypot would be a great project for me to create. There are many different types of honeypots used for collecting stats on different things. I am going to be creating an SSH honeypot, used to log SSH connection attempts on my machine. Before I got started I had to decide where I wanted to host my honeypot. One option was a segmented section of my network that is in between my internal network firewall and my ISP firewall, known commonly as a DMZ. This would work, but I decided that the cloud would be an even better option for this. A cloud instance is great because I can have my honeypot exposed directly to the internet on a network that has no connection to my own. I configured and created an Ubuntu VM on AWS. Once launched, I used SSH and my encryption key to connect to my server.
Before I installed my honeypot, I wanted to change my servers SSH port from port 22 to some random port. The reason I am doing this is because I want my honeypot to run on port 22, so it looks like a real SSH server. Moving my SSH port to something random will also increase its security as attacker are less likely to find it on a different port. Not fully secure, but rather security through obscurity. To edit my servers SSH port I changed the port configuration by using nano on the sshd_config file.
Now that my SSH port has been changed, it’s time to configure some new firewall rules. For the first rule I edited the SSH rule to allow traffic to the port I specified for SSH. This is the real SSH connection I will be using to connect the honeypot. Next, I added a rule to allow all inbound traffic to port 22, where my honeypot will be set up. This will give attackers full access to the honeypot.
Finally, I was ready to install the honeypot. I used a honeypot called cowrie that is installed using Docker. I ran the Docker command docker run -p 22:2222 cowrie/cowrie:latest and I was all set up. I tested it out by connecting to it myself and it worked perfectly. Now it was time to wait for the real attacks to flood in.
The first two connections to my honeypot were very quick only lasting a few seconds. While evaluating the connections I found that both IP addresses were from the US and both requests were SSH scans. The program they were using was called ZGrab SSH Survey, which is a network scanner used for conducting large internet wide surveys. This confirms that this was a random attack and not targeted towards me. On my cloud machine, there is no reason an attacker would specifically target me, but in an enterprise environment, this information could be very useful.
It was at this point I decided to leave the honeypot up for 24 hours and I would check the logs when that time was up.
When I came back after 24 hours I had some new captures. There were a few more SSH surveys, but also some connections that lasted longer. One connection was an SSH connection from the UK lasting 120 seconds. Another SSH connection from the Eastern US lasted 15 seconds.
I am going to continue to run my honeypot for a few more days and go back to analyze the logs. For now though this has been a useful project, strengthening my log analysis, AWS, and security monitoring skills.