As part of one of the subjects for the degree program I’m currently enrolled in, the students enrolled in the subject had to put forward suggestions of projects which would be designed and built as groups on a “beer budget”, as in donated hardware and etc. I put forward a suggestion of building a penetration testing lab, a lab built special for the purpose of exploiting machines within the lab in hopes to teach and practise offensive security based techniques, knowing how an attacker attacks a network or host to learn how to prevent such attacks. My idea was one of the four ideas accepted as the projects that would be done. This blog post will be a write-up about the practise penetration testing lab that my group and I built for our group major project.
The outline of the project I put forward was to build a network security practise lab as of at the time the degree program had no such lab for students enrolled in the degree program to learn how an attacker will attempt to break into a network or host, so the students would have to use virtual machines of individual hosts to learn the skills required. I stated my goal was to build a multi-leveled network which in which students will be able to practise and hone such skills in hopes to better prepare other students in a career in IT Network Security, and this would be done completely on donated hardware from Meadowbank TAFE IT Section.
My intention was to build a multi-level network, what I meant by this was have a introduction network where students would be able to learn and practise skills and as they exploit and gain control of more and more machines they would have the ability to identify other networks within the lab and attempt to gain access to the machines within the other networks and attempt to exploit and gain control of said machines.
Designing the Lab
In this section of the write-up I will describe how my group and myself designed the NSI Network Security Practise Lab. The initial design of the network was to have two physical switches and have the hosting servers connected to the switches, the hosting servers would then host virtual machines which would be the designated machines that the students would be attacking for learning purposes. But this soon became apparent that we would not be able to control the access and it wasn’t friendly for “scope-creep” if we wanted to add other networks or features to the lab.
The final design for the lab ended up with the introduction of a router to the network design, the design being using one switch as a “distribution-level” switch in which all the hosting servers would be connected too, this distribution switch would also be configured with Vlans, allowing the group to easily segregate hosting servers into designated networks. The introduction of the router would allow us to perform inter-vlan routing for our end-to-end communication between each Vlan as well as allow us to configuration DHCP services if required and also Access Control Lists (ACLs) which will help us control the way the students interact with each Vlan. We decided that for now there would be 4 Vlans within the practise lab, the user Vlan the first level vlan, the second level vlan and the administrator vlan. More details regarding the ACLs and Vlan design will be covered in the below section. And the second switch will be a designated as an “access-level” switch, this switch provide access for the students to the lab network.
As for the machines that we going to configure within the lab for the students to work with we decided that the first level network would contain 10 machines to begin with, a mixture of both Windows and Unix/Linux based machines, which have been configured in specific ways which made them vulnerable to an attacker, each machine within the first level would be designed in such away to allow for one type of vulnerability. While the second level would contain 5 machines to begin with that had been configured more complicated vulnerabilities than the machines within the first level.
We put forward a hardware wish list to see if the TAFE would be able to source the required hardware needed for the project, the wish list comprising of the following:
- 1 Router
- 2 Switches
- 12 Computers
- 2 Monitors
- 2 keyboards and mice
We were able to get all the hardware that we required for the lab which were able to source from the Meadowbank TAFE. The hardware we were able to get was the following:
- 1x Cisco 2620XM Router
- 2x Cisco 2900XL Switches
The software we were considering to use for the virtualisation software of our virtual machines was the VMware ESXi but due to the fact that it required a x64 CPU architecture based machines and that we are getting machines donated to the group, it was not feasible to use this software. Because of this the group decided to look for other virtualisation software to use in the lab, the group thought of VMware Workstation 8 would be suitable but does not provide centralized management of all virtual machines so the group kept looking and learnt about Proxmox VE 2.2 which would provide us this feature we desired The group decided that we would use Proxmox VE 2.2 as our main virtualisation software and use VMware Workstation 8 as a backup if any unforeseen problems arise with the Proxmox software.
The group planned to configure and install 3rd party applications on selected machines as well other machines left vulnerable to Metasploit exploit modules as well. The second level network machine’s would consist of only boot-to-root virtual machines which don’t require much or none at all configuring.
Building the Lab
The above image is the diagram created by the group of the coverall network layout of the lab. The diagram was created using the Packet Tracer application.
In this section of the write-up I will write about how the group went about building the lab. The group began configuring the switches and router as needed for inter-vlan routing and also installing the Proxmox VE 2.2 software to the hosting servers. The Proxmox VE software was installed successfully onto hosting servers the group also began installing the virtual machines, the group realized that there was a problem with the Windows based virtual machines in their performance making them almost unbearable to work with. Due to this problem the group decided to turn four of the hosting servers in the first level network to Windows Server 2008 and installed VMware Workstation 8, these four machines would host all the Windows based operating systems for the first level network and the remaining hosting servers would remaining as Proxmox nodes and would host the Unix/Linux based virtual machines.
Once the hosting servers were stable and the switches and routers were configured with inter-vlan routing and DHCP services for the required networks the group connected the network together and began testing the end-to-end communications of the lab. The group wanted to force students using the lab to have to exploit machines in the first level network to be able to reach the second level network, the way the group determined they would force this was reflexive ACL statements, where communication between networks can only be established if the communication begins from one network and not the other.
The image above is a photo taken of the group planning the ACL statements on a whiteboard.
From the above image the group planned the Vlan 50 (User Vlan) can communicate directly with Vlan 11 (First Level Vlan) and Vlan 11 can communicate directly with vlan 12 (Second Level Vlan), though Vlan 50 can only communicate with Vlan 12 if the source of the communicate begins in Vlan 12. And finally no Vlan can communicate with Vlan 100 (admin Vlan) unless the source of the communicate originates from Vlan 100.
Once the group had implemented the ACLs they began auditing the lab, making of the following things were solved and possible:
- Can get an IP Address from a DHCP service for Vlan 50.
- Can get the administrator’s machines can get an IP Address from a DHCP service for Vlan 100.
- The boot-to-root virtual machines in Vlan 12 (Second Level Network) are able to get an IP Address from a DHCP service in Vlan 12.
- The ACL was working properly and as intended and was not blocking any expected communication.
- That the virtual machines with Vlan 11 and Vlan 12 were successfully exploitable.
- That the pivot/tunnel was possible from Vlan 11 into Vlan 12 post-exploitation of virtual machine in Vlan 11.
Once the group had tested all the above features of the lab, the group was happy with the state of the lab and allowed it to go live for other students to use and would transition into a beta stage of lab development. This blog post was a quick write-up of the group major project where I was the project leader of a group in which we built the NSI Network Security Practise Lab which was specifically designed for allowing students to learn how an attacker would attack a network or hosts to learn how to prevent or respond to such attacks.
I have provided a link to the Final Report that the group had submitted at the end of the project as a PDF file.