You're here because you want to build your own Debian-based Linux. This article is intended as a guide to building atop an existing pen-testing distribution to do so, in this case Kali, using Debian live-build. Below is the history of Attack Vector Linux, where the original goal was to provide both pen-testing tools and anonymity, which became Knife Linux, which is intended to provide administrator resources as well as pen-testing tools to create a more comprehensive Linux distribution for a wider audience. I’d like to add three things before you continue: none of this is warrantied and there is no expectation of support; these tools can do serious damage when the proper care is not taken; don’t be evil.
I was approached last year with a question regarding the possibility of adding Tor and/or I2P to Kali. If you’re interested in a breakdown of I2P vs. Tor check out I2P’s fair and balanced comparison between the two systems. Kali (by the creators of Backtrack) is a Debian-based distribution that includes a ton of pen-testing frameworks and tools, ranging from the most popular to some more esoteric functionality. As it happens, Tails (The Amnesic Incognito Live System) is also a Debian-based distribution, in this case a live distribution (intended to be put on external storage, i.e., a DVD or USB key). Tails adds the anonymity of Tor and/or I2P to all parts of the system and comes with tools like secure-delete, which wipes out the memory of the system as it shuts down, and Polipo, a caching web proxy that can be used to route different kinds of traffic through I2P, e.g. nmap, or system updates through Debian’s aptitude.
The legitimacy of reasoning for this distribution was highly dubious in retrospect. I was building it because I had never done it before, and it seemed sensible that others would want to use it for appropriate purposes, especially when pertaining to red team CTF exercises. Due to some miscommunication, misquoting, and misinformation, there were problems with this from the start with the Kali community, and as a result I severed ties with the project. You can still find the project, which, as far as I can tell has no further technical development, as Attack Vector Linux, but as aforementioned I am no longer affiliated in any way (though my name is still on a lot of the documentation). Instead I took much of that work and created Knife Linux. Knife adds additional security tools as well as administrative functionality to Kali; it’s essentially a Debian live-build recipe that will allow you to roll your own attack and defend Linux. For a complete list of additions and how to get your Kali build-environment set up check out the readme included with Knife.
In building out Attach Vector and Knife Linux I looked to Tails for both tools and configuration, to Kali for ways of using Debian live-build to add packages and script configuration changes, and to my friends in the community for additional tools and scripts that they felt were missing from Kali (to whom I also gave a presentation on this very subject in May 2013). If you’re interested in how I determined what Tails installed and how it was configured I suggest you check out the Linux Standard Base documentation, which explains what packages should look like, how they should be installed and configured (and much more) as well as the Debian package management documentation. The first step was understanding the various connections in the Tails system, like how system updates were proxied through Polipo, and how I could install and configure FoxyProxy for Firefox and hook it up to Tor. These additions obviously never made it to Knife, but it gave me insight into how to create a truly secure environment, one in which every aspect of communication was routed through at least one anonymizing service. I then used the Kali live-build recipe to prepare my build environment. The biggest issues were in the compatibility of some of the experimental packages needed by Kali and the stable packages needed by the tools from Tails. I resolved these issues by looking at the conflicts that would arise during install and using package pinning to force packages from certain distributions of Debian.
The live-build recipe is very straight forward, being split into a series of folders that are well-documented:
- In the live-build auto config you’ll find information about the mirrors to be used and options for updating the name of your distribution.
- My advice (not yet implemented for Knife) is to create a local mirror of up-to-date packages: this will cut out a significant amount of time during builds, as it will attempt to install packages from these mirrors each time.
- You can add packages to install via the package lists directory.
- These must, of course, be found in one of the repositories you set up in within the archive config.
- In the archive config you may also specify packages to pin (as aforementioned), which allow you to force packages from a given release.
- This may be necessary in some cases to resolve conflicts that would otherwise confuse the aptitude dependency resolver.
- The chroot includes directory will be copied, in full, to your final mount-point.
- Here you can add sources for aptitude, additional init scripts, Firefox configuration, and so on.
- Finally, the hooks directory is where you will add user-defined scripts, run in lexicographic order.
- These are run last (once the environment is fully set up), and therefore are perfect for making final configuration changes or adding scripts and gems that are unavailable through aptitude
If you’re interested in adding to Debian as part of your own live or installed distribution I urge you to do so using the live-build documentation; you’ll learn a lot about Debian and it will give you full control over the default packages and configuration of your environment. If you want to build an administrator friendly version of an attack Linux please fork Knife and give it a much needed update (and if you have suggestions for tools, packages, scripts, and/or configuration I’d love to hear them). Lastly, I entreat you to use these tools responsibly. The community as a whole spends a tremendous amount of time and effort to produce and distribute these tools, and to use them without thought or understanding is a disservice to the people who have dedicated their lives to the improvement of security.