Listen to this Post
Introduction:
Virtual PLCs (vPLC) replace traditional hardware controllers with software-based solutions, enabling seamless integration into Industry 4.0 and smart manufacturing ecosystems. However, this digital transformation expands the attack surface, exposing operational technology (OT) to remote code execution, network sniffing, and API abuse. This article delivers actionable security hardening techniques for OpenPLC and CodeSys virtual PLCs, bridging software engineering best practices with OT cybersecurity.
Learning Objectives:
- Deploy and harden OpenPLC and CodeSys vPLC environments on Linux and Windows.
- Implement network segmentation, API authentication, and encryption to protect industrial control traffic.
- Simulate MITM attacks and apply mitigation strategies like IPSec and firewall rules.
You Should Know:
1. Hardening OpenPLC vPLC on Ubuntu Linux
OpenPLC v3+ provides a web-based IDE and runtime. Start with a minimal Ubuntu 22.04 installation and apply these security steps.
Step‑by‑step guide:
- Install OpenPLC – Clone the repository and run the installer:
sudo apt update && sudo apt install git python3-pip wireshark -y git clone https://github.com/thiagoralves/OpenPLC_v3.git cd OpenPLC_v3 ./install.sh linux
- Apply firewall rules – Allow only necessary ports (e.g., 8080 for web IDE, 502 for Modbus):
sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp SSH management sudo ufw allow 8080/tcp OpenPLC web IDE sudo ufw allow 502/tcp Modbus TCP sudo ufw enable
- Run OpenPLC as non‑root user – Create a dedicated service account:
sudo useradd -r -s /bin/false openplc sudo chown -R openplc:openplc /opt/openplc sudo systemctl edit openplc Add User=openplc
- Disable default credentials – Change the web IDE password immediately via the admin panel. Enforce HTTPS by configuring Nginx as a reverse proxy with Let’s Encrypt.
2. Securing CodeSys Virtual PLC (Windows & Linux)
CodeSys V4 offers a heavy IDE with web and desktop versions. Unnecessary exposed services are common pitfalls.
Step‑by‑step guide:
- Install CodeSys – Download from the official site. During installation, deselect demo PLCs and remote access components unless explicitly needed.
- Harden the runtime – After deployment on Windows, open `services.msc` and stop:
– `CODESYS Gateway V4` (if not used)
– `CODESYS OPC DA Server`
Set them to “Disabled”.
- Use Windows Defender Firewall – Create inbound rules to block all except:
– TCP 11740 (CodeSys runtime)
– TCP 1210 (legacy, optional)
New-1etFirewallRule -DisplayName "Block CodeSys Remote" -Direction Inbound -Protocol TCP -LocalPort 11740 -Action Block -RemoteAddress Any
4. Linux variant – If using CodeSys for Linux, restrict access via iptables:
sudo iptables -A INPUT -p tcp --dport 11740 -s 192.168.1.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 11740 -j DROP
5. Enable runtime user authentication – In the CodeSys IDE, under “Device → PLC Settings”, set a strong password for online changes.
3. Network Segmentation for vPLC Environments
Virtual PLCs often communicate over corporate networks. Isolate them using VLANs or Linux network namespaces.
Step‑by‑step guide:
- Create a dedicated bridge and namespace (Linux) :
sudo ip netns add plc_net sudo ip link add veth0 type veth peer name veth1 sudo ip link set veth1 netns plc_net sudo ip netns exec plc_net ip addr add 10.0.1.2/24 dev veth1 sudo ip netns exec plc_net ip link set veth1 up
2. Run OpenPLC inside the namespace:
sudo ip netns exec plc_net sudo -u openplc /opt/openplc/start.sh
3. On Windows – Use Hyper‑V virtual switches. Create an “Internal” switch and assign the vPLC VM to it. Then use Windows Firewall to allow only the management host’s IP to access port 502/8080.
4. Verify isolation – From outside the namespace, attempt a port scan:
nmap -p 502 10.0.1.2 Should timeout or be filtered
4. Secure API Integration for vPLC Data Exchange
Modern vPLC solutions expose REST APIs or OPC UA. Attackers can manipulate setpoints or extract process data.
Step‑by‑step guide (using OpenPLC’s Modbus as example with API wrapper):
1. Implement API key authentication – Create a Python proxy that validates tokens before forwarding Modbus requests:
from flask import Flask, request
from pyModbusTCP.client import ModbusClient
app = Flask(<strong>name</strong>)
VALID_TOKEN = "s3cr3t_t0k3n"
@app.route('/write_coil', methods=['POST'])
def write_coil():
token = request.headers.get('X-API-Key')
if token != VALID_TOKEN:
return "Unauthorized", 401
addr = request.json['addr']
value = request.json['value']
c = ModbusClient(host="10.0.1.2", port=502)
c.write_single_coil(addr, value)
return "OK"
2. Run the proxy with TLS – Use `gunicorn` behind Nginx with a self‑signed certificate:
openssl req -x509 -1ewkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -1odes
3. On Windows (PowerShell) – Use `Test-1etConnection` to validate that only HTTPS (443) is exposed, not raw Modbus.
- Simulating a MITM Attack on vPLC and Applying IPSec
Man‑in‑the‑middle attacks on unencrypted Modbus/TCP can alter coil states. Use `arpspoof` and `Ettercap` to demonstrate, then mitigate.
Step‑by‑step guide (lab environment only):
1. Launch ARP spoofing (Linux attacker) :
sudo apt install dsniff sudo arpspoof -i eth0 -t 10.0.1.2 10.0.1.1 Poison PLC → Gateway
2. Capture and modify traffic – Use `scapy` to intercept Modbus write requests:
from scapy.all import def modify_pkt(pkt): if pkt[bash].dport == 502 and b'\x05' in bytes(pkt[bash]): Change coil write value pkt[bash].load = pkt[bash].load[:-1] + b'\x00' send(pkt) sniff(filter="tcp port 502", prn=modify_pkt, store=0)
3. Mitigate with IPSec transport mode – On Linux, set up `strongSwan` between the vPLC host and the HMI:
sudo apt install strongswan sudo ipsec start Configure /etc/ipsec.conf with ESP encryption (AES256)
4. Verify encryption – Run `tcpdump -i eth0 port 502` – after IPSec, traffic becomes ESP (protocol 50), and Modbus is not readable.
6. Monitoring vPLC with SIEM Integration
Forward vPLC logs and network events to a SIEM (e.g., Wazuh, Splunk) for anomaly detection.
Step‑by‑step guide:
- Enable OpenPLC syslog – Edit `/opt/openplc/webserver/core/hardware_layer.py` to add
logging.handlers.SysLogHandler.
2. Install Wazuh agent on the vPLC host:
curl -s https://packages.wazuh.com/4.x/keys/GPG-KEY-WAZUH | sudo apt-key add - sudo apt install wazuh-agent sudo systemctl enable wazuh-agent
3. Create custom rule to detect excessive coil writes (potential sabotage):
<rule id="100010" level="10"> <if_sid>5501</if_sid> <match>Modbus write multiple coils</match> <frequency>60</frequency> <time>10</time> <description>Possible brute-force coil writes on vPLC</description> </rule>
What Undercode Say:
- Key Takeaway 1: Virtual PLCs decouple from proprietary hardware, enabling software engineering best practices like version control, CI/CD, and secure coding. However, this shift requires treating PLC code as application code – with input validation, least privilege, and regular patching.
- Key Takeaway 2: Communities like SASE (sase.space) and modern resources (the recommended PLC book) emphasize that automation engineers must adopt software security mindsets. Traditional “air‑gap” security is dead; vPLC deployments demand network hardening, API security, and runtime monitoring.
Analysis: The post highlights a critical transition: vPLC is no longer experimental – OpenPLC and CodeSys are production‑ready. But the convenience of web IDEs and software integration introduces SQLi, XSS, and insecure direct object references (IDOR) in OT. The lack of built‑in encryption in legacy Modbus/TCP, combined with vPLC’s exposure to standard IT stacks, makes applying the above hardening steps mandatory. The SASES community’s “software engineer” identity is the right approach – treat every ST function block as a potential vulnerability.
Prediction:
- +1 Adoption of vPLC will accelerate OT/IT convergence, lowering automation costs and enabling AI‑driven predictive maintenance (e.g., using TensorFlow Lite on edge vPLC instances).
- +1 Open‑source vPLC IDEs built on VS Code (as the post hints) will foster community security audits and rapid vulnerability fixes, surpassing legacy proprietary systems.
- -1 Without mandatory security baselines, mass deployment of vPLC will lead to ransomware hitting soft‑PLCs – expect 200% increase in OT‑targeted attacks by 2027.
- -1 The shift to web‑based IDEs (OTee, OpenPLC) creates browser‑based attack vectors; supply chain attacks on npm/pip dependencies will compromise PLC logic.
- +1 Standardised security frameworks (e.g., IEC 62443‑4‑2) will incorporate vPLC profiles, and tools like OWASP PLC‑Check will become industry standard for compliance scanning.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Yaoweizhen Learning – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
