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