Lab 08 - Network Security
Objectives
Preparation
Tasks
[30p] 1. Port Scanning
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.
[0p] Task A: Preparation (optional)
Note: this is only if you are working on OpenStack and you want your instance to be easily discoverable by your colleagues.
$ sudo su
$ apt update
$ apt install apache2
$ echo "Hello, I am <insert your 1337 nickname here>" > /var/www/html/index.html
$ sudo passwd student
# just put something you won't forget for this lab, like the name of your crush ;)
[5p] Task B: Network scan
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.
[10p] Task C: TCP port scan
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 ;)
[10p] Task D: UDP port scan
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.
[5p] Task E: OS / Version scans
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.
[30p] 2. Iptables
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.
[0p] Task A: Best practice
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?
[10p] Task B: Server Firewall
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.
[10p] Task C: Workstation Firewall
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.
[10p] Task D: DNS blocking
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?
[0p] Task E: Port knocking (yes, it's optional)
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.
[30p] 3. Man in the Middle
If you are solving this lab on Windows using WSL, note that you most likely won't be able to implement the MitM attack. Docker does not run in the Linux VM, but as a Windows Service. Since Windows is responsible for assuring network connection to the containers (using something other than brctl and network namespaces) and has MitM mitigation techniques implemented, the ARP poisoning will fail. Also, you won't have (easy) access to the Windows ARP cache from WSL.
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.
[20p] Task A: ARP Cache Poisoning
# 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
# install prerequisites for this task
$ apt update && apt install -y iproute2 iputils-ping netcat-openbsd
$ ip a s
# 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
[10p] Task B: Test Implementation
Attacker (term 2): Listen for
DNS traffic from the victim:
$ tcpdump udp port 53 -nvvX
# 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 ;)
[10p] 4. Feedback