Cómo desactivar servicios innecesarios en Ubuntu 24.04

Cada servicio que arranca en un servidor consume memoria, y cada uno que escucha en la red es una posible vía de ataque. Desactivar lo que no usas reduce esa superficie y simplifica la administración. En este tutorial auditarás los servicios de un servidor Ubuntu 24.04, identificarás cuáles sobran, los desactivarás o eliminarás con systemctl y apt, y verificarás que el sistema sigue funcionando.

El método vale para cualquier distribución con systemd, incluidas Debian 12 y Rocky Linux 9; solo cambian los nombres de algunos servicios.

Requisitos previos

• Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
• Un usuario no root con privilegios sudo.
• Acceso a una consola alternativa (VNC o consola de emergencia del proveedor) por si desactivas algo que afecta a la red o a SSH.
• Una idea clara de qué debe hacer el servidor (web, base de datos, correo...). Sin eso no se puede decidir qué sobra.

Paso 1: Ver qué escucha en la red

Empieza por lo más importante: los procesos que aceptan conexiones. Lista los puertos TCP y UDP en escucha con el proceso asociado:

sudo ss -tulpn

Netid State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port Process
udp   UNCONN 0      0          127.0.0.54:53         0.0.0.0:*     users:(("systemd-resolve",pid=512,fd=16))
udp   UNCONN 0      0       127.0.0.53%lo:53         0.0.0.0:*     users:(("systemd-resolve",pid=512,fd=14))
udp   UNCONN 0      0             0.0.0.0:111        0.0.0.0:*     users:(("rpcbind",pid=701,fd=5))
tcp   LISTEN 0      4096          0.0.0.0:111        0.0.0.0:*     users:(("rpcbind",pid=701,fd=4))
tcp   LISTEN 0      4096    127.0.0.53%lo:53         0.0.0.0:*     users:(("systemd-resolve",pid=512,fd=15))
tcp   LISTEN 0      4096                *:22               *:*     users:(("sshd",pid=1,fd=3),("systemd",pid=1,fd=3))
tcp   LISTEN 0      511           0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=903,fd=6))

Fíjate en la columna Local Address:

• 127.0.0.1, 127.0.0.53 o ::1: solo accesible desde el propio servidor. Poco riesgo.
• 0.0.0.0, * o [::]: accesible desde cualquier interfaz, incluida la pública. Cada línea de este tipo debe estar justificada.

En el ejemplo, sshd y nginx son necesarios, pero rpcbind en el puerto 111 solo hace falta si el servidor usa NFS. Es un buen candidato para desactivar.

Para saber qué unidad de systemd corresponde a un proceso, usa su PID:

systemctl status 701

La primera línea muestra el nombre de la unidad, por ejemplo rpcbind.service.

Paso 2: Listar los servicios habilitados y en ejecución

Lista los servicios que arrancan automáticamente:

systemctl list-unit-files --type=service --state=enabled

Y los que están en ejecución ahora mismo:

systemctl list-units --type=service --state=running

No olvides los sockets. Con la activación por socket, systemd escucha en el puerto y arranca el servicio solo cuando llega una conexión, así que un servicio puede aparecer parado y aun así tener un puerto abierto:

systemctl list-units --type=socket

  UNIT                  LOAD   ACTIVE SUB       DESCRIPTION
  dbus.socket           loaded active running   D-Bus System Message Bus Socket
  rpcbind.socket        loaded active listening RPCbind Server Activation Socket
  ssh.socket            loaded active listening OpenBSD Secure Shell server socket
  systemd-journald.socket loaded active running Journal Socket
  ...

Importante

En Ubuntu 24.04, SSH se activa mediante ssh.socket. No desactives ni ssh.socket ni ssh.service si administras el servidor por SSH.

Paso 3: Decidir qué desactivar

Para cada servicio que no reconozcas, averigua qué hace y qué paquete lo instala:

systemctl cat rpcbind.service | grep -E "Description|ExecStart"
dpkg -S rpcbind.service

Description=RPC bind portmap service
ExecStart=/sbin/rpcbind -f $RPCBIND_OPTIONS
rpcbind: /usr/lib/systemd/system/rpcbind.service

Comprueba también si otras unidades dependen de él:

systemctl list-dependencies --reverse rpcbind.service

Si solo aparecen multi-user.target o sockets.target, nada más lo necesita directamente.

Servicios que no debes tocar

Estos servicios son necesarios en prácticamente cualquier servidor Ubuntu:

Candidatos habituales en un servidor

Estos servicios aparecen a menudo en servidores y rara vez son necesarios. Desactívalos solo si se cumple la condición:

No todos estarán instalados en tu servidor; trabaja solo con los que aparecieron en los pasos 1 y 2.

Paso 4: Desactivar un servicio

systemctl disable --now hace dos cosas: detiene el servicio y evita que arranque en el siguiente inicio. Desactiva también el socket si existe, o systemd volverá a arrancar el servicio en cuanto llegue una conexión:

