Kali Linux on AWS
The need for Penetration Testing
Every organization should have a security policy designed to fit its needs based on risks, threats, regulations and the value of the information it wants to protect. Part of such a security policy should encompass vulnerability management and testing. More substantial and more security minded businesses often also perform regular penetration tests to identify vulnerabilities in their systems that go beyond the reach of standard vulnerability scanners. When it comes to penetration testing, Offensive Security’s Kali Linux is the most widely used toolset in the industry. It is a Debian-based Linux distribution which contains hundreds of specific penetration testing tools.
Kali Linux in the Cloud
Having what is essentially a valuable hacker’s toolkit inside an organization’s network could be a risk by itself. It is, of course, the ideal target for an intruder. Even if such a system is relatively isolated and well hardened, some tests, for instance covering ransomware and worms, are probably better performed outside an organization’s network where there is no risk of an unintended outbreak. What better solution than placing a Kali Linux system and the potentially vulnerable target systems in a 3rd party cloud instance. Other than an internet accessible SSH or Graphical interface, there does not need to be any connection between the company’s production network and the testing instance.
Having an external testing source is also a great way to test the company’s perimeter defenses and footprint, from an outsider’s perspective. This could, for instance, identify specific gaps in firewall or webserver policies.
Another excellent use case for a cloud-based Kali Linux system is as a safe (and often free) training environment for security professionals. This works for a single individual, but since a few years, there are also a lot of security training providers utilizing such an environment as a “hacking sandpit” for students.
Finally, for certain aspects of penetration testing such as GPU based password cracking, the enormous scalability of cloud solutions is invaluable. Additional GPU and memory resources can be added for hours, days or longer depending on the requirements and budgetary restraints.
Options and alternatives
There are many ways to get Kali Linux up and running on a cloud instance. Amazon offers the AWS Free Tier service. This is a limited instance available to allow new users to learn to navigate and use their products. The preconfigured Kali Linux Amazon Machine Image (AMI) is also free and fits within the limitations of the Free Tier service. This means the server could be setup and operated for free for at least 12 months at 750 hours per month, although it is important to keep the usage limits in mind to avoid unexpected charges. With this method, costs should not be a limiting factor for training and once-off testing. For a large enterprise, however, these low or no costs should not really play a decisive role though. In that situation, the operational costs to maintain a few more mid-range Linux VM’s are easily justified by having a more secure environment.
Microsoft Azure also offers a Kali Linux machine, but other than a $200 1-month trial credit, this will not be for free. Again, a business would not be too concerned; an interested individual would probably steer towards Amazon for their free offer instead. From a usage and technical perspective, there is not much difference between the two.
Other providers such as onehostcloud have a Kali machine available as well, and some others simply allow a manual installation based on a standard Linux Virtual Machine, which of course could be Kali Linux (check if provider permission is required first).
Cloud providers are naturally hesitant to allow such a powerful toolset inside their environment. Although it is quite often used for testing, it is also very often used maliciously. Not only could this be harmful to the infrastructure of the service provider itself, but it could also involve them in a technical or legal issue if an attack on an unsuspecting target is sourced from within the cloud network. This could be why it took Offensive Security several weeks of back and forth to get their product into the Amazon EC2 Marketplace back in 2014. There are some guidelines as well to which VM’s must comply. Amazons Machine Image Guidelines, for instance, prohibit the use of Kali Linux’s “root” user default login, meaning Offensive Security had to fall back to username “admin” for their cloud image version.
The nature of the Kali Linux product is to run potentially malicious attacks against targets, which will set off some alarm bells at the cloud providers security department. To avoid a temporarily or even permanently disabled account, always inform Amazon of any such activity via their online form or e-mail. This will enable the Amazon team to whitelist the source and destination address for the duration of the test. Depending on the level of monitoring service, it might also prevent Amazon or any other 3rd party sending a critical security escalation to your security team, based on a planned security test.
There is also some limitation on targets within the Amazon cloud environment. As an example, it is not allowed to attack m1.small or t1.micro instances due to the performance impact on shared resources.
The possibility to almost completely segregate systems inside a cloud platform and within an organization’s production network makes penetration and other security testing, such as malware analysis, perfect candidates to run inside a cloud instance. For security researchers, there are boundless opportunities as well. An environment can be built on-demand at very low cost, to reproduce a situation that has occurred or that could potentially occur in the future. There are hardly any technical limitations to what is possible here, and the few that exist are substantially outweighed by the new opportunities the cloud can provide in this space