• Port Scanning (nmap)
• Traffic filtering / manipulation (iptables)
• Port knocking
• Man in the Middle Attack

Please spawn a virtual machine on openstack.

• To make it easier for others to identify your VM, please run this command:

echo "<h1>Hello, I am "<insert your 31337 name here>" </h1>" | sudo tee /var/www/html/index.html

• To prevent main SSH account trolling, you might want to change the password of your account ASAP:

sudo passwd student
# set an unbreakable password, but make sure you won't forget it until the end of the lab!

• After that, enable the hacker guest account for your enemies colleagues to use (and don't cheat!):

# let the h4x0rs in (enables the account):
sudo usermod -e -1 -U hacker

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:

• Steal sensitive information like passwords or credit card details.
• Disrupt services through attacks like DDoS, which can overwhelm and shut down systems.
• Take control of systems via malware or open ports.

Examples of common attacks include:

• Port Scanning: Identifies open entry points, similar to burglars checking for unlocked windows.
• Man-in-the-Middle (MitM) Attacks: Intercepts sensitive data, like passwords, often using tactics like “Evil Twin” Wi-Fi traps in public spaces.
• Traffic Manipulation: Takes advantage of poorly configured systems to enable brute force attacks, data theft, or malware injection.
• Port Knocking: Adds stealth authentication, granting access only after a specific sequence is followed.

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

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.

• Why would you do this? As a defender, you scan your network to identify potential vulnerabilities, misconfigurations, or services that shouldn't be accessible. It’s a proactive way to patch security gaps.
• Why would an attacker do this? Attackers scan to map out your network, identify potential entry points, and target systems running vulnerable or misconfigured services.

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.

What You’ll Do

You’ll use the nmap tool to:

1. Discover devices on your network.
2. Identify open ports on specific machines.
3. Experiment with different scan types to understand how attackers might probe your systems.

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

STEP 1: Scan the network with nmap - ping scan

• What It Does: Sends ICMP Echo Requests (pings) or TCP/UDP probes to detect devices on the network.
• Strengths: Works across subnets and can identify devices beyond the local network.
• Limitations: May miss devices that block ICMP or TCP probes.

 TASK: Run a ping scan to discover active hosts in your network using nmap (you can use CIDR notation! Remember OpenStack's network prefix?).

STEP 2: Scan the network with arp scan

• What it does: Sends ARP requests to resolve IPs to MAC addresses.
• Strengths: Extremely accurate within the local subnet; detects devices even if ICMP is blocked.
• Limitations: Limited to the local network (Layer 2) and cannot scan beyond the subnet.

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

*If you are doing this 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!).

• Pick the VM of your nearest colleague. Scan it for ports.
• Work in pairs: one of you open a TCP netcat server on a non-standard port (e.g. 10002) on your VM while the other scans it.
• If you don't have any willing colleague, just pick a host at random.

• Try TCP Connect Scan, SYN Scan, Xmas Scan and others. What do you notice?
• Hint: use -p <port range> for faster, directed scanning.
• Do the same for UDP: open a netcat -u server on your VM while the other scans for it.
• Note: OpenStack has its own firewall behind each VM; the default rules allow traffic from 10000-40000, but others (e.g. 5001) may be blocked. everything should be allowed now ;)

• Try running OS detection with nmap on some of the detected hosts. Can it correctly identify any of them? What about services running on open ports and their versions?

Iptables is an interface to the Netfilter firewall that is built into the Linux kernel. It provides an administrator with an interface to add, remove, and modify packet rules.

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

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

