Palo Alto Networks Knowledgebase: Creating a lab to test ICS/SCADA protocols

Creating a lab to test ICS/SCADA protocols

6844
Created On 02/07/19 23:38 PM - Last Updated 02/07/19 23:38 PM
User-ID
Resolution

Introduction

Organizations with industrial control systems (ICS) have been on a path to secure the border between IT (corporate network) and OT (ICS network) for some time. The first step for many was to provide simple segmentation between the two networks using firewalls from Palo Alto Networks. This satisfied initial requirements for visibility and packet inspection for malicious activity. As enterprises endeavor to improve the security posture within ICS, there is a strong need to test before implementation. This document will show how to simulate the IT/OT boundary in order to test appID, userID, and other features within the Palo Alto Networks firewall. This entire lab can be virtualized on a single laptop.

 

Requirements

 

Required Item

Notes

Palo Alto Networks virtual appliance

Tested with a VM50, PANOS 8.0.6.

Windows virtual machine

For Java-simulated HMI interface.

MAC OSX

Tested with 10.12.6, requires Xcode environment (could install on a Kali Linux VM as well).

VM Fusion for MAC

Tested with Fusion Pro v8.5.8. VM Workstation for Windows can be used as well.

ModBusPal Java Machine

Tested with v1.6b. Simulates polled PLC devices.

MBTGET

Clone from Github. Simulates a polling server.

Java (on Windows VM)

Tested with JRE v9, 64-bit.

 

 

Diagram

User-added image

 

Configure VM Fusion

 The two networks used in the lab are labled vmet2 (for PLC zone) and vmnet3 (for Polling zone). The example shown is for VM Fusion on a MAC, but the same principle applies to VM Workstation. Note: do not power on the VM50 firewall yet, there are two important steps to do first.

 

 

Vmnet2

Picture2.png

 

Vmnet3

Picture3.png

 

A third network adapter will need to be added in the VM50 firewall settings in VM Fusion.

 

Picture4.png

 

Assign the adapters as follows:

  • Network Adapter to vmnet3
  • Network Adapter 2 to vmnet 3
  • Network Adapter 3 to vmnet2

 

The VM configuration file will need to be edited for the 3rd network adapter. In Fusion, go to the library and right-click on the VM50 and select “Show Config File in Finder”.

 

Picture5.png

 

You will then right-click on the VM file in the folder and select,”Show Package Contents”.

 

Picture6.png

 

Find the .vmx file and edit it with TextEdit or another text editor. Make sure to change the virtual device for ethernet2 to “vmxnet3” as shown below. Save the file. The package contents folder may be closed. From the Fusion library, the VM50 firewall may now be launched.

 

Picture7.png

 

To configure the management IP address of the firewall, follow the instructions here:

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/getting-started/integrate-the-firewall-into-your-management-network/perform-initial-configuration

 

To apply device licenses and registration:

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/getting-started/activate-licenses-and-subscriptions.html

 

Configure initial firewall policy

 Initial firewall policy will allow all applications between the polling zone and the PLC zone. All activity is logged and there are no profiles to configure at this point.

 

Security Policies

Picture8.png

 

NAT Policy

Picture9.png

 

Ethernet Interfaces

Picture10.png

 

Remember the default static route. I am using the default virtual router. For VMWare Fusion, the reserved default gateway IP is 192.168.55.2 on vmnet3.

 

Picture11.png

 

Address Objects

Picture12.png

 

Configure server and client

 On the Windows machine that will serve as the PLC devices, be sure to put it’s Ethernet interface in vmnet2 (on the PLCZone of the firewall). Make sure it’s default gateway points to the firewall interface: 192.168.45.20.

 

ModbusPal will be used to simulate PLC registers. You can download it here:

https://sourceforge.net/projects/modbuspal/files/modbuspal/RC%20version%201.6b/

 

It requires the Java Runtime Environment. Once the requirements have been met, open a command window and go to the directory where ModbusPal resides and launch it as shown below.

 

Picture13.png

 

We will add a Modbus slave by selecting “Add” from the Modbus Slaves section.

 

Picture14.png

 

Add one slave for now, then click “Add”.

 

Picture15.png

 

Name the new slave, then click the eye to populate.

 

Picture16.png

 

Under the Holding registers tab, add the amount of registers you would like to test.

 

Picture17.png

 

Provide values and, optionally, names for the addresses you created.

 

Picture18.png

 

Do the same for the Coils tab. Add binary values and, optionally, names.

 

Picture19.png

 

 

Close the slave window when finished. Click the Enable all button to ensure the slave is enabled. Then click Run to start the simulator.

 

