We currently recommend a “side by side” or “replacement upgrade” for users moving from CHN 1.8 to 1.9, however we recognize that is not possible for every user of CHN. In this post, I’ll dive into the main steps that a user would need to take to upgrade from version 1.8 to 1.9.

I’ll presume that folks are using the chn-quickstart script to bootstrap their installs. For folks with custom path locations, etc., we’ll leave the translation to you. 🙂

Remove unsupported honeypots

Unfortunately, not all of the honeypots supported in 1.8 will work in 1.9, where we removed all Python 2 use. These include: amun, glastopf and wordpot. You can simply shut down those containers, or re-purpose those hosts later for supported honeypot types.

Upgrade the server

A note on those using systemd to manage their CHN-Server instance: you’ll need to swap in the appropriate systemctl commands instead of docker-compose up/down commands below. You should also update your systemd service definition files to look more like the current best practice. Specifically ensure that your docker-compose commands do not include the -v option, which removes named volumes. This is most important on honeypots, where registration data will be kept in named volumes, rather than volume mounts, going forward.

Run docker-compose down  in /opt/chnserver. If you’re already using chn-quickstart, you can git checkout v1.9 to get the latest release version of the script. Run the latest version of ./guided_docker_compose.py and answer the questions asked. You’ll note there is a NEW question section: “Do you wish to enable intelligence feeds from a remote CIF instance?”.

This new section will enable the creation of a chn-intel-feeds container, which previously required manually adjusting the docker-compose.yml file. This container is used both to pull feeds from the CIF repository and re-publish them in a friendly “one-observable-per-line” format, but also is the mechanism by which partners can upload their own safelist items. These safelist items will apply to ANY feeds pulled by the partner, regardless of whether those feeds are pulled via chn-intel-feeds, CIF client, or raw API.

Once all the questions have been answered, a new docker-compose.yml file has been created, as well as all the necessary env files. Note that we now use env files rather than sysconfig files. The primary difference (aside from name!) is how the files are loaded into the containers. The old sysconfig files were volume mapped into the containers, and read as a file; the new env files are loaded into the environmental variables of the container and read out of the running environment. We’ve found that this method is both more friendly for container orchestration environments and more reliable. Being read in via the docker-compose stanza env_file, these new env files do not require quotes around the variable values.

You can now explore the ./config/sysconfig directory and note any differences between the env and sysconfig configurations, adjusting your env files for any customizations needed (such as exporting hpfeeds-logs via syslog). If you’re submitting data to a CIF instance via hpfeeds-cif, you’ll want to adjust your IGNORE_CIDR to include appropriate entries in the hpfeeds-cif.env file. For those pulling feeds with chn-intel-feeds, verify the feed specifications in chn-intel-feeds.env meets your needs. And don’t forget about that new safelist functionality!