Setting Up A DShield Honeypot In AWS

12 min readJan 21, 2023

Back in July of 2022, I had the opportunity to attend SANS SEC504 in D.C. Each day after class was over, SANS typically offered a few evening talks covering a wide variety of topics. I sat in on one that was focused on how to get into security research. This is an area of great interest to me and I was curious to see how I could get started doing some security research without an advanced degree or years of experience in the field. The speaker was from the SANS Internet Storm Center, and one of the ways of getting into security researched he mentioned was setting up a honeypot, particularly one offered by ISC called DShield. I had been wanting to set up a honeypot for a while and was looking into setting up an instance of the T-Pot honeypot. However, it seemed a bit complicated to start off with right off the bat, and so not wanting to bite off more than I could chew, I decided to give DShield a look.

What is DShield?

DShield is a type of low interaction honeypot created to collect data and send it back to ISC. A low interaction honeypot is a type of honeypot that, much as the name implies, does not provide the attacker a lot of opportunity to interact with the service or application being simulated. They are easier to set up and maintain than a high interaction honeypot. Since they are comparatively simpler, low interaction honeypots will not fool sophisticated attackers like the dynamic environment of a high interaction honeypot would. However, because high interaction honeypots attract a more skilled class of attacker, properly securing them is very important. Taking all of these factors into account, a low interaction honeypot is the better choice for getting started with honeypots and security research in general. DShield collects information from three different sources:

SSH and Telnet usernames and passwords via Cowrie.
An HTTP honeypot collecting full HTTP requests.
Firewall logs collected from the honeypot.

All of this information is sent back to ISC for the owner of the honeypot to view, and it is also combined with data collected from DShield sensors installed all over the world. This achieves a sort of crowdsourcing affect for gathering data about the latest attacker trends.

Most of the installation instructions I could find for DShield sensors were for installing them on a Raspberry Pi. However, since I did not have one and it is possible to install them on an AWS free tier instance, I decided to go that route instead. The reason for writing this post is that I found there to be a lack of clear instructions for installing DShield on an EC2, and the official instructions that do exist are a bit vague and out of date. This caused it to take quite some time for me to get the sensor full functional.

Resources

Before I begin detailing the installation process, I wanted to mention the resources I used throughout my experience:

Pre-Installation

The first thing you will need is an AWS free tier account. This will provide access to, among other things, 750 hours of compute time for a t2.micro instance and 30 GBs of Elastic Block Storage.

I am not going to go into much detail about setting up the AWS account, as there are plenty of other resources online that will describe that much better than I can. However, there are a few points I want to mention in the interest of security. After all, we are setting up an intentionally vulnerable system and exposing it to the open internet:

Once the AWS account is created, you will be the root user of the account. Be sure to enable MFA for this user.
Next, it would be wise to create another, lesser privileged user that will be used to actually set up the DShield sensor and carry out other tasks that do not require the permissions of the root user. This can be done by creating a new User Group in IAM (I called mine “Administrators”) and assigning it the “Billing” and “AdministratorAccess” permissions policies. These policies might be a bit over permissive in the grand scheme of things, but I am somewhat new to IAM and not completely familiar with all of the permissions polices. After that, we can create another user (I called mine “admin”) and assign it to the previously created IAM Group. Once again, be sure to enable MFA for the user.
It would be a good idea go into Billing Preferences (found in the Accounts page under Preferences) and turn on “Receive Free Tier Usage Alerts”. That way, you know if you’re incurring charges if you exceed the limitations of AWS free tier. You can also set up a Budget under Cost Management to alert you when costs exceed a budgeted amount. Keeping an eye on cost and usage is particularly important for us due to the potential for our honeypot to become compromised and used for malicious purposes such as cryptomining.

Finally, you will need to make a DShield account in order to get an API key for the sensor, and to view its SSH, web, and firewall logs.

Creating The EC2

