Network connections

This document provides a comprehensive overview of the network connections required for a Linksight installation. It is intended for system and network administrators who need to configure firewalls and network access for Linksight components.

Architecture Overview

The Linksight installation is part of a larger distributed system, and contains the following components:

1. Data station: Executes secure Multi-Party Computation (MPC) protocols in collaboration with data stations from partner organizations.
2. Analysis Hub: Provides an interface for data scientists to initiate, monitor, and manage data analyses.
3. Linksight Supervisor for Docker (LSD) (Docker deployments only): Manages automated deployment, updates, and monitoring of the data station and Analysis Hub components.

The platform is supported by additional infrastructure components:

• Collaboration Services: Orchestrates data collaborations between organizations, handling authentication, authorization, and coordination.
• Container Registry: Hosts and distributes the official Linksight container images, ensuring consistent deployments across environments.

The diagram below illustrates the network architecture and connections between these components:

Required Connections and Firewall Rules

The following tables outline the necessary network connections for a Linksight installation. These firewall rules are defined from the perspective of the virtual machine hosting the Linksight components.

info

For most installations, the IP address of the data station and Analysis Hub are the same.

Data Station and Analysis Hub

Direction	Protocol	Port	Source	Destination	Purpose
EGRESS	TCP	443	[ data station + Analysis Hub IP ]	https://registry.linksight.network	Container image registry access
EGRESS	TCP	443	[ data station + Analysis Hub IP ]	https://services.linksight.network	Linksight services access
EGRESS	TCP	443	[ data station + Analysis Hub IP ]	https://setup.linksight.network	Setup information retrieval

Data Station Peer-to-Peer Communication

info

Ports 8443 and 9090 are secured with mutual TLS (mTLS) authentication, ensuring that connections can only be established between trusted peers that possess valid certificates. The Linksight platform automatically manages this certificate-based authentication system. For more details, see the Mutual TLS for Peer-to-Peer Connections section below.

Direction	Protocol	Port	Source	Destination	Purpose
INGRESS	TCP	8443	0.0.0.0/0 *	[ data station IP ]	mTLS HTTP server for peer-to-peer connections
INGRESS	TCP	9090	0.0.0.0/0 *	[ data station IP ]	mTLS gRPC server for peer-to-peer connections
EGRESS	TCP	8443	[ data station IP ]	0.0.0.0/0 *	mTLS HTTP client for peer-to-peer connections
EGRESS	TCP	9090	[ data station IP ]	0.0.0.0/0 *	mTLS gRPC client for peer-to-peer connections

note

*) For enhanced security, we recommend implementing IP-based firewall restrictions to limit peer-to-peer connections exclusively to known partner organizations' data stations. You can identify the IP addresses of legitimate peers through either:

• The Network Status page in the Governance/Analysis Hub interface, which displays all trusted peers with their IP addresses.
• Connection log lines in the data station logs, which records IP addresses of new incoming connections and failing outgoing connections.

Analysis Hub Internal Network Access

Direction	Protocol	Port	Source	Destination	Purpose
INGRESS	TCP	8000	[ Analysis Hub IP ]	Internal IP range	Analysis Hub frontend access
INGRESS	TCP	8080	[ Analysis Hub IP ]	Internal IP range	Analysis Hub API access (required for Linksight Python Interface)

Security Considerations

Firewall Configuration

• Organizations should configure their firewalls to allow the required connections.
• For Windows installations, specific firewall rules may be needed:

  netsh advfirewall firewall add rule name="Allow Linksight mTLS HTTP" dir=in action=allow protocol=TCP localport=8443
  netsh advfirewall firewall add rule name="Allow Linksight mTLS gRPC" dir=in action=allow protocol=TCP localport=9090

TLS for Analysis Hub

• The Analysis Hub can be configured to use TLS for securing frontend connections.
• TLS certificates can be:
  • Automatically issued using Let's Encrypt: learn more
  • Manually provided by the organization: learn more
  • Handled by a reverse proxy.

Mutual TLS for Peer-to-Peer Connections

Trust Establishment

The Linksight platform implements a robust mutual TLS (mTLS) authentication system to secure communications between data stations:

• Certificate Management: Linksight manages certificates for all data stations in the network independently without operating a central Certificate Authority (CA).
• Certificate Lifecycle: Each data station registers a client certificate on the platform during initial setup, which is automatically rotated periodically according to security best practices.
• Authentication Flow: During connection establishment, data stations exchange and validate certificates against a trusted certificate store maintained by the Linksight platform.
• Mutual Authentication: Both parties in any connection are verified through this certificate exchange, ensuring only trusted data stations can communicate with each other.
• Collaboration-Based Trust Model: Data stations can only establish connections with partner data stations that are part of the same data collaboration(s). Other data stations are not part of the trusted certificate store and therefore cannot establish connections.

