SANS ISC: Using a Raspberry Pi honeypot to contribute data to DShield/ISC - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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: https://github.com/DShield-ISC/dshield .

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 https://github.com/DShield-ISC/dshield.git)
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 ( https://github.com/DShield-ISC/dshield/issues ).

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
STI|Twitter|

I will be teaching next: Defending Web Applications Security Essentials - SANS Munich March 2019

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 atlas.ripe.net 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.

Suggestion:
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.

Hi,
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.

Regards
Thomas

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.

They just updated the website to download Raspbian Stretch. For those who don't know, you can browse to the folder of the download site to retrieve previous versions. http://downloads.raspberrypi.org/raspbian/images/

I'm a Linux noob, can someone recommend an article on how to tee the logs to a local syslog server, say syslog-ng on a raspberry pi, for local analysis? Failing that would SANS consider adding a method to let me download 48 hours worth of data from "my reports"?

Hello...

I'm an average Joe-home-user.

My pi is a version 2, running Raspbian Lite. I had absolutely no issues with the DShield installer, went smooth.

I have my ISP's modem (which has a sub-standard firewall, wireless, and whatnot) running in bridge mode (so it won't dbl NAT) going to my pfSense (community edition) box. I get one IP with a /31 mask from my ISP, so I can't take the DMZ port I set up and do a 1:1 NAT from a truly public-routable IP because there are none available. I did (what I thought would be) the next best thing and made a span port with the WAN interface to this DMZ port. It's getting hammered with public nonsense which is good I guess...

I still had to take the DMZ and give it a private IP that will port-address-translate to get out to the internet which is good so I can update it, install software, etc. I'm not seeing any data in DShield though. How can I troubleshoot why DShield isn't getting anything reporting in from my DShield R-Pi?

I'm hoping I can get this operating and feeding into the system. I'll make a post/write-up on what to do for people like me who don't get more than 1 IP available to them. Thanks, sorry for the long-winded post.

There's a slack group now, active at
(For dshield in general, but including this) https://join.slack.com/t/dshieldusers/shared_invite/enQtMjg0OTE2MjAyMDA1LTFlN2VmNzRhNzlhODBiYzc5YzVhYTQ4NDE5YmZkNzNiMmVhMzQxOGMwY2I1ZTU4Mjk2MzBjNjQwMThlZjBiY2U

"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." ...


--

I've tested it now as well with the original Raspberry pi (model 1+ "B" from 2014); works great, up and running!

Quoting Fu Manchu:Hello...

... I can't take the DMZ port I set up and do a 1:1 NAT from a truly public-routable IP because there are none available....

I still had to take the DMZ and give it a private IP

It will work if you just route the DMZ, port-forwarding, or "exposed host" directly to, and only to the honey pot's private IP address. It's not necessary to use 1:1 NAT, just let the router do that to protect the rest of your network with the firewall. There are steps in the install script if you need to allow other hosts or posts to use your public ip address for other services.