Un sistema Linux, incluso uno considerado robusto, no está inmunizado por defecto contra ataques. La seguridad de Linux se basa en un conjunto de configuraciones, reglas de acceso y mecanismos de monitoreo que deben ser activados y mantenidos manualmente. Sin intervención, un servidor o un equipo recién instalado expone servicios innecesarios, puertos abiertos y cuentas con permisos demasiado amplios.
Priorización de los parches del kernel: el verdadero desafío de la seguridad de Linux
Los competidores repiten que hay que actualizar el sistema. El consejo sigue siendo válido, pero la realidad ha cambiado. En 2024, el núcleo de Linux registró 3 108 CVE, lo que representa un aumento de aproximadamente el 79 % en comparación con los 1 736 CVE de 2023, según la base NVD del NIST.
Esta explosión no indica una degradación del código. Es el resultado de la mejora de las herramientas de análisis automatizadas, algunas de las cuales utilizan inteligencia artificial para escanear las aproximadamente 40 millones de líneas del núcleo. Desde febrero de 2024, el núcleo de Linux se ha convertido en su propia autoridad de numeración CVE (CNA), lo que acelera la declaración de cada vulnerabilidad detectada.
Para un administrador, aplicar ciegamente cada parche publicado equivale a correr tras un flujo casi continuo de actualizaciones. La buena estrategia consiste en clasificar los CVE por puntuación CVSS y por exposición real del sistema. Una vulnerabilidad crítica en un módulo de red en producción merece un parche inmediato. Una vulnerabilidad en un controlador de hardware ausente de la máquina puede esperar al próximo ciclo de mantenimiento.
Para seguir estas evoluciones y comprender su impacto concreto, la información de seguridad en Hebdo Linux detalla regularmente los parches del kernel y las alertas asociadas a las distribuciones principales.
Reducción de la superficie de ataque en un servidor Linux
El endurecimiento del sistema (hardening) tiene como objetivo eliminar todo lo que no tiene razón de existir en la máquina. Cada servicio activo, cada puerto abierto y cada paquete instalado representa un punto de entrada potencial para un atacante.
Servicios y paquetes innecesarios
Después de una instalación estándar, varios servicios se ejecutan sin que nadie los haya solicitado: servidor de impresión (CUPS), Avahi para el descubrimiento de red local, o un agente de correo (Postfix, Exim). En un servidor de producción, estos componentes no tienen utilidad y amplían la superficie de ataque. El comando systemctl list-unit-files –state=enabled permite identificar con precisión lo que se inicia automáticamente.
Desactivar un servicio no siempre es suficiente. Si el paquete permanece instalado, una reactivación accidental o una explotación local sigue siendo posible. Eliminar el paquete completo es el método más fiable.
Configuración de red y firewall
Un firewall correctamente configurado constituye la primera barrera entre la red y los servicios internos. En las distribuciones recientes, nftables reemplaza gradualmente a iptables. La lógica sigue siendo la misma: bloquear todo el tráfico entrante por defecto y luego abrir solo los puertos necesarios.
- Permitir el puerto 22 (SSH) solo desde direcciones IP conocidas, nunca desde toda Internet.
- Cerrar los puertos relacionados con bases de datos (3306 para MySQL, 5432 para PostgreSQL) en la interfaz pública y exponerlos solo en la interfaz local o en una red privada.
- Activar el registro de paquetes rechazados para detectar intentos de escaneo.
Control de usuarios y escalada de privilegios
La gestión de cuentas de usuario determina quién puede hacer qué en el sistema. Una cuenta root utilizada a diario sigue siendo uno de los errores más comunes, incluso en máquinas administradas por perfiles técnicos.
Sudo debe reemplazar cualquier conexión directa como root. Cada comando ejecutado a través de sudo se registra con la identidad del usuario, lo que crea un rastro de auditoría aprovechable en caso de incidente. El archivo /etc/sudoers permite restringir los comandos autorizados por usuario o por grupo.
Más allá de sudo, los módulos de control de acceso obligatorio como SELinux (distribuciones Red Hat, Fedora) o AppArmor (Ubuntu, Debian) añaden una capa de restricción por proceso. Incluso si un atacante compromete un servicio, el módulo impide el acceso a archivos o directorios fuera del perímetro definido por la política de seguridad.
- Aplicar el principio de menor privilegio: cada usuario solo tiene los derechos necesarios para su tarea.
- Desactivar las cuentas no utilizadas en lugar de dejarlas inactivas con una contraseña débil.
- Configurar una expiración automática de las contraseñas a través de chage para forzar un renovación periódica.
- Verificar regularmente los archivos /etc/passwd y /etc/group para detectar cuentas o grupos inesperados.
Registro y detección de comportamientos anormales en Linux
Un sistema puede estar comprometido durante semanas sin que nadie se dé cuenta si los logs no están centralizados ni monitoreados. El registro no solo sirve para el análisis post-incidente: si se utiliza correctamente, permite detectar una intrusión en curso.
El registro de systemd (journalctl) centraliza los eventos del sistema, pero su rotación por defecto puede borrar pistas antes de que sean analizadas. Exportar los logs a un servidor remoto (a través de rsyslog o syslog-ng) garantiza que un atacante que haya obtenido acceso root no pueda eliminar sus propias huellas localmente.
Para ir más allá, herramientas como auditd permiten monitorear eventos específicos: modificación de un archivo de configuración sensible, adición de un usuario, cambio de permisos en un directorio crítico. Cada regla de auditoría genera una entrada con marca de tiempo aprovechable para reconstruir la cronología de un incidente.
La combinación de un firewall estricto, un control de acceso granular y un registro exportado cubre los tres ejes de la seguridad de Linux: prevención, restricción y detección. Negligir uno de estos ejes equivale a dejar una puerta abierta, incluso si los otros dos están cerrados.
