An S7 CPU that answers on TCP 102 from a public address is not a hardened controller with a password on it. It is a controller waiting its turn. Automated tooling then does the rest: enumerate the rack, read the order number and firmware, test whether write access is open, and issue a STOP if it is.
What has changed is the cost of the attack: automated tooling has collapsed the skill floor, so exposure that survived a decade unnoticed now gets found in a weekend.
Exposure Symptoms and What They Mean
Before anything else, confirm which of these you actually have. Each one points at a different part of the path.
| Symptom | Mechanism | First check |
|---|---|---|
| CPU in STOP, no operator command, no hardware fault LED pattern for a diagnostic error | Remote STOP issued over S7 communication. On a CPU left at full access, no credential is required | Diagnostic buffer STOP entry and its timestamp; correlate against edge firewall and cellular router logs |
| HMI and SCADA connections drop and recover intermittently | Scanner traffic consuming the CPU's finite connection resources; legitimate clients get refused | Online connection resources in the CPU diagnostics; count of established connections vs configured |
| Cellular router data consumption jumps with no process change | Continuous scan and brute-force traffic against published ports | Carrier usage portal, router NAT and firewall counters |
| CPU web server login page reachable from outside the plant | Web server enabled and port 80/443 forwarded at the edge | Port-forward, DMZ-host and UPnP tables on every edge device, including machine-builder routers |
| Unknown MAC or IP appears in the PROFINET topology | A device bridged onto the cell network — vendor laptop, consumer appliance, rogue AP | Managed switch MAC address table and port security log |
Do not move on until you know whether the reachability is inbound-published (a NAT rule, a DMZ host, a public IP on the CPU itself) or bridged (something dual-homed onto the cell). They get fixed in different places.
Remote-Access Approaches Compared
Four architectures cover essentially every site. They differ mainly in whether an inbound path exists at all.
| Approach | Inbound path from internet | Supports vendor diagnostics | Failure mode when compromised | Ongoing effort |
|---|---|---|---|---|
| B. Port forward to the CPU, password only | Direct to TCP 102 / 443 | Yes | Full controller access; STOP and download are one hop away | None, which is why it persists |
| C. VPN to plant firewall, jump host in an industrial DMZ | Authenticated tunnel terminating outside the cell | Yes, brokered | Attacker lands on a hardened jump host, not the CPU; cell firewall still applies | Moderate: identity, MFA, certificate and rule lifecycle |
| D. Outbound-only remote-access gateway in the DMZ | None inbound; gateway dials out | Yes, session-based | Depends on the gateway vendor's cloud; cell still firewalled | Low operationally, high on vendor trust and egress control |
Option B is not a configuration choice, it is the defect.
Recommended Architecture
Use C for engineering and maintenance access, with D acceptable where a machine builder demands it and you can constrain the gateway's egress.
- Control cell (CPUs, distributed I/O, drives, panel HMIs) on its own VLAN and IP subnet, one cell per machine or process area.
- No OT device holds a public address and no edge device forwards a port into OT. This is a written rule, not a preference.
The distinction that matters operationally: a cell may need to reach out (NTP, a licensing check, a gateway callback), but nothing on the internet ever needs to initiate a connection into it.
Removing the Exposure: Commissioning Order
- Inventory the edge. List every device with a WAN interface: the plant firewall, every 4G/5G machine router, every vendor-supplied modem, every spare consumer router someone hung on a panel. Machine-builder cellular routers are the most common finding because IT never provisioned them and never sees them.
- Scan from outside. From an internet connection unrelated to the plant, scan the site's public ranges and every cellular router's assigned address for TCP 102, 80, 443, 4840, 161, 502 and 44818. Record what answers before you change anything.
- Delete the published paths. Remove port forwards, DMZ-host entries, one-to-one NAT and UPnP on every edge device. Disable UPnP permanently — it re-publishes ports without a change record.
- Re-scan. Nothing from step 2 should answer. Do not move on until the external scan is clean.
- Insert the cell firewall. Default deny, then add rules for the traffic the process actually generates. Run in a permissive logging mode long enough to catch the once-per-shift and once-per-month flows, then tighten.
- Block cell egress. Deny outbound internet from all OT VLANs. Permit only named destinations, by IP and port, through the DMZ.
- Stand up the authenticated path. VPN terminates on the plant firewall, not on a controller and not on a cell router. Require MFA. Land users on a jump host in the DMZ with session logging; engineering software runs there or on a dedicated workstation reached from there.
- Rotate every credential touched by the old topology: CPU protection-level passwords, HMI runtime users, switch and router admin accounts, VPN accounts, vendor accounts. Assume the previous set is known.
- Archive offline. Full TIA Portal project, HMI runtime, drive parameter sets and switch configurations on media that is not reachable from the network you just secured, and confirm the archive restores.
Controller Hardening in TIA Portal
Segmentation stops the scan; device hardening decides what happens when something already inside the cell misbehaves. Configure these in the CPU properties and download them — several take effect only after a full download.
- Access level. Raise the protection level from full access. Set read access or HMI access for normal operation and assign a distinct password to each level that remains available. Full access stays reserved for the engineering credential.
- PUT/GET. Clear "Permit access with PUT/GET communication from remote partner" unless a specific legacy client requires it. When it is enabled, any station that can route to the CPU can read and write data blocks without touching the protection level. If a partner genuinely needs it, restrict the source addresses at the cell firewall.
- Web server. Disable it if the maintenance procedure does not use it. If it stays on, permit HTTPS only, disable anonymous access, create named users with the minimum function rights, and never publish the port at the edge.
- OPC UA server. Off unless in use. When used, require certificate-based authentication and a signed-and-encrypted security policy; do not run it with anonymous logins.
- SNMP. Disable or move off default community strings. Read-only SNMP is a free asset inventory for an attacker.
- Know-how protection. Apply block-level know-how protection to proprietary logic and copy protection bound to the CPU serial number where cloning is a concern.
- Display protection. On CPUs with an integrated display, set the local protection level so the display cannot be used to change the operating mode or read passwords.
- Mode selector. Treat it as an operating control, not a security control. It stops a download from taking effect in RUN; it does not stop an unauthenticated read or a STOP request.
Remote-Access Endpoint Hygiene
The tunnel is only as trustworthy as the machine at the far end. A recurring pattern in oil and gas and in food and beverage: an engineer's home network hosts an unmanaged consumer appliance — a streaming box, a camera NVR, a cheap AP — that has been backdoored at the supply-chain level. The engineer's laptop sits on the same flat home subnet with a split-tunnel VPN into the plant. The appliance now has a route to OT that no firewall rule anticipated.
- Disable split tunneling on every OT VPN profile. When the tunnel is up, all traffic goes through it.
- Use a dedicated, managed engineering laptop for OT. No personal use, no general browsing, application allow-listing enabled.
- Land every remote session on a jump host. Engineering software and the project archive live there, so no controller-capable toolchain ever runs on an uncontrolled machine.
- Prohibit dual-homing. A laptop with an active Wi-Fi connection and a cable into the cell is a bridge, whether or not routing is deliberately enabled.
Ownership and Change Control
Most exposures are organizational, not technical. The machine arrives with a cellular router already provisioned by the OEM. Nobody in IT knows it exists, because it does not touch their network; nobody in OT owns firewall policy, because that has always been IT's job. The gap between those two positions is where the port forward lives for five years.
Close it with three artifacts: a single asset register that includes OEM-supplied network hardware; a written policy that no OT device receives a public address or an inbound NAT rule; and a change record on every firewall rule with an owner, a justification and a review date. Add a contractual clause requiring OEMs to disclose and hand over credentials for any communication hardware they ship, and to route remote support through your gateway rather than their own.
Verification
Prove each layer separately, in this order. A pass on one does not imply a pass on the next.
- External: re-scan all public addresses and every cellular router address for TCP 102, 80, 443, 4840, 161, 502, 44818. Expect no response. Repeat monthly and after any edge change.
- Lateral: from a host on the business network, attempt a TCP 102 connection to a CPU. It must fail at the DMZ boundary, and the firewall must log the deny.
- Access level: from an authorized station, attempt an online connection without the engineering password. The CPU must refuse write access and prompt for credentials at the configured level.
- PUT/GET: point a legacy PUT/GET client at the CPU. The request must be rejected.
- Egress: from a cell device, attempt an outbound connection to an arbitrary internet address. It must be denied and logged.
- Diagnostics: read the CPU diagnostic buffer after seven days of normal running. No unexplained connection aborts, no mode changes outside the maintenance window.
- Restore drill: restore the archived project onto a spare CPU of the same order number and firmware, and confirm it goes to RUN with the expected block checksums.
Log the timestamp and result of item 1 in the change record — a clean external scan, dated and repeated, is the only evidence that the exposure stayed closed.
Frequently Asked Questions
What happens if I set a protection-level password but leave the S7 CPU reachable from the internet?
The CPU still answers on TCP 102, still discloses its order number and firmware to any scanner, and still consumes connection resources under scan load. A password is a second layer, not a substitute for removing the published port.
Any station that can route to the CPU can read and write data blocks without presenting the protection-level password, because PUT/GET bypasses that check by design. Clear the "Permit access with PUT/GET communication from remote partner" option unless a specific legacy partner requires it, and restrict that partner's source address at the cell firewall.
What happens if the machine builder's cellular router sits on the same switch as the PLC?
The cell has a second, unmanaged internet edge that your plant firewall never sees, and any port forward or default credential on that router publishes the controller directly. Inventory every OEM-supplied router, remove NAT and UPnP entries, and either decommission it or move remote support onto your own gateway.
You add HTTP/HTTPS listeners that expose diagnostics, the diagnostic buffer, variable tables and — with sufficient rights — the operating mode. Keep it internal only, permit HTTPS exclusively, disable anonymous access, and create named users limited to the specific function rights maintenance actually needs.
How do I confirm my S7 is not already exposed?
Scan your public ranges and every cellular router address from an unrelated internet connection for TCP 102, 80, 443, 4840, 161, 502 and 44818, then audit the port-forward, DMZ-host and UPnP tables on every edge device. Follow with the CPU diagnostic buffer and the connection-resource count to spot sessions you cannot account for.