Protocol filtering is the inspection and selective enforcement of industrial protocol traffic at the command level. A protocol-filtering proxy understands the application protocol, not just TCP ports, and applies allow or deny rules to specific function codes, register ranges, and object operations. It is the difference between "this device may talk on port 502" and "this device may read but not write."
Why is port-level filtering not enough for OT?
A traditional firewall filters by the 5-tuple: source IP, destination IP, source port, destination port, and protocol. That works for HTTPS and SSH. It falls apart for industrial protocols, where the difference between a harmless read and a dangerous write is a single function-code byte inside the payload.
A Modbus TCP session on port 502 can carry function code 03 (read holding registers) or function code 06 (write single register) in the same packet structure. A port firewall cannot tell them apart. An engineer's diagnostic tool and an attacker changing a valve setpoint look identical at the port level. Protocol filtering reads the payload, identifies the function code, and applies a policy: allow reads from the SCADA historian, deny writes from anything except the approved engineering workstation during the approved change window.
Which industrial protocols get filtered?
- Modbus TCP (port 502): function codes 01 to 06 cover reads and writes; codes 08, 16, and 23 are frequently restricted.
- DNP3 (port 20000): Control Relay Output Block and Analog Output Block operations are typically deny-by-default.
- EtherNet/IP (ports 44818 and 2222): CIP services Set Attribute Single and Set Attribute All are restricted.
- Profinet (port 34962 and up): cyclic I/O exchange separated from acyclic configuration writes.
- OPC UA (port 4840): Write Service and Call Service governed at attribute-level granularity.
- BACnet (port 47808): WriteProperty and WritePropertyMultiple in building automation.
What does a protocol-filtering proxy add that a firewall cannot?
Three things a port-level firewall has no way to express:
- Command-level audit. Every request and response is logged with its function code and parameters, not just bytes transferred.
- Per-session role enforcement. A read-only operator account reaches a device over the exact same port as an engineer, but only the engineer's writes are permitted.
- Protocol-aware anomaly detection. A sudden burst of write operations outside the change-control window becomes a detectable event instead of ordinary traffic.
How is protocol filtering different from deep packet inspection?
Deep packet inspection (DPI) is the broad technique of reading packet payloads. Protocol filtering is DPI applied with industrial-protocol semantics and an enforcement policy attached. A generic DPI engine might recognize that traffic is Modbus. A protocol filter knows that function code 06 is a write, that it targets register 40001, that the source is not the sanctioned engineering workstation, and that the policy says block. The intelligence is in the OT-specific rules, not the packet reading alone.
How Access Gate helps
Access Gate filters Modbus, DNP3, EtherNet/IP, Profinet, and OPC UA at the command level, enforcing per-session role-based policies that port firewalls cannot express, and forwarding every command-level event to your SIEM. See Securing Modbus for a worked example.
Related terms
- Modbus, the most widely filtered industrial protocol
- Industrial Control Systems Security, the environment protocol filtering protects
- Micro-DMZ, where filtering proxies are commonly placed
- Deny-by-Default (OT), the policy stance protocol filtering enforces
- Deep Packet Inspection, the underlying inspection technique
