What is the Compulsory Setting in Firewall for TCP/IP Modbus in OT Network?
With the convergence of IT and OT (Operational Technology) networks, securing industrial protocols such as Modbus TCP/IP has become a critical task. While Modbus remains a widely used communication protocol for industrial devices like PLCs, RTUs, and SCADA systems, its lack of built-in security features makes it a prime target for cyberattacks.
In this blog post, we will focus on firewall settings required for Modbus TCP/IP communication in OT networks, offering practical guidance for control engineers, cybersecurity teams, and plant automation specialists.
What is Modbus TCP/IP?
Modbus TCP/IP is an industrial protocol that allows data exchange over Ethernet networks using TCP/IP. It operates over port 502 and follows a client-server architecture, where the master (client) polls one or more slave devices (servers).
Why Firewall Configuration Matters for Modbus in OT?
Modbus TCP/IP does not support authentication, encryption, or session management. Without proper firewall controls:
- Malicious users can read/write critical process values
- Attackers can flood devices with requests (DoS attacks)
- Malware can spread across segmented systems
Therefore, firewalls play a vital role in:
- Restricting access to only trusted devices
- Logging communication attempts
- Preventing unauthorized Modbus traffic
Compulsory Firewall Settings for Modbus TCP/IP
1. Allow Only Port 502/TCP
- Rule: Allow traffic on TCP port 502
- Why: This is the standard port used for Modbus TCP
- Tip: Deny all other unused TCP/UDP ports to reduce attack surface
2. IP Whitelisting (Allow Known Hosts Only)
- Rule: Permit communication only between specific IP addresses (PLC ↔ SCADA, etc.)
- Why: Prevents unauthorized devices from accessing critical assets
- Tip: Use static IP addresses and maintain a whitelist
3. Direction-Based Rules (East-West & North-South)
- Rule: Separate communication between:
- SCADA ↔ PLC (Southbound)
- Engineering Workstations ↔ PLCs (East-West)
- Why: Prevent lateral movement inside OT networks
- Tip: Use zone-based firewalls or VLAN-aware filtering
4. Deep Packet Inspection (DPI) for Modbus
- Rule: Use firewalls that support industrial protocol DPI (e.g., Tofino, Fortinet, Palo Alto)
- Why: Detect malformed Modbus commands, unauthorized write attempts, broadcast floods
- Tip: DPI helps enforce function codes and register-level filtering
5. Modbus Function Code Filtering
- Rule: Allow only required function codes (e.g., Read Holding Registers – 0x03)
- Why: Prevent malicious write attempts or unauthorized control
- Example: Block Function Code 0x10 (Write Multiple Registers) unless explicitly needed
6. Schedule-Based Rules
- Rule: Allow communication only during specific time windows
- Why: Reduce risk outside of working hours
- Tip: Apply in remote maintenance or temporary access scenarios
7. Alerting and Logging
- Rule: Enable logging for all Modbus-related traffic
- Why: Supports auditing, intrusion detection, and incident response
- Tip: Integrate logs into SIEM (Security Information and Event Management) platforms
8. Avoid Using ANY to ANY Rules
- Rule: Never configure Modbus access using ANY to ANY (Source: Any IP → Destination: Any IP)
- Why: This opens the network to unrestricted Modbus communication, increasing the risk of unauthorized access, lateral movement, and cyber threats.
- Fix: Always define explicit source and destination IP addresses along with permitted ports.
Recommended Modbus Function Codes to Monitor or Restrict
| Function Code | Name | Action |
|---|---|---|
| 0x01 | Read Coils | Allow (if required) |
| 0x03 | Read Holding Registers | Allow |
| 0x06 | Write Single Register | Restrict |
| 0x10 | Write Multiple Registers | Restrict / Alert |
| 0x2B | Encapsulated Interface | Block (rarely needed) |
Example: Cisco ACL Configuration for Modbus TCP/IP
access-list 101 permit tcp host 10.0.0.5 host 10.0.1.10 eq 502
access-list 101 deny ip any any log
interface GigabitEthernet0/1
ip access-group 101 in➡️ Allows only traffic from SCADA (10.0.0.5) to PLC (10.0.1.10) on TCP port 502
Tofino Firewall Example Settings
- Protocol: Modbus TCP
- Direction: Client → Server
- IP Range: SCADA (10.10.10.0/24) ↔ PLC (192.168.1.0/24)
- Function Code Allowed: 0x03 (Read Holding Registers)
- Logging: Enabled
- DPI: Enabled
Fortinet Firewall Configuration for Modbus TCP
- Policy Rule: Create IPv4 Policy
- Source Interface: SCADA-Zone
- Destination Interface: PLC-Zone
- Source IP: 10.0.0.5
- Destination IP: 192.168.1.10
- Service: TCP_502 (or custom service for Modbus)
- Action: ACCEPT
- Logging: Enable logging for session start and end
- Security Profiles:
- Enable Application Control to block unknown apps
- Enable IPS (Intrusion Prevention System) with Modbus signature filter
- Use Protocol Decoder to inspect Modbus function codes
- Schedule: Work Hours (optional)
➡️ Fortinet supports deep inspection and threat signatures tailored for ICS/SCADA environments, making it a strong candidate for OT segmentation.
Tips for Secure Modbus Deployment in OT
- Use firewalls with industrial protocol awareness
- Isolate control systems in segmented VLANs or DMZs
- Disable unused services on field devices
- Apply firmware updates regularly
- Pair with intrusion detection tools like Zeek or Nozomi
- Implement role-based access and logging for configuration changes
Summary Table: Key Firewall Rules for Modbus TCP
| Rule Type | Action | Description |
| Port Filtering | Allow TCP 502 | Limit traffic to standard Modbus port |
| IP Whitelisting | Permit known hosts only | Block all unknown IPs |
| Function Code Filter | Allow 0x03, block 0x10 | Reduce attack surface |
| Logging | Enable | Keep track of all attempts |
| DPI | Enable | Analyze Modbus content, not just headers |
| Schedule Rules | Restrict by time | Control access window |
| ANY to ANY | Avoid | Prevent broad, unfiltered access |
Final Thoughts
Modbus TCP/IP is powerful but inherently insecure. By applying strict firewall configurations including port filtering, IP-based rules, and DPI you significantly reduce your OT network’s attack surface. These best practices should be the minimum standard for any control system using Modbus TCP/IP in 2025 and beyond.