Industrial protocols in OT firewall rules

To review Modbus and DNP3 firewall rules, find every rule that allows TCP 502 (Modbus/TCP) or TCP and UDP 20000 (DNP3), by port or by application, and check three things on each. The sources and destinations are named hosts: the HMI, SCADA server, master station or engineering workstation, and the controllers or outstations it serves. The path stays inside OT, between adjacent levels. And nothing from the business network, the internet or a VPN reaches it. Then compare each rule with the traffic log, so it allows only the protocols that conduit really carries.

Industrial protocols are how HMIs, SCADA servers and engineering workstations talk to controllers. Most were designed for closed networks, so the classic forms of Modbus/TCP, EtherNet/IP and S7comm carry no authentication: any host that can reach the port can read values, and often write them. That makes the firewall rules around these protocols some of the most important rules in an OT network.

Industrial protocol rule checklist

1. Find every rule that allows an industrial port or application, using the table below, including rules that allow them only through “any”.
2. Name the source and destination hosts, not whole zones. IEC 62443-3-3 SR 5.2.
3. Keep industrial protocols on adjacent OT levels: L0 to L1, L1 to L2, L2 to L3. NIST SP 800-82r3 section 5.2.3.1.
4. Nothing from Level 4, the internet or a VPN reaches them. Remote sessions end on a jump host in the IDMZ. NIST SP 800-82r3 section 5.2.3.1; IEC 62443-3-3 SR 1.13.
5. No industrial protocol crosses the IDMZ unless a named broker, such as an OPC UA proxy, is the endpoint.
6. Each conduit allows only the protocols it carries, and no remote desktop, file sharing or Telnet onto controllers. IEC 62443-3-3 SR 7.7.
7. Match the application, not only the port, where the firewall can identify it.

Common industrial protocols and their ports

Protocol	Default ports	Typical use
Modbus/TCP	TCP 502	Reading and writing registers on PLCs, drives and meters
EtherNet/IP (CIP)	TCP and UDP 44818, UDP 2222	Explicit messaging on 44818; cyclic I/O on UDP 2222
S7comm (Siemens S7)	TCP 102	Siemens controller access, programming and HMI traffic
IEC 61850 MMS	TCP 102	Substation automation
DNP3	TCP and UDP 20000	Utilities: SCADA master to outstation
IEC 60870-5-104	TCP 2404	Utilities: telecontrol between control center and substations
OPC UA	TCP 4840	Data exchange between OT systems and historians or MES

Two protocols share TCP 102, so a rule that allows the port allows both. PROFINET real-time traffic runs at Layer 2 inside a cell; its routable parts use ports 34962 to 34964 and belong on Level 1 and Level 2 only. Vendors and sites can move any of these to other ports; the traffic log shows what is actually in use.

A firewall that identifies applications can match the protocol itself rather than only the port. That is stronger than a port rule, because traffic on the right port that is not the expected protocol does not match.

Where industrial protocols belong

In Purdue model terms, industrial protocols belong on the conduits inside OT:

• between the process (L0) and basic control (L1),
• between basic control (L1) and supervisory (L2),
• between supervisory (L2) and operations (L3), for example a historian collecting from controllers or an OPC UA server.

They do not belong on the boundary between operations (L3) and the industrial DMZ (L3.5), between the IDMZ and the business network (L4), or anywhere toward the internet (L5). The IDMZ guide explains why: every session from the business side ends on a service in the IDMZ, and only that service talks to OT. A historian replica in the IDMZ serves business users the data; nobody on the business side speaks Modbus to a PLC.

OPC UA is the usual exception. Where business systems need plant data over OPC UA, a proxy or a reverse connection in the IDMZ brokers it, and the boundary allows only those named endpoints, never a business client straight to a server in OT.

Even inside OT, name the hosts. An HMI rule should allow the HMIs to reach their own controllers on the protocol they use, not the whole supervisory zone to the whole control zone on every industrial port.

Paths that should never carry industrial protocols

• Business network to OT. Modbus, EtherNet/IP or S7 from an L4 office host to a controller or HMI.
• Internet or VPN to OT. A remote or vendor session that reaches a controller on an industrial protocol directly, instead of ending on a jump host in the IDMZ. Remote engineering sessions end on a Level 3 host, and only a workstation inside the cell zone speaks the industrial protocol to the controllers.
• Industrial protocols across the IDMZ. An L3.5 host that talks to controllers, or business hosts that reach an IDMZ service on an industrial port.
• Protocols the conduit does not need. A supervisory-to-control rule that allows every industrial protocol when the cell uses one, or that also allows remote desktop, file sharing or Telnet onto the controllers.

A firewall rule audit reads each of these rules against the traffic log, so the narrowed rule names the protocols the conduit actually carries.

How SegAudit reports industrial protocols

SegAudit flags industrial protocol traffic that crosses into OT from the business network, the internet or a VPN, and traffic on a conduit that is not on the expected list for that boundary. Each finding names the sessions, the sources and destinations, the allowing rule, and the IEC 62443-3-3 and NIST SP 800-82r3 controls it relates to. The expected protocols per boundary follow the levels above by default. If a site brokers a protocol such as OPC UA through the IDMZ, add it to the expected list for that boundary.

In the Northline sample (a made-up three-site company that ships with SegAudit), the rule “allow-vpn-to-control” lets a remote integrator account reach controllers on the control network at all three sites. The finding “Internet (L5) reaching L1 OT · 25 sessions” is critical: 19 of the sessions are Modbus and 6 are SSH, straight from the VPN to L1. Its recommendation reads, in part: “Deny inbound internet/VPN to L3 and below. Terminate remote access on a jump host in the IDMZ, broker through a PAM gateway, and allow only the jump host into L3 on named apps (RDP, SSH).”

To see what SegAudit catches in one of your own exports, run the free Quick check. For the wider picture, start with OT network segmentation, step by step.

Common questions

Is Modbus/TCP insecure?

Classic Modbus/TCP has no authentication or encryption, so anyone who can reach port 502 can send it commands. A secure variant (Modbus/TCP Security, over TLS) exists, but many installed devices do not support it. The firewall rules around port 502 are often the only control.

Can I allow an industrial protocol by port alone?

It works, but it allows anything that uses the port, including a different protocol on the same number. Where the firewall can identify the application, match the protocol as well. Either way, always name the source and destination hosts, so only the HMI, SCADA server or engineering workstation that needs the controller can reach it.

Should an engineering workstation reach PLCs on an industrial protocol?

Yes, that is its job, but from inside the cell zone (L2), not from the business network or a remote session. A remote engineer reaches that workstation through the IDMZ jump host and a Level 3 host, as a documented, time-limited exception.