sudo systemctl disable --now rpcbind.service rpcbind.socket

Removed "/etc/systemd/system/multi-user.target.wants/rpcbind.service".
Removed "/etc/systemd/system/sockets.target.wants/rpcbind.socket".

Comprueba el estado:

systemctl is-enabled rpcbind.service rpcbind.socket
systemctl is-active rpcbind.service rpcbind.socket

disabled
disabled
inactive
inactive

Y confirma que el puerto ya no está abierto:

sudo ss -tulpn | grep ':111 '

Si el comando no devuelve nada, el puerto está cerrado.

Otro ejemplo, en un VPS sin almacenamiento SAN:

sudo systemctl disable --now multipathd.service multipathd.socket

Paso 5: Enmascarar los servicios que no deben arrancar nunca

Un servicio desactivado todavía puede arrancar si otro servicio lo pide como dependencia o si alguien lo inicia a mano. Enmascarar una unidad la enlaza a /dev/null y hace imposible arrancarla hasta que se desenmascare:

sudo systemctl mask rpcbind.service rpcbind.socket

Created symlink /etc/systemd/system/rpcbind.service → /dev/null.
Created symlink /etc/systemd/system/rpcbind.socket → /dev/null.

Si intentas arrancarlo, systemd lo impide:

sudo systemctl start rpcbind.service

Failed to start rpcbind.service: Unit rpcbind.service is masked.

Usa el enmascarado con moderación: es útil para servicios que otros paquetes podrían reactivar, pero hace más difícil diagnosticar problemas si alguien olvida que lo hizo.

Paso 6: Eliminar los paquetes que no necesitas

Si un servicio no hace falta en absoluto, lo más limpio es desinstalar el paquete. Así no recibe actualizaciones innecesarias ni puede volver a activarse. Revisa primero qué se eliminaría con --simulate:

sudo apt purge --simulate rpcbind

Si la lista solo incluye lo que esperas (y no, por ejemplo, nfs-common cuando sí montas NFS), elimínalo:

sudo apt purge rpcbind
sudo apt autoremove --purge

En el caso de snapd, comprueba antes que no tienes snaps instalados:

snap list

No snaps are installed yet. Try 'snap install hello-world'.

Si la lista está vacía, puedes eliminarlo:

sudo apt purge snapd

Paso 7: Verificar el sistema

Reinicia el servidor para comprobar que arranca correctamente y que los cambios persisten:

sudo reboot

Tras reconectar, confirma que no hay unidades fallidas:

systemctl --failed

  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

Vuelve a revisar los puertos en escucha y compara con el paso 1:

sudo ss -tulpn

Solo deberían quedar los servicios que el servidor necesita. Por último, comprueba que tus aplicaciones responden (web, base de datos, correo) y revisa si hay errores recientes:

sudo journalctl -p err -b

Para ver cuánto tarda cada servicio en arrancar, útil para detectar otros candidatos:

systemd-analyze blame | head -15

Diferencias en Rocky Linux 9

Los comandos systemctl, ss y journalctl son idénticos. Cambian los candidatos y la gestión de paquetes:

• Los candidatos más habituales son cockpit.socket (consola web en el puerto 9090), postfix, rpcbind y avahi-daemon si están instalados.
• Para saber a qué paquete pertenece un archivo, usa rpm -qf /usr/lib/systemd/system/rpcbind.service o, de forma más general, dnf provides '*/rpcbind.service'.
• Para eliminar paquetes, usa sudo dnf remove rpcbind.

Solución de problemas

Una aplicación deja de funcionar tras desactivar un servicio. Vuelve a activarlo y revisa qué dependencia tenía:

sudo systemctl unmask rpcbind.service rpcbind.socket
sudo systemctl enable --now rpcbind.service rpcbind.socket

El servicio vuelve a estar activo tras reiniciar. Probablemente no desactivaste su socket o lo arranca otra unidad. Revisa systemctl list-dependencies --reverse y, si de verdad no lo necesitas, enmascáralo.

Has perdido el acceso SSH. Entra por la consola VNC o de emergencia del proveedor y ejecuta sudo systemctl enable --now ssh.socket.

Failed to disable unit: Unit file ... does not exist. El servicio no está instalado con ese nombre. Búscalo con systemctl list-unit-files | grep nombre.

Conclusión

Has auditado los servicios y puertos de tu servidor, desactivado y enmascarado los que no se usan, eliminado los paquetes sobrantes y comprobado que el sistema arranca sin errores. Repite el paso 1 cada vez que instales software nuevo: ss -tulpn es la forma más rápida de ver qué expone realmente tu servidor.

Como siguientes pasos, puedes configurar un cortafuegos (UFW en Ubuntu, firewalld en Rocky Linux) para cerrar cualquier puerto que deba quedar abierto solo en local, instalar Fail2ban para proteger SSH o activar las actualizaciones automáticas de seguridad.