The steps for creating the EC2 are going to be pretty much the same as the official steps laid out in the AWS Installation Guide for Dshield which I have linked above.

Select the region to create the EC2 that DShield will be installed on:

2. Go to the EC2 page and select “Launch instance”:

3. Give the server a name and select Ubuntu Server 20.04 LTS. Note: The official documentation says to select 18.04, this is out of date and will cause installation issue further down the line.

4. Select t2.micro as the instance type:

5. Select a key pair, or create a new pair if you do not already have one. Make sure to save the private key in a secure location.

6. Set up the initial security group. AWS will take care of most of the networking set up for you. It will also create the security group. Make sure to only allow SSH traffic from your IP. We will replace this with a more open security group once we get the sensor fully up and running.

7. Allocate storage for the instance. For mine, I used 25 GBs of the 30 GBs that come with free tier:

8. Review your settings and hit Launch Instance:

After a few minutes, your instance should finish setting up and you can SSH in using the public IPv4 DNS name as the user “ubuntu”.

Preparing The EC2

I want to mention a few other basic things to do to add a bit more security once you are able to SSH into the EC2:

You will be logged in as the default user “ubuntu”. It would be a good idea to set up a password for this user. This can be accomplished by running the following command:
$ sudo passwd ubuntuYou will be prompted to enter a new password for “ubuntu”. Make sure you save the password in a safe spot.
You might have noticed already that you can run any command as root via sudo without being asked for a password. While convenient, this is not ideal in the case that the honeypot becomes compromised. We can change this by editing the /etc/sudoers.d/90-cloud-init-users file using visudo. Become the root user and change to the directory of the file:
$ sudo su - $ cd /etc/sudoers.d
If you cat out the file, you will see the rule for the user “ubuntu”:
ubuntu ALL=(ALL) NOPASSWD:ALLAll we have to do is remove “NOPASSWD:”. Run this command to open the file for editing:
$ visudo 90-cloud-init-users
Move down to the rule for the “ubuntu” user and change it to:
ubuntu ALL=(ALL) ALLThen save and exit. Switch back to “ubuntu” by entering exit and you’ll find that any attempt to use sudo requires a password.

First thing is first, update the OS:
$ sudo apt update && sudo apt full-upgrade -y
Then reboot the system:
$ sudo reboot
Next we have to a few extra things. This is what gave me the most trouble as I was working through the installation process. Here is what the documentation says:
“You will have to install Python2, Python-pip, git [may be installed by default] manually. You may refer: https://linuxize.com/post/how-to-install-pip-on-ubuntu-20.04/ or use the following commands:
It is advisable to be in the home directory when carrying out the following commands. (cd ~)
$ cd ~ && sudo apt update && sudo apt full-upgrade -y && sudo apt install python-pip -y && sudo apt install python3-pip -y && sudo apt update && sudo apt install python2.7 -y && sudo apt install git -y && curl https://bootstrap.pypa.io/get-pip.py — output get-pip.py && sudo python2 get-pip.py && sudo python3 get-pip.py"
I did not like installing everything all in one shot, as if one thing fails, the whole command does. Therefore, I broke it up into individual commands to make it easier to catch/troubleshoot any errors:
$ cd ~ $ sudo apt install python3-pip -y $ sudo apt install python2.7 -y $ sudo apt install git -y $ curl https://bootstrap.pypa.io/pip/2.7/get-pip.py --output get-pip.py $ sudo python2.7 get-pip.pyHere we are changing to our home directory and then installing pip for Python3. I removed all of the update and upgrade commands as they are not necessary since we just upgraded the system. I also removed the command to install python-pip because it will not work since the package is not available for this version of Ubuntu. Next, we install Python2.7 and git, although git should already be installed. Finally, to install pip2, we must grab a script from pypa.io and execute it.

Give the system another reboot for good measure, and we should be ready to install the DShield sensor.

Installing the DShield Sensor

