Home » Articles posted by Jesse Bowling
Author Archives: Jesse Bowling
CommunityHoneyNetwork version 1.9.1 released!
We’re happy to release a minor update to CHN, version 1.9.1. This version brings a couple small bug fixes (such as P2P hpfeeds3 sharing), and two new features:
- chn-intel-feeds now supports generating a feed from the API of a CHN-Server
- Two new honeypots: Big-HP and elasticpot
For those currently using chn-intel-feeds, please consult the documentation because without adding at least one new ENABLED configuration item, you won’t get any data! With this latest release of this container, you can now generate feeds from a CIF server, upload safelist items specifically for you to a CIF instance, or generate a feed by querying a local CHN-Server instance. This last option is a convenient way for those running CHN (but not connected to the STINGAR repository) to provide pre-formatted feeds to protection devices. For those already connected to the STINGAR repository, this option is not recommended as it won’t get you the data any faster.
This release includes Elasticpot, maintained by Vesselin Bontchev, and Big-HP, the first exemplar of a new web honeypot framework by Alexander Merck emulating F5 Networks BigIP management interface. These two honeypots provide two new web interface honeypots that should provide useful additional telemetry for users.
One change made to our deployment scripts in this version, and reflected in the documentation, is the removal of web ports from Dionaea configurations. We no longer recommend that these ports be exposed to the internet, as we’ve discovered a false positive condition with these ports for Dionaea. The documentation for P2P hpfeeds3 full data sharing has been updated to reflect the changes in 1.9 to command locations, etc.
Upgrading from 1.9 should be as simple as updating the tags in your docker-compose.yml, with the exception for users of chn-intel-feeds who should consult the documentation for the new chn-intel-feeds.env configuration option. For most users, simply adding a *-ENABLED (for CIF-FEED, CHN-FEED, or CIF-SAFELIST) should be enough to keep you instance running properly.
Hopefully everyone will upgrade to this latest version, and let us know via Github of any issues you encounter or features you’d like to see.
Stay safe out there!
Ad-hoc queries against STINGAR repository
We talk with participants in the STINGAR project a lot about using feeds in protection devices via the chn-intel-feeds container, but our partners don’t have to limit themselves to the time-limited feeds; ad-hoc queries are also supported both via the CLI cifsdk client, as well as via a Chrome browser plugin! In this post, I’ll walk through the simple process for setting up the Chrome plugin and configuring it to query the STINGAR CIFv3 backend.
You can install the Chrome plugin via the Chrome Store at this URL:
Once you’ve installed the plugin, you should have a new icon on your toolbar:
Click the plugin icon, then click the “hamburger” to expose the settings link.
Once you’re in the settings, fill out a name of your choice, and then fill in the information you were given when joining the STINGAR project:
API Location : Fill in your “Production CIF URL”
Token: Fill in your “Read Token”
Groups: Fill in “everybody” and your partner ID, comma separated. I.e.: “everybody,partner1”
Provider: Your partner ID (“partner1”, etc)
Ensure the “Default Server” option is selected, and uncheck the “Log Queries” option.
Click the “Save” button and you’re all set! Your read key cannot submit data to the server, nor do we encourage using your write key for submitting via the plugin.
From here you can search for observables and see quick results across all time for any reports in the STINGAR CIFv3 backend. This data can help confirm suspicious activity, or identify IP’s that could be excluded based on their presence on a safelist.
The plugin works great for quick searches while reviewing reports, surfing the web, reading Twitter, etc., however for use cases that involved hundreds of indicators (or more!) users should consider using the CIFsdk CLI interface. For users of the awesome TheHive and associated Cortex, you may find this repo useful, enabling STINGAR lookups as an analyzer.
Upgrading from CHN 1.8 to CHN 1.9
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!
CommunityHoneyNetwork version 1.9 released!
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!
How long should you block?
One question we get a lot is “how long should we block IP’s observed by STINGAR honeypots?”
Generally, we’ve explained that we block for seven days, a number we arrived at through the highly scientific process of “I dunno…seven days sounded good and we’ve never had reason to change it”. 🙂
While more research needs to be done in this space, we do have at least one partner that showed a marked increase in the number of connections blocked by extending their block list duration from the original 24 hours. The result is intuitively unsurprising, as we would expect that it would sometimes take more than 24 hours for scanners to get from one network to another, but it’s nice to see the data laid out in a graph.
You may remember an earlier version of this graph; this graph shows roughly a doubling of connections blocked starting in May 2019, when the block time was extended from 24 hours to four days. So perhaps the magic number is between 4-7 days (which would jibe with the anecdata I’ve collected over the years), or maybe it’s not. We see good results in this range and will be leveraging STINGAR and our own network flow and block data to try and (more scientifically) identify a reasonable block lifespan.
CommunityHoneyNetwork version 1.8 released!
Hi All,
We’re happy to announce the release of version 1.8 of CommunityHoneyNetwork. This release represents four months of feature development and bug fixes. A short list of things to look out for in this release include:
- ARM support for honeypots
- “Personality” support for Dionaea (and an upgrade to 0.8)
- Persistence of custom scripts via a volume mount
- CIDR exclusions for hpfeeds-cif (so you can exclude submitting your own IP addresses, etc.)
- A new container to feed a BHR instance directly from hpfeeds (which also includes CIDR exclusions)
- More flexible file rotation options for hpfeeds-logger (including specifying time unit, or “none” to allow for rotation outside the container)
- More robust tag support (and a suggested “key-value” format)
- Tons of small bug fixes, including removal of web interface items that aren’t in use
As always when upgrading, take a look at the documentation to ensure that there aren’t new variables that need to be added to your sysconfig files; those running hpfeeds-cif will want to check out the new IGNORE_CIDR variable, which replaces the previous “IGNORE_RFC1918” variable.
CommunityHoneyNetwork version 1.7 released!
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
Is Sharing Caring?
My three year old knows to say “sharing is caring” when his older brother is playing with a toy he wants. Sometimes it works, often it doesn’t; thankfully, sharing threat intelligence data works differently. Once the mechanism for sharing is established, it’s essentially free to share, and no one has to give up their “toy”. But do we want to “play” with other people’s “toys” when it comes to threat intelligence? </tortured_analogy> 🙂
One of the big questions people have for me on threat intelligence sharing is whether it provides value. Our own experiences here at Duke say that it does, and the limited cases where we’ve found other higher education institutions sharing their own data, we’ve found the data to be highly applicable to our own networks, with the caveats that the data is shared as close to real-time as possible, and protections are applied in an automated fashion. The key to getting value from many sources of threat intelligence data is the velocity of the data from source into protection devices.
A primary hypothesis for the STINGAR project is that if higher education networks collect information about attacks against their networks using honeypots, share that data as quickly as possible with other higher education participants, and automatically block on this data, attacks will be less effective overall. We recently received data from one of our partners which seems to back our hypothesis.
This partner has been running CHN in their environment for several months now, and decided in early December to start putting their own data into their border firewall for automatic blocking. Recently, they also decided to incorporate the data available via the shared CIF repository into their blocking rule.
Please note: The “Count” is connections blocked per day.
So after averaging 4.1 millions connections per day blocked, inclusion of the STINGAR data pushed this average up to 11.7 million connections per day blocked, a near three-fold increase. I’m personally very excited to see this data. While we cannot know the intent of those connections, we do know that there haven’t been any reported false positives to the partner based on the blocking they’ve done. I think this is another data point (outside our own experiences) that points to high-speed sharing of data with automated blocking as a valuable tool in the network defense toolbox.
Looking for IP’s that get detected by more than one institution is another way to start to measure applicability of the data between institutions. While the number of institutions actively sharing data is still on the lower end of the scale we eventually anticipate, we’re starting to see a decent amount of IP overlap between institutional sensors.
I’d love to hear your thoughts on the matter! If you’re a higher education institution you’re welcome to join our mailing list stingar@duke.edu to share your thoughts in a closed forum, or otherwise feel free to join us at Github (file an issue, or join us on Gitter).
Cheers,
Jesse
Happy New Year and a new release!
Hi all,
We hope you’ve enjoyed the holidays and are energized for a new year of security! We’re happy to announce a new version, 1.6, which has been tagged as latest. Those of you pulling images from DockerHub can enjoy the latest release by updating your server and honeypots with:
docker-compose stop && docker-compose pull && docker compose up -d
We’ve had this one running in our production environment for several weeks at this point, and briefly considered a Christmas week release, but decided it would be more of a gift to wait until after the holidays from an operational perspective. 🙂
This release includes some nice new features including:
- Tagging of honeypot type when submitting to CIF
- Initial (alpha) UHP support
- Automatic TLS certificate provisioning on CHN-Server via LetsEncrypt
- More logging format options with hpfeeds-logger (json!)
There’s also numerous bug fixes, including one for those upgrading from older versions that haven’t seen the pre-provisioned Deploy scripts show up yet. This fix ensures that those scripts are always populated when updating versions.
As always, please give these new versions a run in your environment and let us know how they perform. Visit our Github site to file issues or ask questions…
Happy hunting!
Jesse
CHN v1.5 released
We’re pleased to announce the release of version 1.5 of CHN. This new version includes a number of bugfixes, new features, and a new home for documentation.
In order to support versioned documentation, we’ve moved all our documentation to https://communityhoneynetwork.readthedocs.io/. This enables us to build documentation for future releases as we go, and you to get a sneak peek at future features!
The major new feature is the inclusion of deployment scripts for honeypots in the CHN interface. Take a look at the instructions here to see how easy this has become! As a teaser, here’s a screenshot:
We hope today is a good day for you to try out CHN, and give us feedback!
— Jesse