In this section, we will discuss our lab design and provide some information that you can use to expand it in the future.

As we begin to set up our lab, we want to take some time to discuss the lab setup and some of the considerations that we will take when using the lab. Some of these considerations are designed to make the lab more effective, while others are used for the protection of the networks our lab is connected to. We also want you to be in a position to easily expand or grow this network with other test machines as you master the Kali recipes that follow.

In this section, we will be discussing general topics as opposed to specific recipes.

Today, there are many different hypervisors that will allow you to run multiple virtual machines on a single physical machine. For our specific purposes, we have chosen to show you how to setup the initial lab in VirtualBox due to several compelling factors. It's free to use, has multi-platform support, and it's able to run within your main operating system. However, as we progress past the first chapter, we will be switching to VMware ESXi. This will not affect recipes in any way between using VirtualBox and VMware ESXi. Our main reason for switching is the amount of compute resources that are available to us in our dedicated lab. We have the ability to run many virtual machines at once, and we will have the ability to insert firewalls and other security devices between our Kali instance and our testing hosts, as needed. We also have the flexibility to create more complex environments.

If, for any reason, you are looking to build a larger test network or have a different hypervisor of choice that better suits your purposes, feel free to use it, as we will assume you will be able to translate our instructions between the different hypervisors.

In our lab, we are going to be using two networks within VirtualBox: a NAT network and a host-only network. Our Kali box will be connected to both the networks, so it can communicate with devices on the internet, download updates, and get software packages as needed. Our target machines will only be connected to the host-only network. The host-only network can only talk within the host and among other devices connected to the host-only network. It cannot communicate through your Ethernet or wireless networks. This setup is extremely critical to our testing environment, as we do not ever want to expose our testing hosts to the outside world, as they are very vulnerable and will be hacked rather quickly.

To further protect the networks that your lab is connected to, we would actually suggest disconnecting the virtual adapter of the Kali virtual machine that connects to the NAT network, unless specifically required for the recipe operation. This way, your network is protected from accidental exposures to any attacks you may be sourcing from Kali.

One of the many questions frequently asked is why we soften machines or use machines that have vulnerabilities. The fact is that a properly patched, properly configured, and properly hardened machine is quite difficult to get into. Penetration testing is not trying to get through to hardened devices but looking specifically for those devices that have vulnerabilities. In a typical engagement, you may find only one or two machines that have vulnerabilities. You can then use these machines to gain a foothold into an environment to compromise other more hardened machines. If you start doing regular engagements as a penetration tester, you will be surprised by just how many machines you may be able to find that have vulnerabilities. This is especially true with the proliferation of low cost Internet of Things (IoT) devices such as internet connected cameras, thermostats, automation systems, and monitoring. These devices often run Linux-type embedded operating systems and are rarely patched and often overlooked. More importantly, they are often riddled with bugs and vulnerabilities that we can use for our purposes.