Endurecer un servidor no debería convertirse en una sesión de ruleta rusa. La forma más sensata —y repetible— de empezar es bloquear todo el tráfico entrante, permitir el saliente, y luego abrir únicamente lo imprescindible. En Ubuntu/Debian y derivados, UFW (Uncomplicated Firewall) es una capa cómoda sobre iptables/nftables que permite aplicar esta estrategia sin pelearse con reglas kilométricas.
La regla de oro para sysadmins es simple: primero defines reglas, después activas. Activar UFW sin haber permitido tu entrada por SSH es la manera más rápida de “autoexpulsarte” del servidor.
Antes de tocar nada: dos ideas clave (y muy reales)
- UFW no sustituye una buena política de acceso: si dejas SSH abierto al mundo con password, te expones igual. UFW es una capa de control, no una solución total.
- El orden importa: prepara reglas, valida y entonces habilita. Si puedes, hazlo con consola fuera de banda (ILO/KVM) o al menos con una sesión SSH secundaria abierta por seguridad.
1) Comprueba el estado y entiende qué está controlando UFW
Antes de aplicar cambios, revisa cómo está UFW:
ufw status
Si aparece Status: inactive, perfecto: puedes definir reglas sin que entren en vigor todavía.
Para ver más contexto:
ufw status verbose
Aquí verás política por defecto, logging y reglas aplicadas.
2) Define la política por defecto: “cierra lo entrante, deja salir”
Este patrón es el básico para casi cualquier servidor:
ufw default deny incoming
ufw default allow outgoing
Lenguaje del código: JavaScript (javascript)deny incoming: nadie entra salvo que tú lo permitas.allow outgoing: el servidor puede salir (repos, DNS, NTP, APIs, etc.).
Nota práctica: si estás en entornos ultra-restrictivos (servidores “air-gapped”, DMZ estricta, compliance), también puedes limitar salidas, pero eso ya requiere inventariar dependencias (DNS, NTP, mirrors, endpoints de backup, etc.).
3) Asegura tu acceso: abre SSH antes de activar (sí o sí)
Este es el paso que separa una hardening limpia de un ticket urgente.
Opción A: abrir SSH al mundo (simple, menos seguro)
ufw allow ssh
También válido:
ufw allow 22/tcp
Usar ssh es más legible y evita “olvidar” el protocolo.
Opción B: restringir SSH a una IP concreta (recomendado si puedes)
Si tienes IP fija (oficina, bastión, VPN, jump host):
ufw allow from 100.100.100.100 to any port 22 proto tcp
Lenguaje del código: CSS (css)O con el alias:
ufw allow from 100.100.100.100 to any port ssh
Lenguaje del código: CSS (css)Tip sysadmin (importante): si tu IP cambia, te puedes bloquear tú solo. Alternativas mejores:
- Bastión con IP fija
- VPN (WireGuard / Tailscale / Netbird)
- Rango corporativo controlado
- MFA y llaves SSH + fail2ban (o similares) si no puedes restringir por IP
Extra útil: rate limiting en SSH (reduce fuerza bruta)
UFW permite un “limit” sencillo:
ufw limit ssh
No es un IDS, pero reduce spam y escaneo automatizado.
4) Abre solo lo que vas a publicar (y documenta por qué)
Ejemplo típico de servidor web:
ufw allow http
ufw allow https
Equivalente explícito:
ufw allow 80/tcp
ufw allow 443/tcp
Buena práctica: en infra real, conviene dejar claro qué servicio justifica cada puerto. Si es para un reverse proxy, perfecto. Si es una app interna, quizá no debería estar expuesta y mejor usar VPN o red privada.
5) Si usas IPv6, decide si lo gestionas o lo desactivas (pero decide)
Muchos sustos vienen de aquí: “cerré todo” y luego resulta que tu servicio está accesible por IPv6 porque nadie lo estaba mirando.
- Comprueba si UFW aplica a IPv6 (suele hacerlo si está habilitado):
grep -i ipv6 /etc/default/ufw
Lenguaje del código: JavaScript (javascript)Si pone IPV6=yes, UFW aplicará reglas también a IPv6.
Si no usas IPv6 en ese servidor, considera desactivarlo de forma explícita (según política) o al menos asegurarte de que las reglas cubren ambos.
6) Activa UFW (cuando ya tienes tu “puerta de entrada” garantizada)
Ahora sí:
ufw enable
Y valida:
ufw status
ufw status verbose
7) Logging: suficiente para auditar, sin convertirlo en un horno de discos
Puedes activar logging:
ufw logging on
O ajustar nivel:
ufw logging low
lowsuele ser un buen punto: útil para ver intentos sin llenar logs.- En sistemas con mucho ruido público,
low+ rate-limit y una estrategia de SSH adecuada suele ser lo más sano.
Los logs suelen ir a syslog/journal según distro. Si usas systemd:
journalctl -u ufw --no-pager
(Dependiendo del sistema, puede variar; a veces se registra como kernel firewall events.)
8) Checklist de seguridad rápida (sysadmin realista)
Si el servidor está expuesto a Internet y quieres que esto sea serio:
- SSH con llaves, desactiva password si puedes.
- Restringe SSH por IP o por VPN/bastión.
ufw limit sshpara bajar el ruido.- Mantén solo 22/80/443 (o lo mínimo real), nada de “ya lo cerraré luego”.
- Revisa
ss -tulpny alinea puertos expuestos con servicios reales. - Documenta reglas: cuando haya incidente, te ahorra tiempo.
Flujo recomendado (resumen operativo)
ufw status(confirmar inactivo)ufw default deny incomingufw default allow outgoingufw allow from X.X.X.X to any port 22 proto tcp(oufw allow ssh)- Abre solo lo necesario (http/https u otros)
ufw enableufw status verbose- Ajusta logging + revisa IPv6
Errores típicos que siguen ocurriendo (y cómo evitarlos)
- Activar UFW antes de permitir SSH → bloqueo inmediato.
- Abrir puertos por costumbre (“por si acaso”) → superficie de ataque gratuita.
- Olvidar IPv6 → exposición “fantasma”.
- Usar SSH con password abierto al mundo → cuestión de tiempo que lo intenten.
- No validar servicios escuchando → firewall bien, demonios mal.
