Guía práctica de hardening para tu VPS Linux: de CrowdSec al kernel

Tener un VPS expuesto a internet es como dejar la puerta de tu casa en una calle muy transitada. No basta con echar la llave, conviene reforzar la cerradura, poner alarma y asegurarte de que las ventanas también están cerradas. En este artículo repaso las capas de seguridad que considero imprescindibles para cualquier servidor Linux en producción.

CrowdSec: seguridad colaborativa

Si vienes de usar Fail2Ban, CrowdSec es el siguiente paso natural. Mientras Fail2Ban se limita a buscar patrones regex en los logs de tu servidor, CrowdSec analiza comportamientos y, lo más interesante, comparte inteligencia de amenazas con toda su comunidad de usuarios.

Cómo funciona

La arquitectura se divide en tres piezas principales:

• El Security Engine lee los logs, los procesa con parsers YAML y aplica escenarios de detección conductual. No busca una línea concreta, sino patrones como «esta IP ha generado 200 peticiones HTTP en 10 segundos cuando lo normal son 2».
• La LAPI (Local API) es el centro de mando local que gestiona las decisiones de bloqueo, anonimiza la información antes de compartirla y recibe la inteligencia global.
• Los Bouncers son módulos de remediación que actúan sobre las decisiones. Los hay para nftables, iptables, Nginx, Traefik, Cloudflare y más.

Instalación básica

# Instalar CrowdSec
curl -s https://install.crowdsec.net | sudo bash
sudo apt install crowdsec

# Instalar bouncer de firewall (nftables)
sudo apt install crowdsec-firewall-bouncer-nftables
sudo systemctl enable crowdsec-firewall-bouncer

# Instalar colecciones de detección
sudo cscli collections install crowdsecurity/sshd
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/base-http-scenarios

# Verificar estado
sudo cscli metrics
sudo cscli bouncers list
sudo cscli decisions list

¿Por qué no Fail2Ban?

La diferencia fundamental es el alcance. Fail2Ban es reactivo y local: solo protege tu servidor con lo que ve en tus logs. CrowdSec es colaborativo: cuando un usuario detecta un ataque, la señal se envía anonimizada al motor de consenso, que la cruza con reportes de otros nodos. El resultado es una blocklist comunitaria verificada que te protege antes de que el atacante llegue a tu puerta.

Además, CrowdSec ofrece respuestas más granulares. No todo tiene que ser un ban: puedes servir CAPTCHAs o aplicar throttling según la gravedad del escenario.

SSH: la primera línea de defensa

SSH es la puerta principal de administración de cualquier VPS y, por tanto, uno de los objetivos más atacados. Un hardening básico debería incluir al menos estos puntos:

# /etc/ssh/sshd_config

# Cambiar el puerto por defecto
Port 2222

# Solo claves, nunca contraseñas
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# Sin acceso root
PermitRootLogin no

# Limitar intentos y sesiones
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30

# Desactivar todo lo innecesario
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no

# Timeouts de sesión
ClientAliveInterval 300
ClientAliveCountMax 2

# Solo usuarios específicos
AllowUsers tuusuario

# Nivel de log detallado
LogLevel VERBOSE

Para las claves, Ed25519 es la opción recomendada hoy. Es más rápida, más segura y genera claves más cortas que RSA:

ssh-keygen -t ed25519 -a 100 -C "tu@email.com"

Si tu versión de OpenSSH lo soporta (10.0+), también puedes añadir mlkem768x25519-sha256 a los algoritmos de intercambio de claves para protección post-cuántica.

Firewall: denegar todo por defecto

La regla de oro es simple: deniega todo el tráfico entrante y permite solo lo estrictamente necesario.

# Políticas por defecto
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH con rate limiting
sudo ufw limit 2222/tcp comment 'SSH rate limited'

# Tráfico web
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Activar
sudo ufw enable

La trampa de Docker con el firewall

Este es un detalle que pilla desprevenido a mucha gente: Docker escribe reglas de iptables directamente, saltándose UFW por completo. Si publicas un puerto con -p 8080:80, tus reglas UFW no aplican a ese contenedor.

Las soluciones más comunes son hacer bind a localhost (-p 127.0.0.1:8080:80), gestionar las reglas en la cadena DOCKER-USER de iptables/nftables, o usar un proxy inverso como Traefik que exponga solo los puertos 80 y 443.

Actualizaciones automáticas de seguridad

Un servidor sin parches de seguridad es un servidor con fecha de caducidad. unattended-upgrades se encarga de aplicar parches de seguridad automáticamente:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

En la configuración puedes afinar bastante: qué orígenes se actualizan, si se reinicia automáticamente cuando el kernel lo requiere, notificaciones por email y paquetes excluidos. Lo importante es que los parches de seguridad del sistema se apliquen sin intervención manual.

# Verificar que funciona
sudo unattended-upgrade -v --dry-run

Docker: reducir la superficie de ataque

Si tu VPS ejecuta contenedores, hay varias medidas que deberían ser estándar:

Nunca ejecutar como root

RUN groupadd --system --gid 1001 appgroup && \
    useradd --system --uid 1001 --gid appgroup appuser
