As a company, we are pretty huge fans of Open Source software. We use FLOSS extensively in our production stack and we make sure to give back where we can. One of the ways we do this, is by making our Canarytokens & OpenCanary projects open source and free to download.
People needing Canarytokens can use the free hosted instance we run at Canarytokens.org, or they are free to download the docker images to run on their own networks. Literally hundreds of thousands of tokens have been generated online and the docker images have been pretty widely deployed too.
Our paid Canary customers get their own hosted tokens server, the ability to trivially customize it, as well as some tokens that have not been ported over to the free-server yet.
The relationship between OpenCanary(left) and Canary(right) is less clear.
Marco and I recently spoke at LinuxConfZa where we discussed this. In the buildup to the talk, we added some new features to OpenCanary (mostly by backporting features from our paid Canary service) which we’d like to show you below:
What’s new
Portscans
We have added to the capability of OpenCanary’s portscan module. We now have detection for specific nmap portscans: nmap FIN, NULL, XMAS and OS scans. This means that OpenCanary has multiple event types for a portscan which would indicate which type of scan has been targeted at your OpenCanary sensor.
We make this happen in the background by adding some iptables rules. These new rules match specific packets based on what we can expect from different nmap scans. This then creates specific logs with chosen prefixes giving us a number of new, defined logtypes.
Using our usual portscan mechanism of monitoring this log file, we can start to alert based on the log’s prefix. If the log’s prefix is `nmapNull`, we know that the log was generated by iptables’ match rule associated with nmap’s NULL scan. And this process is repeated for all newly supported portscan dectections. Below is an example of an FIN scan by nmap,
Followed by what we would expect to see being logged by our OpenCanary.
As you can see, logtype 5005 which we already saw is tied to a nmap FIN scan event.
New Services
We have also added three new services that your OpenCanary can now emulate.
The first service is Redis. Redis “is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker”. Our Redis service fakes a full fledged Redis server – alerting on connect and on any subsequent commands sent to your OpenCanary.
The above image shows that the Redis service mimics the behaviour closely by returning errors for Redis commands that have not been given the correct number of arguments or our Redis server will return an authentication required error for correctly crafted Redis commands.
And here we can see the logs generated by our previous Redis-related indiscretions: the command we tried along with their additional arguments.
The second service is Git. Git is a version-control system used (mainly) for code repositories. Hence you can run a Git server that would allow for collaboration across organisations. Our Git service fakes a Git server – alerting on `clone` git commands which means someone is trying to get that repository of code.
Here we have tried to clone a repository by attempting to connect to the git service being run by OpenCanary. The interaction mimics that of the actual Git service and errors out in an expected way.
And in our OpenCanary logs, we will get the repository name that the attacker was looking for. This is helpful in understanding where your leak may be.
The last new service is actually a potential factory of hundreds of TCP services. It’s a service to build generic TCP banners. This allows you to create a TCP listener on an arbitrary port. You can select a banner to greet your client on connect, and can control subsequent responses sent to the client. This allows you to quickly model plaintext protocols.
In this example, we have set up our TCP banner service to mimic an SMTP server. We connect to the service and receive the first banner. When the client sends through more data to interrogate the service, she receives our data received banner.
We then alert and log on the full interaction creating a great audit trail for investigation.
General Cleanup
We have also heard the cries (we are sorry!) and have touched up some configuration documentation on opencanary.org along with our brand new OpenCanary logo.
Setting up an OpenCanary instance should be as simple as following the instructions over here.
Upgrading is dead simple too. Simply run `pip install opencanary –upgrade`. It will upgrade the version of your OpenCanary, but keep your old config. You can check out the new config file options over here.
Take it for a spin, you won’t be disappointed.
(We love Pull Requests and have been rumoured to respond with 0day Canary swag).
Ps. If you want honeypots that deploy in minutes, with 0 admin overhead, you really should check out our Thinkst Canary. It’s one of the most loved devices in infosec, and you will see why..