El 70% de los servidores web del mundo corren Linux. Sin hardening y parches adecuados, son objetivos frecuentes. Estos son los vectores de ataque más explotados en infraestructura Linux empresarial y cómo protegerla.
Linux tiene una reputación de seguridad que en parte merece y en parte es mito. Es más transparente que Windows —su código fuente es público y revisado por miles de ojos— y su modelo de permisos es robusto cuando se configura correctamente. Pero "cuando se configura correctamente" es un requisito que en la práctica se cumple menos de lo que se asume.
El 70% de los servidores web del mundo corren Linux. La mayoría de los contenedores Docker, Kubernetes y servicios en la nube también. Si hay un sistema que merece revisión sistemática de seguridad, es precisamente el que más se asume que está bien.
En este artículo —parte de nuestra serie sobre vulnerabilidades en plataformas empresariales— abordamos las vulnerabilidades de kernel, las misconfiguraciones más peligrosas y los vectores de ataque que los equipos de seguridad encuentran en auditorías de infraestructura Linux.
Vulnerabilidades de kernel con alto impacto real
Dirty Pipe (CVE-2022-0847): escritura en archivos de solo lectura
En marzo de 2022, el investigador Max Kellermann publicó una vulnerabilidad en el kernel de Linux que permitía a cualquier usuario local sobrescribir el contenido de archivos de solo lectura, incluidos archivos ejecutables propiedad de root. La implicación es directa: un atacante con acceso básico al sistema podía escalar a root en segundos.
La vulnerabilidad afectó kernels desde la versión 5.8 (agosto de 2020) hasta la 5.16.11. Servidores Ubuntu 21.10, Debian 11, RHEL 8 recientes y muchas distribuciones de contenedores estuvieron expuestos durante meses hasta que los administradores aplicaron los parches.
PwnKit / Polkit (CVE-2021-4034): 12 años de vulnerabilidad silenciosa
En enero de 2022, Qualys descubrió una vulnerabilidad en pkexec, el componente de Polkit instalado por defecto en prácticamente todas las distribuciones de Linux desde 2009. El fallo permitía escalar a root desde cualquier usuario sin privilegios. Doce años de distribuciones afectadas, incluyendo Ubuntu, Debian, CentOS, Fedora y RHEL.
Lo más preocupante de PwnKit no fue la vulnerabilidad en sí, sino el tiempo que tardaron muchas organizaciones en aplicar el parche. Servidores críticos de producción se dejaron sin actualizar semanas después de la divulgación pública.
# Verificar si su sistema es vulnerable a PwnKit
ls -la /usr/bin/pkexec
# Si aparece como -rwsr-xr-x (bit SUID activo) en kernels sin parchear, es vulnerable
# Aplicar parche en Debian/Ubuntu:
apt update && apt upgrade -y policykit-1
# Mitigación temporal si no puede parchear inmediatamente:
chmod 0755 /usr/bin/pkexec # Elimina el bit SUIDLas misconfiguraciones más peligrosas en servidores Linux
SSH con autenticación por contraseña habilitada
SSH (Secure Shell) es el protocolo estándar para administración remota de servidores Linux. Su seguridad depende de cómo esté configurado. La configuración más insegura —y desafortunadamente más común— es habilitar la autenticación por contraseña.
Un servidor Linux con SSH en el puerto 22 expuesto a Internet recibe en promedio miles de intentos de login por día. Los ataques son automatizados: herramientas como Hydra y Medusa prueban diccionarios de contraseñas comunes a velocidades que superan las defensas de bloqueo por intentos fallidos cuando no están bien configuradas.
# /etc/ssh/sshd_config — configuración segura
PermitRootLogin no # Nunca permitir login directo como root
PasswordAuthentication no # Solo llaves SSH, nunca contraseñas
PubkeyAuthentication yes
Port 2222 # Cambiar el puerto reduce el ruido de bots
AllowUsers usuario1 usuario2 # Lista explícita de usuarios permitidos
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
# Reiniciar SSH después de cambiar configuración:
systemctl restart sshdEntradas NOPASSWD en sudoers
El archivo /etc/sudoers define qué comandos puede ejecutar cada usuario como root. La entrada más peligrosa es NOPASSWD: ALL, que permite a un usuario ejecutar cualquier comando como root sin confirmar su contraseña.
Encontramos esta configuración con frecuencia en servidores donde un equipo de desarrollo necesitaba ejecutar scripts de despliegue sin interrupciones interactivas. La solución fue conveniente; la implicación de seguridad no fue considerada: si ese usuario es comprometido, el atacante tiene acceso de root inmediato.
# Revisar entradas NOPASSWD en sudoers
grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/
# Alternativa segura: NOPASSWD solo para comandos específicos
# En /etc/sudoers.d/deploy:
deploy_user ALL=(root) NOPASSWD: /usr/bin/systemctl restart miservicioCron jobs con archivos modificables por usuarios no privilegiados
Los cron jobs que se ejecutan como root y llaman a scripts ubicados en directorios con permisos incorrectos son vectores de escalada de privilegios clásicos. Si un script que ejecuta root puede ser modificado por un usuario normal, ese usuario puede ejecutar código arbitrario como root.
# Encontrar scripts de cron potencialmente vulnerables
crontab -l # Cron del usuario actual
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.weekly/
# Verificar permisos del script referenciado — solo root debe poder escribirlo
ls -la /ruta/del/script.sh # Debe ser -rwxr-xr-x root root o más restrictivoContenedores Docker: privilegios mal asignados
Docker cambió la forma en que se despliegan aplicaciones en Linux, pero también introdujo nuevas superficies de ataque. La misconfiguration más crítica: correr contenedores en modo privilegiado (--privileged).
Un contenedor privilegiado tiene acceso completo al dispositivo del host, puede montar el filesystem del host y puede inyectar código en el kernel. En términos prácticos, comprometer un contenedor privilegiado equivale a comprometer el servidor host completo.
# Verificar contenedores corriendo con privilegios elevados
docker ps -q | xargs docker inspect --format '{{.Name}}: Privileged={{.HostConfig.Privileged}}' 2>/dev/null
# Verificar capacidades adicionales
docker inspect --format '{{.HostConfig.CapAdd}}'Principio básico: los contenedores deben correr con el usuario mínimo necesario, sin --privileged, sin montar el socket de Docker (/var/run/docker.sock) dentro del contenedor, y con el sistema de archivos raíz en modo solo lectura cuando sea posible.
Gestión de paquetes y actualizaciones automáticas
Como mencionamos en el artículo sobre Windows, la brecha entre la publicación de un parche y su aplicación es el período de mayor riesgo. En Linux, las actualizaciones automáticas de seguridad son una herramienta estándar que muchas organizaciones no aprovechan.
# En sistemas Debian/Ubuntu: habilitar actualizaciones de seguridad automáticas
apt install unattended-upgrades -y
dpkg-reconfigure -plow unattended-upgrades
# En /etc/apt/apt.conf.d/50unattended-upgrades
# Habilitar solo actualizaciones de seguridad (no todas las actualizaciones):
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false"; # Controlar reinicios manualmente
Unattended-Upgrade::Mail "admin@suempresa.com";
# En RHEL/CentOS/AlmaLinux:
dnf install dnf-automatic -y
systemctl enable --now dnf-automatic.timerSupply chain: el nuevo vector en ecosistemas Linux
En 2024, el incidente de XZ Utils (CVE-2024-3094) demostró un vector de ataque que la industria conocía en teoría pero nunca había visto a esta escala: un backdoor insertado en una librería de compresión estándar por un contribuidor malicioso durante casi dos años de trabajo paciente en el proyecto open source.
XZ Utils afectó versiones de desarrollo de Debian y Fedora antes de ser detectado. El backdoor habría permitido acceso SSH no autenticado a millones de servidores. Solo un observador atento notó una anomalía en el rendimiento de SSH y siguió el rastro hasta descubrirlo.
La lección: confiar en un paquete porque es open source o porque está en los repositorios oficiales no es garantía suficiente. Las organizaciones con infraestructura crítica deben implementar:
- Verificación de firmas de paquetes en todos los repositorios.
- Escaneo de imágenes de contenedores con herramientas como Trivy o Grype antes del despliegue.
- Software Composition Analysis (SCA) en pipelines de desarrollo.
Tres controles con el mayor retorno de inversión en seguridad Linux
- Actualizaciones automáticas de seguridad habilitadas: Cierra el 80% de las vulnerabilidades conocidas sin intervención manual.
- SSH solo con llaves, sin contraseñas, sin acceso root directo: Elimina el vector de fuerza bruta más común.
- Revisión trimestral de sudoers, cron jobs y permisos SUID: Los vectores de escalada de privilegios más comunes se detectan con una auditoría básica.
En el siguiente artículo de la serie pasamos al ecosistema que más creció en entornos corporativos en los últimos cinco años: macOS. Los equipos Apple son elegantes, poderosos y tienen un perfil de seguridad que las organizaciones subestiman sistemáticamente.
¿Tiene servidores Linux en producción y quiere saber si tienen vulnerabilidades activas? Nuestro servicio de pentesting incluye evaluación de infraestructura Linux con reporte de hallazgos y plan de remediación priorizado.