Cómo proteger un servidor Linux frente a vulnerabilidades Zero-Day cuando todavía no existe un parche

Cómo proteger un servidor Linux frente a vulnerabilidades Zero-Day cuando todavía no existe un parche

Ver servicios activos

systemctl --type=service --state=running --no-pager

Ver puertos en escucha y procesos asociados

sudo ss -tulpen

Ver paquetes relacionados con el componente vulnerable

dpkg -l | grep -Ei 'nginx|apache|openssh|openssl|sudo|glibc|php|java|kernel'
rpm -qa | grep -Ei 'nginx|httpd|openssh|openssl|sudo|glibc|php|java|kernel'

Detener temporalmente

sudo systemctl stop nombre-servicio

Evitar que arranque automáticamente

sudo systemctl disable nombre-servicio

Enmascarar si debe quedar totalmente bloqueado

sudo systemctl mask nombre-servicio

sudo nft add table inet filtro
sudo nft 'add chain inet filtro input { type filter hook input priority 0; policy drop; }'

Permitir tráfico local y conexiones ya establecidas

sudo nft add rule inet filtro input iif lo accept
sudo nft add rule inet filtro input ct state established,related accept

Permitir SSH solo desde IP administrativa

sudo nft add rule inet filtro input ip saddr 203.0.113.10 tcp dport 22 accept

Permitir servicio vulnerable solo desde VPN o IP autorizada

sudo nft add rule inet filtro input ip saddr 10.50.0.0/24 tcp dport 8443 accept

Bloquear todo lo demás hacia ese puerto

sudo nft add rule inet filtro input tcp dport 8443 drop

Recomendaciones habituales

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers adminlinux
MaxAuthTries 3
AllowTcpForwarding no
X11Forwarding no

sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

Limitar métodos HTTP si la aplicación no los necesita

if ($request_method !~ ^(GET|POST|HEAD)$) {
    return 405;
}

Limitar tamaño de solicitudes

client_max_body_size 10M;

Ubuntu / Debian con AppArmor

sudo aa-status

Ver denegaciones recientes

sudo ausearch -m AVC,USER_AVC -ts recent 2>/dev/null || true
sudo journalctl | grep -i apparmor | tail -n 50

Ver permisos peligrosos

sudo find / -perm -4000 -type f 2>/dev/null
sudo find /var/www -type f -perm /002 -ls 2>/dev/null

Revisar sudo

sudo grep -R "NOPASSWD|ALL" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/servicio-vulnerable /var/log/servicio-vulnerable
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true

sudo systemctl daemon-reload
sudo systemctl restart servicio-vulnerable

Ver procesos con conexiones

sudo lsof -i -P -n 2>/dev/null | head -n 50

Buscar conexiones extrañas recientes en logs

sudo journalctl --since "2 hours ago" --no-pager | grep -Ei 'connect|wget|curl|bash|sh|python|perl|nc|ncat'

Logs de servicio vulnerable

sudo journalctl -u servicio-vulnerable --since "6 hours ago" --no-pager

Procesos sospechosos

ps aux --sort=-%cpu | head -n 20
ps aux | grep -Ei 'curl|wget|nc|ncat|perl|python|bash -i|/tmp|/dev/shm'

Archivos recientes en rutas temporales

sudo find /tmp /var/tmp /dev/shm -type f -mtime -1 -ls 2>/dev/null

Usuarios conectados y últimos accesos

w
last -a | head -n 30

Buscar eventos

sudo ausearch -k usuarios
sudo ausearch -k webroot
sudo aureport -f --summary

Verificar integridad si usas hashes

sha256sum -c MANIFEST.sha256

Probar restauración en entorno aislado

No declares un backup como válido si nunca fue restaurado.

¿Qué hago si no existe parche para una vulnerabilidad Zero-Day?

Reduce exposición, bloquea acceso público, desactiva funciones vulnerables, usa WAF o parcheo virtual, aplica SELinux/AppArmor, limita privilegios, aumenta monitoreo y prepara el parche apenas esté disponible. CISA describe las mitigaciones como soluciones temporales para impedir o reducir explotación mientras llega la corrección.

¿Debo apagar el servidor?

Depende del riesgo. Si el exploit está activo, el servicio está expuesto y el impacto de compromiso supera el impacto de caída, apagar o aislar puede ser la decisión correcta. Si el servicio es crítico, puede mantenerse con restricciones fuertes: VPN, firewall, WAF, allowlist y monitoreo.

¿Un WAF soluciona un Zero-Day?

No lo soluciona, pero puede bloquear patrones de explotación en aplicaciones web. OWASP llama a esto virtual patching y recomienda tratarlo como parte del proceso formal de gestión de parches, con pruebas y seguimiento.

¿SELinux o AppArmor reemplazan el parche?

No. Sirven como controles de contención. Pueden limitar lo que un proceso comprometido puede leer, escribir o ejecutar, pero el parche oficial sigue siendo necesario cuando esté disponible.

¿Qué evidencia debo guardar?

Servidor afectado, versión, exposición, logs, reglas aplicadas, decisión tomada, responsable, fecha, hora, IOC, respaldo, resultado de pruebas, parche aplicado y verificación final. Esa trazabilidad ayuda a responder, auditar y mejorar el proceso.