COMP 4108 Assignment 5

Firewalls, Encrypted Tunnels, and Network Scanning

Due 11:59PM on 8-Apr-2026

55 marks total


For this assignment, you may optionally work with one other student.


Submit TWO files to Brightspace:

  1. A TAR or ZIP archive, named code_package[.tar.gz/.tar.xz/.zip], containing any requested code or script files. The names for these files will be specified in the relevant question.
  2. A PDF, named report.pdf, with your answers to assignment questions. At the top of the first page, include all of the following: your full name(s), your student number(s) (if you are working in a group, both members of the group must be listed), the course number, the assignment number, and the date.

If you are working in a group, only one member of the group needs to submit.

Setting up your environment

If you have completed the setup steps for Assignment 1, you will already have created a Linux virtual machine for this course on the SCS OpenStack platform. You will re-purpose that VM instance for this assignment.

Follow the instructions from Assignment 2 to rebuild your VM instance against the comp4108-w26-assignment-05 image. Once you have, connect to it and change your password.

Part A - Firewalls (23 Marks)

Relevant textbook sections: 10.1

This assignment will explore various aspects of computer network security from the perspective of a network administrator. At a network's perimeter, firewalls can be used in an attempt to ensure that packet traffic flows only through expected protocols, and between expected sources and destinations. Firewall rules, and the exposed services that they enable, should be auditable and regularly reviewed for any new threats they may enable.

This part involves securing a Linux host using its kernel's built-in packet-filter firewall, provided by the Netfilter framework and managed using the iptables utility. The name iptables refers to its concept of a "table", a logical structure which categorises chains of rules that handle many operations against packets, beyond just packet filtering. For the purposes of this assignment, we will only focus on chains within the filter table.

When a chain within this table is run by the kernel, administator-specified rules are evaluated in sequence to match against the packet. The "first-matching" rule will determine the target action: whether to allow (ACCEPT) or deny (type-1 DROP or type-2 REJECT) the packet, or whether to defer the decision by running a different (possibly custom) chain altogether. There are three built-in chains in the filter table that the kernel will choose from when it processes a packet: INPUT, FORWARD, or OUTPUT. All three of these chains are explained in the man page for iptables.

To inspect the effect of your packet-filter firewall, you will use the tcpdump command. This is used for capturing packets sent over the local machine's network interfaces. (The name is a slight misnomer, as it also supports UDP and ICMP protocol packets.)

