Deploying & monitoring honeypots on GCP with Kibana

Stephen Chapendama
Oct 24, 2019 · 5 min read

One of my favourite areas of cybersecurity is SIEM (Security Incident Event Management). In 2017 I wrote a medium 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?

T-Pot

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?

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.

Deployment on GCP

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

You’ll have to install git: sudo apt-get install git

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.

Select the standard build.

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.

Click on view network details

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.

There’s 2 firewall changes configs to change

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.
  • SpiderfootA reconnaissance tool that automatically queries over 100 public data sources (OSINT) to gather intelligence
Did not expect to see Seychelles there as a top attacker

Stephen Chapendama

Written by

Cyber Security & Africa | Technology Consultant @ Foundervine.com & Cyber Security @ Fujitsu UK

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade