Introduction
Running a public-facing server requires constant vigilance, especially when it comes to security. While we often focus on the big-ticket items like firewalls and web server configurations, sometimes it’s the smaller, less-known services that can open the door to vulnerabilities. One such service on many modern Linux systems, including Debian 12, is the Link-Local Multicast Name Resolution (LLMNR) protocol. By default, it’s enabled and listens on port 5355, a behavior that is completely normal for a local network but potentially risky for a public server. In this post, we’ll explore what LLMNR is, why it’s a concern for public servers, and walk through the simple steps to disable it, making your server just a little bit more secure.
Identifying the Application
First, you can use ss (socket statistics) to find the process ID (PID) associated with the port. The ss command is the modern replacement for netstat and is generally faster and more efficient.
- Open your terminal and run the following command:
sudo ss -tulnp | grep 5355sudo: This is required to see the process name and PID, which are often owned by other users or the system.-t: Shows TCP sockets.-u: Shows UDP sockets.-l: Shows listening sockets.-n: Shows numerical addresses and port numbers instead of trying to determine hostnames and service names.-p: Shows the process using the socket.| grep 5355: This pipes the output ofssto thegrepcommand, which filters for lines containing “5355”.
tcp LISTEN 0 128 0.0.0.0:5355 0.0.0.0:* users:(("systemd-resolve",pid=12345,fd=13))From this output, you can see the process name is systemd-resolve and the PID is 12345. This immediately tells you thatsystemd-resolvedis the application using that port.
What is It?
Port 5355 is the standard port for Link-Local Multicast Name Resolution (LLMNR). This is a protocol that allows devices on the same local network (without a central DNS server) to discover each other’s names. For example, it’s what lets you easily connect to a printer or another computer on your home network without needing to manually configure an IP address.
systemd-resolved is the service in Debian 12 that provides this functionality, along with other name resolution features. It’s an integral part of how the system handles DNS and local network discovery.
Is it a Security Risk?
While having systemd-resolved listening on port 5355 is normal, it can sometimes be a concern, especially on a public server. LLMNR broadcasts can be vulnerable to certain security attacks, like LLMNR poisoning, where an attacker can impersonate a device to intercept network traffic.
On a public server, this is often unnecessary because the server typically relies on external DNS servers rather than local network discovery. If your server doesn’t need to resolve local hostnames on its network, you can consider disabling the LLMNR functionality to reduce its attack surface.
How to Disable It
If you decide that the LLMNR service isn’t needed for your specific use case, you can disable it by editing the systemd-resolved configuration file.
1. Open the configuration file with a text editor:
sudo nano /etc/systemd/resolved.conf
2. Find the [Resolve] section and add or uncomment the following line:
[Resolve] LLMNR=no
3. Save the file and exit the editor.
4. Restart the systemd-resolved service for the changes to take effect:
sudo systemctl restart systemd-resolved.service
After restarting the service, port 5355 should no longer be listening, and the LLMNR protocol will be disabled.
Final Thoughts
By disabling the LLMNR protocol and stopping the service on port 5355, we’ve taken a small but meaningful step to harden our server’s security posture. While LLMNR is a useful feature for local network discovery, its broadcast-based nature makes it an unnecessary risk on a public server that doesn’t need to resolve hostnames in this manner. Remember, server security is an ongoing process of reducing the attack surface. Every port you close and every unnecessary service you disable contributes to a more robust and secure environment. Keep this in mind as you continue to manage your servers—small changes can make a big difference.
