It’s been a long while since we released a new version; many of us were pulled in a different direction by March 2020. Rest assured that we have not been idle since the 1.8 release! We’re happy to announce version 1.9 of CommunityHoneyNetwork, which brings security updates as well as some new features for partners participating in the STINGAR community.

There was a lot of backend work which will be mostly transparent to the every day user, but was important for security and roadmap reasons:

• Removal of Python 2 code and dependencies and ansible build process (major re-factoring!)
• Removal of Amun, Wordpot, and Glastopf honeypots (due to lack of Python 3 support)
• Updated Cowrie, RDPhoney, UHP, Conpot, and Dionaea containers
• Improved logging (username/password logs from Dionaea, hpfeeds-logger support for syslog and file logging in single container, etc.)
• Per-partner safelisting uploads via chn-intel-feeds
• More k8s friendly honeypot containers (almost there!)

By far, the most work went into updating the CHN-Server and honeypot containers to ensure they’re using Python 3 (support for Python 2 ended in January). This also required us to update the backend data exchange code (hpfeeds -> hpfeeds3) and touch just about every part of the system. There are countless bug and performance fixes rolled into this release so hopefully the loss of the older honeypot types won’t be too painful.

We’re always interested in supporting the honeypot needs of the community, so if there’s a honeypot you’d like to see in the project, please file an issue on Github to let us know of your interest! Honeypots that support hpfeeds(3) or minimally have a plugin-based logging system are far easier to integrate, and of course we’re happy to take PR’s! 🙂

Users of the dionaea honeypot will see increased central logging due to some bug fixes and capture of logs with username and passwords. The hpfeeds-logger container now supports writing logs files and exporting via syslog in a single instance, reducing the need to run multiple containers.

We’ve deprecated our own Mongo and Redis containers in favor of upstream containers; we found that we currently have no need to customize these containers, so we’ re defaulting to upstream versions instead. Speaking of Redis, we’ve removed the need for Redis containers in CHN-Server (though users of hpfeeds-cif and hpfeeds-bhr will still need Redis for caching purposes). We’ve also removed Ansible as part of the container build process; we found that the ansible-based build process made our development processes very slow, and our experiences with the STINGAR customer base indicated that the ability to do local installs of honeypots/servers (v/s using container images) was never exercised.

More emphasis has been put on use of the chn-quickstart script for 1.9 deployments, and that repo is now using release tags. Please be sure to use a tagged release when starting up a new CHN instance to ensure you don’t catch us development and get unexpected results! 🙂

Unfortunately with all the major shifts in technology, the upgrade process from 1.8 to 1.9 will not be as simple as changing which tag your docker-compose.yml files are pointing to. We highly recommend spinning up a new server instance using the chn-quickstart script and re-deploying honeypots from the new console. For those wishing to retain log data, we’ve always recommended using the hpfeeds-logger container to write out files that are ingested elsewhere, so for most users throwing away the server instance and re-deploying the honeypots is a painless process. For those that choose to upgrade in place, we’ll write up a follow up blog post on the process, but expect you’ll be fiddling with a lot of formatting and docker-compose format changes, which will (in our tests) take much longer than spinning up a new instance in another location.

Participants in the STINGAR data sharing project will be pleased at the inclusion of a mechanism to include their own safelist entries in the chn-intel-feeds container, which will safelist any incoming data against their own private safelists. Since many partners also desired safelisting against the Umbrella Top 10K domains (resolved to IP’s), we’ve added a process to automatically ingest those IP addresses on a daily basis. Partners can request this safelist be added to their partner key by sending an email to team-stingar[at]duke.edu. This feature should help those partners who are working to automatically ingest STINGAR feeds into protection devices feel more comfortable with the process, without having to “re-invent the safelisting wheel” as it were.

Finally, if you’re a CHN user, but not a STINGAR partner, we’d love to hear from you! We’d like to know how the project is working for you, and what you’d like to see in the future.We’re at a crossroads where we’re looking seriously at where we should invest our energy: do you need more TIP-like functionality? More honeypots or honeypot customization? New features for integrating into your existing SOAR platform, or automation in general? File an issue on Github or send us an email at team-stingar[at]duke.edu.

Stay safe out there folks!