You may accidentally block yourself from connecting over SSH when applying your new firewall rules. If this happens, go to Instances in OpenStack. At the right end of the row for your VM instance, click the button to the right of Create Snapshot, then, select Soft Reboot Instance in the drop-down menu.
  1. 1 Mark Use the iptables command to list all active rules in the chains belonging to the filter table. Explain the command that you ran, and provide its output.

  2. 4 Marks (total) For the following questions, use curl http://www.google.com to make an HTTP request to google.com. (Recall that cURL is a lightweight tool for transferring data over a protocol such as HTTP.)
    1. 2 Marks Add a new rule to the filter table (in the appropriate chain) that type-1 denies any outbound TCP packet to port 80. Explain the command that you ran. Then, make a curl request to google.com. Explain how your new rule impacted the request.
    2. 2 Marks Modify your rule so that it performs a type-2 deny instead. Explain any command(s) that you ran. Then, make a curl request to google.com. Explain the difference in how curl behaved compared to the rule as defined in (a).
  3. 12 Marks (total) Create a Bash script file named a-3-filters.sh. In this file, use iptables commands to replace all of the filter table's chains as follows:

    1. Flush all rules for all chains in the table.
    2. Reset the packet and byte counters for all chains in the table.
    3. Add a rule to type-1 deny incoming packets with an invalid state.
    4. Add a rule to allow incoming packets with states ESTABLISHED or RELATED.
    5. Add a rule to allow incoming TCP SYN packets destined for port 22 with state NEW.
    6. Add a rule to allow incoming ICMP packets with type echo-request.
    7. Add a rule to type-1 deny any unmatched incoming packet.

    Apply the policy by running your script using bash a-3-filters.sh.

    Finally, you will need to test (and show) that your script works, as follows. In a new terminal, use the tcpdump command to set up a packet capture process on your VM. Capture all TCP packets, moving over all network interfaces, with a destination port of 3333. Use the -w option to stream the output to file filtered-1.cap. Then, in your original terminal, use curl to make a request to http://localhost:3333, which is a basic webserver running on your VM. Ensure that the output of the curl command looks as you expected. Kill the tcpdump process in your other terminal.

    1. 5 Marks Submit your a-3-filters.sh script with your code package.
    2. 3 Marks Explain the options for the tcpdump command you executed to create filtered-1.cap. Showing excerpts from your packet capture output, which can be obtained using tcpdump -r filtered-1.cap, briefly explain how the curl command you ran helped to validate your implementation of the desired firewall policy.
    3. 2 Marks On an Ubuntu OS, all built-in chains in the filter table have a default policy of ACCEPT. Briefly describe how this affects the behaviour of the overall chain. What change(s) would you make to your script if your INPUT chain had a default policy set to DROP instead?
    4. 2 Marks Select one security principle discussed in Chapter 1.7 of the course textbook that the above-specified firewall enforces. Explain.
  4. 3 Marks (total)
    1. 1 Mark Without editing your a-3-filters.sh script, alter your active firewall such that unmatched incoming packets are type-2 denied instead of type-1 denied. Explain any command(s) you ran.
    2. 2 Marks Open a new terminal on your VM, and use the tcpdump command to again capture all TCP packets, moving over all network interfaces, which route through port 3333, but this time saving the output to file filtered-2.cap. In a new terminal, use curl to again make a request to http://localhost:3333, then kill the tcpdump process. Show excerpts from your two packet captures, filtered-1.cap and filtered-2.cap to explain how type-1 and type-2 deny rules differ at the packet level.
  5. 2 Marks Run your a-3-filters.sh script again. Then, without editing your script, add a new rule to your firewall that allows TCP SYN packets with state NEW, originating from localhost, to travel to the socket listening on port 3333. Explain any command(s) you ran after running a-3-filters.sh. Verify that your new firewall allows you to successfully curl http://localhost:3333.

  6. 1 Mark Run your a-3-filters.sh script again. Save your current firewall rules so that they are retained on reboot by storing the output of iptables-save to the file /etc/iptables/rules.v4. Run sudo reboot and reconnect to your VM, then verify that the iptables listing subcommand still returns your firewall rules intact. Submit the output of iptables-save after rebooting.
    • Note – If you somehow lose access to your VM after saving your rules, a soft reboot will be insufficient—you will either need to rebuild the instance (see the setup instructions near the top of this page), or use the OpenStack console to clear your rules. The OpenStack console for your instance can be accessed by navigating to Instances, then clicking the name of your instance, and then clicking the Console tab.
  7. 0 Marks Before continuing to Part B, delete /etc/iptables/rules.v4 and reboot your VM again. You do not have to submit anything for this question.

Part B - Encrypted Tunnels and the WireGuard VPN (13 Marks)

Relevant textbook sections: 10.3, 10.4, 10.5

This part uses tunneling protocols to provide confidentiality to other protocols using encapsulation. One such example was the use of port forwarding over the SSH protocol in Assignment 4: insecure web application data was transmitted to the browser via HTTP, but all packets were secured by an encrypted SSH tunnel using port 22. We say in this case that the HTTP protocol was encapsulated by the SSH protocol.

