Using a Raspberry Pi honeypot to contribute data to DShield/ISC

Published: 2017-08-03
Last Updated: 2017-08-03 14:06:22 UTC
by Johannes Ullrich (Version: 1)
16 comment(s)

We have been working for a while now on a honeypot based on a Raspberry Pi. Thanks to our volunteers, we now have a version of the honeypot that provides us not just with the firewall data that we usually collect, but also with data about telnet/ssh and web attacks. Traditionally, we have focused on firewall logs, and we will, of course, continue to collect them. But it has become more difficult to collect logs from many consumer level firewalls. The Raspberry Pi based system will allow us to maintain one code base that will make it easier to collect rich logs beyond firewall logs.

To participate, you will need a Raspberry Pi that is exposed to internet traffic. You can do so by either connecting it directly to your cable/DSL modem or by exposing it to Internet traffic via your firewall. But it is important that the device will receive more or less unfiltered traffic (it is ok if a couple of ports are blocked or used by other services). The Raspberry Pi should be dedicated to the task as a honeypot.

We have tested the system with a Raspberry 2 and 3. It works best if you use the wired network interface, but a WiFi connection should work as well.

To install the honeypot, it is best to follow the instructions in our GitHub repository for the project: .

The short version of the instructions:

  1. Setup an account here to submit your reports
  2. Install the base Raspian OS (the Lite version will do)
  3. Install "git" (sudo apt install git)
  4. clone the repository (git clone
  5. run the install script.

But please see the full instructions for additional details.

What do you get out of it?

First of all, you are contributing to an awesome project that measures the internet's "background radiation" for about 16 years now. Our data is regularly used by researchers to improve defensive recommendations and to validate and observe trends in attack patterns. All of our data is made available for free under a creative commons license.

Secondly, you will be able to review summaries of your data via this site. Your data will be linked to IP address reports and summaries of data submitted by others.

In talking to people interested in submitting in the past, I often hear the following arguments against it, which I call my "top myths not to submit data":

  • My data isn't all that interesting
    Absolutely right. Your data, by itself, isn't all that interesting. But it becomes interesting once we can correlate it with data from other users. What we are looking for is "average home users," small businesses and just about anybody connected to the internet. We are not trying to find the next APT. Instead, we are looking for the next worm or bot scanning the internet for a new vulnerability, which may not even be a zero day.
  • My employer will not allow me to submit data
    No need to submit data from work. Your home connection will work just fine (see above)
  • It is hard to submit data
    I hope we make this easier using this Raspberry Pi honeypot. It shouldn't take much "care and feeding." Maybe an update once a month with new software.

We try our best to make this honeypot secure. We do use software like Cowrie and some additional python scripts to emulate services. We rather allow the honeypot to be fingerprinted as a honeypot then having it exploited.

If you do however find any bugs (security or functional), then please submit a report via GitHub ( ).

We are in the process of making the same code work in an Ubuntu virtual machine. For some that already have a local virtual machine setup, this may be an easier method to deploy these honeypots.

Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute

16 comment(s)


Why is IPv6 disabled? Is there no value on it?
We had issues with the external IP discovery. If we enable IPv6, then we only got the external IPv6 address, and not the external IPv4 address, which caused problems as it looks like IPv4 packets hit that IPv6 address. Once we got this sorted out, IPv6 will be enabled again.

So more a stupid issue with the logging script that needs to be fixed at some point.
I'd be delighted to deploy a turnkey ISC.SANS.EDU device (akin to a style network appliance where SANS manages it remotely to ensure it was up-to-date (firmware/software wise) so that it has a direct WAN side connection with a dynamic routable IPv4 from my business ISP -- so long as you did not chew up more than 10Mbps / 2 Mbps up/down. And I'd suggest that any turnkey SANS device has the remote ability to change WAN MAC address from time to time so as to force the ISP to assign a new dynamic routable IPv4 from my ISP and hence, appear as a new honeypot.
Basic hygiene questions:

- What to do when it becomes infected?
- Do I get notified if it becomes infected?
- What period of time to wipe and reload to mitigate the risk of infection?
The honeypot should not require significant bandwidth. I will have to measure how much mine sends (should be easy to see in my netflow logs). I will see if we can randomize the MAC address.

The Hygiene questions:
The honeypot should not get infected. This is not a full interaction honeypot. Instead, we picked low/medium interaction honeypot software that simulate vulnerable systems, but are not actually vulnerable.

If it ever becomes infected (for example due to a bug in out software), then just wipe it and reinstall from scratch.
Since the Pi is flash memory based with a SD card, having a spare SD card ready to go is always a good idea :)

If you get infected, simply power down the Pi, remove old SD card, put in new SD card, and power-up again...Much easier to abuse a 35 dollar piece of h/w rather than a full blown computer/server or frankenputer
How important is it that effectively all ports are routed to the Raspberry Pi honeypot?

I would like to find a way to have my firewall forward all ports that are not associated with an SPI established connection. (Save for a few ports like SSH.)

This would mean that the vast majority of traffic would be routed to the honeypot, but that it could miss some traffic that might otherwise go to it.
It might be a good idea to set up an organized web forum/blog for this initiative, if one doesn't exist already.
Someplace where people who will engage in this program can ask questions and share notes.

I know that the bug reporting is in github, but should that be used for other Q&A and collaboration activity as well?

BTW - I think this initiative is an exceptional idea. A non-government owned "collective sensor" for internet activity monitoring totally trips my trigger. Looking forward to joining that kind of a collective whole heartedly.
I just started using a Raspberry Pi 1 Model B as a DShield honeypot - it seems to work like a charm.
Let's see how it performs over time.

Just in case of infection or SD drive failure, I created an image of the configured SD card using a diskimager. That way I just write the image to a replacement SD and pop it in the Raspberry and boot and go.

Diary Archives