Listen to this Post
Introduction:
In industrial control system (ICS) environments, a single firewall separating Information Technology (IT) from Operational Technology (OT) creates a dangerous single point of failure. Attackers routinely bypass poorly configured or exposed management interfaces, turning that “protective wall” into an open doorway. Implementing a layered firewall architecture with an IT/OT DMZ significantly reduces the risk of malware propagation, environmental disasters, and production downtime.
Learning Objectives:
- Design and deploy a dual-firewall DMZ architecture between IT and OT networks.
- Harden firewall management interfaces against local network exposure and credential theft.
- Implement high-availability failover to prevent operational disruption from a single device failure.
You Should Know:
- The Dual-Firewall DMZ Architecture: Why Two Walls Beat One
The post highlights a critical truth: a single firewall can fail—either through hardware malfunction, misconfiguration, or active exploitation. Attackers who compromise the IT network often scan for exposed firewall management interfaces (SSH, HTTPS, SNMP). If found, they can modify rules to allow direct OT access. A second firewall creates a demilitarized zone (DMZ) where only proxy hosts (e.g., data diodes, historian mirrors, patch servers) can communicate between IT and OT.
Step‑by‑step guide to implement an IT/OT DMZ with two firewalls:
- Segment the networks: Assign distinct IP subnets – IT (e.g., 10.0.0.0/24), DMZ (10.0.1.0/24), OT (10.0.2.0/24).
- Configure Firewall A (IT‑to‑DMZ): Allow only IT hosts to reach DMZ servers on required ports (e.g., HTTPS 443, SMB 445 for file transfer). Block all direct IT‑to‑OT traffic.
- Configure Firewall B (DMZ‑to‑OT): Allow only DMZ servers to initiate connections to OT devices (e.g., Modbus TCP 502, OPC UA 4840). Deny any traffic from IT directly to OT.
- Harden management interfaces: Bind management services to a dedicated management VLAN, not the production network. Disable web interfaces on OT‑facing firewalls.
- Test with controlled traffic: Use `tcpdump` or `Wireshark` to verify no IT‑to‑OT direct packets cross either firewall.
Linux (iptables) example for Firewall A (IT→DMZ only):
Allow established/related connections iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Allow IT subnet to DMZ on HTTPS iptables -A FORWARD -s 10.0.0.0/24 -d 10.0.1.0/24 -p tcp --dport 443 -j ACCEPT Drop IT to OT directly iptables -A FORWARD -s 10.0.0.0/24 -d 10.0.2.0/24 -j DROP
Windows Firewall (PowerShell) for a DMZ server:
Block all inbound from OT subnet except required service New-NetFirewallRule -DisplayName "Block OT to DMZ" -Direction Inbound -RemoteAddress 10.0.2.0/24 -Action Block Allow specific OT device (e.g., PLC) to DMZ on Modbus New-NetFirewallRule -DisplayName "Allow PLC Modbus" -Direction Inbound -RemoteAddress 10.0.2.10 -Protocol TCP -LocalPort 502 -Action Allow
2. Never Expose Management Interfaces on Operational Networks
Mike Holcomb warns: “don’t expose your management interfaces!” Attackers who breach the IT side often scan for firewall admin panels (e.g., port 443 for web, 22 for SSH) on the local network. If found, default credentials or known CVEs (e.g., CVE-2023-27997 on Fortinet) allow full rule modification. Even a “$50 firewall off Amazon” with an exposed web UI becomes a weapon for attackers.
Step‑by‑step management interface hardening:
- Disable remote management on OT‑facing interfaces. If the firewall has multiple physical ports (e.g., LAN, WAN, DMZ), bind the management service only to the IT‑side port.
- Change default credentials and enforce MFA (even TOTP) for all admin accounts.
- Implement a dedicated management VLAN (e.g., 192.168.99.0/24) that is not routable from production IT or OT. Access requires a separate jump host.
- Use access control lists (ACLs) to restrict management access to specific IT admin workstations.
- Disable unnecessary services – SNMP, Telnet, HTTP (force HTTPS), UPnP.
Verify exposed management ports with Nmap (run from IT workstation):
nmap -p 22,80,443,161,8080 --open 10.0.0.1-254
If any firewall responds, reconfigure immediately.
Linux command to bind SSH management to only one interface (in /etc/ssh/sshd_config):
ListenAddress 192.168.99.5 management VLAN IP Do not listen on production IT or OT IPs
- High Availability (HA) – Because One Firewall Can and Will Fail
The post notes: “Don’t forget additional firewalls for high availability!” In OT environments, unplanned downtime can cost millions per hour. A single firewall failure (power supply, firmware crash, DoS attack) disconnects all necessary traffic between IT and OT, halting data historians, alerting, and remote monitoring.
Step‑by‑step HA firewall deployment (vendor‑agnostic):
- Deploy two identical firewalls in active‑passive or active‑active mode. Use a dedicated heartbeat link (e.g., crossover cable) for state synchronization.
- Configure failover triggers – link status, interface health, service responsiveness (e.g., ping to a critical OT PLC).
- Test failover manually – unplug the active firewall’s power. Verify that the passive unit assumes all IP addresses and sessions within <3 seconds.
- Automate configuration backup – save running config to a remote TFTP or SCP server every hour.
- Monitor with SNMP or syslog – send alerts when a failover event occurs.
Example pfSense HA configuration (via web UI or CLI):
On primary firewall, enable CARP (Common Address Redundancy Protocol) ifconfig carp0 vhid 1 pass secretpass advskew 100 10.0.0.1/24 On secondary firewall, same vhid but advskew 200 Then configure pfsync to synchronize state table ifconfig pfsync0 syncdev em1
- The “Something Is Better Than Nothing” Emergency Firewall
Mike Holcomb pragmatically advises: if you have zero firewall between IT and OT, “Get one TODAY … even if it’s that $50 one off of Amazon for now.” While not enterprise‑grade, a basic NAT router with default deny rules stops opportunistic malware (e.g., WannaCry) from spreading directly to PLCs. However, you must still disable UPnP, change default passwords, and block all inbound from IT except whitelisted IPs.
Step‑by‑step emergency firewall setup (using a Raspberry Pi or old PC with iptables):
- Install Linux (e.g., Ubuntu Server) with two network interfaces: eth0 (IT side), eth1 (OT side).
- Enable IP forwarding temporarily (
sysctl -w net.ipv4.ip_forward=1) and make permanent in/etc/sysctl.conf.
3. Set default policies to DROP:
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
- Allow only essential traffic (e.g., IT admin to OT historian):
iptables -A FORWARD -s 10.0.0.50 -d 10.0.2.20 -p tcp --dport 1433 -j ACCEPT
5. Log dropped packets for threat hunting:
iptables -A FORWARD -j LOG --log-prefix "IT-OT-DROP: "
5. Beyond Firewalls: Additional Layers for OT/ICS Security
The post mentions resilience, slowing attackers, and preventing environmental disasters. Firewalls alone cannot stop insider threats, compromised laptops brought into the OT network, or malicious firmware updates. Pair firewalls with:
- Unidirectional gateways (data diodes) for read‑only data flow from OT to IT – physically impossible to send commands back.
- Port‑based authentication (802.1X) on OT switches to block unauthorized devices.
- Deep packet inspection (DPI) for industrial protocols (Modbus, DNP3, IEC 61850) – block function codes 5, 6, 15, 16 (write coils/registers) from unknown sources.
Example Snort rule to detect Modbus write commands from IT subnet:
alert tcp $IT_NET any -> $OT_NET 502 (msg:"Modbus write from IT"; content:"|06|"; offset:7; depth:1; sid:1000001;)
What Undercode Say:
- Key Takeaway 1: A single firewall is a single point of failure; dual firewalls with a DMZ force attackers to compromise two distinct devices, dramatically raising the cost of a successful OT breach.
- Key Takeaway 2: Exposed management interfaces are the 1 firewall killer – treat them like root passwords, bind them to isolated VLANs, and monitor for unauthorized access attempts.
- Analysis: Mike Holcomb’s pragmatic advice (including the $50 firewall) bridges the gap between perfect security and real‑world constraints. Many small manufacturers have zero segmentation; even a basic iptables rule on a recycled PC stops 90% of automated IT‑borne ransomware from encrypting PLCs. However, organizations must plan to replace temporary solutions with industrial‑grade, HA firewalls that support OT protocol awareness. The coming years will see more IT‑OT convergence attacks (e.g., Pipedream/Incontroller malware), making layered firewalls non‑negotiable. Ignoring this advice means accepting that a single phishing email can trigger a physical explosion.
Prediction:
By 2028, regulatory bodies (e.g., NERC CIP, IEC 62443) will mandate dual‑firewall DMZ architectures for critical infrastructure, penalizing single‑firewall designs as non‑compliant. Automated attack tools will specifically scan for exposed firewall management interfaces on OT networks, using them as primary entry points. Organizations that adopt high‑availability firewall clusters with AI‑driven anomaly detection today will withstand the next generation of state‑sponsored ICS attacks, while those relying on a single “set and forget” device will face catastrophic failures and lawsuit‑level liabilities.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
