Knowledge Base /
Technical Notes
Recommended Modbus TCP/IP Firewall Rules
By Jake Nichelson
Product: IOD-4111 - Modbus TCP IP Driver for DeltaV VIM2

Introduction

MYNAH Technologies recommends the following firewall rules when integrating the Tofino Xenon Firewall with the Modbus TCP/IP VIM2. See Industrial Ethernet Integration with a Tofino Xenon Security Appliance for more information.


Firewall Rules for Modbus TCP/IP Devices

In this common scenario, the VIM2 is a Modbus TCP/IP master and the PLC/device is a Modbus TCP/IP slave. The Tofino SA would be placed between the device and the switch. Therefore, the VIM will exist on Net1 or the Wide Access Network (WAN). The device will exist alone on Net2 or the Local Access Network (LAN).

Network Diagram

Without the Modbus TCP/IP LSM (Loadable Security Module)

Only three rules are required to protect the Modbus device if the Modbus TCP/IP LSM is not used.

Rule 1: Default rule to allow all ARP traffic. ARP is necessary for all IP traffic to function.

Rule 2: The VIM2 performs an initial ping to the device. If the device does not respond to the ping then the VIM will never attempt to connect.

Rule 3: All Modbus TCP/IP traffic between the VIM and the device will be forwarded. Additional filtering regarding the Modbus TCP/IP protocol will require the Modbus TCP/IP LSM.

With the Modbus TCP/IP LSM

Rule 1: Default rule to allow all ARP traffic. ARP is necessary for all IP traffic to function.

Rule 2: The VIM2 performs an initial ping to the device. If the device does not respond to the ping then the VIM will never attempt to connect.

Rule 3: The specific behavior of the Enforcer Rule is determined by the Enforcer settings. The Enforcer rule cannot be bidirectional. The direction arrow specifies which node opens the connection, not the flow of traffic. The arrow should always point away from the Modbus master and point to the Modbus slave.

The Modbus/TCP Enforcer rule can be used to create additional rules specific to Modbus TCP/IP. There are 5 radial selections for function codes:

  • Read-Only - Only allow Read-Only function codes (no Writes or Programming)
  • Read/Write - Allow Read and Write function codes (no Programming)
  • Programming/OFS - Only allow Programming (no Reads or Writes)
  • Any - Allow all Modbus traffic
  • Advanced… - Used to specify which function codes and registe ranges are allowable

We also recommend leaving “Exception” unchecked with “Reset” checked. When an invalid function code is used, DeltaV Diagnostics will report “0x5036: Connection Reset by Peer” for the dataset status. This should indicate that the Firewall has reset the VIM's connection because a firewall rule has been broken.



Firewall Rules for Modbus TCP/IP VIM2s

This firewall configuration is very similar to the firewall rules for Modbus TCP/IP Devices. There are a few differences:

  1. The VIM2 will be on the LAN interface and the Modbus devices will be connected on the WAN interface. Assuming that the VIM2 is the Modbus master, the Modbus protocol direction arrow will point in the opposite direction.
  2. The VIMNet Explorer Special Rule and the VIMNet Messaging protocol must be allowed and properly configured so VIMNet Explorer can communicate to the VIM.

Network Diagram

Without the Modbus TCP/IP LSM

Rule 1: Default rule to allow all ARP traffic. ARP is necessary for all IP traffic to function.

Rule 2: The VIM2 performs an initial ping to the device. If the device does not respond to the ping then the VIM will never attempt to connect. VIMNet Explorer will also need to ping the VIM.

Rule 3: All Modbus TCP/IP traffic between the VIM and the device will be forwarded. Additional filtering regarding the Modbus TCP/IP protocol will require the Modbus TCP/IP LSM.

Rule 4: The VIMNet protocol must be allowed for VIMNet Explorer to properly communicate to the VIM2. See MYNAH's article on DeltaV Virtual IO Module Network Ports for more details about which network ports are used by VIMNet Explorer. The VIMNet Explorer Messaging protocol under Protocols → Common Industrial must be updated manually. The two ports (51001 and 52000) need to be updated as follows:

  • Add the last octet of the VIM's IP Address to 51001 (e.g.: 192.168.1.28 = 51029)
  • Add the last octet of the VIM's IP Address to 52000 (e.g.: 192.168.1.28 = 52028)

Rule 5: The VIMNet Explorer Special Rule must be allowed for VIMNet Explorer to detect th VIM on the network.

With the Modbus TCP/IP LSM

Rule 1: Default rule to allow all ARP traffic. ARP is necessary for all IP traffic to function.

Rule 2: The VIM2 performs an initial ping to the device. If the device does not respond to the ping then the VIM will never attempt to connect. VIMNet Explorer will also need to ping the VIM.

Rule 3: The specific behavior of the Enforcer Rule is determined by the Enforcer settings. The Enforcer rule cannot be bidirectional. The direction arrow specifies which node opens the connection, not the flow of traffic. The arrow should always point away from the Modbus master and point to the Modbus slave.

Rule 4: The VIMNet protocol must be allowed for VIMNet Explorer to properly communicate to the VIM2. See MYNAH's article on DeltaV Virtual IO Module Network Ports for more details about which network ports are used by VIMNet Explorer. The VIMNet Explorer Messaging protocol under Protocols → Common Industrial must be updated manually. The two ports (51001 and 52000) need to be updated as follows:

  • Add the last octet of the VIM's IP Address to 51001 (e.g.: 192.168.1.28 = 51029)
  • Add the last octet of the VIM's IP Address to 52000 (e.g.: 192.168.1.28 = 52028)

Rule 5: The VIMNet Explorer Special Rule must be allowed for VIMNet Explorer to detect the VIM on the network.

The Modbus/TCP Enforcer rule can be used to create additional rules specific to Modbus TCP/IP. There are 5 radial selections for function codes:

  • Read-Only - Only allow Read-Only function codes (no Writes or Programming)
  • Read/Write - Allow Read and Write function codes (no Programming)
  • Programming/OFS - Only allow Programming (no Reads or Writes)
  • Any - Allow all Modbus traffic
  • Advanced… - Used to specify which function codes and register ranges are allowable

We also recommend leaving “Exception” unchecked with “Reset” checked. When an invalid function code is used, DeltaV Diagnostics will report “0x5036: Connection Reset by Peer” for the dataset status. This should indicate that the Firewall has reset the VIM's connection because a firewall rule has been broken.