From here, the installation is relatively straightforward. I will be following the installation instructions and using screenshots from the DShield Installation PDF Guide with a few caveats.

Run the following commands from your home directory:
mkdir install cd install git clone https://github.com/DShield-ISC/dshield.git cd dshield/bin sudo ./install.shA GUI installer will walk us through the remainder of the process.
You will be prompted with a message warning about the risks of creating a honeypot and a privacy notice. Select “Yes” for both.
Next, you will be asked to choose between manual or automatic updates. I went with the recommended choice of automatic.
Enter the email you used to set up your DShield account and the API key which is available under the “My Account” page. Click “Verify”. If everything checks out, you should get a message saying it was successful.
Select the default interface, this will most likely be eth0.
After this, we will be asked to configure the “Local Network and Access”. These are the ports and IPs that will be able to have administrative access to the honeypot. The default admin port is 12222 which you can leave the same or change. For the “Local Network”, it should pre-fill the CIDR range of the local network that the EC2 resides in. This also does not need to change since there are no other hosts on the local network. Finally, there is the “Further IPs” section which turned out to be a bit tricky. Originally, I would just put my IP address. However, like most people I do not have a static IP address. So if it changed, I would have to go update it in the Security Group settings in AWS (more on that later). But, I still would not be able to SSH in on port 12222 because my new IP would be blocked by the configurations made during this step of the install. I would be essentially locked out since I could not get onto the server to change it (unless I somehow got my old IP address back). The solution is to trust any IP address: 0.0.0.0/0. While this may seem like a major security issue, we must remember that we already have a Security Group controlling access to the EC2. This essentially renders the “Further IPs” functionality redundant. With all this filled out, hit “Ok”.

An example of the installation GUI from the PDF guide

7. Another window will ask you to confirm the settings. Hit “Ok”.

8. We will then be asked if there are any IPs that the firewall should not log or redirect to honeypot ports. The CIDR range for the local network should used here. If we had a static IP address we were accessing the EC2 from, it would also be place in this list. Click “Ok” for this and the confirmation message afterwards.

9. Similarly, we will be asked for ports and IPs to disable the honeypot for. The description is a bit vague, but it seems to serve a similar purpose as the previous configuration: to prevent logging of legitimate access attempts. The IP we use to access the honeypot will be logged, but since we do not have a static IP to exclude, we do not have much choice other than to leave our IP out. The CIDR range for the local network should suffice. You should not have to change any of the honeypot ports. Click “Ok” for this and the confirmation message afterwards.

10. Almost done! Next we must make an SSL certificate. I just used the defaults it had an hit “Ok”.

It will then ask us if we want it to create a CA for us to sign the certificate. I choose “Yes”.

11. Finally, once the installation is complete, give the EC2 another reboot.

Post Installation

If you remember back earlier, our current Security Group is only allowing SSH traffic in on port 22 from our IP address. We need to expose the honeypot to the open internet and change how we are SSHing in.

I created another Security Group for these purposes, and gave it the following configuration before assigning it to the EC2:

This will allow any TCP, UDP, or ICMP traffic using IPv4 or IPv6 from any IP address to hit any port on the server, with one small exception. We only allow traffic to port 12222 from our home IP address. If that IP address changes for any reason, it must be updated here in order to access the server. Also, I believe the “Custom TCP” type can be changed to “SSH” without issue. Now we can SSH in on port 12222.

Once you verify you can access the honeypot on the new port, I recommend going into /home/ubuntu/install/dshield/bin (or wherever you installed DShield) and run status.sh. The output should tell you if everything is working properly. Here is what you should see:

With that, there is not much more to do besides sitting back and letting DShield do its work.

It would be wise to login once a month and run $ sudo apt update && sudo apt full-upgrade -y and give the system a reboot. It also would not be a bad idea to run the update.sh script as well on a monthly basis to make sure the honeypot remains up to date.

After you’ve give DShield some time to send in its first reports, you can login to your account and check out the logs.

Firewall: