Lab 11 | Implementing a Secure Network Design

Lab 11 | Implementing a Secure Network Design

This lab is demonstrating a man in the middle arp attack and also dabbling in using VLANs and subnets.

In the first exercise of the lab we set up a redirection the redirected users requesting the 'HTTP' version of the local website to the 'HTTPS' session instead, this was in preparation for implementing authentication to our website that is protected by a serverside cert & TLS.

This exercise was essentially following the steps to install the measures I spoke of, once this was implemented our website could not be connected to without the ability for the user to authenticate with username & password as well as our certificate environment functioning correctly which was the source of many peoples problems whilst trying to get the website to open again. 

Following this setup in exercise to we executed an arp poison attack on a specific target range.

Following this, we used kali to sniff the traffic as we connected to the website with our new authentication system included. Highlighted below is the vm mac addresses that were involved in the transmission.

Despite our ability to have our arp poisoning attack allow us to read all the traffic the contents of the packets are still protected by TLS so the sensitive data is still unreadable.

Following this we set up SSL instead which differs in function from the previous attack method, SSL instead acts like a proxy that intercepts the redirects to HTTPS and returns a plain HTTP version of the web page instead, without the redirect to HTTPS being accomplished the site is no longer protected by TLS, if I am correct then this means there is weakness in using redirection methods like we implemented in order to redirect users to a secure connection, instead it may be wise to simply have them use the secure URL in the first place and not consider redirecting the 'HTTP' URL.

Due to TLS not being in play any more thanks to this improved attack method we can see the credentials, it should be noted that users to get a warning that they are entering their details over an unsecured connection although I doubt that this will not dissuade users from entering their details.

In the next exercise we are to organize our little network setup into two different VLANs this is to demonstrate the ability to segment our servers away from our client machines and maintain greater control over the traffic that flows between the two logically separate VLANs.

Our VM environment did not allow us to follow the setup steps as per the labs instructions and Mark provided us with an alternative (pictured below), we utilized the switches to logically seperate our machines.

Following the organizing of this system we set the ethernet port addresses in our router to the correct specifications we also set the correct settings to implement a DHCP relay agent, this will allow our domain controller to give our IP addresses to the machine in the separate VLAN.

Following this we set up a new DHCP scope that is intended for the client machines on the other VLAN, this separates our logically separated VLAN in a logically separated subnet as well.

This setup made our environment more secure in that there is less accessibility to the VLAN which contains our servers, there would only be accessible to the server ports within the server room if done correctly, the lab book noted however that we can still get onto the client VLAN and execute arp spoofing from there.

This was demonstrated and shown in the pictures below we can see packet contents, this lead into the closing revelation about the vlans in that to protect from arp spoofing correctly you also need to use secure protocols and restrict network access at the device level, this would not allow our malicious device to read the traffic.

Lab Questions

Ex 2 | 14

Which VM MAC addresses are used?

Highlighted below.

Critical Thinking & Analysis

Concluding this lab I have learnt about the vulnerabilities we need to be aware of whilst implementing a secure network design, demonstrated by our arp spoofing exercises malicious actors are able to compromise network traffic unless you implement the correct safeguards to this.

Our network design has to be comprehensive in the case of our network holding sensitive data. I see this in practice within my current place of employment, the only computers allowed access to the network are those that are registered with AD, it would appear that this ties down access to the network at a device level, devices with foreign mac addresses cannot gain access to the network via ethernet connection. 

In the VLAN exercise it was demonstrated that it is beneficial to vlan off our servers separate to our client machines so that we may further control access to the most sensitive portion of our networking environment, you may also place different company departments with separate VLANs as well, this follows the methodology of least privilege and allows us to give only as much access to the users as they need to complete their jobs. This VLAN implementation would mean that if a malicious actor gained access to an ethernet port the 'operations' department, for example, they would not be able to gain access directly to the 'financial' department. 

From the demonstrations in this lab, it is easy to see how oversights in network design can lead to a possible data breach by exposing a greater amount of attack vectors to malicious actors. It is important to be meticulous in designing a company network infrastructure in such a way that reduces the potential attack vectors to minimal level & users/groups are given the least amount of privilege possible whilst still being able to effectively undertake their required functions.