Debian 13: Unexpected Port 5355 in the Daily Health Check

All examples use fictional data: server beispielserver.example.com.

Starting Point

In the morning, the daily health check of a newly configured Debian 13 server reported:

[WARN] unexpected public port 5355 listening

We had not opened port 5355 during setup and had not intended to use it on the server.

The first question was therefore not how to close the port, but: Which program opened it in the first place?

1. Identify the Listener and Process

With the appropriate options, ss shows not only the open listeners but also the associated process:

sudo ss -lntup | grep ':5355'

On the server, this produced:

udp   UNCONN 0 0 0.0.0.0:5355 0.0.0.0:* users:(("systemd-resolve",pid=384,fd=11))
udp   UNCONN 0 0 [::]:5355    [::]:*    users:(("systemd-resolve",pid=384,fd=13))
tcp   LISTEN 0 4096 0.0.0.0:5355 0.0.0.0:* users:(("systemd-resolve",pid=384,fd=12))
tcp   LISTEN 0 4096 [::]:5355    [::]:*    users:(("systemd-resolve",pid=384,fd=14))

This made the cause clear: systemd-resolved.

The service was listening on port 5355 over both TCP and UDP, on all IPv4 and IPv6 addresses.

2. Check the Cause

Port 5355 is used by LLMNR (Link-Local Multicast Name Resolution).

First, we checked whether LLMNR had been explicitly configured on the server:

grep -R '^[[:space:]]*LLMNR' \
    /etc/systemd/resolved.conf \
    /etc/systemd/resolved.conf.d/ 2>/dev/null

No output - we had not created any custom configuration for it.

The actual state of systemd-resolved could be checked with resolvectl:

resolvectl status

Excerpt:

Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens18)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

LLMNR was therefore active even though we had not configured it ourselves when setting up the server.

3. Selectively Disable LLMNR

systemd-resolved itself is still needed for DNS resolution. We therefore did not disable the entire service, but only the unneeded LLMNR functionality.

Create a dedicated drop-in directory:

sudo mkdir -p /etc/systemd/resolved.conf.d

Then create, for example, /etc/systemd/resolved.conf.d/10-disable-llmnr.conf:

[Resolve]
LLMNR=no

Then restart systemd-resolved:

sudo systemctl restart systemd-resolved

4. Verify the Configuration

First, check the resolver status again:

resolvectl status

The server then showed:

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens18)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

LLMNR is now disabled both globally and on the network interface.

What matters, however, is the actual listener. So, one final check:

sudo ss -lntup | grep ':5355'

No more output - port 5355 is closed.

The Health Check Behind It

The finding did not come from a targeted scan for LLMNR. The daily health check compares public listeners with the ports expected on the server.

That is how port 5355 was noticed in the first place:

[WARN] unexpected public port 5355 listening

In the future, the check will additionally take the firewall rules into account. This will make it easier to distinguish whether an unexpected listener is already blocked by the firewall or is actually reachable through an allowed port.

The Debian Health Check used here can be found in the public Lazy Admin Tools repository. The project is also mirrored on GitHub.

Result

Health check warning → listener identified with ss → systemd-resolved found as the cause → LLMNR confirmed with resolvectl → selectively disabled → port 5355 disappeared.

Not a large tutorial about systemd-resolved or LLMNR, but a small finding from day-to-day server operations - and exactly why the health check keeps an eye not only on known services, but also on unexpected public listeners.