• Put specific rules at the top of the policy and generic rules at the bottom.
• The more criteria you specify in the rule, the less chance you will have of locking yourself out. There are plenty of ways in which you can be more specific, such as specifying the input or output interface (-i | -o), the source IP address (-s), the destination IP address (-d), the protocol and ports (-p <tcp|udp> --dport|sport <number>.
• First, place a rule at the very top of the INPUT chain, which includes the IP address of your workstation (in our case, the fep will originate your ssh packets to OpenStack), so that you won’t get locked out. A rule for whitelisting your IP address at the top of the policy looks like this. Notice that Insert (-I) was used instead of Append (-A), because we want this rule to be the first.

  iptables -I INPUT -s "<FEP IP address>" -j ACCEPT

• Add whitelist or blacklist rules for the types of traffic you use (or don't want to receive); you will do that for the next subtask! You should use the INPUT chain for that.
• You should use the connection tracking module(s) to bypass the firewall for already established (usually, outgoing) connections, otherwise replies cannot be received (if you drop them in INPUT).

• For this task: work in pairs!
• Ask for your colleague's VM IP address. Using curl, read the message from his http server (check man / some examples if you never used it).
• See if you can ssh into it using the hacker:student credentials! When successful, send a broadcast message

  hacker@<colleague-VM>$ wall "Wazzaap?"

• Run tcpdump to see where ssh packets come from (make sure to ignore the ones coming from fep):

  tcpdump -i eth0 'host not <FEP's IP address here>'
  # note the source IP of the other OpenStack VMs connecting to you!

• We want to stop the spam, so blacklist the ssh (TCP port 22) and http (TCP port 80) from any other OpenStack VMs addresses (recall the CIDR range?). Be extra careful not to ban yourself!
• You may still wish for your more civilised friends to be able to connect back to you. Whitelist them again by adding a ALLOW rule before the ones dropping the packets!

• Any security-conscious user should secure his/her workstation. The recommended way is to block all traffic and whitelist only the required connections.
• Note: this task is for reference only! But check it out: it is a very good policy if you had it on a laptop that you use with public wifi hotspots (such as the ones offered by coffee shops or hotels), and you would not want anybody to compromise it. The policy would do a good job because it allows very few things in and out. If it doesn’t know what to do with a packet, the packet gets dropped automatically, because you set that up at the very beginning in the policy (iptables … -P DROP):

# 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

• Block access to Facebook by using iptables to block all DNS queries containing “facebook.com”.
• Hint: The string iptables module can do packet contents matching (sudo iptables -m string -help). But what does a DNS query look like?
• Note: you can supply a hex string parameter with the syntax |HH HH HH …|<plaintext> (e.g., hello|20 57 6F|rld) to match binary contents of a packet! Also choose a string matching algorithm!

• Start a netcat TCP server on 31337 and implement a port knocking scheme to open it!
• Ask a colleague to scan your port. It should be seen as closed / filtered.
• Then ask that colleague to knock the correct port sequence and connect to your netcat server.

• Check out the recent iptables module!
• Reference: https://wiki.archlinux.org/index.php/Port_knocking

The ARP protocol is widely used for translating L3 (IP) addresses into L2 (data-link) addresses.

Unfortunately, it suffers from a critical security vulnerability: due to its unauthenticated nature, a destination machine has no way of determining whether a ARP reply is valid, so an attacker can forge ARP packets and tell a victim PC to associate the router's IP address to the attacker's MAC address, such that it will send all traffic through the victim's machine.

• We will use two Docker containers to simulate a vulnerable local network (OpenStack filters ARP packets, so you won't be able to do this there).

# turn on IP Forwarding -- for the attacker (inherited from host)
# containers don't have permission for this and we don't want to bother with capabilities
sudo sysctl -w net.ipv4.ip_forward=1
 
# Open a "Victim" terminal (on your VM):
docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04
# Open an "Attacker" terminal (also on the same VM):
docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:22.04
 
# we need two terminals for the attacker (for the tcpdump later)
# so... in a third terminal, spawn a Docker exec shell:
docker exec -ti attacker /bin/bash

• Victim terminal (note: we're inside a container): install prerequisites & find out the IP address given by Docker:

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

• Attacker terminal: install prerequisites & establish yourself as the Man in the Middle using ARP Spoofing:

# install prerequisites for this task
apt update && apt install -y dsniff tcpdump iproute2 iputils-ping
 
# start poisoning the host's ARP cache
arpspoof -i <INTERFACE> -t <VICTIM_IP> <GATEWAY_IP> -r

• Attacker terminal: Listen for DNS traffic from the victim:

tcpdump udp port 53 -nvvX

• Victim terminal: Open a netcat server and listen for content

# check ARP table (your gateway's MAC should be the attacker's)
ip nei sh
# ping your favorite website
ping my.secretwebsite.com
# Unfortunately, IP forwarding inside container doesn't work :(

The tcpdump capture on the Attacker terminal should show the intercepted DNS requests ;)

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