When data station A connects to data station B:

1. A TLS handshake is initiated between the data stations
2. Both data stations present their unique certificates
3. Each data station validates the other's certificate against its trusted certificate store
4. The connection is established only after successful mutual verification, ensuring only authorized data stations within the same data collaboration can communicate

SSL Offloading, Deep Packet Inspection and Web Application Firewalls

Some organizations implement security measures such as SSL offloading/bridging, Deep Packet Inspection (DPI), and Web Application Firewalls (WAF) to enhance their network security. However, these technologies present compatibility challenges with Linksight's mTLS implementation.

Compatibility Challenges

Network security technologies like SSL Offloading, SSL Bridging, DPI, and WAF are fundamentally incompatible with Linksight's mTLS implementation because they intercept, examine, and often modify encrypted traffic between endpoints:

• SSL Offloading/SSL Bridging: SSL offloading and SSL bridging terminate the original TLS connection, breaking the end-to-end trust model. Data stations will not be able to verify each other's identity through the mTLS handshake and establish secure connections within their data collaborations. These technologies provide no security benefit for Linksight's traffic, as they merely replace one secure connection with another while breaking the critical mutual authentication.

• Deep Packet Inspection/Web Application Firewalls: These security systems fundamentally cannot provide value for Linksight's traffic for several key reasons:

  • Linksight's network traffic after TLS decryption consists primarily of large encrypted data payloads between authenticated servers, not traditional web application traffic
  • The server-to-server nature of communications means typical web vulnerabilities (XSS, CSRF, SQL injection) that WAFs protect against are not applicable
  • Content-based routing decisions cannot be made on large encrypted payloads
  • The traffic patterns (high-volume data transfers with complex binary protocols) are unsuitable for inspection-based security controls
  • These technologies require the ability to inspect the payload of the encrypted TLS traffic, which breaks the end-to-end encryption. Data stations will not be able to verify each other's identity through the mTLS handshake and establish secure connections within their data collaborations.

The Linksight mTLS implementation already provides comprehensive security through:

• Strong certificate-based mutual authentication
• Automatic certificate rotation on a regular schedule
• Strict collaboration-based trust boundaries
• End-to-end encryption with modern cipher suites

Recommended Network Configuration

For successful Linksight deployments, we recommend:

• Inspection Exclusion: Configure network security devices to exclude Linksight mTLS traffic (ports 8443 and 9090) from inspection
• Direct Connections: Allow direct, uninterrupted mTLS connections between data stations
• Perimeter Security: Implement network-level controls (IP filtering, rate limiting, and access control lists) rather than attempting to inspect encrypted traffic

Attempting to add intermediate inspection layers provides no additional security benefits while compromising the fundamental trust model that ensures secure peer-to-peer communications.

Using Forward Proxies

Linksight components have native support for forward proxies. This feature enables the routing of outgoing traffic from Linksight components through a designated proxy server, enhancing network management and security.

Configuring Forward Proxies in Docker

The Linksight components will automatically use the proxy settings configured in Docker. To set up a forward proxy for Docker, follow these steps:

• If you're running Docker Desktop:
  • Docker Desktop automatically detects and uses the system proxy. Alternatively, the proxy server can be manually specified.
  • To manually specify the proxy server in Docker Desktop: go to Settings > Resources > Proxies.
  • Refer to configuring Docker Desktop to use HTTP/HTTPS proxies for more information.
• If you're running Docker Engine without Docker Desktop:
  • The recommended way is configuring the daemon using a daemon.json file:

    {
      "proxies": {
        "http-proxy": "http://proxy.example.com:3128",
        "https-proxy": "https://proxy.example.com:3129",
        "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
      }
    }
  • The default location of daemon.json is: (from https://docs.docker.com/engine/daemon/)
    • Linux, regular setup: /etc/docker/daemon.json
    • Linux, rootless mode: ~/.config/docker/daemon.json
  • After changing the configuration file, restart the daemon for the proxy configuration to take effect:

    $ sudo systemctl restart docker
  • Refer to Configure the Docker daemon to use a proxy to learn how to configure a proxy server for the Docker daemon (dockerd) itself.

Once the proxy settings are configured in Docker, the Linksight components will automatically use these settings for their outgoing network connections.