DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Modbus and S7 on the Public Internet: 202,686 Reachable Industrial Ports and What They Actually Expose

Modbus and S7 on the Public Internet: 202,686 Reachable Industrial Ports and What They Actually Expose

Two ZoomEye queries executed on 2026-09-16 return 40,917 assets on port 502 and 161,769 assets on port 102. Port 502 carries Modbus TCP; port 102 carries Siemens S7 communication. Together they represent 202,686 reachable endpoints on two protocols that were designed for isolated industrial networks and that carry no authentication of their own.

The problem

Modbus TCP and S7 predate the assumption that their network would ever be hostile. Neither protocol includes authentication, authorization or encryption in its base specification. A device that accepts a Modbus write to a coil register will perform that write for any host that can reach the port, regardless of who sent it. There is no credential to steal and no session to hijack, because there is no session in the security sense. Reachability is control.

How the measurement was taken

The figures come from two ZoomEye queries executed on 2026-09-16:

  • Search dork: port="502" — Result: 40,917 matching assets
  • Search dork: port="102" — Result: 161,769 matching assets These are port-based queries, which is a deliberate limitation. ZoomEye cannot confirm from the outside that a service on port 502 is a genuine Modbus device rather than another application using the port, and it cannot determine whether the device is a production controller, a lab unit, a simulator or a honeypot. The counts measure reachable ports associated with industrial protocols, not confirmed industrial control systems. ## Why port counts understate and overstate at the same time Two corrections are needed before using these numbers. They may overstate the industrial population. Port 502 and port 102 are not reserved exclusively for their nominal protocols. A honeypot network, a research scanner or a misconfigured service can occupy the port. Some of the 202,686 endpoints are certainly not industrial devices. They understate the actual exposure. Many industrial devices are reachable through other ports: web-based HMI interfaces on 80 or 443, vendor-specific management ports, and remote access services on the same host. A device that does not answer on 502 may still be fully controllable through a web interface. Port-based measurement captures one slice of a larger problem. The honest reading is that the counts establish scale for a known class of exposure while being imprecise about the exact population. ## What an attacker can do with reachability The consequences of reaching an unauthenticated industrial protocol depend on the device, but the categories are consistent:
  • Process manipulation. Writing to coils or holding registers can change setpoints, open or close valves, and alter the state of physical equipment, with safety implications that extend beyond data.
  • Reconnaissance. Reading registers and device identification reveals the process layout, the equipment vendor and the firmware version, which informs further targeting.
  • Denial of service. Malformed or rapid requests can disrupt a controller that was never designed to handle hostile traffic, halting a process without any need to understand it.
  • Pivot. An exposed controller or gateway is frequently dual-homed between the plant network and the corporate network, making it a bridge between the two. ## Practical next steps for defenders Enumerate before you argue. Query your own address space for ports 502 and 102, and separately for web interfaces on industrial devices. Compare the result with the asset inventory. Devices that appear in the scan but not in the inventory are the finding. Remove direct internet exposure. Industrial protocols should not be reachable from the public internet. Where remote access is required, it should go through an authenticated broker or a segmented gateway, not a port forward. Use a firewall that understands the protocol. A stateful firewall that permits only the specific function codes and register ranges an application needs is a stronger control than a port-level rule. Where that is not available, restrict source addresses to the specific engineering hosts. Segment the plant network from the corporate network. A dual-homed gateway defeats segmentation. Enforce the boundary at the gateway and monitor traffic crossing it. Log and baseline the protocol. Modbus and S7 traffic is highly regular in a stable process. Deviations, new function codes and requests from unexpected source addresses are detectable and are worth alerting on. Plan for the device you cannot patch. Many controllers cannot be updated or cannot be updated without a maintenance window. For those, network controls are the only available mitigation, which makes the segmentation work the priority. ## Limitations Port-based queries cannot distinguish a production controller from a simulator, a honeypot or an unrelated service that happens to use the port. They also cannot see devices reachable through web interfaces or vendor management ports, so the true exposure is larger than the counts suggest in some respects and smaller in others. The 202,686 figure should be read as evidence that unauthenticated industrial protocols remain reachable from the public internet at scale, and that any organisation with industrial infrastructure should verify its own exposure rather than assume a firewall rule from a previous project is still in place. ## References
  • CISA, "Guide to Operational Technology (OT) Security": https://www.cisa.gov/resources-tools/resources/guide-operational-technology-ot-security
  • NIST SP 800-82 Rev. 3, Guide to Operational Technology Security: https://csrc.nist.gov/pubs/sp/800/82/r3/final
  • CISA advisories on internet-exposed industrial control systems: https://www.cisa.gov/news-events/cybersecurity-advisories
  • ZoomEye search interface: https://www.zoomeye.ai/

Top comments (0)