Escanee en una dirección IP nueva: el puerto 6379 de Redis está abierto, el puerto 3306 MySQL responde. El VPS tenía nginx configurado correctamente y sin firewall denegado de forma predeterminada. El atacante no hackeó nginx; Habló directamente con Redis. Este escenario ocurre en minutos en cualquier IP pública sin filtrar, no en semanas.
Configurar el firewall de un VPS significa definir quién tiene derecho a hablar con qué servicios. No instale diez herramientas: comience negando todo el tráfico entrante excepto el esencial, luego abra solo lo que el sitio realmente respira. El firewall no crea la vulnerabilidad; hace visible la negligencia de escuchas ilegales de su red.
Muchos equipos configuran nginx, implementan la aplicación y luego "hacen el firewall más tarde". Lo posterior suele ocurrir después del primer análisis, o después de que un compromiso de Redis se haya dejado abierto "temporalmente".
Puertos para autorizar como entrada para un sitio web clásico
| Puerto | Servicios | Nota |
|---|---|---|
| 22/tcp | SSH | Restringir a la IP del administrador si es posible |
| 80/tcp | HTTP | Redirección ACME y HTTPS |
| 443/tcp | HTTPS | Sitio público |
| ICMP | hacer ping | Opcional; algunas herramientas de monitoreo lo usan |
Todo lo demás cerrado de forma predeterminada: MySQL 3306, Redis 6379, Postgres 5432, SMTP 25, panel de administración 8080. Los servicios internos escuchan en 127.0.0.1 o en la red privada, no en 0.0.0.0 expuesta a Internet.
Antes de escribir la primera regla, enumere lo que realmente se escucha:
ss-tlnp
Compare el resultado con lo que pensó que había instalado. Docker, por ejemplo, puede publicar puertos sin que ufw los filtre según la configuración; consulte los errores a continuación.
ufw: secuencia segura para que no te bloqueen
Antes de ufw enable, mantenga abierta una sesión SSH y pruebe desde una segunda ventana:
ufw por defecto denegar entrada
ufw por defecto permite salida
ufw permite 22/tcp
ufw permite 80/tcp
ufw permite 443/tcp
habilitar ufw
estado ufw detallado
Si está administrando desde una IP fija, restrinja SSH:
ufw permite desde TU.IP.OFICINA a cualquier puerto 22 proto tcp
IPv6: una regla ufw enable 443/tcp debe cubrir v6 o una regla explícita; olvidar v6 crea un agujero que escanea el exploit. Verifique con ufw status detallado que las reglas v6 estén alineadas.
Muchos hosts (Hetzner Cloud Firewall, OVH Network Security) filtran antes que el VPS. Se recomienda doble capa: panel restrictivo más UFW local alineado. Consulte Nube de firewall de Hetzner para ver un ejemplo concreto de reglas de panel.
Complementos: fail2ban, claves SSH, errores clásicos
fail2ban prohíbe direcciones después de repetidos fallos de SSH; consulte SSH seguro. Sin contraseña SSH: solo claves. El firewall no parchea las vulnerabilidades sin parches (CVE); Reduce la superficie de ataque expuesta.
Errores que vuelven:
- Permitir 3306 “temporalmente” durante meses;
- Docker
-p 6379:6379que publica Redis sin filtro ufw según la configuración; - Deshabilitar ufw “para depuración” sin fecha de regreso al servicio;
- SSH abierto globalmente con autenticación de contraseña débil.
Para obtener un bastión de acceso, consulte Bastión SSH: alternativa a exponer SSH directamente desde cualquier IP.
The Top: El firewall revela lo que habitualmente expones
Enumere ss -tlnp antes de escribir la primera regla. Compare VPS con firewalls de panel a través del directorio y la comparación: algunos hosts europeos incluyen un firewall en la nube gratuito, otros lo cobran por separado.
Decide y avanza sin puntos ciegos
Durante medio día, puedes asegurar un nuevo VPS o auditar uno existente:
- Inventario puertos abiertos con
ss -tlnpy escaneo desde afuera; no confíe en su memoria de la instalación. - Configure primero el firewall restrictivo en la nube: SSH desde la IP de la oficina, 80 y 443 pública, todo lo demás cerrado.
- Habilite ufw como denegación de forma predeterminada con las mismas reglas: mantenga abierta una sesión SSH durante la prueba.
- Vincular bases de datos y caché en localhost o red privada únicamente; nunca en 0.0.0.0 sin túnel o VPN.
- Empareje autenticación de clave fail2ban y SSH: el firewall por sí solo no es suficiente contra ataques de fuerza bruta.
- Vuelva a verificar los contenedores IPv6 y Docker que publican puertos sin filtros después de cada implementación.
Preguntas frecuentes
¿ufw o nftables directamente?
ufw para comenzar rápidamente en Ubuntu o Debian: abstracción legible. nftables o iptables si son reglas complejas o scripts de infraestructura. Ambos pueden coexistir; Evite duplicados conflictivos que bloqueen el tráfico legítimo.
¿Deberíamos cambiar el puerto SSH 22?
Solo oscuridad de bajo beneficio. Las claves SSH sin contraseña más fail2ban valen más. Puerto personalizado como beneficio adicional para reducir el ruido del escaneo, no como reemplazo de una autenticación sólida.
¿Firewall de host en la nube + ufw local?
Recomendado para defensa en profundidad: panel firewall como primera barrera, ufw en la instancia. Alinee las reglas para que no lo bloqueen, especialmente a través de SSH desde una IP fija.
¿Abrir MySQL en el escritorio para phpMyAdmin?
No vivir en Internet. Túnel SSH, VPN o administración únicamente a través de localhost. Expose 3306 atrae escaneos en minutos.
Un firewall VPS efectivo no comienza permitiendo todo: comienza negando todo y luego abriendo solo lo que el sitio no puede prescindir.