The Friday before Labor Day, I went through the exercise of setting up a new CHN instance; the server on a local VCL-like Ubunutu 18 image, and cowrie and dionaea honeypots in each of three EC2 regions (Sydney, Singapore, Sao Paulo), and one cowrie honeypot in the same VCL IP space, for a total of 7 honeypots. All told, this took about 45 minutes (no automation on the EC2 setup, just creating a t2.nano image with minimal specs). Most of this time was spent fumbling through EC2 setup and setting up some simple bash scripts to copy/paste for the host setup. Actual time spent setting up each honeypot was probably closer to 2 minutes (mostly time spent pulling images over the network).

The following Tuesday I pulled some stats to get a sense of what those honeypots saw over the holiday weekend.

$ curl -s “http://${CHN_SERVER}/api/intel_feed/?api_key=${API_KEY}&hours_ago=96&limit=10000” |jq ‘.meta’
{
“size”: 3070,
“query”: “intel_feed”,
“options”: {
“limit”: “10000”,
“hours_ago”: “96”
}
}

This command is hitting the CHN server API endpoint to get a list of all honeypot hits for the last 96 hours. That’s not a bad haul of malicious IP’s of 96 hours. But how applicable is that data to OUR network?

First I examined incoming flow records, and found that we had inbound connections from 1055 of the original CHN IP’s in that time frame, or put another way, of all the IP’s we collected in that 96 hour period, we found that 34% of them visited our network in that same time frame. Next I compared the CHN IP’s against our threat intelligence sources for that same time period (so any locally generated threat intel from honeypots, network flow detections, host log reports, etc.) and found that in the same time frame our existing mechanisms detected 340 of these IP addresses (11% over all CHN IP’s, 32% of the locally active CHN IP’s).

In other words, our internal honeypots, threat intelligence feeds, and all other detection methods identified only 32% of the attacking IP addresses identified with honeypots distributed across multiple networks. I think this speaks powerfully to the case for operating and sharing honeypot data across numerous networks.

I’d also like to point out that our process for honeypot builds is now much easier (and more reliable). Our documentation now defaults to using images, built by us, hosted on Docker Hub, which eliminates many of the issues we saw in building the images locally. Building locally gives you a lot of flexibility to integrate into your central management as you wish, but using pre-built images GREATLY speeds spin-up time.

If you’ve been putting off trying out CHN, please set aside a couple hours on your calendar to try it out. If you ARE using the system today, it would be great if you could share your stories with us.

— Jesse