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

Creating a lab to test ICS/SCADA protocols

Created On 02/07/19 23:38 PM - Last Updated 02/07/19 23:38 PM


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.




Required Item


Palo Alto Networks virtual appliance

Tested with a VM50, PANOS 8.0.6.

Windows virtual machine

For Java-simulated HMI interface.


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.


Clone from Github. Simulates a polling server.

Java (on Windows VM)

Tested with JRE v9, 64-bit.




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.









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




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”.




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




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.




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


To apply device licenses and registration:


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



NAT Policy



Ethernet Interfaces



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




Address Objects



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:


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


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.




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




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




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




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




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




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





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




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:


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.




Help screen for MBTGET:




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


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.




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.




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




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.




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.




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.




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”.




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




Under the Advanced tab, select “all” users.




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




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




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




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




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




The modified rule should look something like this.




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




Commit the changes.


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




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




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.




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




Retry the MBTGET poll and it should once again succeed.




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




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




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




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




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.






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: 


  • Print
  • Copy Link

Choose Language