We’re very excited to announce the release of version 1.7 of CommunityHoneyNetwork! In addition to the usual bug fixes (updating dependencies, etc.), there are some great new features available in 1.7, such as:

• Honeypot tagging: Add a tag to your honeypot configuration that will show up in all logs. This allows some flexibility to add metadata about the collecting sensor directly in the log data.
• Custom ACME server support with Certbot: If you use a certificate provisioning service other than LetsEncrypt that supports the ACME protocol, you can have CHN-Server talk directly to it!
• Cowrie “Personalities”: Alter the SSH version, filesystem layout, output from commands, etc. using “personalities”. These are folders with bundles of cowrie configs that can be referenced in the sysconfig file to change the “look” of your cowrie honeypot, making it more difficult to identify.
• Dionaea bistreams log rotation: Given the proliferation of WannaCry on the open internet, we found that rotating the Dionaea bistreams logs to be critical in preventing near-daily filling up of disk space.

For an administrative perspective, we added features to delete events from the database when a sensor is deleted, removed a number of unsupported dependencies, and added lots of documentation on topics such as integrating honeypot services with systemd, and using the CIF client to pull feeds of data.

We’re also making a major change in the way we reference images in the docker-compose.yml and deployment scripts: rather than referencing ‘latest’, we’re specifying a specific version that matches with the server version. So for instance, with CHN-Server version 1.7, the deployment scripts will reference version 1.7 tagged images directly. This will allow for a number of useful things from our side, and ensure that users don’t inadvertently find themselves with mis-matched server and honeypot versions, or upgrading accidentally.

As with all upgrades in this project, we highly recommend that you take a fresh look at the documentation. As new features are added, there are often new options for sysconfig files that can impact the way your CHN instance functions. Once you’re comfortable with the changes, things should be as easy as a “docker pull” and “docker-compose down && docker-compose up -d” away! For the more risk-adverse/VM-rich, given the ease of deployment you can always spin up a new instance, fresh, and simply migrate old sensors to the new server via deployment scripts.

As always, feel free to reach out to us via the Github project (now with a Gitter IM room)!

Cheers,

Jesse