Home » Posts tagged 'stingar'

Tag Archives: stingar

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!

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!

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



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:

Scripted deploy using CHN server
Deploying Cowrie

We hope today is a good day for you to try out CHN, and give us feedback!

— Jesse



A Quick Adventure in AWS

The Friday before Labor Day, I went through the exercise of setting up a new CHN instance; the server on a local VCL-like Ubunutu 18 image, and cowrie and dionaea honeypots in each of three EC2 regions (Sydney, Singapore, Sao Paulo), and one cowrie honeypot in the same VCL IP space, for a total of 7 honeypots. All told, this took about 45 minutes (no automation on the EC2 setup, just creating a t2.nano image with minimal specs). Most of this time was spent fumbling through EC2 setup and setting up some simple bash scripts to copy/paste for the host setup. Actual time spent setting up each honeypot was probably closer to 2 minutes (mostly time spent pulling images over the network).

The following Tuesday I pulled some stats to get a sense of what those honeypots saw over the holiday weekend.

$ curl -s “http://${CHN_SERVER}/api/intel_feed/?api_key=${API_KEY}&hours_ago=96&limit=10000” |jq ‘.meta’
“size”: 3070,
“query”: “intel_feed”,
“options”: {
“limit”: “10000”,
“hours_ago”: “96”

This command is hitting the CHN server API endpoint to get a list of all honeypot hits for the last 96 hours. That’s not a bad haul of malicious IP’s of 96 hours. But how applicable is that data to OUR network?

First I examined incoming flow records, and found that we had inbound connections from 1055 of the original CHN IP’s in that time frame, or put another way, of all the IP’s we collected in that 96 hour period, we found that 34% of them visited our network in that same time frame. Next I compared the CHN IP’s against our threat intelligence sources for that same time period (so any locally generated threat intel from honeypots, network flow detections, host log reports, etc.) and found that in the same time frame our existing mechanisms detected 340 of these IP addresses (11% over all CHN IP’s, 32% of the locally active CHN IP’s).

In other words, our internal honeypots, threat intelligence feeds, and all other detection methods identified only 32% of the attacking IP addresses identified with honeypots distributed across multiple networks. I think this speaks powerfully to the case for operating and sharing honeypot data across numerous networks.

I’d also like to point out that our process for honeypot builds is now much easier (and more reliable). Our documentation now defaults to using images, built by us, hosted on Docker Hub, which eliminates many of the issues we saw in building the images locally. Building locally gives you a lot of flexibility to integrate into your central management as you wish, but using pre-built images GREATLY speeds spin-up time.

If you’ve been putting off trying out CHN, please set aside a couple hours on your calendar to try it out. If you ARE using the system today, it would be great if you could share your stories with us.

— Jesse

Join private STINGAR mailing list

Interested parties are encouraged to interact with the team via the project Github pages or in the Gitter IM community, which gives us a public space for quick questions.

Academic institutions can email Alex Merck at team-stingar@duke.edu to be added to the private STINGAR mailing list and Slack workspace.

Please include information about your organization’s interest in the STINGAR project in your request.