In the previous chapter, we prepared a network "basis" for the lab in two options: hardware and virtual. Now, it is time to fill the lab network with application-level functional components such as web servers and database servers. Those components are needed to build a lab network that has most of the capabilities of a real enterprise network to let a penetration tester practice the most common and "must-know" cases and techniques.
Usually, applications and network services are the main goal for attackers and the main target of their attacks. Such components are usually used to process and store financial and private data, trade secrets, and other sensitive confidential data. They are often used to manage other network components and accounts, thus controlling the access to network resources. Some of them can provide various customer services and are therefore one of the key profit or reputation systems for a commercial company, so-called business-critical systems (or application/services).
Needless to say, companies place high emphasis on protecting such systems and services and often tend to get another third-party opinion, ordering penetration tests and other information security consultancy services.
That is why you have to be well-prepared to meet at least some of the popular network services and we will see how to reach that goal in this chapter.
This chapter covers the following topics:
As usual, before you start building something, it should be planned and all prerequisites should be fulfilled.
In the current topic, we are going to define which server will host which services and applications. We are going to try to host several applications and services at one server, because most of us are limited with computing resources and server hardware, remember?
So, depending on your capabilities and budget, you can use relatively powerful servers to host several relatively powerful VMs or you can use SOHO computers to host VMs with limited RAM and CPUs.
Lab environment flexibility
It is worth reminding that it depends on your own needs and preferences which hosts to include in your lab and which ones to omit. We just want to show the most useful options of installing lab components, but it is totally up to you what exactly to use and what to do not use.
A good thing about using virtual machines is that you do not have to keep all the servers turned on at the same time. For most of your lab tasks, you do not even need to turn on your network devices. In most cases, it is enough to just turn one VM on and keep everything else suspended.
As we have already decided in the previous chapters, the IP range for our server subnet is 10.0.0.0/24 and the IP address 10.0.0.1 is already assigned to the core router's subinterface. Workstations will get their dynamic IP addresses from the router via DHCP, so we don't need to plan their address space now, except the admin workstation which has the IP address 10.1.0.30.
Keeping all that in mind, let's draw another table to summarize what and on which IP addresses we are going to install:
IP address |
OS |
Apps and services |
Remarks |
---|---|---|---|
10.0.0.2 |
Windows Server 2008 |
Directory services |
AD, e-mail server, certification authority, SSH |
10.0.0.3 |
Linux |
Metasploitable 2 |
Vulnerable network services |
10.0.0.4 |
CentOS |
vulnVoIP |
Vulnerable VoIP service |
10.0.0.5 |
Ubuntu Server |
Web application server |
Liferay Portal CE, OWASP WebGoat, DVWA |
You can always get back to this table to quickly refresh the server subnet's layout in your memory.
Back up your lab systems
Do not forget to make snapshots of your VMs after finishing installations. There is a big probability of unintentionally breaking something during further hacking exercises and it is good to have a backup image which you can quickly restore—a snapshot in case of VM.
You will also probably want to have several snapshots of some VMs having various configurations or security levels to be able to quickly switch between them according to your current lab tasks.
3.19.244.57