Lab0: Setup Pentesting Lab in GNS3
Overview
This document will guide you through the process of designing and implementing a pentesting laboratory using GNS3 as the primary tool.
Network Architecture
For the network design, we will consider a small organization that requires:
- A network for servers exposed to the internet
- A public network where clients can connect to the internet via cable or Wi-Fi
- A network for administrative personnel
- A network for developers
As seen, we have 4 groups or subnets. Some additional conditions are:
- From the server network, there should be no connectivity to other networks except to the internet
- The other networks can have connectivity to the servers
- The public, administrative, and developer networks should not have connectivity between them except to the internet, for security reasons
- Use appropriate devices to add future subnets
Diagram
We create a simple diagram with the requirements for each network:
Explanation:
- The public network or for clients offers connectivity via cable Ethernet and Wi-Fi
- The developer, administrative, and server networks will use the same type of topology and connectivity via cable Ethernet
Devices:
In all networks, we implement:
- A router
- A switch
- In the case of the public network, a Wi-Fi access point
Internetwork
The diagram of how the networks will connect:
As we see in the diagram, from left to right, first, we use a firewall, in this case, Pfsense, which will prevent possible intrusions from the server network. Remember that these servers are production servers, have a public IP, and could be, for example, a registration system. The firewall is connected to the server router, and this area is known as the DMZ (demilitarized zone). After the firewall, we have the internal network, which consists of:
- R1, the main router that connects all the other networks
- R2, the router of the public network
- R3, the router of the administrative network
- R4, the router of the developer network
IP Segmentation
Now that we have the network design, we can establish the addresses that each network will have. The private range for the internal network will be:
Segment | Network | Gateway | DHCP |
---|---|---|---|
172.16.20.0/24 | public | 172.16.20.1 | yes |
172.16.30.0/24 | administrative | 172.16.30.1 | yes |
172.16.40.0/24 | developers | 172.16.40.1 | yes |
For scalability:
- The distance of 10 is to add and/or segment more networks within that subnet. For example, if we wanted to add a network for administrators with high privileges, we could create a network 172 .16.31.0/28, so we clearly identify that this network belongs to the administrative network (range 30-39).
- The /24 mask is just for convenience in this laboratory; obviously, there won’t be 254 machines in each subnet.
A detailed explanation of addressing and subnetting can be found in Chapter 3 of the book:
Routers and Firewall
We must consider that only 2 IP addresses will be used between routers, so:
Segment | Device | IP | Device | IP | DHCP |
---|---|---|---|---|---|
10.0.1.0/30 | Pfsense | 10.0.1.1 | R1 | 10.0.1.2 | no |
10.0.2.0/30 | R1 | 10.0.2.1 | R2 | 10.0.2.2 | no |
10.0.3.0/30 | R1 | 10.0.3.1 | R3 | 10.0.3.2 | no |
10.0.4.0/30 | R1 | 10.0.4.1 | R4 | 10.0.4.2 | no |
10.10.10.0/29 | Pfsense (DMZ) | 10.10.10.1 | servers (DMZ) | 10.10.10.0/29 | no |
The DMZ zone will only have a switch that will be connected directly to Pfsense. There is no need to use a router for now, and there will only be addresses for a maximum of 6 servers (due to th e /29 mask).
Implementing NAT
Why use NAT? Is it really necessary? Yes, looking at Figure 2, especially R1, we can use this router to:
- Control which network can have connectivity to the internet
- DHCP server for all networks
This would be convenient, as we would have a single point to control the connectivity of the networks. Now, what type of NAT to use? Since between Pfsense and R1, there are only 2 unique IP addresses, the type of NAT to use is overloading (or PAT), which is a one-to-many connection:
The graph means that all internal networks can only have connectivity via the IP address of R1 (10.0.1.2), and Pfsense will only recognize that single IP address.
A more detailed explanation and examples can be found in Chapter 11 of the book:
Final Diagram
The final design with everything mentioned is:
GNS3
This guide assumes that the reader already has GNS3 installed and configured on their device. A very detailed guide can be found in the book:
The devices used and available for download from the GNS3 Marketplace are:
- Pfsense firewall
- CISCO 7200 router or equivalent, but must be CISCO
- CISCO iosvl2 switch (already integrated with GNS3)
ISP
Like VirtualBox, we need to choose an interface to allow connectivity to the internet. This part is similar to the “bridge mode” section, but in GNS3, all external devices are represented by a cloud, which can be configured in the “Edit > Preferences > Cloud nodes” section:
- Click on New
- Select “Run the cloud node on your local computer” and then Next
- In “Name”, type WAN or ISP, and then click Finish
- Select the created cloud and then click Edit
- In “Ethernet interfaces”, select the physical network card through which we will obtain connectivity to the internet, and click Add
- Finally, click OK, Apply, and OK
In the “End devices” section, we can already see our cloud, and we just need to drag it to the central panel of GNS3.
Pfsense and DMZ Configuration
Pfsense must be installed before it can be used. A video of the Pfsense installation can be found on the REeset2099 channel.
And the configuration of the DMZ network and LAN:
Router Configuration
R1
We drag the CISCO router to the GNS3 panel and, by right-clicking and going to “Configure > Slots”, we add 4 Gigabyte interfaces as seen in the following image:
Table for R1 addressing:
Device1 | Interface | IP | Device2 | Interface | IP |
---|---|---|---|---|---|
R1 | GigabitEthernet1/0 | 10.0.1.2 | Pfsense | em2 | 10.0.1.1 |
R1 | GigabitEthernet2/0 | 10.0.2.1 | R2 | GigabitEthernet1/0 | 10.0.2.2 |
R1 | GigabitEthernet3/0 | 10.0.3.1 | R3 | GigabitEthernet1/0 | 10.0.3.2 |
R1 | GigabitEthernet4/0 | 10.0.4.1 | R4 | GigabitEthernet1/0 | 10.0.4.2 |
Table of services for R1:
Device | Service | Interface | Segment |
---|---|---|---|
R1 | DHCP | GigabitEthernet2/0 | 172.16.20.0/24 |
R1 | DHCP | GigabitEthernet3/0 | 172.16.30.0/24 |
R1 | DHCP | GigabitEthernet4/0 | 172.16.40.0/24 |
R1 | NAT | GigabitEthernet2/0 | 172.16.20.0/24 |
R1 | NAT | GigabitEthernet3/0 | 172.16.30.0/24 |
R1 | NAT | GigabitEthernet4/0 | 172.16.40.0/24 |
Addressing R1
Now that we have everything defined, we configure the interfaces on the router by right-clicking and going to the console. The commands are:
|
|
An introduction to using CISCO commands and their modes can be found in the book:
- Cisco Routers for the Desperate, 2ed in Chapter 1
The following commands are performed for each interface, only changing the corresponding IP address and interface:
|
|
The result should be:
|
|
DHCP on R1
Following the segmentation table, we first separate the gateways for each network:
|
|
Then we configure the pools for each network:
|
|
NAT on R1
First, we create a global pool and the IP address that will be used:
|
|
Then we create a rule that allows only the IP addresses that are in list 1 to access the globalNet pool:
|
|
Now we add the networks to the access list 1 (ACL):
|
|
To verify the access lists:
|
|
As we see, all LAN networks are in ACL 1. Finally, we establish the interfaces as outside and inside:
|
|
All the configuration above must be saved to memory to prevent loss at device restart. The command is:
|
|
Routes on R1
The routes are:
|
|
Default route or gateway for R1:
|
|
To see the routes:
|
|
Up to this point, if we are already connected to Pfsense, we should have connectivity from R1 to the outside:
|
|
The most complex configuration is done!!!
More information about routing in CISCO can be found in Chapter 5 of the book:
Routers R2, R3, and R4
Similar to R1, each router must have an interface added in their configuration options:
Table of addresses for routers R2, R3, and R4:
Device | Interface 1 | IP | Interface 2 | IP |
---|---|---|---|---|
R2 | GigabitEthernet1/0 | 10.0.2.2 | FastEthernet0/0 | 172.16.20.1 |
R3 | GigabitEthernet1/0 | 10.0.3.2 | FastEthernet0/0 | 172.16.30.1 |
R4 | GigabitEthernet1/0 | 10.0.4.2 | FastEthernet0/0 | 172.16.40.1 |
Only the commands for R2 will be shown, as the commands for R3 and R4 are similar, just changing the corresponding IP address:
|
|
The line in blue allows this interface to obtain an IP address via DHCP from R1.
Then we add the routes:
|
|
If we try to ping an external IP address, we won’t have a response, as the router IP address 10.0.2.2 is not in the ACL of the NAT pool:
|
|
Hosts
Now that we have everything configured, we must add the CISCO IOSVl2 switch to the public network. This switch does not require configuration for now. We connect an interface of the switch to the FastEthernet0 interface of the R2 router and leave the rest for the hosts.
At this point, we should connect a machine to verify connectivity, as seen in this video:
Connectivity Test
Up to this point, we should already be able to reach the IP address of the R1 router 10.0.1.2 from R2:
|
|
And from R1 to the IP address 172.16.20.1 (R2):
|
|
Final Diagram in GNS3
After applying all the configuration, the final diagram in GNS3 is:
Weak Points/Failures
Although the diagram above is functional, the weak points are:
- The routers/switches are not configured with a user and password
- Pfsense still uses default credentials (this is simple to fix)
- There is connectivity between the Public, Administrative, and Developer networks
- There is still no Wi-Fi access point
In the following posts, these points will be addressed.