Port Scanning and Firewalls

[10pts] Part 1: Setup and Port Scanning

Setup

Install web server, telnet, SSH, and nmap on VMs

In machines it430a, it430b, it430c:

sudo apt update

sudo apt install apache2

sudo apt install telnetd -y

sudo apt install openssh-server

sudo apt install nmap

Your Task

From VM it430b, perform port scanning on host it430a using nmap. See here for details about how to use nmap (use IP address of it430a instead of the domain name).

Deliverables

In your lab report, give a screenshot of nmap port scanning results showing that ports 80, 23 and 22 are open on VM it430a. I expect something like the following:

choi@it430b:~$ nmap 192.168.172.4
Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-21 14:18 EST
Nmap scan report for 192.168.172.4
Host is up (0.00082s latency).
Not shown: 996 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
23/tcp  open  telnet
80/tcp  open  http
111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds

[10pts] Part 2: Learning How to Configuring the IPTables Firewall

In this part, you will configure your Ubuntu server's IPTables firewall on VM it430a. You can use this as a reference.

Three chains

As you see below, the command sudo iptables -L -v shows the iptable rules. Here, -L is for listing and -v is for being verbose. You can use three chains when you construct rules for the IPTables firewall.

choi@it430a:~/Desktop$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

The INPUT chain is used to set rules for packets destined for your system.
The OUTPUT chain is used to set rules for packets sent by your system.
The FORWARD chain is used when your system is acting as a router forwarding packets to and from other hosts.

Four actions

IPTables has 4 actions that can be taken on a packet

ACCEPT - Accept the packet and stop processing rules in this chain.
REJECT - Reject the packet and notify the sender that we did so, and stop processing rules in this chain.
DROP - Silently ignore the packet, and stop processing rules in this chain.
LOG - Log the packet, and continue processing more rules in this chain. Allows the use of the --log-prefix and --log-level options.

Your Task

Follow the instructions below. In your lab report, add screenshots to show that you actually followed all the instructions above.

Adding a rule (option -A). Let's add our first rules for the inbound traffic. So, we will use the INPUT channel.

The following command will allow TCP access to our server on (destination) port 1337:
```
sudo iptables -A INPUT -p tcp --dport 1337 -j ACCEPT
```
The following command will allow UDP access to our server on port 53:
```
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPT
```
The following command will deny TCP access to our server on port 3389:
```
sudo iptables -A INPUT -p tcp --dport 3389 -j DROP
```

You can write a script file to batch the above commands.

Copy the following and store it in file ipt_rules.sh.

#!/bin/bash
#ipt_rules.sh
sudo iptables -A INPUT -p tcp --dport 1337 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3389 -j DROP

Make the script file executable.
```
chmod 755 ipt_rules.sh
```
Run the script.
```
./ipt_rules.sh
```

Now, you can check how the rules have changed:

choi@it430a:~/Desktop$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:1337
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:domain
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp dpt:ms-wbt-server

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Deleting a rule (option -D). Let's delete some rule 2.

You can use the option "--line-numbers" to see the line number in the output (see below).

choi@it430a:~/Desktop$ sudo iptables -L -v --line-numbers
Chain INPUT (policy ACCEPT 2 packets, 146 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:1337
2        0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:domain
3        0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp dpt:ms-wbt-server

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1 packets, 73 bytes)
num   pkts bytes target     prot opt in     out     source               destination

The following command will delete the line 2 in the INPUT chain.

sudo iptables -D INPUT 2

After executing the above command, you will see:

choi@it430a:~/Desktop$ sudo iptables -L -v --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:1337
2        0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp dpt:ms-wbt-server

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Inserting a rule (option -I) in a specific place. Let's insert the rule we just deleted. This time, we will insert in the first line.

sudo iptables -I INPUT 1 -p udp --dport 53 -j ACCEPT

You will see:

choi@it430a:~/Desktop$ sudo iptables -L -v --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:domain
2        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:1337
3        0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp dpt:ms-wbt-server

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Flusing all rules Let's flush all of the rules so we can start over.

sudo iptables -F

choi@it430a:~/Desktop$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Deliverables

In your lab report, add screenshots to show that you actually followed all the instructions above.

[20pts] Part 3: Wrong Configuration Example

Let's first make sure of the following:

From it430a, you can access the webserver on it430b.

Likewise, from it430b, you can access the webserver on it430a.

Suppose you write a shell script ipt_rules_wrong.sh that configures your iptables firewall on VM it430a to the following specification:

From it430a, users should be able to freely access any external server.
For this, we may think about adding the following rules in the OUTPUT channel:
```
sudo iptables -P OUTPUT ACCEPT 
```
Here, -P is used to set the policy (default) rule.
Any incoming access should be denied.
For this, we may think about adding the following rules in the INPUT channel:
```
sudo iptables -P INPUT DROP 
```

Overall, we have the following scripts:

