Tutoriales de VPS
No expongas las bases de datos de tu VPS directamente a Internet (2026): cómo hacer seguro el acceso remoto a MySQL, PostgreSQL y Redis
Muchos incidentes en VPS no se deben a errores en el código de la aplicación, sino a que MySQL, PostgreSQL y Redis están abiertos directamente a Internet. Este artículo explica por qué no debes exponer 3306/5432/6379 y cubre métodos de acceso remoto más seguros, como túneles SSH, VPN, redes privadas y listas de permitidos.
Un amigo, por comodidad, cambió el bind-address de MySQL a 0.0.0.0 y luego abrió el 3306 en el firewall. La razón era simple: conectarse desde Navicat local era fácil.
Al principio sí era cómodo, hasta que un día la CPU subió de golpe y aparecieron un montón de conexiones extrañas en la base de datos. Revisó los registros y descubrió que el puerto 3306 llevaba mucho tiempo siendo escaneado. Aunque la contraseña no fue descifrada, había estado bajo ataques de fuerza bruta continuos durante días.
Redis da aún más miedo. Un Redis sin contraseña y expuesto directamente a Internet es básicamente esperar a que lo escaneen. Muchos de esos incidentes que se ven en Internet, donde escriben tareas programadas, instalan mineros o borran bases de datos, vienen exactamente de esto.
Así que este artículo plantea un solo principio: una base de datos no es un sitio web; no la expongas directamente a Internet solo para que las conexiones remotas sean cómodas.
Primero la conclusión: los puertos de base de datos no deberían estar abiertos a toda Internet por defecto
Los puertos de bases de datos habituales incluyen:
- MySQL / MariaDB: 3306
- PostgreSQL: 5432
- Redis: 6379
- MongoDB: 27017
- Elasticsearch: 9200
Si estos puertos están expuestos a Internet, serán escaneados rápidamente. No es "puede que alguien los escanee", sino que casi con seguridad alguien los escaneará.
El enfoque correcto es:
- Aplicación y base de datos en el mismo VPS: la base de datos escucha en el
127.0.0.1local - Aplicación y base de datos en la misma red privada: solo permitir acceso desde IP privadas
- Gestión temporal desde un equipo local: usar un túnel SSH
- Gestión a largo plazo por varias personas: usar VPN o bastion host
- Acceso público obligatorio: permitir solo una lista de IP fijas y habilitar contraseñas fuertes y TLS
No consideres "se conecta" como una configuración exitosa. Para el acceso remoto a bases de datos, primero pregunta: quién puede conectarse, desde dónde, si está cifrado y cómo detener el daño si algo sale mal.
Muchos tutoriales te dicen: cambia bind-address en la configuración de MySQL de 127.0.0.1 a 0.0.0.0, luego permite el 3306 y podrás conectarte en remoto.
Técnicamente es correcto, pero desde el punto de vista de la seguridad es peligroso.
0.0.0.0 significa escuchar en todas las interfaces de red. Si el firewall también está abierto, cualquier IP pública puede intentar conectarse a este puerto de base de datos.
Puedes comprobar los puertos en escucha con:
ss -lntp | grep -E '3306|5432|6379|27017|9200'
Si ves:
0.0.0.0:3306
0.0.0.0:6379
mantente alerta. A menos que estés totalmente seguro de que el firewall solo permite IP de confianza, esto es exposición pública.
El valor predeterminado más seguro es:
127.0.0.1:3306
127.0.0.1:5432
127.0.0.1:6379
Cuando la aplicación y la base de datos están en el mismo VPS, escuchar en local es suficiente. Las aplicaciones Nginx, PHP, Node y Python pueden conectarse desde la máquina local; la base de datos no necesita estar abierta a Internet.
Si solo quieres gestionar la base de datos desde tu equipo local con Navicat, DataGrip o TablePlus, la forma más simple y segura es un túnel SSH.
Por ejemplo, si MySQL está en el 127.0.0.1:3306 local del VPS, ejecuta en local:
ssh -L 3307:127.0.0.1:3306 root@你的服务器IP
Luego conecta tu herramienta de base de datos local a:
127.0.0.1:3307
Los datos viajan realmente por el canal cifrado SSH y el puerto de la base de datos no está expuesto a Internet.
PostgreSQL es similar:
ssh -L 5433:127.0.0.1:5432 root@你的服务器IP
Redis también funciona:
ssh -L 6380:127.0.0.1:6379 root@你的服务器IP
Este truco sirve para gestión personal, diagnóstico temporal y ediciones ocasionales de datos. La desventaja es que no puedes conectarte cuando el túnel se cae, pero eso es en realidad algo bueno: el puerto se cierra solo cuando no lo usas.
Si varias personas del equipo necesitan acceder a la base de datos, no se recomienda que todos se conecten directamente al puerto público de la base de datos.
Un enfoque más sólido es:
- Crear una red privada con WireGuard / Tailscale / ZeroTier
- Hacer que la base de datos escuche solo en la dirección privada de la VPN
- Permitir solo a la subred de la VPN acceder al puerto de la base de datos
- Dar a cada persona su propia identidad y permisos de VPN
Por ejemplo, el servidor de base de datos tiene una IP privada de WireGuard:
10.8.0.2
Los servidores de aplicaciones o los equipos de desarrollo acceden a través de la VPN:
10.8.0.2:3306
Ni el grupo de seguridad público ni el firewall del sistema abren el 3306. El puerto de la base de datos no se puede escanear desde fuera, así que el riesgo es mucho menor.
Si usas varios VPS del mismo proveedor cloud, también puedes usar una red privada/VPC. Permite solo que las IP privadas accedan al puerto de la base de datos; no lo abras a Internet.
Hay escenarios que realmente requieren acceso público, como un sistema de terceros que extrae datos desde una IP fija, o una IP de salida de oficina fija.
En ese caso, no permitas 0.0.0.0/0; permite solo IP de origen fijas.
Ejemplo con UFW:
ufw allow from 你的办公公网IP to any port 3306 proto tcp
ufw deny 3306/tcp
ufw status numbered
iptables sigue una idea similar: primero permitir IP de confianza y luego rechazar otras fuentes.
Lo mismo en los grupos de seguridad del cloud: pon como origen tu IP fija, no Anywhere.
Al mismo tiempo, también debes hacer lo siguiente:
- Contraseñas fuertes, sin credenciales débiles
- Prohibir el inicio de sesión remoto root en la base de datos
- Crear una cuenta separada con privilegios mínimos para el negocio
- Habilitar TLS/SSL (especialmente a través de Internet)
- Revisar periódicamente los registros de inicios de sesión fallidos
- Las copias de seguridad deben poder restaurarse
Una lista de permitidos no es una bala de plata, pero es mucho mejor que estar abierto a toda Internet.
Redis es una zona de desastre importante.
Mucha gente piensa que Redis es solo una caché y que si se borra, se regenera. Pero una vez que Redis está expuesto, el riesgo no es solo la pérdida de datos: también puede usarse para escribir tareas maliciosas, escribir archivos mediante replicación maestro-esclavo o servir como trampolín para minería.
Como mínimo, Redis debe hacer:
bind 127.0.0.1
protected-mode yes
requirepass 一个足够强的密码
Si necesitas dar acceso remoto a las aplicaciones, prioriza la red privada o la VPN; no abras el 6379 directamente a Internet.
Comprueba si Redis escucha en Internet:
ss -lntp | grep 6379
Si ves 0.0.0.0:6379, no lo dudes: retíralo de inmediato a local o a la red privada.
Si descubres que un puerto de base de datos ha estado público durante un tiempo, no te limites a cerrar el puerto y dar por terminado.
Se recomienda hacer lo siguiente en orden:
- Cerrar de inmediato el acceso público en el firewall/grupo de seguridad
- Conservar los registros; no borrarlos de inmediato
- Revisar los usuarios y permisos de la base de datos
- Cambiar todas las contraseñas de la base de datos
- Revisar si hay cuentas, bases de datos y tablas desconocidas
- Revisar las tareas programadas del sistema, las claves SSH y los procesos sospechosos
- Comparar los datos críticos con copias de seguridad de confianza
- Si Redis/MongoDB estuvo alguna vez desnudo, tratarlo como un incidente de intrusión
En MySQL puedes revisar los usuarios:
SELECT user, host FROM mysql.user;
En PostgreSQL revisa los roles:
\du
En Redis hay que revisar la configuración, los datos, las tareas programadas y el nivel del sistema. El impacto de un Redis desnudo puede ir más allá del propio Redis.
Comprueba los puertos en escucha en el VPS:
ss -lntp | grep -E '3306|5432|6379|27017|9200'
Comprueba desde tu equipo local si los puertos son accesibles:
nmap -Pn -p 3306,5432,6379,27017,9200 你的服务器IP
Si tu equipo local puede escanear estos puertos como abiertos y no has configurado una lista de permitidos, entonces básicamente son accesibles públicamente.
Luego revisa el firewall:
ufw status verbose
iptables -L -n -v
También revisa el grupo de seguridad en la consola de tu proveedor cloud. Mucha gente solo cierra el firewall del sistema y olvida el firewall del cloud; otros endurecen el grupo de seguridad del cloud pero el servicio en el sistema sigue escuchando en Internet. Revisa ambos lados.
Aquí tienes una tabla simple:
| Escenario | Solución recomendada |
|---|---|
| Aplicación local se conecta a base de datos local | Escuchar en 127.0.0.1 |
| Gestión ocasional desde un equipo local | Túnel SSH |
| Gestión de equipo a largo plazo | WireGuard / Tailscale / ZeroTier |
| Comunicación interna entre varios VPS | Red privada / VPC |
| Acceso de terceros con IP fija | Lista de permitidos pública + TLS + privilegios mínimos |
| Caché Redis | Local o red privada; evitar Internet si es posible |
| Diagnóstico temporal | Lista de permitidos temporal, eliminar de inmediato tras su uso |
Si no sabes cuál elegir, usa por defecto el túnel SSH. Simple, seguro y suficiente.
Después de desplegar una base de datos en un VPS nuevo, yo compruebo así:
- ¿MySQL/PostgreSQL/Redis escuchan solo en local o en la red privada?
- ¿El firewall evita abrir 3306/5432/6379 a toda Internet?
- ¿El grupo de seguridad del cloud no tiene reglas de entrada Anywhere?
- ¿Está deshabilitado el inicio de sesión remoto root/admin en la base de datos?
- ¿Se ha creado una cuenta con privilegios mínimos para el negocio?
- ¿Hay contraseñas fuertes o autenticación por clave?
- ¿Se necesita TLS/SSL?
- ¿Están configuradas las copias de seguridad y los simulacros de restauración?
- ¿Sabes dónde consultar los registros?
- ¿Has registrado quién puede acceder a la base de datos?
En el acceso remoto a bases de datos, la comodidad y la seguridad suelen entrar en conflicto. Mi consejo es: si puedes evitar Internet, evítalo; si puedes usar un túnel, úsalo; si puedes usar una red privada, úsala.
Cuando realmente se necesite acceso público, tampoco expongas la base de datos como un servicio web normal. Los puertos web pueden estar orientados a los usuarios; los puertos de base de datos deberían estar orientados solo a las máquinas y personas en las que confías.