Lab 08 - Network Security

• 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
# you may also append a slogan (choose one or make your own):
echo '<h3>All your base are belong to us!</h3>' | sudo tee -a /var/www/html/index.html
echo '<h3>We will rock you!</h3>' | sudo tee -a /var/www/html/index.html
echo '<h3>Am talent și nu mă las!</h3>' | sudo tee -a /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

Read here about port scanning techniques.

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

• Scan the network for other hosts (you can use CIDR notation! Remember OpenStack's network prefix?).
• Either a ping scan (nmap) or an ARP scan (arp-scan) should be fine. Is there a difference?
• If you are doing this task 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.