#!/bin/bash
#ipt_rules_wrong.sh
sudo iptables -P OUTPUT ACCEPT 
sudo iptables -P INPUT DROP

If you run the above script on it430a, you will see the following results:

choi@it430a:~$ chmod 755 ipt_rules_wrong.sh
choi@it430a:~$ ./ipt_rules_wrong.sh
choi@it430a:~$ sudo iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Your Task 1

From it430a, try to access the webserver on it430b. You will see an error message from Firefox. It is because the incoming packets from the webserver it430b are blocked from the following rule:
```
sudo iptables -P INPUT DROP
```
From it430b, try to access the webserver on it430a. You will see an error message from Firefox. This is consistent with our policy, and it is good.
Deliverables: Add screenshots of the results in your lab report.

Your Task 2

In order to allow the reply packets from the webserver, write ipt_rules_wrong2.sh so that the firewall allows the incoming TCP packets as long is it's source port number is 80. The results should look as follows:

choi@it430a:~$ ./ipt_rules_wrong2.sh
choi@it430a:~$ sudo iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp spt:http

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Now, let's run Firefox from it430a to it430b. It should work fine!

Security against it430b?

Let's see how nmap results look:

choi@it430b:~$ nmap 192.168.172.4
Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-21 13:08 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.15 seconds

So, it still seems that no access trials from it430b to it430 are allowed.

Oops: Spoofing packets with the source port number

However, there is a hole in the rule: accept any incoming packets with the source port 80. So, using packet spoofing, the adversary can penetrate the network. Check out the following nmap result.

choi@it430b:~$ sudo nmap --source-port 80 192.168.172.4
Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-21 13:09 EST
Nmap scan report for 192.168.172.4
Host is up (0.00080s latency).
Not shown: 996 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
23/tcp  open  telnet
80/tcp  open  http
111/tcp open  rpcbind
MAC Address: 08:00:27:50:76:69 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.38 seconds

Deliverables: ipt_rules_wrong2.sh and a screenshot proving the correctness of your script and more screenshots showing the results of running Firefox and nmaps.

[10pts] Part 4: Need For a Stateful Firewall

As we saw from the lecture, suppose a user on the internal network would like to connect to a web server as shown below.

Of course, the firewall would like the user to connect the web server on the Internet. This means that the second SYN+ACK packet from the web server should be allowed. But, then, what should be the firewall rule for it?

The port number of a client socket is randomly chosen (e.g., 25123), which means that any port number is possible. Now, when the server sends a pacekt back to the client, for a stateless firewall to accept this reply packet, it has to allow every destination port number!
Moreover, the stateless firewall check the three packets together to see whether the sequence numbers and ack numbers in the 3-way handshake are all consistent.
You could consider the source port require the source port number to be 80, but that's risky -- what if the packet has been spoofed? The above two facts imply that packet spoofing and SYN flooding will simply work!

To fix these problem, the firewall has to remember the first SYN packet so that any incoming SYN+ACK packet is legetimate.

Using conntrack module in IPTables

IPTables Firewall can be configured through a kernel moduel called "conntrack" to track these kinds of outbound connections that are initiated from the internal host.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

There are several states that conntrack considers, but here we just explain the two states we are concerned with:

ESTABLISHED: The connection has been established.
RELATED: This is a special state that helps to establish relationships amont different connections. For example, in FTP, two TCP connections have to be established; one for control and the other for data transfer. In this case, the control connection is marked as ESTABLISHED and the data transfer connection is marked as RELATED.

In summary, the above command says that the firewall looks at the incoming packet (i.e., the INPUT channel), and if this incoming packet belongs to an established (or related) connection, accept the packet without looking at port numbers or anything.

Your Task

Fix ipt_rules_wrong2.sh and write ipt_rules_fixed.sh. When running the script, the rules should look as follows:

choi@it430a:~$ sudo iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

You may want to flush all previous rules first by using the following statement:

 sudo iptables -F                          # flush all rules

Then, the namp from it430b will look as follows:

choi@it430b:~$ sudo nmap --source-port 80 192.168.172.4
Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-21 13:25 EST
Nmap scan report for 192.168.172.4
Host is up (0.00072s latency).
All 1000 scanned ports on 192.168.172.4 are filtered
MAC Address: 08:00:27:50:76:69 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 23.22 seconds

Deliverables: ipt_rules_fixed.sh and the screenshot showing the rules of iptables and the nmap result.

[20pts] Part 5: Configuring IPTables for Scenario 1

Your Task

Write a shell script ipt_rules2.sh that configures your iptables firewall on VM it430a to the following specification:

All external hosts should be able to access the web server on it430a (TCP port 80)
All external hosts, except it430c, should be able to access the SSH server on it430a (TCP port 22)
From it430a, users should be able to freely access any external server except the following:
- Access from it430a to the SSH server on it430b should be denied (TCP port 22)
- Telnet is insecure. Block it. (TCP port 23)
Any other access should be denied.

