Planning the network topology

An essential step in building a network is developing a network topology. A network topology determines how lab components can be interconnected physically and logically, significantly influences data flows inside a network and sets requirements and limitations on network protocols usage.

Network segmentation is another important mechanism to think about in the planning stage. A network segmentation allows us to implement network management protocols to practice more network layer attacks, and it allows us to use integrated security features of network devices and dedicated network-based firewalls to provide better inter-segment isolation and network access control.

Thus, if you want to implement certain network protocols operating in a lab, which make sense with practicing certain attack types and provide security to the lab at the same time, we need to plan a segmental lab's network with several subnets and virtual LANs instead of just connecting all lab components to one switch. We are not going to implement the security measures mentioned earlier, but we will implement some network segmentation to secure the lab and allow you to improve the lab security later if you want.

Lab environment security is also highly dependent on a network topology that is implemented in a lab, so we should state general security requirements before we start to plan subnets and network segments:

• We need to keep our internal network segments insecure to allow practice various attacks and, at the same time, we do not want to see somebody unauthorized accessing our lab whatever intentions they may have
• The lab should be accessible for authorized users and devices via a protected WLAN, but it should be also possible to connect testing machines directly to the lab LAN to practice certain network attacks

After we have understood our lab security requirements, let's proceed with defining subnets and network segments which we would like to have in our lab.

It is common practice to separate server and user workspaces in enterprise networks and assign different IP ranges to them. That is what we are going to implement to imitate a real network. Additionally, we are going to establish a separate management VLAN for managing servers—again, as in a real enterprise network. This will allow you to practice attack scenarios such as getting management access to a server after privilege escalation on a normal user workstation or build a network tunnel from a hacker's machine to a management interface of a network device via a hacked server.

Usually, large companies want to provide Internet access to their visitors and still keep their internal networks safe from the possible risks associated with untrusted connections. Such risks can be represented, for example, by intended malicious behavior or even non-intended malware spreading from visitor devices.

To minimize those risks, companies usually implement guest network segments. They are normally logically or physically isolated from other enterprise networks and network segments but allow visitors to access the Internet. With the high popularity of mobile devices, WLAN became the most convenient and widely spread technology for guest networks.

We also would like to have a guest WLAN in the lab and mostly because we don't want to ever switch our trusted WLAN in a less secure mode than the one which protects our lab in the best way. Our lab is supposed to be accessible mostly via Wi-Fi (remember the book's name?) but to be vulnerable inside, so it a very important point to do not reduce the security of the trusted WLAN.

Taking into account all requirements provided previously along with the idea to imitate a real network without building a huge and expensive infrastructure, let's design a lab with a popular scheme for small offices called Router-on-a-Stick. It is assumed in this scheme that the whole network is built on two network devices: a switch and a router that is connected just to one port on a switch.

The Router-on-a-Stick scheme assumes that a local network is connected to an external network (or ISP) via only one designated and logically isolated switch port. Please keep in mind that everything outside this port is an untrusted environment. The guest WLAN subnet is also an untrusted network environment because it is exposed to the air and destined for connecting untrusted devices.

We think it is a good idea for a lab to join untrusted network areas and connect the guest WLAN via a SOHO Wi-Fi router.

If you decide to get an additional network-based firewall with an IPS module, a good place to install it is between a SOHO and a core routers. Thus, it will become an additional layer of security and will protect the internal lab network against attacks originated from external and guest networks.

To better represent all the ideas described till now, let's depict the resulting network topology in a diagram:

The lab network topology diagram

As the last step, let's define an addressing scheme for our network.

The server subnet will have static IP addresses as in real networks and the user subnet can operate a DHCP server to provide dynamic IP addresses to workstations. The guest network and the trusted WLAN should also assign dynamic IP addresses. You can find the IP ranges for each subnet in the following list:

• Server subnet: 10.0.0.0/24
• User subnet: 172.16.0.0/24
• Guest WLAN: 192.168.0.0/24
• Trusted WLAN: 172.16.1.0/24
• Management VLAN: 10.1.0.0/24

So, the network topology has been developed and we can continue with choosing lab components.