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

Please spawn a virtual machine on openstack.

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. Locally, scan whatever devices you have that are connected to the same network.

Note: this is only if you are working on OpenStack and you want your instance to be easily discoverable by your colleagues.

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

$ sudo su
$ apt update
$ apt install apache2
$ echo "Hello, I am <insert your 1337 nickname here>" > /var/www/html/index.html

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

$ sudo passwd student
# just put something you won't forget for this lab, like the name of your crush ;)

• Scan the network for other hosts (try your /24 prefix, for added speed).
• 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.

• Pick the VM of your nearest colleague. Scan it for ports.
• If you don't have a willing colleague, just pick a host at random.
• Try Connect Scan, SYN Scan, Xmas Scan and others. What do you notice?

• Now, 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.
• Note: OpenStack has its own firewall; the default rules allow traffic from 10000-40000, but some other (e.g. 5001) may be blocked. everything is allowed now ;)

• Work in pairs: one of you open a UDP netcat server on your VM while the other scans it.
• What do you notice? Is the port detected as closed? How can you remedy this?
• Hint: use ”-p <port number>” for faster, directed scanning.

• 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? If solving the lab locally, your router should be a pretty easy target.

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.

• 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, the source IP address, the destination IP address, the protocol and ports.
• You can also place a rule at the very top of the chain, which includes the IP address of your workstation, so that you won’t get locked out. Everyone else might still do, but if that were the case you would be able to quickly do something about it.

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).

$ iptables -I INPUT -s ${YOUR_IP} -j ACCEPT

• Place loopback rules as early as possible.
• Place forwarding rules as early as possible.
• Use the state and connection-tracking modules to bypass the firewall for established connections.
• Combine rules to standard TCP client-server connections into a single rule using port lists.
• Place rules for heavy traffic services as early as possible. So, where should you place stateful packet inspection?

• Oh, and the most important one: try to not get locked out of your machine (if SSHing)!

• Note: This task must be done on the VM.
• Block all incoming HTTP connections to your server. Ask a colleague to test it.
• Whitelist your colleague s.t. [s]he can access your HTTP server again.

• Any security-conscious user should secure his/her workstation. The recommended way is to block all traffic and whitelist only the required connections.

• Start from the following configuration but maybe leave setting the default policies (that are applied when no rule has been matched) until after you finished adding your other rules. Just to make sure you still have access to stack overflow :)
• Hint: if working on OpenStack and you lock yourself out, remember that you can open a console from the dashboard.

# 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 --policy INPUT DROP
$ iptables --policy OUTPUT DROP
$ iptables --policy FORWARD DROP

• Add the rules to allow: outbound DNS lookups, SSH, NTP, PING requests, HTTP and HTTPS and inbound SSH.

So far you have a basic workstation setup. Users can access the web, they can find addresses, and the administrator can obtain remote access to make changes if need be.

This 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.

• Block access to Facebook by using iptables to block all DNS queries containing “facebook.com”.
• Hint: The “string” module can do packet contents matching. But what does a DNS query look like?

• NOTE: This task gets solved on the VM!
• NOTE: Make sure that the ports used are allowed by the Openstack firewall

• 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.

• Hint: We're still on the iptables section ;) Check out the “recent” module!
• Hint2: 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.

• Let's run an experiment using two docker containers:

# 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
 
# in different terminals:
$ docker run --rm -ti --entrypoint /bin/bash --name victim   ubuntu:20.04
$ docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:20.04
 
# we need two terminals for the attacker
$ docker exec -ti attacker /bin/bash

• Victim: Install packages & find out your IP address:

# install prerequisites for this task
$ apt update && apt install -y iproute2 iputils-ping netcat-openbsd
$ ip a s

• Attacker (term 1): 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 (term 2): Listen for DNS traffic from the victim:

$ tcpdump udp port 53 -nvvX

• Victim: 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
# IP forwarding inside container doesn't work :( 

The attacker's tcpdump capture should show the intercepted DNS requests ;)

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