Restrict network access to CAST Imaging

Overview

A default CAST Imaging installation listens on every network interface, so any machine that can reach the host can also reach the internal components directly, bypassing the gateway. This page describes the host firewall rules that leave only the gateway reachable from the network, and is intended for administrators hardening an installation on Microsoft Windows or Linux via Docker/Podman.

No CAST Imaging configuration files are changed: the rules are applied in the host firewall, either with the sample scripts provided on this page or with your own tooling.

Network rules

• Browsers reach the SSO/Keycloak login pages through the gateway, so the SSO port never needs to be reachable from the network.
• The rules include ports that no user interface answers on, in particular 2381 (Control Panel internal broker) and, on Microsoft Windows, 9002 (SSO Service). Restrict them like every other internal port.
• On Linux, the embedded PostgreSQL instance (DB_MODE=embedded in configuration.conf, the default) is restricted like every other port, on 2285.
• The “other CAST Imaging machines” are the machines hosting the analysis nodes, dashboards and viewer, plus any machine hosting the CAST Imaging MCP Server, which also registers with the Control Panel on 8098.
• Traffic from the machine itself (loopback) and, on Linux, between containers is not affected, so local access keeps working.

The rules do not cover:

• An external database: the PostgreSQL instance on Microsoft Windows (2284), or on Linux with DB_MODE=external. Restrict it according to your own database security policy.
• Operating system ports such as RDP, SMB, WinRM or SSH.
• The ports of the CAST Imaging MCP Server and the CAST MCP Server for Gatekeeper themselves, which are installed separately and have their own port requirements.

Ports to restrict

Restrict every port below except 8090. Only the ports of the components installed on a given machine are in use there. Where you changed a default port during the installation, use the value set in the installer configuration file used on the machine:

• Microsoft Windows: config-all.conf on a single machine. In a distributed installation, the file of the component installed on the machine: config-imaging-services.conf, config-analysis-node.conf, config-dashboards.conf or config-imaging-viewer.conf.
• Linux: configuration.conf.

• Microsoft Windows
• Linux via Docker/Podman

Requirements

• Administrator (Microsoft Windows) or root (Linux) access on each CAST Imaging machine.
• In a distributed installation, the IP address or host name of every other CAST Imaging machine. Host names must be resolvable (DNS or hosts file) from each machine.

You can apply the rules before or after installing CAST Imaging. Apply them again whenever a port changes, a CAST Imaging machine is added, or the IP address of a CAST Imaging machine changes.

Apply the rules

Use the sample scripts

CAST provides sample scripts that read the port numbers from the installer configuration file and apply the rules above. They are provided as samples: review what they will do with a dry run before applying them, and adapt them to your own process if needed.

Run the scripts on each CAST Imaging machine. They take the port numbers from the installer configuration file used on that machine, so that file must contain the port numbers that the installation uses:

• Microsoft Windows: config-all.conf on a single machine. In a distributed installation, the file of the component installed on the machine: config-imaging-services.conf, config-analysis-node.conf, config-dashboards.conf or config-imaging-viewer.conf.
• Linux: configuration.conf.

In a distributed installation, list the other CAST Imaging machines as IP addresses, IP/CIDR ranges or host names, separated by commas, either in IMAGING_SERVERS at the top of the script or on the command line, as shown below. If a listed host name cannot be resolved, the script stops without changing anything. Machines named in the *_HOSTNAME entries of the configuration file are added automatically, so listing them again does no harm:

• On the analysis node, dashboards and viewer machines, these entries name the imaging-services machine, which is therefore allowed automatically.
• On the imaging-services machine, the configuration file does not name the other machines: list every analysis node, dashboards, viewer and MCP Server machine explicitly, otherwise they cannot register with the Control Panel.

• Microsoft Windows
• Linux via Docker/Podman

Use your own tooling

• Microsoft Windows
• Linux via Docker/Podman

table inet cast_imaging {
  set internal_ports {
    type inet_service
    elements = { 2285, 2381, 8089, 8091, 8092, 8096, 8097, 8098 }
  }

  set nodes4 {
    type ipv4_addr
    flags interval
    elements = { 192.0.2.11, 192.0.2.12 }
  }

  chain prerouting {
    type filter hook prerouting priority -150; policy accept;

    iifname "lo" accept
    iifname "docker0" accept
    iifname "podman*" accept
    iifname "br-*" accept
    iifname "cni*" accept
    iifname "veth*" accept
    fib daddr type != local accept

    tcp dport @internal_ports ip saddr @nodes4 accept
    tcp dport @internal_ports counter drop
  }
}

Check the configuration

1. From a machine that is not part of the CAST Imaging installation, test each port, for example with nc -zv <host> <port> or Test-NetConnection <host> -Port <port>. Port 8090 must connect, and every other CAST Imaging port, including 8098, must time out or be refused.
2. In a distributed installation, repeat the test from another CAST Imaging machine: 8098 and the internal ports must connect.
3. Open http://<host>:8090 from a remote browser, log in, open an application in the viewer and the dashboards, then run an analysis. Each step must complete without an error.