Network Ports and Firewall

This page lists the ports the UTMStack v12 server uses, the ports you must block, and the connections the server makes to the internet. It also gives firewall examples for ufw, AWS, Azure and Google Cloud. Ports that devices need on the UTMStack Forwarder are listed in Ports and Network Requirements. The ports the services use inside the server are listed in Server Services and Files Reference.

Inbound ports on the UTMStack server

Port 443 carries everything

In UTMStack v12, agents and collectors connect to the server on 443/TCP only: registration, log streams, heartbeats, commands and downloads all use it. The web interface and the API use the same port.

Ports that UTMStack v12 no longer uses

If you are coming from UTMStack v11, you can remove firewall rules for these ports on the v12 server:

Docker Swarm

The installer starts Docker Swarm on the server. Docker Swarm listens on its own cluster ports (2377/TCP, 7946/TCP and UDP, 4789/UDP). UTMStack v12 uses a single server, so no other machine needs to reach these ports. Do not allow them from outside.

Ports for data sources

• Agents (Windows, Linux, macOS), the UTMStack Forwarder and collectors connect to the UTMStack server on 443/TCP.

• Network devices (firewalls, switches, hypervisors and others) send syslog or NetFlow to the UTMStack Forwarder, not to the UTMStack server. Open the Forwarder's ports on the machine where it runs. See Ports and Network Requirements and UTMStack Forwarder.

• Cloud integrations (for example AWS, Microsoft Azure, Google Cloud, Microsoft 365, CrowdStrike and Sophos Central) need no inbound port. The UTMStack server connects out to them over HTTPS.

Outbound connections from the UTMStack server

If your firewall filters outbound traffic by host name, also allow the hosts these services redirect downloads to: *.githubusercontent.com for GitHub and ghcr.io, and registry-1.docker.io, auth.docker.io and production.cloudflare.docker.com for Docker Hub.

Firewall examples

Ubuntu and Debian with ufw

nginx and Cockpit run directly on the server, so a host firewall such as ufw controls ports 22, 80, 443 and 9090. Replace the example addresses with your own networks.

# Default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH from the administrator workstation only
sudo ufw allow from 192.168.1.100 to any port 22 proto tcp

# Web interface from the SOC network
sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 443 proto tcp

# Agents, the UTMStack Forwarder and collectors
sudo ufw allow from 10.0.0.0/8 to any port 443 proto tcp

# Cockpit from the administrator workstation only
sudo ufw allow from 192.168.1.100 to any port 9090 proto tcp

# Turn the firewall on and check the rules
sudo ufw enable
sudo ufw status verbose

On Red Hat Enterprise Linux, the installer stops and disables firewalld. Filter traffic on the network firewall or cloud security group in front of the server.

AWS security group

{
  "SecurityGroupIngress": [
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "CidrIp": "10.0.0.0/8",
      "Description": "Web interface, API, agents and collectors"
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 80,
      "ToPort": 80,
      "CidrIp": "10.0.0.0/8",
      "Description": "Redirect to HTTPS"
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 22,
      "ToPort": 22,
      "CidrIp": "ADMIN_IP/32",
      "Description": "SSH from the administrator"
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 9090,
      "ToPort": 9090,
      "CidrIp": "ADMIN_IP/32",
      "Description": "Cockpit from the administrator"
    }
  ]
}

A security group denies everything that no rule allows, so port 10001 stays closed as long as you do not add a rule for it.

Azure network security group

az network nsg rule create 
  --resource-group UTMStack-RG 
  --nsg-name UTMStack-NSG 
  --name Allow-HTTPS 
  --priority 100 
  --source-address-prefixes "ANALYST_AND_AGENT_NETWORKS" 
  --destination-port-ranges 443 
  --protocol Tcp 
  --access Allow

Create similar rules for 80, 22 and 9090 with the sources from the table above. Do not create a rule for 10001. Azure's default rule AllowVnetInBound still lets machines in the same virtual network reach every port; if that matters, add a rule that denies 10001/TCP with a lower priority number than 65000.

Google Cloud firewall rules

gcloud compute firewall-rules create utmstack-https 
  --network=default --direction=INGRESS --action=ALLOW 
  --rules=tcp:443 --source-ranges=ANALYST_AND_AGENT_NETWORKS --target-tags=utmstack

gcloud compute firewall-rules create utmstack-admin 
  --network=default --direction=INGRESS --action=ALLOW 
  --rules=tcp:22,tcp:9090 --source-ranges=ADMIN_IP/32 --target-tags=utmstack

Give the server the network tag utmstack. Do not create a rule for 10001. In the default network, the rule default-allow-internal still lets machines in the same network reach every port; if that matters, add a deny rule for 10001/TCP with a higher priority (a lower number).

For complete cloud setups (machine, disks, fixed addresses and DNS), see Install on AWS, Azure or Google Cloud.

Test the ports

From another machine:

# Port 443 should be open
nc -zv UTMSTACK_IP 443

# The health check should answer {"status":"ok"}
curl -k https://UTMSTACK_IP/api/ping

# Port 10001 should NOT be reachable from outside
nc -zv -w 5 UTMSTACK_IP 10001

On the server, list the ports that are listening:

sudo ss -tlnp

Troubleshooting

# Is nginx listening on 443?
sudo ss -tlnp | grep ':443'

# Is nginx running?
systemctl status nginx

# Check the firewall rules
sudo ufw status numbered

# Test from the server itself
curl -k https://localhost/api/ping

curl -k https://UTMSTACK_IP/api/ping