How to Deploy & Monitor Honeypots on GCP with Kibana [Tutorial]

One of my favourite areas of cybersecurity is SIEM (Security Incident Event Management). In 2017 I wrote a post on how I got a role in cyber security, one of my recommendations was using the Elastic Stack as a SIEM as a start-off point for those looking to understand log analysis and how to investigate incidents. But one of the main gripes people had was, where can they get data to work on in their home environments. This post will focus on setting up a honeypot that already utilises the ELK Stack…

What is a honeypot?

Honeypot is a system, whose sole purpose is to attract potential intruders and record their activity, to further analyse and investigate security breaches. In practice, a lot of devices can be classified as honeypots. By being enticing (i.e open ssh ports, unsecured S3 buckets etc), it is possible to generate logs from this into a SIEM platform like Graylog or Elastic and perform some threat intel. More often, honeypots 🤝 bot networks.

Why even have a honeypot?

For companies, having a honeypot can be a useful data resource and also an excellent threat hunting exercise to understand the threat landscape and which IPs to block on their internal networks based on honeypot activities. It is also possible to build personalised honeypots mimicking a companies environment to further entice attackers by hosting a fake active directory for example. Understanding who wants to attack you, will also help you prepare your defences.

Which honeypots can I use?

For this post, we will be focusing on T-Pot, a honeypot system consisting of many other honeypots put together by T-Mobile (yes, the mobile carrier). It comes arm in arm with the ELK Stack utilising Kibana for visualisation and all the honeypots are dockerized using Docker making the setup far easier to manage than running them individually.

However, it’s worth noting that the honeypots used by T-Pot only emulate services meaning a real attacker could potentially be able to detect it’s not a real system, but automated bots and scripts would still try, and it’s worth identifying what bot networks are out there right?

What’s included?

<iframe class="airtable-embed" src="https://airtable.com/embed/shr8iwURPGxrthCkJ?backgroundColor=gray" frameborder="0" onmousewheel="" width="100%" height="533" style="background: transparent; border: 1px solid #ccc;"></iframe>

Okay how do I install it?

Requirements:

• Debian 9.7 or newer— For this I utilised the standard Debian 10(Stretch) build available in GCP (Google Cloud Platform).
• 4 GB RAM — I opted for 7.5GB
• 32 GB of free storage — I opted for 40 GB
• A working internet connection
• A Google Cloud account (with credits)

For this build, I will be utilising Google Clouds compute engine to deploy a Debian VM. If you are looking to deploy this on AWS, please check out this post by Steve Gathof on Deploying a Honeypot on AWS. More information on the different ways of installing (ISO, VM, Ansible etc) is available here.

As T-Pot comes with a Universal Installer, this will upgrade the system to Debian (Sid) and also install the required dependencies.

git clone https://github.com/dtag-dev-sec/tpotce
cd tpotce/iso/installer/
./install.sh --type=user

There’s different variations of T-Pot depending on what you’re looking for. Based on the server I have provisioned, I’ll be selecting the standard build which includes all the honeypots and access to the ELK dashboard.

The installer will also then ask you for a username and password, this will be used to access Kibana and view the honeypot data. After all the dependencies are installed, the server will reboot.

House Keeping

After the reboot, as port 22 (ssh),port 80 (http) and port 443 (https) are now being utilised by the honeypot, you will find you won’t be able to access the honeypot anymore. But all we need to do is amend the firewall rules in GCP.

From the main console page on GCP compute engine page, click on the VM instance you wish to manage and click on view network details.

Click on firewall rules and you will find the SSH is still set to 80 and so will the https port. You can delete or amend the rules and add the following:

SSH: Port 64295

HTTPS: 64297

These will be the ports used to connect to the honeypot. As I don’t see myself needing to SSH regularly to the honeypot, I have disabled the rule for SSH. You are also welcome to amend the firewall rules so that only your IP address will be accepted into the honeypot via SSH or https. You will now be able to connect to Kibana using:

https://your.ip.address:64297

Using the credentials you created during setup, you will now be able to log into Kibana and view the data coming in from your honeypot. It took 16 minutes before I had my first attack. On Kibana, the team at T-Pot have developed dashboards already which you can use based on the honeypot data you wish to view. You will also have access to the following tools with your deployment:

CyberChef — A web app for encryption, encoding, compression and data analysis.

ES Head — A web front end to maintain your elasticsearch cluster.

Spiderfoot — A reconnaissance tool that automatically queries over 100 public data sources (OSINT) to gather intelligence

By Stephen Chapendama