Cómo configurar de forma segura las reglas de firewall del VPS
Publicado el 4 de septiembre de 2026
Un firewall debe permitir el tráfico que tu servidor necesita y rechazar discretamente el resto. Para configurar de forma segura las reglas de firewall del VPS, comienza con los servicios que deben seguir siendo accesibles, especialmente SSH, y luego agrega los puertos web y de aplicación uno a la vez. No empieces bloqueándolo todo desde la única sesión de terminal que tienes abierta. Así es como una tarea de mantenimiento tranquila se convierte en una tarea de recuperación por consola.
Para la mayoría de los despliegues de VPS Linux, el objetivo práctico es simple: denegar por defecto el tráfico entrante no solicitado, permitir el tráfico saliente requerido y crear reglas de entrada estrictas para usuarios y servicios de confianza. Esto reduce la superficie de ataque sin dificultar la administración rutinaria.
Comienza con el mapa de tráfico
Antes de cambiar cualquier regla, anota qué hace realmente el VPS. Por ejemplo, un sitio público de WordPress normalmente necesita SSH para la administración y los puertos 80 y 443 para el tráfico web. Una API privada puede necesitar solo HTTPS, mientras que un servidor de base de datos normalmente debería aceptar conexiones solo desde un servidor de aplicaciones en una red privada.
Primero verifica los servicios en escucha. En la mayoría de las distribuciones de Linux, este comando ofrece una vista útil:
```bash sudo ss -tulpn ```
No abras automáticamente todos los puertos mostrados. Algunos servicios escuchan solo en localhost o en una interfaz privada y no necesitan acceso público a través del firewall. Otros pueden ser servicios de prueba antiguos, agentes de monitorización o software que no debería ser accesible desde internet en absoluto.
Para cada puerto expuesto al público, responde tres preguntas: ¿quién lo necesita, desde dónde y sobre qué protocolo? Una regla que permite HTTPS desde cualquier lugar es normal para un sitio web público. Una regla que permite un puerto de base de datos desde cualquier lugar normalmente es un problema esperando cortésmente en los registros.
Mantén una vía de recuperación antes de configurar las reglas de firewall del VPS
Mantén dos sesiones SSH activas mientras realizas cambios en el firewall. Usa una sesión para aplicar las reglas y deja la segunda intacta. Después de aplicar un cambio, prueba una conexión nueva desde otra terminal antes de cerrar nada. Esto detecta errores en la ruta de conexión real en lugar de confiar en el optimismo.
Confirma también que la consola de tu proveedor de VPS esté disponible. Una consola basada en navegador o un entorno de rescate es la alternativa si SSH queda bloqueado. No sustituye el trabajo cuidadoso, pero es un buen seguro operativo.
Si SSH se ejecuta en un puerto no estándar, verifícalo antes de crear reglas:
```bash sudo ss -tulpn | grep ssh ```
Un puerto SSH no estándar puede reducir el ruido de fondo de los escaneos automatizados, pero por sí solo no es una medida de seguridad significativa. La autenticación sólida, el acceso limitado por origen y la aplicación oportuna de parches son lo que realmente hace el trabajo.
Usa una política de denegación predeterminada para el tráfico entrante con UFW
UFW es una interfaz de firewall práctica para servidores VPS con Ubuntu y Debian. Es fácil de leer más tarde, lo cual importa cuando otro administrador necesita solucionar una interrupción a las 2 de la mañana.
Primero, establece valores predeterminados sensatos:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
A continuación, permite SSH antes de habilitar el firewall. Si tu servidor usa el puerto SSH predeterminado, usa:
```bash sudo ufw allow OpenSSH ```
Si SSH escucha en un puerto personalizado, especifícalo explícitamente. Este ejemplo usa el puerto 2222:
```bash sudo ufw allow 2222/tcp ```
Para un sitio web público normal, permite HTTP y HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Luego habilita el firewall y verifica la política resultante:
```bash sudo ufw enable sudo ufw status numbered ```
El estado numerado es útil porque después las reglas pueden eliminarse con precisión. Evita dejar reglas temporales demasiado amplias después de la resolución de problemas. Las reglas temporales tienen la curiosa costumbre de convertirse en mobiliario permanente.
Si el VPS aloja una aplicación web detrás de un proxy inverso, puede que el puerto de la aplicación no necesite ser público. Por ejemplo, Nginx puede aceptar tráfico en los puertos 80 y 443 mientras la aplicación escucha en `127.0.0.1:3000`. En ese diseño, no se necesita ninguna regla de firewall para el puerto 3000.
Restringe el acceso administrativo por IP de origen
SSH no debería estar abierto a todas las direcciones a menos que tu equipo realmente necesite esa flexibilidad. Si tu oficina, VPN o jump host tiene una dirección IP pública estable, limita SSH a ella:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Para un equipo distribuido con IP domésticas cambiantes, una VPN o un bastion host suele ser una mejor opción que abrir SSH globalmente. Añade un poco de trabajo de configuración, pero te da una única ruta de administración controlada y un rastro de auditoría más limpio.
La limitación de velocidad también puede reducir los intentos básicos de adivinar contraseñas de SSH:
```bash sudo ufw limit 22/tcp ```
Esto no sustituye las claves SSH, la autenticación por contraseña deshabilitada cuando corresponda ni el acceso multifactor a través de tu ruta de administración. Piénsalo como un panel de la cerca, no como toda la cerca.
Trata las bases de datos, paneles y monitorización por separado
Los puertos de bases de datos como MySQL en 3306, PostgreSQL en 5432, Redis en 6379 y MongoDB en 27017 casi nunca deberían estar disponibles públicamente. Permítelos solo desde la dirección IP privada o la subred del servidor de aplicaciones.
Por ejemplo, para permitir conexiones MySQL solo desde un VPS de aplicaciones en `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
El propio servicio de base de datos también debería vincularse a la interfaz privada prevista cuando sea posible. Las reglas de firewall y la vinculación del servicio son capas separadas. Usar ambas significa que un cambio erróneo en el firewall tiene menos probabilidades de exponer el servicio.
Los paneles de hosting, los paneles de Grafana y los endpoints de monitorización merecen la misma atención. Si son solo para el personal, restríngelos a una VPN, un rango de IP de oficina o una red de administración dedicada. Las páginas públicas de monitorización pueden exponer más detalles de la infraestructura de lo esperado, incluso cuando no muestran secretos.
Ten en cuenta el firewall del proveedor y IPv6
Tu VPS puede tener más de una capa de firewall. Un firewall de nube o de nivel de proveedor filtra el tráfico antes de que llegue al servidor, mientras que UFW, firewalld, nftables o iptables filtran el tráfico en el propio VPS. Usar ambos es sensato, pero las reglas deben coincidir.
Si el puerto 443 está abierto en el VPS pero bloqueado en la capa del proveedor, los visitantes seguirán sin poder conectarse. Si el proveedor permite un puerto pero el VPS lo deniega, el VPS sigue protegido. Durante la resolución de problemas, comprueba ambas capas en orden: política del proveedor, firewall del VPS, dirección de escucha del servicio y configuración de la aplicación. Por lo general, los registros cuentan la misma historia una vez que se comprueba todo esto.
No olvides IPv6. Si tu VPS tiene una dirección IPv6 pública, se requieren reglas IPv6 equivalentes. UFW puede gestionar IPv6 cuando está habilitado en su configuración, pero verifícalo con:
```bash sudo ufw status verbose ```
Una dirección IPv4 correctamente protegida no ayuda si el mismo servicio está completamente abierto a través de IPv6.
Prueba desde fuera y luego supervisa el resultado
Después de cada cambio importante, prueba desde una red externa al VPS. Confirma que los servicios previstos funcionan y luego confirma que los puertos que deben seguir siendo privados no sean accesibles. Las pruebas en el navegador son útiles para sitios web, pero las pruebas en línea de comandos dan respuestas más claras para puertos específicos:
```bash nc -vz your-server-ip 443 ```
En los puertos bloqueados, un tiempo de espera o un rechazo pueden significar cosas distintas según la regla y el estado del servicio. Revisa el estado del firewall, el estado del servicio y los registros del sistema en lugar de cambiar varios ajustes a la vez.
Habilita el registro cuidadosamente al diagnosticar un problema:
```bash sudo ufw logging low ```
El registro de nivel bajo suele ser suficiente para detectar tráfico denegado inesperado sin generar actividad innecesaria en disco. En servidores con mucha actividad, los registros de firewall de alto volumen pueden convertirse en su propia pequeña molestia operativa.
Revisa las reglas de firewall siempre que despliegues un servicio nuevo, retires una aplicación antigua, cambies las direcciones IP de la oficina o modifiques la arquitectura de red. Las mejores reglas no son el conjunto más largo de reglas. Son el conjunto más pequeño que describe con precisión cómo debe comunicarse el servidor.
Si prefieres no asumir este trabajo en solitario, un equipo de VPS administrado puede revisar los requisitos de acceso, aplicar cambios con un plan de recuperación y supervisar el servidor después. En kodu.cloud, esto encaja de forma natural junto con las operaciones administradas y la monitorización continua, especialmente para equipos que necesitan centrarse en los clientes y el producto en lugar del filtrado de paquetes.
Un firewall está haciendo su trabajo cuando nadie lo nota. Mantén la política estricta, documenta por qué existe cada excepción y prueba el acceso antes de declarar que el servicio vuelve a estar tranquilo.
Andres Saar Ingeniero de Atención al Cliente