Listen to this Post
Introduction:
Operational Technology (OT) environments have long been tested using sanitized, simulated labs that fail to replicate the chaotic reality of live industrial control systems. Zakhar Bernhardt’s post about building a real GE MS5002E gas turbine station—complete with PLCs, SIS, local HMIs, and 11 dynamically assigned VLANs—reveals a paradigm shift: realistic OT labs are now mandatory for validating intrusion detection systems (IDS) and security tools. This article extracts the technical backbone of that build, delivers actionable commands for network segmentation and OT monitoring, and explains how you can spin up your own high-fidelity testing ground.
Learning Objectives:
- Design and deploy an OT lab architecture with multiple turbines, PLCs, SIS, and SCADA integration using automated network builders like Labshock Builder.
- Configure advanced network segmentation across 11 VLANs with dynamic IP assignment, routing, and access control lists for industrial networks.
- Execute IDS/IPS testing on live OT protocols (Modbus/TCP, DNP3, GE SRTP) and analyze detection gaps using open-source and enterprise tools.
You Should Know:
- Building an OT Lab That Mirrors Real Critical Infrastructure
Zakhar’s team didn’t just demo a simulator—they assembled a physical station based on the General Electric MS5002E, a heavy-duty gas turbine used in power generation and gas transportation. The lab includes four turbines, each with its own Programmable Logic Controller (PLC), Safety Instrumented System (SIS), and local HMI running GE Mark VIe controls. Every turbine talks to a central SCADA system that provides full visibility from a single pane of glass.
Step‑by‑step guide to replicate a basic OT lab on a budget (using virtual or refurbished hardware):
1. Source core components: Obtain one or more PLCs (e.g., Siemens S7-1200, Allen‑Bradley MicroLogix) and an HMI panel or software (Ignition, VTScada). For GE‑specific testing, use GE Proficy Machine Edition or emulate Mark VIe with available VM images.
2. Set up the SCADA server: Install openSCADA (Linux) or a trial of a commercial SCADA platform. Example on Ubuntu:
sudo apt update && sudo apt install openscada libmodbus-dev sudo systemctl enable openscada
3. Connect PLCs via industrial protocols: Use Modbus TCP for simplicity. On Linux, test connectivity with mbpoll:
sudo apt install mbpoll mbpoll -a 1 -t 3 -r 100 -c 1 192.168.1.10
4. Automate network configuration – Labshock Builder auto‑assigns IPs and segments VLANs. For DIY, use `dnsmasq` with DHCP and VLAN tagging on a managed switch.
2. Network Segmentation & Routing for OT Environments
The post highlights 11 VLANs with automated IP assignment and segmentation. In OT, VLANs isolate safety systems, control networks, and monitoring traffic to prevent a compromised HMI from reaching a PLC’s safety shutdown. The builder generated routing rules—something you can replicate with a Linux router or enterprise firewall.
Step‑by‑step to implement OT‑style VLANs on a Linux router (e.g., Debian with two NICs):
1. Install VLAN tools:
sudo apt install vlan bridge-utils sudo modprobe 8021q
2. Create VLAN interfaces for three example OT segments (Control, SIS, SCADA):
sudo ip link add link eth0 name eth0.10 type vlan id 10 Control VLAN sudo ip link add link eth0 name eth0.20 type vlan id 20 SIS VLAN sudo ip link add link eth0 name eth0.30 type vlan id 30 SCADA VLAN sudo ip link set dev eth0.10 up sudo ip addr add 10.0.10.1/24 dev eth0.10
3. Enable routing between VLANs (only where necessary):
sudo sysctl -w net.ipv4.ip_forward=1 sudo iptables -A FORWARD -i eth0.10 -o eth0.30 -p tcp --dport 502 -j ACCEPT Allow Modbus from Control to SCADA sudo iptables -A FORWARD -i eth0.20 -o eth0.10 -j DROP Block SIS to Control by default
4. On Windows Server (or Windows 10/11 with Hyper‑V): Use PowerShell to create virtual switches with VLAN IDs:
New-VMSwitch -Name "OT_Switch" -NetAdapterName "Ethernet1" Set-VMNetworkAdapterVlan -VMName "PLC_VM" -VlanId 10 -Access
- HMI and SCADA Configuration – Full Visibility One Place
Zakhar mentions four local HMIs (GE Mark VIe controls) feeding a central SCADA for unified monitoring. This mimics real control rooms where operators need a holistic view while maintaining local override capabilities.
Step‑by‑step to configure central SCADA data aggregation:
- Set up a data historian (e.g., using InfluxDB + Grafana). On Ubuntu:
sudo apt install influxdb grafana sudo systemctl start influxdb grafana-server
- Modbus polling script to read coil status from each PLC and push to InfluxDB:
from pyModbusTCP.client import ModbusClient from influxdb import InfluxDBClient c = ModbusClient(host="192.168.1.10", port=502) influx = InfluxDBClient(host='localhost', port=8086) while True: c.open() regs = c.read_holding_registers(0, 10) influx.write_points([{"measurement": "turbine1", "fields": {"status": regs[bash]}}]) c.close() - Integrate with Grafana dashboard – add InfluxDB as data source, create panels for RPM, exhaust temp, and alarm status.
-
Testing IDS on Real OT Traffic – Detection Engineering
“Test your IDS here, test detection on real OT” – this is the core value of a physical lab. Traditional IT IDS signatures fail on proprietary OT protocols like GE SRTP or Modbus function codes used for unsafe commands.
Step‑by‑step to deploy Snort for OT‑aware detection:
- Install Snort on a span port mirroring your OT switch:
sudo apt install snort sudo snort -i eth0 -c /etc/snort/snort.conf -A console
- Add custom rules for Modbus exception responses or illegal function codes:
alert tcp $HOME_NET any -> $PLC_NET 502 (msg:"Modbus illegal function"; content:"|FF|"; offset:7; depth:1; sid:1000001;) alert tcp $HMI_NET any -> $PLC_NET 502 (msg:"Modbus write coil to safety PLC"; content:"|05|"; offset:7; depth:1; sid:1000002;)
- Generate attacks from a Kali Linux machine inside the lab:
Modbus write to coil 0 (start turbine) – dangerous sudo apt install modbus-cli modpoll -m tcp -a 1 -t 0 -r 0 -c 1 192.168.1.10 1
- Verify detection – Snort should fire alerts. Use Wireshark to capture the traffic:
sudo tcpdump -i eth0 -w ot_attack.pcap wireshark ot_attack.pcap
-
Hardening OT Networks – Segmentation & Access Control
With 11 VLANs, misconfiguration can open backdoors. The builder’s auto‑IP assignment reduces human error, but you must still enforce strict firewall policies and monitor inter‑VLAN traffic.
Step‑by‑step hardening guide using iptables on the OT router:
1. Default drop policy for all OT VLANs:
sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP sudo iptables -P OUTPUT ACCEPT
2. Allow SCADA to poll PLCs (Modbus TCP port 502) but block everything else:
sudo iptables -A FORWARD -s 10.0.30.0/24 -d 10.0.10.0/24 -p tcp --dport 502 -j ACCEPT sudo iptables -A FORWARD -s 10.0.30.0/24 -d 10.0.20.0/24 -j DROP SCADA cannot touch SIS
3. Log and drop any unexpected traffic between SIS and control VLAN:
sudo iptables -A FORWARD -i eth0.20 -o eth0.10 -j LOG --log-prefix "SIS2CTL_DROP " sudo iptables -A FORWARD -i eth0.20 -o eth0.10 -j DROP
4. Windows equivalent using PowerShell and New-NetFirewallRule (on a Windows‑based SCADA server):
New-NetFirewallRule -DisplayName "Block SIS to Control" -Direction Outbound -RemoteAddress 10.0.10.0/24 -Action Block
6. Vulnerability Exploitation & Mitigation in OT Environments
The lab is built “already breaking our old architecture” – exactly what you want before an attacker finds it. Common OT vulnerabilities include unauthenticated Modbus writes, default credentials on HMIs, and lack of integrity checks on firmware.
Step‑by‑step simulation of a Man‑in‑the‑Middle (MITM) attack on Modbus traffic:
1. On a Linux attacker machine connected to the control VLAN, run ARP spoofing:
sudo apt install dsniff sudo arpspoof -i eth0 -t 10.0.10.10 10.0.10.1 spoof PLC to believe router is attacker
2. Forward traffic and modify Modbus write requests using scapy:
from scapy.all import def modify_modbus(pkt): if pkt.haslayer(TCP) and pkt[bash].dport == 502: Change write coil value from 0 to 1 (start turbine) if pkt[bash].load[bash] == 0x05 and pkt[bash].load[bash] == 0x00: pkt[bash].load = pkt[bash].load[:12] + b'\x01' + pkt[bash].load[13:] send(pkt) sniff(prn=modify_modbus, store=0)
3. Mitigation – Enable Modbus TCP with TLS (IEC 62351‑3) or use deep packet inspection (DPI) at the OT firewall. Example using nDPI:
sudo apt install ndpi-netfilter sudo ndpi-netfilter -p 502 -d modbus
- Using Labshock and Builder for Tool Demo & Detection Testing
Zakhar invites: “write me, we connect you to Labshock”. This indicates a commercial product (Labshock Builder) that automates the entire lab lifecycle – from asset discovery to network generation. While the internal details are proprietary, the concept is clear: provide a realistic, reproducible OT testbed for IDS vendors and security researchers.
Step‑by‑step to build a minimal open‑source alternative:
- Use GRFICS (Graphical Realism Framework for Industrial Control Simulations) – a free ICS simulation:
git clone https://github.com/GRFICS/grfics cd grfics && vagrant up
2. Add virtual PLCs using OpenPLC:
docker run -d -p 502:502 openplc/openplc
3. Generate network traffic with `mbtget` (Modbus tester):
mbtget -a 1 -r 0 -c 10 -p 502 172.17.0.2
4. Run Zeek (formerly Bro) for OT protocol analysis:
sudo zeek -i eth0 /opt/zeek/share/zeek/policy/protocols/modbus
5. Compare detection rates between Snort, Zeek, and Suricata on the same pcap.
What Undercode Say:
- Realistic OT labs expose weaknesses that simulation cannot – Zakhar’s team discovered that their old architecture broke under real turbine traffic, proving that “virtual purity” hides production flaws.
- Automated network configuration is a game changer – Building 11 VLANs and routing by hand is error‑prone; tools like Labshock Builder (and open‑source alternatives) reduce misconfigurations that attackers love.
- IDS testing must be adversarial – Running commercial IDS against a live GE Mark VIe stack reveals false negatives on proprietary protocol extensions, pushing vendors to improve.
- Segmentation without monitoring is theatre – VLANs plus strict iptables rules only work if you actively inspect inter‑VLAN traffic for anomalous Modbus writes or unusual SIS commands.
- The future is “build to break” – Every OT lab should be designed to fail safely under attack, allowing blue teams to iterate detection logic before deployment.
Prediction:
Within two years, every major OT security vendor will offer an “assault‑ready” lab service like Labshock, where physical turbines, PLCs, and SIS are rented per hour for red‑team drills. This will drive the demise of purely virtual OT simulators, as regulators begin mandating physical testbed certifications for critical infrastructure. We’ll also see open‑source frameworks emerge that emulate GE, Siemens, and ABB controllers with 99% protocol fidelity, turning every security researcher’s laptop into a miniature gas station. The biggest winner? IDS and SIEM tools that finally learn to distinguish normal turbine vibration from a cyber‑induced explosion.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Zakharb Labshock – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