Although SSH serves as a lightweight tunneling protocol between a client and a server, a virtual private network (VPN) is generally more suitable for securely bridging entire networks together. A VPN protocol also sits at the Network layer (3) of the OSI model or lower, meaning that the tunnel handles all routing, and applications do not need to be aware of it. In Linux, a network interface (usually named tun0 or similar) is set up to handle this routing. The OpenVPN and IPsec protocols are prominent examples. (Carleton University uses Cisco's AnyConnect VPN, which uses a protocol called DTLS instead.)

A more recent VPN protocol (and product) is called WireGuard, promoted as a simpler alternative to IPsec. It uses asymmetric keys shared out-of-band to establish a secure tunnel. The client and server endpoints of a WireGuard tunnel each define the other as a peer. For a client seeking to gain access to the server's private network, it configures a new network interface (usually named wg0 or similar) for sending packets to its local WireGuard kernel module, to be encrypted using the server's public key and sent to the corresponding server endpoint.

The assignment submission server has a WireGuard endpoint to provide you access to a private network, 172.16.41.0/28. You will negotiate WireGuard key pairs with this server out-of-band, and configure your VM to access its private network using the protocol. One of the hosts within this private network, 172.16.41.5, is a file server that can store a text file for you once you are able to reach it.

  1. 1 Mark Use the routel command on your VM, which stands for "route list" and is part of the iproute2 project, to view the main routing table configured on your VM. (A routing table provides the OS with information about how to route to a particular IP address.) Submit the resulting output.

  2. 1 Mark Try viewing the contents of the private file server at 172.16.41.5 using an HTTP GET request by running curl --connect-timeout 3 http://172.16.41.5:5000/files?student_id=[your-student-ID], substituting the bracketed placeholder with your student ID number. The command should fail to complete successfully. Use the traceroute command, which describes each network hop that a packet must make on its way to a destination host, to demonstrate where your attempt failed: traceroute --max-hops=10 172.16.41.5. Submit a screenshot of your outputs for your curl and traceroute commands.

  3. 2 Marks Use the wg genkey and wg pubkey commands to create a WireGuard asymmetric key pair for encryption. Save these to files wg0.key and wg0.pub respectively. In your local web browser, navigate to the assignment submission website at http://134.117.225.32/a5/submit.php reusing your login credentials from Assignment 3. (Remember that it is only accessible on the Carleton VPN.) The submission form accepts a public key and returns the following pieces of information:

    • The address and port of the server's WireGuard endpoint.
    • The public key part of the server's WireGuard key pair.
    • The private network addresses the server allows you to access.
    • Your assigned static IP address.

    Paste your WireGuard public key into the form and submit it. You may re-submit if necessary (e.g., if you somehow lose the private key), but some returned values may change.

  4. 6 Marks As a superuser, create a WireGuard configuration file in /etc/wireguard/wg0.conf on your VM. This configuration file follows the INI file format, and must have two sections: an [Interface] section, which configures your wg0 network interface, and a [Peer] section, which tells WireGuard how to interact with the remote WireGuard endpoint. The man pages for the wg-quick and wg commands both have documentation on expected fields.

    Initialise your new wg0 interface by running wg-quick up wg0 as a superuser, then try your HTTP GET request using curl http://172.16.41.5:5000/files?student_id=[your-student-ID] again. (If it did not work, you can run wg-quick down wg0 to tear down the interface, then run up again once you have fixed your configuration file.) Once you are successful, submit your WireGuard configuration file as b-4-wg0.conf with your code package, redacting sensitive values where necessary.

    You must explicitly configure your WireGuard listening port to 51820. This is because the SCS network firewall has been configured to allow inbound UDP packets to only reach this port. (Normally, WireGuard chooses a random listening port.)
  5. 2 Marks Store a new text file on the private file server using an HTTP POST request. You can convert the curl command from the previous question to an HTTP POST request by adding the -X POST option to it. To provide the text file content, add the --data '[your-text]' option, replacing the bracketed placeholder with your file content. Once you are successful, execute a new HTTP GET request to the file server – you should see your new text file appear in the response. Submit a screenshot of your commands, and your latest HTTP GET response.

  6. 1 Mark Use the routel command from Q1 again. Show the new row from your main routing table in your report, and then explain its Dst and Dev values within the context of your WireGuard configuration.
    • Hint – It may also help you to try the traceroute command from Q2.

Part C - Network Mapping and Scanning (19 Marks)

Relevant textbook sections: 10.6, 11.3 (and optionally 11.6, as explained below)

In this part, we will introduce a few common Linux utilities related to network auditing and reconnaissance: ss, netcat, and nmap. These tools provide a basic toolbox for an administrator to scan both local and remote network hosts for open ports, and any exploitable vulnerabilities associated with those ports. The utilities and commands that we will use are:

You will use each of these tools to evaluate the state of your VM, and the network in which it resides.

  1. 1 Mark Use the ss command as a superuser on your VM to display all of its open and listening TCP sockets, and the processes that are using them. Submit a screenshot of the command you executed and its output.

  2. 4 Marks Your VM should have 10 active processes listening on ports 10,000 and above. These processes respond to simple text messages over the TCP protocol. Write a short Bash script that reads the output of ss to find all open and listening TCP sockets corresponding to a port greater or equal to 10000. Then, for each of these sockets, use the netcat command to send the following message to its open port: The quick brown fox jumps over the lazy dog. For each message sent, ensure that the socket's response is printed to standard output. Provide a screenshot of your script's execution output in your report, and submit the completed Bash script with your code package as c-2-netcat.sh.

    • Hints
      • To skip the ss table's header, use tail -n +2.
      • Use the awk command to retrieve a specific column from the ss table, e.g., awk '{print $1}'.
      • netcat normally expects a file as input. To emulate this without creating a file, a here document can be used to send a file-like list of lines to standard input.
  3. 6 Marks (total) For the following questions, use the nmap command on your VM to discover hosts with open services on the network that your VM is situated in.
    1. 2 Marks Run a host discovery scan using nmap as a superuser, without performing a port scan, targetting the 192.168.23.0/24 network. Expect this to take a few minutes. Explain the nmap command that you executed in your report, and submit the output as c-3-nmap.out in your code package.
    2. 2 Marks Choose one of the hosts you discovered in (a) and run a TCP SYN scan against its ports 1 to 10000. Expect this to take about a minute. Explain the command that you executed, and provide a screenshot of the output.
      • Note – Section 11.6 of the course textbook has background information on the three-way TCP handshake, which might help contextualize what nmap is doing.
    3. 1 Mark Use the same host from (b) to perform a TCP SYN scan with OS detection enabled. Provide a screenshot of the output.
      • Notenmap may not be able to exactly identify the OS, but you can assume it is a flavour of Linux.
    4. 1 Mark Assume that your results from (b) and (c) would be the same if repeated against the other hosts you found in (a). Form a hypothesis on what the hosts in the 192.168.23.0/24 network represent.
      • Hint – You might be able to strengthen your hypothesis by looking at the Network section of our OpenStack project.
  4. 4 Marks Run tcpdump on your VM to capture incoming and outgoing packets on all network interfaces, outputting the results to file tcp-fin.cap. In another terminal, start a TCP FIN scan using nmap, targetting the host localhost. Then, kill the tcpdump process in the first terminal. Once this is complete, perform the same steps, but now capturing packets from a TCP ACK scan, outputting to tcp-ack.cap. Explain the difference between the two types of scans showing excerpts from your packet capture output. Then, research and explain why a user should use one over the other, citing any material(s) you have used.

  5. 4 Marks (total) The nmap utility positions its Nmap Scripting Engine (NSE) as a powerful tool to extend its capabilities using custom user scripts. Built-in scripts such as vulners illustrate how the results from an nmap scan can be used to assess vulnerabilities on a host. The vulners script in particular tries to match any identified service and version to known vulnerabilities, and lists identifiers in the Common Vulnerabilities and Exposures (CVE) system. (Other scripts even go as far as trying to exploit the host with a specific vulnerability.)

    1. 3 Marks Run the built-in vulners NSE script with nmap's service detection feature enabled, targetting the host localhost. Set the script argument for minimum CVSS to 6 (out of a maximum 10) to filter out any lower severity vulnerabilities. Provide the exact command you executed, and a screenshot of the results. Then, from the results of the scan, choose one CVE ID and describe the vulnerability it corresponds to.
      • Note – The output of the vulners script will be filled with many duplicate entries from the proprietary Vulners database. You can pipe the output into grep "CVE" to get a list specific to CVE identifiers.
    2. 1 Mark Find your chosen CVE on the Ubuntu CVE report system. Is your VM currently safe from this vulnerability? If so, explain why. If not, explain what action would be required to secure it.