COPY --chown=appuser:appgroup . /app
USER appuser

Filesystem de solo lectura y capabilities mínimas

services:
  app:
    read_only: true
    tmpfs:
      - /tmp:rw,noexec,nosuid
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true

Redes aisladas

No todos los contenedores necesitan hablar entre sí ni acceder a internet. Separa las redes por función:

networks:
  frontend-net: {}
  backend-net:
    internal: true    # Sin acceso a internet

El socket de Docker

Montar /var/run/docker.sock directamente en un contenedor es equivalente a darle acceso root al host. Si algún servicio como Traefik necesita leer el estado de Docker, usa un proxy de socket como tecnativa/docker-socket-proxy con permisos mínimos de solo lectura.

Escaneo de imágenes

Herramientas como Trivy permiten escanear imágenes antes de desplegarlas, detectando vulnerabilidades conocidas y errores de configuración en el propio Dockerfile:

trivy image --severity CRITICAL,HIGH mi-app:v1.0
trivy config Dockerfile

Hardening del kernel con sysctl

El kernel de Linux tiene parámetros configurables que refuerzan la seguridad a nivel de red y sistema. Crear un fichero /etc/sysctl.d/99-hardening.conf con al menos estos ajustes es buena práctica:

# Protección contra SYN flood
net.ipv4.tcp_syncookies = 1

# Reverse path filtering (anti IP spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignorar ICMP redirects (prevenir MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# ASLR completo
kernel.randomize_va_space = 2

# Restringir dmesg y punteros del kernel
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2

# Restringir ptrace (solo padre-hijo)
kernel.yama.ptrace_scope = 1

# No generar core dumps de procesos SUID
fs.suid_dumpable = 0

# Aplicar sin reiniciar
sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Un detalle importante: si usas Docker, net.ipv4.ip_forward debe estar a 1. Docker lo necesita para el networking entre contenedores, así que asegúrate de no desactivarlo.

Sistema de ficheros: noexec, nosuid, nodev

Directorios temporales como /tmp, /var/tmp y /dev/shm son vectores habituales de ataque. Montarlos con restricciones impide la ejecución de binarios descargados por un atacante:

# /etc/fstab
tmpfs  /tmp      tmpfs  defaults,nosuid,noexec,nodev,size=2G  0 0
tmpfs  /var/tmp  tmpfs  defaults,nosuid,noexec,nodev,size=1G  0 0
tmpfs  /dev/shm  tmpfs  defaults,nosuid,noexec,nodev          0 0

Estas opciones no son una solución completa (existen técnicas de ejecución en memoria que evitan el disco), pero elevan significativamente el esfuerzo que necesita un atacante.

Cabeceras de seguridad HTTP

Si usas un reverse proxy como Traefik o Nginx, las cabeceras HTTP son otra capa de defensa que no cuesta nada añadir:

• HSTS fuerza HTTPS en el navegador, incluso si el usuario escribe http://. Con includeSubDomains y preload para máxima protección.
• La CSP define qué orígenes puede cargar el navegador, mitigando ataques XSS e inyección de contenido.
• X-Frame-Options previene clickjacking impidiendo que tu sitio se cargue en un iframe.
• Permissions-Policy restringe el acceso a APIs del navegador como cámara, micrófono o geolocalización.
• X-Content-Type-Options: nosniff evita que el navegador interprete ficheros con un MIME type distinto al declarado.

Tras configurarlas, puedes validar tu puntuación en herramientas como Security Headers o el HTTP Observatory de Mozilla. El objetivo es alcanzar una calificación A+.

Monitorización y logging

De nada sirve tener todas las capas anteriores si no monitorizas lo que ocurre en tu servidor. Algunas recomendaciones:

• Con auditd puedes registrar ejecuciones como root, cambios en ficheros críticos (/etc/passwd, /etc/shadow, sshd_config) y modificaciones en sudoers.
• Configura journald con almacenamiento persistente, compresión y retención de al menos 90 días.
• La consola web de CrowdSec ofrece visibilidad sobre las decisiones de bloqueo, las alertas y las señales compartidas con la comunidad.

# Consultas útiles con journalctl
journalctl -u sshd --since "1 hour ago"     # Logs SSH recientes
journalctl -p err --since today              # Solo errores de hoy
journalctl _UID=0 --since today              # Acciones de root

Revisa los logs periódicamente y configura alertas para eventos críticos. Un servidor comprometido suele dejar rastro antes de que el daño sea visible.

La seguridad como proceso, no como destino

Ninguna de estas medidas por separado convierte tu VPS en un búnker, pero aplicadas en conjunto crean una defensa en profundidad que obliga al atacante a superar múltiples barreras. La idea es que cada capa compense las debilidades de las demás.

Más importante aún: la seguridad no es algo que se configura una vez y se olvida. Los parches se aplican, las blocklists se actualizan, los logs se revisan. Es un proceso continuo que requiere atención regular.

Si solo puedes hacer tres cosas hoy, que sean estas: cambiar SSH a solo claves con puerto no estándar, instalar CrowdSec con un bouncer de firewall y activar las actualizaciones automáticas de seguridad. Con eso ya estarás por delante del 90 % de los servidores expuestos a internet.