Posts Tagged ‘security’

Kumina sponsoring CloudABI: practical sandboxing for UNIX

Friday, October 14th, 2016

Ed Schouten: “Almost exactly two years ago I started working on a project called CloudABI. In a nutshell, CloudABI is a UNIX-like programming environment for Linux and the BSDs that allows you to easily design sandboxed applications. It accomplishes this by making strong use of capability-based security, inspired by the University of Cambridge’s Capsicum. Compared to traditional UNIX applications, CloudABI applications are better resistent against security vulnerabilities, easier to test and easier to maintain. CloudABI is available as Open Source Software, free of charge. Feel free to watch my talk at 32C3 if you’re interested in all of the nitty-gritty details.

Some time ago I decided to visit the folks at Kumina, as I used to work there until early 2012. That’s why you’ll see my name next to some of the older posts on this blog. During my visit, Tim made me an offer I simply couldn’t refuse: a job at Kumina that allows me to spend a significant amount of time every week to continue the development of CloudABI. As you can see, I’ve accepted the offer. As of last month, I’m a member of the team once again!

What brings me joy is that this step makes the development of CloudABI sustainable. Over the last couple of weeks I’ve already managed to implement at least one large new feature: support for 32-bit hardware architectures. The CloudABI Development Blog now has an article describing the work that was needed to realise this.

At Kumina my job consists of a mixture between systems administration and software development. There are various pieces of software that we’re developing in-house. One of my tasks is to release some of these as Open Source Software, so stay tuned for my next posts!”

Buckler: Authentication and authorization for Kibana, for free!

Thursday, September 29th, 2016


At Kumina, we make heavy use of the ELK stack: Elasticsearch, Logstash and Kibana. All of our servers have their logs collected by Logstash and stored in Elasticsearch, so we can easily access them through Kibana. As of recently we started providing direct access to our Kibana instance to our customers, so that they can perform analysis on the data themselves. This brings us to an interesting problem: Elasticsearch – and in effect Kibana – does not implement any authentication and authorization mechanisms. This means that by default customers would be able to view each other’s data.

Support for access controls is instead offered by a commercial product by Elastic, called Shield. Though Shield certainly looks like an interesting product, it looks far too advanced and costly for the problem we tried to solve at Kumina: simply having partitioned access to the data for several customers. This is why we commissioned the development of a new piece of software called Buckler. Buckler is a light-weight proxy for Kibana, written in Python (Django). It allows you to restrict access in Kibana by adding password authentication. When logged in, a user is only allowed to access indices specified for that user in Buckler’s configuration file.

Free alternative to Shield

Today we’re glad to announce that we’re releasing Buckler as open source software licensed under the Apache License, version 2.0. The Git repository containing sources and documentation can be found on our company’s Git Hub page. In addition to the proxy itself, we’re also releasing a Vagrant environment that allows you to easily test and experiment with Buckler. Right now Buckler only works in combination with Kibana 4.1, as that’ s the version in use at Kumina. There is a fair chance we’re going to extend Buckler over time to support newer versions of Kibana, such as 4.3 and 5.x.



The Collectd encrypted packet format

Friday, March 21st, 2014

Yesterday, Logstash 1.4.0 was released containing many improvements, one of which was contributed by us. We’ve implemented signature verification and packet decryption in the collectd input plugin. This blogpost will give an overview of how encryption and signing is used in the collectd binary protocol.

We’re currently working on deploying a logstash infrastructure that will eventually extend our monitoring and trending capabilties. At the same time, we want to move from our pull-based trending (Munin) to push-based (Collectd). Logstash recently added a Collectd input plugin, but it didn’t support decryption and signature verification of collectd packets. As we send (some) of this data over the public internet, we need to encrypt this traffic, so we decided to implement this.

During implementation, we discovered that the documentation was scarce and the comments in the collectd source-code appeared incomplete. This post gives a description of the collectd signed and encrypted packet formats. It assumes that you’re familiar with the collectd binary protocol.


Check and detect Linux/CDorked.A infections

Wednesday, May 8th, 2013

We’ve been reading a lot about a Linux exploit targeting webservers and since we manage quite a lot of webservers, we’re keeping a close eye on it. We recently already deployed a check for rogue Apache modules (since we mainly use Apache), but now we’ve also created a check from the code provided by ESET on their security blog describing the Linux/CDorked.A exploit. All it does is check shared memory for a segment of a specific size, but it’s still better than nothing.

As usual, the Icinga check can be found in our GitHub repository and if you’re on Debian, you can find the nagios-plugins-kumina package in our repository. This check needs to be run on the local machine, so you need to setup nrpe or ssh access from Icinga for that.

Let us know if this helps you or if we should improve on it! All kudos to ESET, since they provided the actual script (and research!) for this check.

Checking for rogue Apache modules

Wednesday, April 3rd, 2013

We’ve read a lot recently about attacks in which an attacker loads a modified module into Apache to insert iframes in outgoing data. Pretty scary, especially since nobody really seems to know how the hacks are performed. Recently, Sucuri wrote a blog article about how to check for rogue Apache modules on Debian. We’ve decided to implement this into an Icinga/Nagios check.

You can find the source for the plugin here. We also publish all our plugins via the ‘nagios-plugins-kumina’ package, provided by our apt repository.

Hope this helps!

Update: I packaged and pushed the wrong version of the script… Silly me. Fixed now!