Unintentional exposure of bound services due to inactive default ufw

Direct answer

There is no confirmed public roadmap for KDE Neon to ship a default-deny-incoming ufw policy in future editions. The reliable path today is to configure ufw manually on the existing Ubuntu LTS base.

What is actually happening

KDE Neon installs the Uncomplicated Firewall package but leaves it inactive. When ufw is inactive, the kernel-level netfilter rules are not managed by ufw, so the effective incoming policy is to accept all traffic. Any daemon listening on 0.0.0.0—including development servers, databases, or debug ports—is reachable from any interface, including untrusted LANs or the public internet if the host is directly exposed.

Recommended default-deny policy set

Apply these rules before enabling the firewall. If you connect over SSH, add an allow rule for your SSH port first to avoid lockout.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 1714:1764/tcp
sudo ufw allow 1714:1764/udp
sudo ufw allow from 172.17.0.0/16
sudo ufw enable

This blocks unsolicited inbound connections while preserving outbound access. The 1714:1764 range covers KDE Connect discovery and transfer on TCP and UDP. The 172.17.0.0/16 rule permits traffic from the default Docker bridge subnet.

Important caveats

• If you use a custom Docker bridge, rootless Docker, or another container runtime, 172.17.0.0/16 may be incorrect and could either fail to permit container traffic or unnecessarily widen the allowed range.
• KDE Connect may use additional ports for specific plugins or file-transfer features; verify pairing and transfer after enabling.
• Any other inbound service (SSH, local web servers, etc.) must be explicitly allowed before ufw enable.

Verification

Confirm the active policy and rules:

sudo ufw status verbose

Expected output includes Status: active and Default: deny (incoming), allow (outgoing). Test KDE Connect from a paired device and confirm container port access from the host.

Missing detail that changes the rule

Please provide the exact subnet of your container bridge—for example, the output of docker network inspect bridge or ip addr show docker0. If the subnet is not 172.17.0.0/16, the allow rule above must be adjusted to match your environment.