Table of Contents

Lab 08 - Network Security

Objectives

Preparation

Please spawn a virtual machine on openstack.

You need to prepare the playground:

echo "<h1>Hello, I am "<insert your 31337 name here>" </h1>" | sudo tee /var/www/html/index.html
sudo passwd student
# set an unbreakable password, but make sure you won't forget it until the end of the lab!
# let the h4x0rs in (enables the account):
sudo usermod -e -1 -U hacker

Leave hacker's password unchanged!

No trolling / spamming yet, please!

Overview

Think about how much we depend on networks: sending emails, shopping online, streaming Netflix, or storing personal and professional data. These networks are the backbone of our online lives. But with that power comes risk — attackers can exploit weaknesses to:

Examples of common attacks include:

This lab combines both offensive (attacking) and defensive (securing) techniques to help you understand both perspectives.

Tasks

[30p] 1. Port Scanning

You can read here more about port scanning techniques.

Port scanning is a fundamental technique in cybersecurity, both for attackers and defenders. It allows you to identify what services a system is running and determine potential vulnerabilities. Think of it as a building where every room has a door. Some doors are open, some are locked, and some are guarded. Port scanning is like walking down the hallway, checking which doors are open and what’s behind them.

Real-World Example: The Mirai Botnet Attack (2016) is a notable example of port scanning used maliciously. Attackers used port scanning to identify IoT devices ( with open Telnet (port 23) and weak credentials, compromising them to create a botnet. This botnet launched massive DDoS attacks, including the one on Dyn (a company that controls much of the internet’s dns infrastructure), disrupting major websites like Twitter and Netflix. The attack highlighted the importance of securing open ports, updating firmware, and using strong credentials to prevent similar exploits.


For the following exercises, you should be working on an OpenStack VM, scanning for the VMs of your colleagues.

[10p] Discover Devices on the Network

STEP 1: Scan the network with nmap (using ping scan)

TASK: Run a nmap with ping scan to discover active hosts in your network using nmap (you can use CIDR notation! Remember OpenStack's network prefix?). Hint: Search on google how to run a “nmap with ping scan option”

STEP 2: Scan the network with arp scan

TASK: Run an ARP scan to detect devices on the local subnet

TASK: If you are doing this exercise with colleagues, try to find each other's hosts (note: since you all have the same VM images, try to find one with the same ports!).

[10p] Scan a Machine for Open Ports on TCP/UDP (work in pairs)

STEP 1: Set up a TCP netcat server

TASK: Work in pairs. One person opens a TCP server on their VM using netcat, while the other scans for it. Choose a non-standard port (e.g., 10001). Hint: use -p <port range> for faster, directed scanning.

STEP 2: Scan the TCP Server with nmap

TASK: Use 'nmap' to run TCP Connect, SYN, and Xmas scans on the target IP and observe the results.

STEP 3: Set up an UDP netcat server

TASK: Work in pairs. One person opens an UDP server on their VM using netcat, while the other scans for it. Choose a non-standard port (e.g., 10002). Hint: use -k when opening the server to allow multiple connections

STEP 4: Scan the UDP Server with nmap

TASK: Use `nmap` to perform an UDP scan on the target IP and observe the open port.

[10p] OS/Version scans

STEP 1: Perform OS Detection with nmap

TASK: Use `nmap` to perform OS detection on your partner’s VM or another detected host. Observe the detected OS and note its potential vulnerabilities.

STEP 2: Perform Service Version Detection with nmap

TASK: Use `nmap` to detect service versions on the same target. Match the service version to potential vulnerabilities.

Explore CVE and MITRE ATT&CK for Additional Context

[30p] 2. Iptables

Here's an iptables cheeatsheet to help you get started.

Iptables is a command-line utility that acts as an interface to the netfilter firewall built into the Linux kernel. Think of it as the security checkpoint at a building. Guards check who’s entering, leaving, and passing through, ensuring only authorized people (or data packets) are allowed. With iptables, you establish these security checkpoints for your system's network traffic.

Real-World Importance

Real-World Examples: A real-world example highlighting the consequences of misconfigured iptables rules is the “IptabLes and IptabLex botnet attacks”. In 2014, security experts at Akamai-Prolexic discovered a botnet dubbed “IptabLes and IptabLex” that infected and exploited poorly maintained Linux servers to run large-scale Distributed Denial of Service (DDoS) attacks.

Example in Action: Imagine a situation where a server is being spammed with SSH login attempts from a malicious IP. Using iptables, you can block this IP address immediately:

 iptables -A INPUT -s <malicious-IP> -p tcp --dport 22 -j DROP

[5p] Best practices

Here are some best practices when writing firewall rules (read them):

Try to not get locked out of ssh-ing your virtual machine! Double-check the rule before you add it to a iptables chain (always ask yourself: does it match a broad range of packets / will it filter my SSH traffic from fep)!

[10p] Secure Your VM from Unwanted SSH/HTTP Traffic (work in pairs)

STEP 1: Access Your Colleague’s VM and Observe Traffic

TASK: Work in pairs. Follow these steps:

  1. Ask your colleague for their VM IP address.
  2. Use `curl` to connect to their HTTP server and display the server’s response
  3. Attempt to SSH into their VM using the credentials `hacker:student`
  4. If successful, send a broadcast message to your colleague’s system
    hacker@<colleague-VM>$ wall "Wazzaap?" 

STEP 2: Monitor Incoming Traffic with tcpdump

TASK: Use the 'tcpdump' tool to observe SSH connections to your machine:

  1. Run the following command to monitor all incoming traffic except packets from the FEP:
    tcpdump -i eth0 'host not <FEP's IP address>'
  2. Watch the output and note the source IPs of the OpenStack VMs connecting to your machine.
  3. Record the IPs for later use when setting up firewall rules.

STEP 3: Block Unwanted SSH and HTTP Traffic

TASK: Use `iptables` to block SSH and HTTP connections from unauthorized machines:

  1. Use the OpenStack CIDR range to block SSH (TCP port 22) and HTTP (TCP port 80) traffic:
  2. Double-check your own IP is not in the blocked range to avoid locking yourself out.

STEP 4: Allow Trusted Colleagues to Access Your VM

TASK: Add rules to allow SSH and HTTP traffic from your colleague’s IP:

  1. Insert the rules before the block rules
  2. Verify the rule placement using:
    iptables -L -v

If you want to stop `wall` messages from appearing on your terminal, check out the `man mesg` command.

Reminder: If you're using nested shells (e.g., switching from `student` to `root` using `su`), ensure you run `mesg` in the original tty spawned by SSH.

[5p] Workstation Firewall

Workstation Firewall Script

Workstation Firewall Script

# Remove any existing rules from all chains
iptables --flush
 
# Allow traffic on the loopback interface
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
 
# Allow SSH traffic
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
 
# Accept any related or established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Set the default policy to drop
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
 
# Outbound DNS lookups
iptables -A OUTPUT -o ens3 -p udp -m udp --dport 53 -j ACCEPT
 
# Allow outbound SSH
iptables -A OUTPUT -o ens3 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
 
# Outbound PING requests
iptables -A OUTPUT -o ens3 -p icmp -j ACCEPT
 
# Outbound Network Time Protocol (NTP) requests
iptables -A OUTPUT -o ens3 -p udp --dport 123 --sport 123 -j ACCEPT
 
# Outbound HTTP and HTTPS
iptables -A OUTPUT -i ens3 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -i ens3 -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT

[10p] DNS Blocking

Task: Block access to Facebook by dropping all DNS queries containing “facebook.com.”

[0p] Task E: Port Knocking (Bonus)

Task:

  1. Start a `netcat` TCP server on port `31337`.
  2. Configure a port knocking scheme so the server remains invisible (closed/filtered) until the correct sequence of port “knocks” is performed.
  3. Ask a colleague to scan your port. It should appear closed or filtered.
  4. Provide your colleague with the correct knock sequence and confirm they can access the `netcat` server after performing it.

[30p] 3. Man in the Middle

The Address Resolution Protocol (ARP) is used to map IP addresses (Layer 3) to MAC addresses (Layer 2) on local networks. However, ARP is inherently vulnerable because it lacks authentication. Attackers can exploit this weakness by forging ARP responses, tricking a victim into associating a legitimate IP (e.g., the router) with the attacker’s MAC address. This allows the attacker to intercept and manipulate network traffic, a classic example of a Man in the Middle (MitM) attack.

Think of this as you’re mailing a letter to your bank. A middleman secretly intercepts the letter, opens it, reads all your private information, and replaces it with their own fake letter before sending it to the bank. You never realize your communication was tampered with, but the middleman now has all your sensitive details. This is essentially what a Man-in-the-Middle attack does in a digital network.

Real-World Example: The 2015 Superfish Visual Discovery vulnerability in Lenovo laptops exposed millions of users to Man-in-the-Middle attacks by allowing attackers to intercept and decrypt HTTPS traffic, highlighting the dangers of pre-installed software and weak security practices.

Is MitM Still Used? Yes, Man-in-the-Middle attacks are still used today and remain a serious threat. Their methods, however, have evolved with the advance in technology

Mitigation Today:


For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks.

[20p] ARP Cache Poisoning

STEP 1: Set up the environment

Create a simulated network with Docker containers to demonstrate how ARP cache poisoning works in a controlled environment.

sudo sysctl -w net.ipv4.ip_forward=1
docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04
docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:22.04
docker exec -ti attacker /bin/bash

STEP 2: Configure the victim container

Prepare the victim machine to simulate a normal user in the network.

apt update && apt install -y iproute2 iputils-ping netcat-openbsd
ip a sh

STEP 3: Launch the ARP spoofing attack

Perform ARP cache poisoning from the attacker container to impersonate the gateway (router) for the victim.

apt update && apt install -y dsniff tcpdump iproute2 iputils-ping
arpspoof -i <INTERFACE> -t <VICTIM_IP> <GATEWAY_IP> -r

STEP 4: Verify the Setup

Observe the impact of ARP poisoning and verify the attack's success.

 tcpdump -i <INTERFACE> -nvvX

Check the victim’s ARP table to confirm the gateway MAC address has been replaced with the attacker’s MAC. The victim’s traffic should now flow through the attacker.

 ip nei sh

[10p] Test Implementation

STEP 1: Monitor DNS traffic from the victim

Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information.

tcpdump udp port 53 -nvvX

STEP 2: Simulate victim activity

Generate network traffic from the victim to verify interception. Observe DNS traffic in the tcpdump output to confirm interception.

 ip nei sh
 ping my.secretwebsite.com 

Mitigation and Defense

[10p] 4. Feedback

Please take a minute to fill in the feedback form for this lab.