If you've ever tried to crack Wi-FI passwords or test for security vulnerabilitieson your network, then you're likely familiar with Kali Linux. It's a security-focused version of Linux that offers a multitude of tools to seek out weaknesses and secure your network.
It began out of necessity for lead Kali developer Mati Aharoni (known as muts in the community). While doing professional security work he needed a variety of security tools without being able to install any software on his client's systems, and so he took to Linux. We spoke with Mati to learn more about how it started and how the community-driven project has grown and evolved over the years into one of the leading security-focused Linux distributions.
Where did the idea for Kali come from? Were you trying to solve a problem you'd experienced, or did the inspiration come from somewhere else?
Mati Aharoni: The idea for a Live Linux distribution which contains a bunch of security tools was born out of necessity many years ago, when I faced a perplexing dilemma on a security engagement. I was not allowed to bring any hardware to the engagement—and what's more, I was only allowed to use onsite computers on the condition that I would not touch their hard disks or modify them in any way. (I actually was allowed to bring a laptop onsite, however it would be taken on exit).
After thinking long and hard, I figured that these seemingly impossible work conditions could be met by adding a few tools to an existing bootable Live Linux CD (Knoppix 2.0, to those familiar with ancient history). Once created, I would be able to bring in the CD to the engagement, boot an onsite computer with the CD, and work directly out of RAM. At the end of the engagement, I would be able to destroy the CD without too much heart-ache. And so I started a Linux Security based Distribution, ten years ago!
After you came up with the idea, what was the next step?
I will take the liberty to apply this question to our recently released Kali Linux distribution, the 3rd iteration of the Matrix.
Kali Linux was born out of our understanding that we need to take our eight years of experience in building Linux Security Distributions and apply them to a new, clean canvas. This meant tearing down everything we had done to that point, and starting afresh. This process was both terrifying and liberating—on one hand we had let go of our beloved BackTrack distribution, but on the other, we had the opportunity to rebuild and expand our current systems to create something better.
Once this hard decision was made, we figured that the next step should involve people who actually know what they are doing, and we brought in a Debian developer who helped us build our development infrastructure from the ground up. His assistance proved to be invaluable to our project and crucial to the success of the distribution.
How did you choose which platforms to target and which to ignore or wait on?
I'll answer this in regards to our Kali Linux ARM images.
One of our goals with Kali is to provide images of the operating system for all sorts of exotic hardware—mainly ARM based. This includes everything from Raspberry Pi's to tablets, to Android TV devices, with each piece of hardware having some unique property. For example, the MK808 has a dual-core CPU with a whopping 1GB of RAM, while having the form factor of a medium-sized USB dongle. Imagine that: a powerful hacking computer, battery-powered, in your pocket.
So how do we decide what type of ARM hardware to target ? That depends on several things—availability being the main obstacle. We try to identify interesting hardware that could be used in interesting ways for security assessments—and if such is found, we try to build Kali for it. By now, we have a wide array of hardware supported by Kali, and this list keeps on growing every month.
What was your biggest roadblock and how did you overcome it?
One of our biggest concerns with the move from BackTrack to Kali was the rebranding we had to do. After so many years of being a major force in the security community, "BackTrack" was known by all. To suddenly change this around would undoubtedly be hectic and confusing for our users. I thought long and hard at other major rebranding feats in the open source world, and thought to myself, "Didn't Wireshark rebrand a few years ago? What was their name beforehand?" After having to think for two long minutes before coming to the right answer, I figured that rebranding would be tough, but not impossible.
What was launch like for you?
The launch of Kali Linux went better than we could ever have hoped for. We had good friends to support the effort, and a proper infrastructure to support the mind-boggling amounts of traffic required to allow the gazillion downloads we experienced in the first few days.
We had the good sense to create a knowledge source before the release, as well as some community outlets like forums and a bug tracker.
How do you handle user requests and criticisms effectively?
Over the years we have become much more patient with opinionated users and criticism at large. I think we've learned that sometimes a seemingly silly bug report can actually be a symptom of a serious underlying problem. Treating all of these reports with the respect they deserve is something we are getting better and better at as time goes by.
Now, how do you split time between developing new features and managing existing ones?
In Kali, this question can be applied to the tools and features we provide in our distribution. We don't have a specific methodology for this. If we see a useful security tool, or a relevant security feature we think may be useful, we simply add it. A good example for this was the LUKS NUKE feature in Kali, which allows the user to "self destruct" their hard drive.
What advice would you give to others that want to take on a similar project?
In the world of Unix-derived operating systems, we all stand on the shoulders of giants. Going back to the original Berkeley source, to the initial Linux kernel, to the GNU toolset, to the modern Debian distribution, in all cases every Linux distribution is a true community effort. The biggest advice I would have is "don't be afraid to leverage existing infrastructure where possible." Why recreate the wheel unless you have to, especially when you can take an existing one and simply modify it for your purposes.