Lab 14

Lab 14

This lab was quite cool, it involved using a rogue DHCP server to get devices to have bad configurations. It also showed ways to deal with this sort of attack with 

Exercise 1

In this exercise I set up a fake website that affected clients would see instead of the legitimate site. I then got the legitimate site open.

 

Exercise 2

In this exercise I set up bad DNS service and configured the rogue DHCP server to prepare for the next step. I did not run the DHCP server yet.

Exercise 3

In this exercise I ran the attack. First off I ran a script that starved all DHCP servers on the network. This is why I haven't started the rogue DHCP server because the script would starve it as well. Once the script finishes, the legitimate DHCP server will have all its entries filled so the only server able to hand out addresses is the rogue one. To have that happen, we start the rogue DHCP server and renew the address of the client. Once the client has the new address and DNS settings, if I access the classroom.local site, it will give me a malicious site with a dangerous download.

I then turned off the attack for the next exercise.

Exercise 4

In this exercise I implemented DNSSEC. This means that devices on my domain have signed DNS records so even if rogue DHCP server gives bad DNS configurations, it will only use the signed DNS records. As can be seen, the fake website can't be accessed because the DNSSEC is stopping the client from using the bad DNS service.

Exercise 5

In this exercise I changed the switch I was using to one that did not allow MAC address spoofing, this meant that the attack doesn't work because I can't starve the DHCP server. I then got a legitimate address on the client and was able to access the legitimate website.

Showing that I have removed all bad leases caused by the DHCP starvation attack. The client then got an address from this pool.

Lab 13

Lab 13

For this lab, I attempted to get everything working, but there seems to be issues with the promiscuous mode on the INT03 switch. I couldn't seem to get any results even after trying a few times and testing different configs, so I decided to move on and leave this lab unfinished.

Lab 12

Lab 12

This lab was a tricky one. I spent a lot of time to get this to work; too much time. The purpose of this lab was to configure a firewall and perform attacks on it.

Exercise 1

This first exercise involved looking at the pfSense web interface. I looked at various things and tested that www.web.local could be tracerouted with the mtr tool (This didn't initially work and required some fiddling with DNS settings on the DC). I also set up logging.

Exercise 2

In this exercise I looked at firewall rule settings. I set up a redirection and a blocking rule on the firewall at viewed the results.

Exercise 3

In this exercise I tested the Suricata tool and saw the results of its logging.

Exercise 4

In this exercise I tested how the firewall would react to a DoS attack. As can be seen in Suricata, the Kali machine that the DoS attack is occuring on is blocked. The firewall does suffer from higher bandwidth and CPU utilization though, so if the DoS attack was strong enough it would use all the resources and stop the firewall from functioning properly. 

I also tested another DoS attack that made the firewall unuseable.

 

Critical Thinking

Looking back on this lab, I spent way too much time trying to get stuff working. Having the forum with other classmates' contributions really helped me get through in the end. It really showed how not everything will work as intended, so you should always be prepared to spend time troubleshooting and problem solving.

Lab 11

Lab 11

In this lab  I looked at how to perform a man in the middle attack, and I worked with subnets. The lab was also supposed to involve VLANs, but our lab environment did not allow is to use VLANs. Instead we just used 2 seperate switches to achieve the same results.

Exercise 1

For this first exercise, I had to set up a secure HTTPS website.

Exercise 2

In this exercise I set up a man in the middle attack. This is basically a proxy that forces all the traffic through itself. Using this I can see all the traffic travelling between machines. Since the traffic here is HTTPS traffic secured with TLS, I can't see the contents.

Exercise 3

This exercise is where I get past the TLS encryption to see the contents of the traffic. Using sslstrip I can get an HTTP version of the site allowing me to see unsecured contents.

Exercise 4

In this exercise I set up network segmentation. Instead of using VLANs I just used 2 seperate switches. 

When I was setting up the Vyos router, config.bare did not exist. I figured out that it must just load a bare configuration without any network configuration, so I turned to find another way to reset the configuration to have nothing. One option was to manually remove configurations, but the easiest way was to load the default configuration with this command: 

config load /opt/vyatta/etc/config.boot.default

I then did the rest of the exercise and had everything communicating between subnets.

Exercise 5

For this exercise I used ARP poisoning to sniff traffic passing through the default gateway, so the Vyos router. 

Critical Thinking

Looking back on this lab, it really highlighted how simple it is to perform attacks on the network, and it shows how important using secure protocols and other methods to secure a network are. Businesses should make sure that their networks are designed in a secure way to reduce the chance of malicious attacks happening. This exercise also really shows how dangerous a normal unsecured network is. If you connect to public WiFi or similar, anybody could be intercepting your traffic and stealing information. Everybody should be taking measures to make sure that their traffic is properly secured.

Lab 10

Lab 10

This lab was all about managing accounts in Active Directory.

Exercise 1

In this exercise, I had a look at the processes running on a system. Each process runs at a different privilege level. The importance of this is that malware runs at the privilege level of the user that is logged on. This is where least privilege comes in. If you give your users as little privilege as possible, it makes it less likely for any malware to cause major damage.

Exercise 2

In this exercise I looked at some of the default accounts and groups in Active Directory.

Exercise 3

In this exercise I renamed the administrator account and made a dummy account. The goal is that the dummy administrator account would be compromised instead of the true administrator account. This method is not perfect though because the account SID remains the same, so hackers could identify the true administrator account using the SID.

I also delegated some control of  UsersOU to the user 'Sam'.

Exercise 4

In this exercise I set up an audit policy and changed the password requirements for administrative accounts.

Exercise 5

In this exercise, I looked at how the restrictions I created last exercise affect what a user can do.

Questions:

In the "Administrators Properties" dialog, click the Apply button - does it work? - No

Can you access any of the snap-ins? - No

Exercise 6

In this exercise I set up a file share on the network, then I assigned permissions and auditing.

Critical Thinking

Looking back at this lab, the focus was on managing the privileges of accounts. This is very important for businesses to manage properly, because if a regular employee has admin privilege for example, they could maliciously or accidently make damaging changes to the network. It also adds a vector of attack for malware. If an employee downloads a malicious program from an email or a dodgy website, it will run at their privilege level. 

Removing all privilege except for what is needed reduces the chance of many different things going wrong. The principle of least privilege is highly important.