Remote-management ports
medium external
What it inspects
Opens a plain TCP connection to each of these ports on the scanned host and records whether it connects: 3389 (RDP), 5900 and 5901 (VNC), 2375 (Docker API, plain), 2376 (Docker API, TLS), 6443 (Kubernetes API), 10250 (Kubelet), 2379 (etcd). It sends nothing and never logs in. Any port that connects is a WARN. SSH (22) and web ports (80/443) are deliberately not flagged. This is an active check: it runs only after you have verified ownership of the host.
Why it matters
These interfaces control the machine or the whole cluster: an unauthenticated Docker API is root on the host, an open kubelet or etcd can expose or alter every workload, and RDP and VNC are constant targets for password guessing. An open port is not proof of a breach, but it is attack surface that a VPN or an address allow-list removes at no cost.
How to verify
# only against hosts you own
nmap -Pn -p 3389,5900,5901,2375,2376,6443,10250,2379 example.com
# Every port should be reported closed or filtered (or, for 6443, open only from your allow-listed addresses).
How to fix
Bind each interface to loopback or a private address and tunnel to it, or limit the port to the addresses that need it at the firewall.
Decide who needs each interface and shrink its audience needs your judgement
Any distro
# Management interfaces give whoever reaches them control of the machine or the cluster. Find out which are listening:
# ss -tlnp '( sport = :3389 or sport = :5900 or sport = :5901 or sport = :2375 or sport = :2376 or sport = :6443 or sport = :10250 or sport = :2379 )'
# Then, per interface, pick the smallest audience that still works. Back up a config file before editing it.
#
# RDP (3389), usually xrdp: in the [Globals] section of /etc/xrdp/xrdp.ini set
# address=127.0.0.1
# restart with systemctl restart xrdp, then connect through an SSH tunnel: ssh -L 3389:127.0.0.1:3389 user@example.com
# VNC (5900, 5901): start the server bound to loopback (x11vnc: -localhost ; TigerVNC: -localhost yes) and use the same kind of
# SSH tunnel. VNC passwords are weak protection on their own.
# Docker API (2375 plain, 2376 TLS): 2375 is unauthenticated and equals root on the host. Find where the TCP listener is set:
# systemctl cat docker | grep -e '-H'
# grep -n hosts /etc/docker/daemon.json
# Remove the tcp:// entry and keep the local socket (fd:// or unix:///var/run/docker.sock). Putting "hosts" in daemon.json
# AND -H in the service file makes dockerd refuse to start, so change one place only. Run `systemctl daemon-reload` after editing
# a unit file, then `systemctl restart docker` (restarting the daemon stops running containers unless live-restore is enabled in daemon.json; plan for it). Administer remotely over SSH instead:
# docker context create remote --docker "host=ssh://user@example.com"
# 2376 requires a client certificate; if you meant to expose it, leave the daemon alone and restrict who may connect (next step).
# Kubernetes API server (6443): nodes and admins need it, the open internet does not. Restrict by source address (next step) or put the
# control plane on a private network behind a VPN.
# Kubelet (10250): never public. In the kubelet configuration set authentication.anonymous.enabled: false and authorization.mode: Webhook,
# and firewall the port to the control plane.
# etcd (2379): it holds all cluster state. Set --listen-client-urls to loopback or a private address, and require client certificates (--client-cert-auth).
#
# Re-test from outside afterwards (only against hosts you own):
# nmap -Pn -p 3389,5900,5901,2375,2376,6443,10250,2379 example.com
- Limit what must stay public to known addresses
1 more step in the Fix Pack. See pricing