Skip to main content

Modbus TCP

The Corsha Gatekeeper provides MFA protection for Modbus TCP communications using session-based credential enforcement in proxy mode deployments.

How Corsha Enhances Modbus TCP Security​

Standard Modbus TCP has no native authentication—any client that can reach a Modbus server can send commands. This leaves industrial control systems vulnerable to unauthorized access and manipulation.

Corsha adds multi-factor authentication to Modbus TCP connections through the Corsha Gatekeeper, which injects and validates MFA credentials at the protocol level.

Session-Based MFA​

Unlike HTTP where each request is independently authenticated, Modbus TCP uses a session-based MFA model:

How Sessions Work​

  1. Client Establishes Connection: A Modbus TCP client connects to the Corsha Authenticator
  2. Session Authentication: The Authenticator injects a Corsha MFA credential into the first Modbus TCP message
  3. Gatekeeper Validation: The Corsha Gatekeeper validates the credential and establishes a trusted session
  4. Subsequent Messages: Additional Modbus commands within the session timeout window are permitted without re-authentication

Session Configuration​

Sessions are configured with two parameters:

  • timeout: Maximum time between messages before the session expires (e.g., 5s, 10s)
  • maxMessages: Maximum number of Modbus messages allowed per credential before re-authentication is required

This session-based approach balances security with the performance requirements of industrial control systems, where Modbus clients often send rapid sequences of commands.

Example Scenario​

With a configuration of timeout: 10s and maxMessages: 5:

  1. Client sends command 1 → New credential validated, session created
  2. Client sends commands 2-5 → Allowed within session
  3. Client sends command 6 → Requires new credential (maxMessages exceeded)
  4. Client waits 15 seconds → Session expires, next command requires new credential

Key Features​

  • Client-Side Protection: Authenticators deployed alongside Modbus TCP clients inject credentials transparently
  • Server-Side Enforcement: Corsha Gatekeepers validate credentials and manage sessions before forwarding traffic
  • Session Management: Tracks active sessions and enforces timeout and message limits
  • No Application Changes: Modbus client and server applications require no modifications

Deployment Considerations​

Performance Impact​

The Corsha Gatekeeper adds minimal latency to Modbus TCP connections:

  • First message: ~5-10ms for credential validation and session establishment
  • Subsequent messages: <1ms (in-memory session lookup)

Industrial Control Requirements​

Session-based MFA is designed for industrial control environments:

  • Low latency: Critical for real-time control operations
  • Command bursts: Supports rapid sequences of Modbus commands common in SCADA systems
  • Deterministic behavior: Session parameters provide predictable credential refresh patterns

Compatibility​

The Modbus TCP implementation supports:

  • Modbus TCP: Standard Modbus over TCP/IP
  • Function codes: All standard Modbus function codes (read/write coils, registers, etc.)
  • Multiple clients: Concurrent sessions from different Modbus clients

Configuration​

Modbus TCP is configured in the Gatekeeper configuration file:

modbusTcp:
  listenPort: 502
  upstream:
    host: "modbus-server.local"
    port: 502
    protocol: MODBUSTCP
  credEnforcement:
    timeout: 10s      # Session expires after 10 seconds of inactivity
    maxMessages: 5    # Require new credential after 5 messages

Configuration Parameters​

  • listenPort: Port where Gatekeeper listens for Modbus TCP connections
  • upstream.host: Hostname or IP of the protected Modbus server
  • upstream.port: Port of the protected Modbus server
  • credEnforcement.timeout: Session timeout duration (e.g., 5s, 10s, 30s)
  • credEnforcement.maxMessages: Maximum messages per credential

Tuning Guidelines​

High-frequency polling systems (e.g., HMI displays updating every second):

timeout: 30s
maxMessages: 100

Low-frequency control systems (e.g., operator commands):

timeout: 5s
maxMessages: 3

Default recommendations (balanced security and performance):

timeout: 10s
maxMessages: 10

Next Steps​

For deployment instructions and configuration details, see the Gatekeeper Docker or Helm Chart guides.

For information about other supported protocols, see OPC UA.