Project Objective

This project followed the scenario described below:

A new water treatment facility has a fully automated system. Unfortunately, the water treatement facility was hacked, and the network has been infiltrated. The water cannot be reliably treated anymore, so a penetration test is necessary to determine and resolve the network vulnerabilities.

Network Topology and Operation

Workers from the water treatment plant want to monitor the water pump activity. PumpPLC is a low-level computer that directly controls the water treatment plant pumps. Periodically, PumpMon (Pump Monitor) transfers a logfile from PumpPLC to PumpMon, which includes details of the pump operation. This logfile is then transferred from PumpMon to Web01 (a web server) that hosts the pump logfiles so the public can view the water treatment activity. The public (TargetWindows01) can access these logfiles by sending an HTTP request through their browser to Web01 (the webserver).

Baseline Network Traffic

Baseline network traffic serves as a control group for network security analysis. This traffic represents any communications over a network under ideal circumstances.

To capture this traffic on PumpMon, a GNU/Linux machine, I used the tcpdump command.

Syntax of the tcpdump command is as follows:

                
Example:
tcpdump -w BC_PumpMon_Baseline1.pcap -n -s 65535 -i ens5 not port 22

Where:
-w writes the output to a file
-n records IP addresses instead of hostnames,
–s 65535 records entire packets instead of just header information
-i ens5 uses the ethernet network interface for monitoring
not port 22 ignores SSH traffic
                
            

FTP from PumpPLC to PumpMon

Here, the PumpMon computer uses FTP (the File Transfer Protocol) to access a logfile from PumpPLC

FTP from PumpMon to Web01

Next, the PumpMon computer uses FTP to transfer the logfile from PumpMon to Web01 so it can be hosted on the webserver.

Browsing Web01 from TargetWindows01

After the logfile has been transferred to the webserver (Web01), the web interface can be accessed by a user using their web browser.

Malicious Network Traffic

Once baseline network traffic was collected, I could simulate attacks on the network and gather malicious network traffic. Keep in mind that I had permission to perform these attacks through my curriculum.

Network Scan from TargetWindows01

A network scan is often used by network administrators, but also by malicious attackers. This practice allows identifying all devices on a network. Furthermore, a network scan can identify open ports on devices. These ports correspond to services such as FTP, HTTPS, HTTP, and SSH. If these services are not configured properly, a hacker may be able to gain unauthorized access to a system within the network.

The network scan results are shown below: (required services for normal operation are highlighted green)

Browsing Web01 from PumpMonitor

PumpMonitor should not be browsing Web01 as PumpMonitor is a headless GNU/Linux machine and Web01 is intended to be used for end-users, not internal browsing.

FTP from Web01 to PumpPLC

This transfer raises suspicions as Web01 should not be able to send a file to PumpPLC. If Web01 were compromised, a hackker could send malicious files to the low-level PumpPLC, which could in turn affect the water-treatment facility pumps.

Comparison of Baseline and Malicious Network Data Filesizes

The combined Wireshark PCAP capture files contained 11.41 MB of capture data. In contrast, the baseline capture files contained only 53 KB of capture data. This demonstrates that the malicious actions resulted in large quantities of network traffic, which could easily be identified.

Securing the Network

The network can be secured by using a host-based firewall. A host-based firewall allows or denies network traffic on each device in a network.

The rules below should be applied:

To set up this host-based firewall, I used the iptables command. The iptables command follows the following syntax:

iptables -A INPUT -p <PROTOCOL> -s <SOURCE_IP> --dport <DESTINATION_SERVICE_PORT> -j <ACCEPT/DENY>
Where:
-A INPUT adds a rule for inbound traffic
-p <PROTOCOL> filters by protocol
-s <SOURCE_IP> adds the source IP address for the rule
--dport <DESTINATION_SERVICE_PORT> defines the port used by the service
-j <ACCEPT/DENY> defines whether to accept or deny the network traffic

Other useful arguments:
iptables -L INPUT lists inbound rules
iptables -F INPUT clears ("flushes") inbound rules
iptables --policy INPUT DROP adds an ANY/DENY rule
iptables-save will save the rules

Examples for setting up the rules in the above table:
sudo iptables -F INPUT
sudo iptables -A INPUT -p tcp -s 10.2.0.8 --dport ssh -j ACCEPT
sudo iptables -A INPUT -p tcp -s 10.2.0.8 --dport ssh -j ACCEPT
sudo iptables -A INPUT -p tcp -s 10.2.0.8 --dport ssh -j ACCEPT
sudo iptables -A INPUT -p tcp -s 10.2.0.8 --dport ssh -j ACCEPT
sudo iptables -A INPUT -p tcp -s 10.2.0.8 --dport ssh -j ACCEPT
sudo iptables --policy INPUT DROP
sudo iptables-save
            

Network Scan After Updating the IP Table

This shows that only SSH is available from TargetWindows01. FTP can no longer be used from TargetWindows01 to PumpPLC.

Reflection: Network-Based Firewalls vs. Host-Based Firewalls

There are network firewalls and host-level firewalls. A network-based firewall controls traffic for the entire network, while a host-based firewall is different on each host. A host-based firewall controls traffic to and from its host. The latter increases configuration options within a network. However, it is more difficult to monitor all the host-based firewalls on a network than a single network-based firewall. Additionally, changing multiple host-based firewalls is more difficult than changing a single network-based firewall as each device must be logged into.