Note: Do not use the keyword REJECT but use the keyword DROP in your rules. Also, you need to have a proper understanding of why and how the conntrack module is used in the previous parts.

Note:

You can use this as a reference.

Your shell script should start as follows:

#!/bin/bash
#ipt_rules2.sh

sudo iptables -F                          # flush all rules
sudo iptables -A INPUT -i lo -j ACCEPT    # free pass for traffic with the loop back interface (lo) 

# add more rules...

Your nmap results should look something like the following:

From it430a

choi@it430a:~/$ nmap 192.168.172.5
...(omitted)...
PORT   STATE    SERVICE
22/tcp  filtered ssh
23/tcp  filtered telnet
80/tcp  open     http
111/tcp open     rpcbind

Nmap done: 1 IP address (1 host up) scanned in 1.56 seconds
choi@it430a:~$/ nmap 192.168.172.6
...(omitted)...
PORT    STATE    SERVICE
22/tcp  open     ssh
23/tcp  filtered telnet
80/tcp  open     http
111/tcp open     rpcbind

Nmap done: 1 IP address (1 host up) scanned in 1.57 seconds

From it430b:

choi@it430b:~/$ sudo nmap --source-port 80 192.168.172.4
...(omitted)...
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 4.09 seconds

From it430c

choi@it430c:~/$ sudo nmap --source-port 80 192.168.172.4
...(omitted)...
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds

Deliverables

Run the following and add the results in the lab report.

sudo iptables -L -v --line-numbers (explain why you chose to come up with the rules)
nmap from it430a to it430b and it430c (screenshots)
nmap from it430b to it430a (screenshot)
nmap from it430c to it430a (screenshot)

Of course, the results should be consistent to the above specification.

[20pts] Part 6: Configuring IPTables for Scenario 2

Write a shell script ipt_rules3.sh that configures your iptables firewall on VM it430a to the following specification:

All external hosts should be able to access the web server on it430a (TCP port 80)
All external hosts, except it430c, should be able to access the SSH server on it430a (TCP port 22)
From it430a, no outgoing connections allowed. We are hardening the system so that there will be no data exfiltration to the outside.
Any other access should be denied.

Tips:

For the OUTPUT channel, your rules should allow the packets due to the inbound connections initiated from an outside host specifically for situations 1 and 2 in the above.
Carefully think about the default action for each of the INPUT and OUTPUT channels.

Notes:

Your shell script should start as follows:

#!/bin/bash
#ipt_rules3.sh

sudo iptables -F                          # flush all rules
sudo iptables -A INPUT -i lo -j ACCEPT    # free pass for traffic with the loop back interface (lo) 

# add more rules...

Think about how (and where) to use the conntrack module to satisfy the specification.

Your nmap results should look something like the following:

From it430a

choi@it430a:~/$ sudo nmap --source-port 80 192.168.172.5
Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-21 14:01 EST
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 192.168.172.5, 16) => Operation not permitted
Offending packet: TCP 192.168.172.4:80 > 192.168.172.5:1723 S ttl=42 id=37542 iplen=44  seq=197578923 win=1024 
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 192.168.172.5, 16) => Operation not permitted
(...omitted...)
Nmap scan report for 192.168.172.5
Host is up (0.00086s latency).
All 1000 scanned ports on 192.168.172.5 are filtered
MAC Address: 08:00:27:6F:C1:40 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 34.94 seconds

choi@it430a:~$/ sudo nmap --source-port 80 192.168.172.6
Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-21 14:06 EST
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 192.168.172.6, 16) => Operation not permitted
Offending packet: TCP 192.168.172.4:80 > 192.168.172.6:554 S ttl=44 id=21516 iplen=44  seq=2695886880 win=1024 
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 192.168.172.6, 16) => Operation not permitted
(...omitted...)
Nmap scan report for 192.168.172.6
Host is up (0.00069s latency).
All 1000 scanned ports on 192.168.172.6 are filtered
MAC Address: 08:00:27:13:F0:C6 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 34.94 seconds

From it430b:

choi@it430b:~/$ nmap 192.168.172.4
...(omitted)...
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 4.09 seconds

From it430c

choi@it430c:~/$ nmap 192.168.172.4
...(omitted)...
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds

Deliverables

Run the following and add the results in the lab report.

sudo iptables -L -v --line-numbers (explain why you chose to come up with the rules)
nmap from it430a to it430b and it430c (screenshots)
nmap from it430b to it430a (screenshot)
nmap from it430c to it430a (screenshot)

Of course, the results should be consistent to the above specification.

[10pts] Lab Report and Submission

Write a lab report by using the provided template.

Your lab report should contain:

All the deliverables to be contained in the lab report.
The writing quality of your explnation will matter.

~/bin/submit -c=IT430 -p=lab07 *.sh lab07_report.docx