Un sistema Linux recién instalado no es un sistema seguro. Las distribuciones de uso general incluyen configuraciones pensadas para funcionar rápidamente, no para resistir un intento de intrusión. Reforzar la seguridad de tu sistema Linux en el día a día requiere unas cuantas medidas concretas, aplicadas con regularidad, que reducen la superficie de ataque sin convertir tu equipo en una fortaleza inutilizable.
Sandboxing con systemd: aislar cada servicio Linux por separado
La mayoría de las guías de seguridad de Linux hablan de cuentas de usuario y permisos de archivos. Un aspecto menos tratado es el aislamiento de los propios servicios. A menudo, un servidor web o un gestor de bases de datos se ejecuta con muchos más permisos de los que necesita.
¿Te has fijado en que un servicio comprometido puede leer archivos que no tienen nada que ver con su función? Eso es precisamente lo que corrige el sandboxing de systemd. Tres directivas marcan la diferencia:
- ProtectSystem=strict monta el sistema de archivos raíz como solo lectura para el servicio en cuestión, lo que impide cualquier modificación fuera de los directorios autorizados explícitamente.
- PrivateTmp=true asigna al servicio un directorio temporal aislado, invisible para los demás procesos. Si un atacante accede al /tmp del servicio, no podrá ver el del sistema.
- NoNewPrivileges=true bloquea cualquier escalada de privilegios después de iniciar el servicio, incluso si hay un binario setuid en la ruta de ejecución.
Estas opciones se configuran en el archivo unit del servicio, en la sección [Service]. Después de cada cambio, reinicia el servicio y comprueba que funciona con normalidad. Una directiva demasiado restrictiva puede bloquear el acceso legítimo a un socket o a un archivo de configuración.
Para profundizar en este enfoque y conocer otros métodos de refuerzo de la seguridad, los consejos de seguridad de Hebdo Linux describen varios escenarios adecuados tanto para equipos de escritorio como para servidores.
Comprobar el estado real de SELinux y AppArmor en tu sistema
Tener SELinux o AppArmor instalado no significa que estos mecanismos estén protegiendo nada. ¿Por qué se suele pasar por alto este aspecto? Porque la presencia de un módulo de seguridad en el núcleo da una falsa sensación de protección.
Un módulo de seguridad inactivo no protege ningún proceso. En una distribución como Ubuntu, AppArmor viene instalado de forma predeterminada, pero no todos los perfiles están en modo “enforce”. Algunos funcionan en modo “complain”, que se limita a registrar las infracciones sin bloquearlas.
Comandos concretos para comprobarlo
En AppArmor, el comando aa-status muestra la lista de perfiles cargados y su modo. Cada perfil en modo “complain” es una puerta abierta. En SELinux, sestatus indica si el modo es “enforcing”, “permissive” o “disabled”.
Comprobar estos estados forma parte de las verificaciones diarias más útiles. Un script ejecutado mediante cron o un temporizador de systemd puede enviar una alerta si el modo pasa a permissive después de un reinicio o de una actualización del núcleo. Este tipo de regresión silenciosa es frecuente al actualizar a una nueva versión.
Actualizaciones de Linux: comprobar que el parche está realmente activo
Instalar un parche no es suficiente. Después de actualizar el núcleo, tu equipo puede seguir funcionando con el núcleo anterior hasta que se reinicie. El gestor de paquetes indica que está “actualizado”, pero el sistema sigue siendo vulnerable.
Comprueba qué núcleo está activo después de cada actualización crítica. El comando uname -r muestra la versión del núcleo que se está ejecutando. Compárala con la última versión instalada, que puedes consultar en el gestor de paquetes. Si no coinciden, es necesario reiniciar.
Gestión de parches en un servidor de producción
En un servidor, no siempre es posible reiniciar de inmediato. Documenta la diferencia entre el núcleo instalado y el activo. Algunas distribuciones ofrecen un mecanismo de “live patching” que aplica parches al núcleo sin reiniciar, pero no cubre todos los tipos de vulnerabilidades.
Un aspecto que suele olvidarse: las entradas de arranque alternativas. Si el cargador de arranque conserva núcleos antiguos, un reinicio accidental con una entrada obsoleta vuelve a introducir las vulnerabilidades corregidas. Elimina periódicamente los núcleos antiguos de la lista de arranque, una vez que hayas confirmado la estabilidad del nuevo.
Reducir a diario la superficie de red expuesta
Cada puerto abierto es un posible punto de entrada. En un equipo Linux de escritorio, servicios como CUPS (impresión), Avahi (detección de redes) o un servidor SSH pueden estar a la escucha sin que te des cuenta.
El comando ss -tlnp muestra todos los puertos a la escucha y el proceso asociado. Revisa la lista:
- Desactiva los servicios que no utilices (Avahi en un equipo sin impresora de red, por ejemplo) con
systemctl disable --now, seguido del nombre del servicio. - Si tienes un servidor SSH expuesto en el puerto estándar (22), es más seguro restringir el acceso mediante clave pública en lugar de contraseña. Desactiva la autenticación por contraseña en
/etc/ssh/sshd_configconPasswordAuthentication no. - El cortafuegos nftables (o iptables, según la distribución) debe establecer una política predeterminada de rechazo del tráfico entrante, con excepciones explícitas únicamente para los servicios necesarios.
Cuantos menos servicios estén a la escucha, menor será la superficie de ataque que haya que vigilar. Esta revisión lleva unos minutos y reduce considerablemente el riesgo de explotación remota.
Proteger un sistema Linux no es una tarea puntual. Aislar los servicios, comprobar que los módulos de seguridad están activos, confirmar que los parches se están aplicando realmente y cerrar los puertos innecesarios conforman un ciclo breve. Si lo repites cada semana, este ciclo cubre la mayoría de los vectores de ataque habituales en un equipo o servidor Linux.
