Minimise services and packages

Find every listener, remove what you do not need.

After patching, the cheapest control is to run less. A listening socket is code that anyone who can reach the port can talk to, and every installed package is code that can carry a vulnerability or help an intruder who is already in. In this lesson you take an inventory of what a server exposes, trace each listener to the unit, package and setting behind it, switch off what is not needed at the right strength, bind what must stay to the local machine, and check the result from another host instead of trusting the configuration.

What a fresh install exposes

Linux essentials showed how to read sudo ss -tulpn: 0.0.0.0 and [::] mean every address the machine has, 127.0.0.x and [::1] only the machine itself, and %eth0 one interface. Here is the baseline of an untouched install.

On this untouched Ubuntu Server 26.04 install, SSH on TCP 22 is open to the network; systemd appears next to sshd because ssh.socket holds the port (socket activation, from Linux essentials). The DHCP client of systemd-networkd uses UDP 68 on eth0 to get the address. Everything else is loopback: the systemd-resolved DNS stub on 127.0.0.53 and 127.0.0.54, and chrony's command port 323. The exception is UDP 5353 (multicast DNS) on every address, and it is not Ubuntu's doing, as the next section shows. So the network-facing surface of a default install is SSH and the DHCP client, which is a good starting point.

ss covers only TCP and UDP; systemctl list-sockets shows every socket unit. As Linux essentials explained, systemd-ssh-generator adds sshd on AF_VSOCK port 22 inside a VM (reachable only from the hypervisor host, which on a cloud VM is your provider's) and a local Unix socket; systemd.ssh_auto=no on the kernel command line turns that off (systemd-ssh-generator(8)).

Services that do not listen still matter, because each is code running on your server. List what runs:

lima-guestagent, the sshd@... vsock connection and user@502 (the tool's login session) belong to the lab's VM tool. Among Ubuntu's own services, ModemManager handles cellular modems, multipathd manages storage reached over several paths (a SAN), and udisks2 manages disks on behalf of desktop tools. A cloud VM usually needs none of them; multipathd must stay on a server whose disks are multipath. They take the same stop, disable and mask steps as the listener below.

Trace a listener to its cause

A listener you cannot explain is a finding until you can. The 5353 socket above belongs to systemd-resolved. On the working lab machine, go from the process to the unit to the configuration.

ps -o unit= turns the PID from ss into the systemd unit. systemd-analyze cat-config prints the main configuration file and every drop-in in the order they apply (the grep keeps file names and settings). Ubuntu ships 00-disable-mdns.conf with MulticastDNS=no. The VM tool adds 00-lima-enable-mdns.conf with MulticastDNS=yes, and because its name sorts later, it wins. A plain Ubuntu server does not answer multicast DNS queries from the local network; these lab machines do.

The fix is another drop-in whose name sorts last. Comments go on their own lines: systemd's configuration files do not support a comment after a value.

[Resolve]
# SecOpsLog: no multicast DNS on servers (Ubuntu's own default).
# This file sorts after the VM tool's 00-lima-enable-mdns.conf, so it wins.
MulticastDNS=no

ss prints only its header, and resolvectl reports -mDNS globally and on the link. The operational impact is that names ending in .local no longer resolve on this host, which a server rarely needs. To roll back, delete the file and restart systemd-resolved. The control restores Ubuntu's default; keeping it is SecOpsLog advice.

Off, and how far off

systemd gives four strengths of "off". stop ends the running process now. disable removes the links that start it at boot. mask links the unit to /dev/null, so nothing can start it: not a person, not another unit that depends on it, not a socket. Purging the package removes its files and configuration. rpcbind shows why the difference matters. It maps RPC services to ports and is needed for NFS versions 2 and 3, which is why nfs-common depends on it. The CIS RHEL 10 Level 1 server profile (scap-security-guide 0.1.82, introduced in the first lesson) includes a rule that it be disabled. To follow along, install it with sudo apt install rpcbind, as nfs-common would.

Port 111 is open on every address, over TCP and UDP. Both rpcbind.service and rpcbind.socket are enabled, and systemd co-owns the sockets: rpcbind is socket-activated. Disable the service the obvious way:

The first two lines appear because rpcbind still ships an old-style init script, which systemd's helper disables as well. The unit links are removed, including the socket's, because the service names the socket under Also=. But --now stopped only the service, and systemctl says so: its triggering unit, rpcbind.socket, is still active. Port 111 is still open, now held by PID 1 alone, and the next connection would start rpcbind again. When ss shows systemd as the only owner of a port, look for a .socket unit.

Check it the way an attacker would, from another machine on the same network, such as your laptop with nmap installed (it is not on a default server; nc -zv SERVER 111 also tests one port). In the lab the other machine is a second network namespace wired to the server, which is 198.51.100.1 on that link. nmap -n -sT -p 111 makes a full TCP connection to port 111 and skips reverse DNS lookups (-n).

Stop the socket as well, then mask both units so that nothing can start them again:

disable --now on the socket prints nothing because its links were already gone, but it stops the socket. Masking both units makes the decision stick; the failed start and the closed port seen from outside are your verification. The impact is that anything needing rpcbind, such as an NFS version 3 mount, now fails until you unmask it. The rollback is unmask and enable --now on the socket:

If nothing on the server needs it, purge the package. Reinstalling it is the rollback, but the configuration a purge deletes does not come back.

Packages: less code on disk

A default install has 682 packages, 42 of them marked as installed by hand (apt-mark showmanual); the rest came in as dependencies. The telnet and FTP clients are there by default. They are clients, not listeners, so they add no open port, but they send credentials in clear text, and the CIS RHEL 10 profile requires them removed. The telnet client goes cleanly:

The FTP client does not. Ubuntu's ubuntu-standard metapackage depends on ftp or ftp-ssl, so the simulation (-s) shows apt installing ftp-ssl to keep that dependency satisfied. Removing ubuntu-standard itself has a wider effect:

Everything the metapackage pulled in becomes "no longer required", and the next apt autoremove would take nano, rsync, tcpdump and sysstat with it. SecOpsLog advice: keep ubuntu-standard and accept the FTP client, or remove the metapackage and mark the tools you use as manual (apt-mark manual) first. Listeners are the higher priority either way. The rollback for a removal is reinstalling the package.

The best time to minimise is at install time. Recommended packages are installed by default, and they can be large:

aide alone is one package; with its recommendations it brings a mail server, postfix. Use --no-install-recommends when you install server software, and add the recommended packages you actually want by name.

Bind to loopback, then check from outside

Some services must run but only need to be reached from the machine itself. The lab's example is a small internal status page: Python's built-in web server, which by default binds to all interfaces (the Python documentation says so), serving /srv/hard-svc-app/index.html (one line, "internal status page") from this unit. Write it, then run sudo systemctl daemon-reload and sudo systemctl start hard-svc-app.

[Unit]
Description=Internal status page (demo)
 
[Service]
Type=exec
DynamicUser=yes
ExecStart=/usr/bin/python3 -m http.server 8080 --directory /srv/hard-svc-app
 
[Install]
WantedBy=multi-user.target

Then scan all ports from the other machine:

-p- means all 65,535 TCP ports. Anyone on this network can read the status page on 8080. Rebind it with a drop-in:

The socket is now on 127.0.0.1, the page still works locally, and the scan finds only SSH. The rule is SecOpsLog advice: bind every internal service to loopback even though a firewall comes later in this course. The two are independent, so an internal service stays unreachable on the day the firewall is flushed. The impact is that remote clients, including a monitoring server, can no longer connect directly. To roll back, run sudo systemctl revert hard-svc-app and restart it.

On RHEL 10

The Rocky Linux machine runs sshd.service directly on port 22. The containerd line belongs to the lab VM tool's own user and listens on loopback only. Port 9090 is the Cockpit web console, socket-activated. Rocky's release package enables cockpit.socket through its systemd preset file, so the console answers on every address until you decide otherwise. Check your RHEL image the same way: the preset column tells you what the distribution chose. The CIS RHEL 10 Level 2 server profile disables it.

Package work uses dnf: dnf repoquery --userinstalled lists what was installed on purpose (50 packages on this machine), dnf remove removes, and --setopt=install_weak_deps=False is the counterpart of --no-install-recommends.

Try this

On your Ubuntu lab machine, install rpcbind and run sudo systemctl disable --now rpcbind. Confirm with sudo ss -tulpn sport = :111 that port 111 is still open and that systemd is its only owner. Close it for good (stop the socket, mask both units) and confirm that sudo systemctl start rpcbind fails with "Unit rpcbind.service is masked." Then roll back with unmask and enable --now rpcbind.socket, check that 111 is back, and finish with sudo apt-get purge rpcbind. At the first and second stage, scan port 111 from your laptop with nmap -n -sT -p 111 SERVER: open, then closed.

Takeaway

Every open port needs an owner and a reason. Close socket-activated services at their .socket unit, bind internal services to 127.0.0.1, and prove the result from another machine rather than from the configuration file.

Related