Installing and Exploring Kali Linux in an Isolated Environment

Kali Linux is the workbench of many security professionals: a Linux distribution that comes with hundreds of tools for network analysis, web testing, password auditing and forensics. It has a reputation that makes some people nervous, but it is simply a toolbox, and a very good way to discover how the profession works. In this lesson you install it in your lab and take your first tour, without using any of the offensive tools yet.

You prepared your hypervisor and your lab plan in the previous lesson. Now Machine 1 of the plan comes to life.

What Kali Linux is, and is not

Kali Linux is a free, open-source Linux distribution based on Debian, maintained by a company that specialises in security training. It gathers security tools in a single system, pre-configured, and organises them in a menu by category: information gathering, vulnerability analysis, web applications, password attacks, wireless, forensics, reporting.

It is not a magic hacking machine, and it is not a system for everyday use. It is designed for security work, which is why the project's own documentation advises against using it as a general-purpose desktop. Its tools do exactly what a good professional needs, so everything you do with them must respect the legal framework. Having Kali on your computer is legal; using its tools on a system without authorisation is not.

Getting the right image

Go to the official Kali Linux website (type the address yourself or use a trusted search, and be wary of look-alike domains, which is a topic you know well from the DNS lesson). The project offers several formats:

• Installer images (ISO): you go through a standard installation in your VM.
• Pre-built virtual machine images for VirtualBox and VMware: you download an archive, import or open it in your hypervisor, and you are ready in minutes. They are the simplest option for a lab.

Whichever you choose, apply what you learned: use only the official download page, pick the image that matches your processor architecture and your hypervisor, and compare the checksum of the file you downloaded with the one the project publishes. If they differ, delete the file and download it again.

The project documentation also tells you the default account for pre-built images. This information changes between releases, so read it on the official site rather than relying on this course, and change the default password at the first login. A default password on a machine that is connected to a network, even a virtual one, is a bad habit to avoid.

Creating the VM

If you import a pre-built image, the hypervisor does most of the work: you open the file, adjust memory and CPU according to your lab budget, check the network adapter (we will set it in the next lesson), and start the machine. If you use an installer ISO, create a new VM, choose a Linux type matching Debian, give it a reasonable amount of RAM (at least what the documentation recommends), a dynamically allocated virtual disk, attach the ISO and start it. The installer guides you: language, keyboard, user name and password, disk partitioning (guided, using the entire virtual disk, is fine), and package selection (the default selection is a good start).

When the installation ends, remove the ISO from the virtual drive, reboot, and log in. Then install the guest additions or the equivalent virtualisation tools, as recommended in the project's documentation for your hypervisor, to get a better display and clipboard integration.

First things to do after the first boot

1. Update the system. Open a terminal and refresh your package lists, then upgrade. On Debian-based systems:

   sudo apt update
   sudo apt full-upgrade

   This needs Internet access, so do it while the VM is still connected through a NAT adapter (next lesson explains how to isolate it afterwards).
2. Change the default password if one was provided, using the passwd command.
3. Take a first snapshot named "clean install updated" (next lesson). This is your safety net.

A guided tour of the desktop

The desktop looks like a modern Linux environment, with an application menu. Explore it with curiosity and without launching tools blindly. In the menu, the tools are grouped in numbered categories. You will meet several by name later in the track:

• Wireshark, which you already know, for packet analysis.
• Nmap, a network mapper used to discover hosts and services, and that we meet in the next courses.
• Burp Suite, an intercepting proxy for testing web applications.
• Metasploit, a framework for exploitation, studied with great care in course 4.
• John the Ripper and similar tools for auditing password hashes.

Open a few of them just to look at their windows. Do not run scans, even "just to see". Remember that the only systems that you may target are your own lab machines and the legal training platforms listed in the track.

Next, open a terminal and run a few harmless commands to get oriented. They also prepare chapter 4:

whoami
hostname
pwd
ip addr show
uname -a
cat /etc/os-release

The last one prints a text file describing the distribution. It is a quick way to know exactly which system and version you are on, and a good habit to note in your lab notebook.

Customising wisely

You may adjust your environment: a larger font in the terminal, a keyboard layout matching your hardware, a full-screen mode. Resist the temptation to install lots of extra software from random websites: each addition makes your lab less predictable and potentially less safe. For tools that you do want, use the package manager (apt), which verifies signatures of official packages.

Also build the habit of keeping a log. A professional note-taking routine is: date, goal, command, result, conclusion. If you are using a note-taking application inside Kali, make sure that its content is backed up outside the VM, because VMs can be deleted or corrupted.

Your turn: install, update, document

Set up your Kali VM following the steps above. Then, in your lab notebook, record: the image you used and its source, whether the checksum matched, the output of cat /etc/os-release, the amount of RAM and disk allocated, and the output of ip addr show (what IPv4 address does the VM have, and in which range?). Take a snapshot when you finish.

See a solution

If the VM uses the default NAT adapter of the hypervisor, its IPv4 address is typically a private address delivered by a DHCP server built into the hypervisor, for example in the 10.0.2.0/24 range with VirtualBox's default NAT. That range is not your home network: it is a small private network created by the hypervisor just for the VM, which explains why it is invisible from the other machines (a feature, not a bug). Your answers on the image, checksum and release will depend on the file you downloaded. What matters is that the notebook is complete enough for someone else to rebuild the same VM.