Using honeypots to gather information and analyse the state of security on the Internet.
we have all probably heard of the internet referred to as the new wild wild west, and you always read about new attacks, and bigger and bigger DDoS attacks flooding our internet and breaking our webb-services. But how big of an issue is this actually to your typical user?
I thought it would be interesting to see what kind of attacks traffic is flooding our internet, primarily based on geographic location, so I set up a few honeypots in different data centers through Amazon Web Services. They are currently running and collecting data, and Hopefully I'll publish some interesting analysis based on this in the coming days. First of though, I want to present T-Pot: The all in one honeypot!
Introduction to Honeypots & T-Pot
For those who might not know, a Honeypot is a system built to "detect, deflect, or, in some manner, counteract attempts at unauthorised use of information systems". Most typically the honeypot would look like an actual system to an attacker. An organisation might install a honeypot to trick attackers to focus on the honeypot instead of actual systems in production.
Honeypots are also used in research to gather information about motives, tactics and attack types of individuals and organisations targeting networks and systems on the internet. According to Wikipedia, "Research honeypots are complex to deploy and maintain [...]", but this is no longer the case with T-pot.
T-Pot is a collection of different honeypots put together by T-Mobile. It comes with a great implementation of ELK stack to visualize all events captured by the different honeypots and some other sweet tools.
All honeypots in T-Pot is running dockerized using Docker which makes the whole setup quite a lot easier to manage.
The different kinds of honeypots used in T-Pot include:
A low interaction honeypot designed to emulate industrial control systems (ICS/SCADA).
A Medium interaction honeypot designed to log brute force attacks and shell interactions via TELNET/SSH.
- A low interaction honeypot designed to emulate vulnerable systems running protocols such as SMB, HTTP, FTP, TFTP, MSSQL, MySQL, SIP.
Designed to capture attacks on Elasticsearch.
High interaction honeypot designed to simulate a transport infrastructure environment with charging points and a central web interface.
A low interaction honeypot designed to simulate a large amount of different web vulnerabilities, such as RFI, LFI and different kinds of injections.
A low interaction honeypot designed to observe attacks against TCP or UDP services.
A low interaction honeypot designed to emulate SMTP-services and collects information on attacks against the mail-server.
Designed to emulate RDP protocol.
Low interaction honeypot which listens to RDP-requests and logs responses.
As you can see, the majority of the included honeypots are so called low interaction honeypots. This means that they only emulate the desired service and doesn't actually run the full service. This also means that an attacker would be able to detect that it isn't a real system, but since most attacks against systems on the internet today are automatic, we still get a lot of attacks and login attempts against our honeypots.
Setting up T-pot
I used a guide written by Steve Gathof to set up my honeypots in AWS: https://medium.com/@sudojune/deploying-a-honeypot-on-aws-5bb414753f32
This guide was perfect for quickly and easily setting up T-Pot in AWS. Unfortunately I Wasn't able to install T-Pot in a T2.Micro instance (I'm guessing because of the low RAM amount), so I had to use a T2.Medium instance which costs about $0.0416 per Hour.
When I'd set up my first instance and installed T-Pot, i created a new AMI image which I could copy to other regions, instead of going through the whole installation process manually each time i wanted an instance in another region, and with AWS CLI, this became even easier:
aws ec2 copy-image --source-image-id <AMI-ID> --source-region <Source Region> --region <Dest. Region>--name "name of the new ami"
This command copies the AMI from the requested region to a new region, includes the key-pairs and renames the image. Now all you have to do is launch a new ec2 instance using the newly copied AMI and you've got a new t-Pot running in your requested region!
This was just a short introduction of honeypots and T-pot. I hope to write more about it and other interesting topics in the future!
I have written a few articles regarding what kind of data I was able to see from T-pot here:
Cyberattack patterns based on geographical locations - Oregon
Cyberattack patterns based on geographical locations - London
Cyberattack patterns based on geographical locations - Seoul