Picture20.png

 

To use the MBTGET tool to simulate a polling server, you will need to clone the tool from GitHub. You can download the free MAC/Windows client here:

https://desktop.github.com/

 

Optionally, the tool may be cloned onto a Kali Linux virtual machine. To clone the MBTGET tool, follow these instructions from a terminal or command prompt.

 

Picture21.png

 

Help screen for MBTGET:

 

Picture22.png

 

A static route will need to be created on the laptop hosting the images in order to reach the PLC simulator.

 

For MAC:

# sudo route -n add -net 192.168.45.0/24  192.168.55.20

 

Testing the environment

To ensure the images are working properly, open a terminal window and initiate a poll using MBTGET. The resulting poll should show the values you created in the holding registers within ModbusPal. The value after “-n” should match the number of registers you created.

 

Picture23.png

 

Testing Modbus with appID

 

To move towards a more positive security posture, you can start by implementing appID. Here, we simply add the Modbus application and subfunctions that we want to allow. In my example, I will add Modbus-base and Modbus-read-holding-registers as the only allowed applications to be used from the PollingZone into the PLCZone.

 

Picture24.png

 

After running the MBTGET tool, review the logs to see the application recogniztion and that the policy allowed the action.

 

Picture25.png

 

In our appID rule, we are allowing read requests for holding registers only. We can use MBTGET to request to read a coil. The request fails.

 

Picture26.png

 

The log shows that the request failed and that it was attempting to read a coil register, which is not what we are allowing in the policy.

 

Picture27.png

 

Testing Modbus with appID and userID

 

To decrease the attack surface even further, enforce userID to only allow holding register reads from specific users.

 

Under Device / Local User Database / Users, add two test users.

 

Picture28.png

 

Under Device / Local User Database / User Groups - place each user in a different group. In my example, I added user1 to the group “CanReadHolding” and user2 to the group “CanReadCoils”.

 

Picture29.png

 

Under Device / Authentication Profile, create a new authentication profile. Select Local Database for the Type.

 

Picture30.png

 

Under the Advanced tab, select “all” users.

 

Picture31.png

 

Under Network / Interfaces / Loopback, create a loopback address to redirect users for authentication.

 

Picture32.png

 

Provide an IP address under the IPv4 tab. Make sure it is from the same range as your PollingZone.

 

Picture33.png

 

Under Device / User Identification / Captive Portal, edit the Captive Portal settings as shown. Use the IPv4 loopback address just created.

 

Picture34.png

 

Under Policies / Authentication, create a new authentication policy with the values shown.

 

Picture35.png

 

Under Policies / Security, edit the first rule and add the user group for reading holding registers.

 

Picture36.png

 

The modified rule should look something like this.

 

Picture37.png

 

Add a new rule to allow authentication traffic to the loopback so captive portal will work.

 

Picture38.png

 

Commit the changes.

 

Attempt to read the holding registers with MBTGET and we see that it fails.

 

Picture39.png

 

The Traffic log reveals that the read request was denied by the ExplicitDeny rule. This is because the userID requirement was not satisfied.

 

Picture40.png

 

To initiate user authentication in this setup, browse to the loopback address created for captive portal and login with the user who is allowed to read holding registers.

 

Picture41.png

 

Under Monitor / User-ID, see the authenticated user in the list.

 

Picture42.png

 

Retry the MBTGET poll and it should once again succeed.

 

Picture43.png

 

The Traffic logs also show the authenticated user associated with the register read.

 

Picture44.png

 

From the firewall CLI, issue these two commands to clear all userID data.

 

Picture45.png

 

Initiate the login in again using another user that is not authorized to read holding registers.

 

Picture46.png

 

Attempt the MBTGET register read and see that it fails for user2.

 

Picture47.png

 

Notice the reason for the failure in the traffic logs is due to ExplicitDeny since the traffic did not match any other rule. Specifically, user2 is not a member of the CanReadHolding group so the register read fails.

 

Picture48.png

 

 

Summary

There are more scenarios that can be used with this virtual lab that can further increase the security posture within the ICS environment. The addition of multi-factor authentication for users gaining access to the OT network, for example. The addition of security profiles to the ruleset is another. Attacks may be simulated as well using tools such as metasploit. See this article for ideas on using the log profile features of PAN-OS 8.0 to watch for malicious activity and potentially place ICS users in a quarantined state upon a violation: https://live.paloaltonetworks.com/t5/Learning-Articles/Protecting-ICS-and-SCADA-Networks-with-PAN-OS-8-0/ta-p/180651 

 



Attachments
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm2pCAC&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Attachments
Choose Language