Datahorses

Puertos de bases de datos expuestos: MySQL, PostgreSQL, MongoDB, Redis y Elasticsearch

Por · · 4 min de lectura

Un puerto de base de datos está expuesto cuando cualquiera en internet puede abrir una conexión con él. Su aplicación necesita llegar a la base de datos; un ordenador cualquiera en otro país, no. Sin embargo, basta una regla de cortafuegos, una línea de configuración modificada o un valor predeterminado en la nube para que MySQL, PostgreSQL, MongoDB, Redis o Elasticsearch respondan a todo internet.

Un puerto abierto no es automáticamente una brecha. Si la autenticación es sólida y el software está actualizado, el atacante todavía tiene que superarla. Pero un puerto abierto convierte su base de datos en algo que cualquiera puede sondear, contra lo que puede probar contraseñas y en lo que puede buscar vulnerabilidades conocidas. Cerrarlo elimina toda esa categoría de riesgo.

Este artículo enumera los puertos predeterminados, muestra cómo comprobarlos desde fuera y explica cómo cerrarlos correctamente.

Los puertos predeterminados que conviene conocer

Estos son los puertos predeterminados según la documentación de cada fabricante:

Los servicios pueden funcionar en otros puertos, así que tome esta lista como punto de partida, no como un escaneo completo.

Cómo acaban las bases de datos en internet

La mayoría de estos productos son hoy más seguros por defecto que antes:

Por eso la exposición suele venir de un cambio deliberado que iba a ser temporal:

  • alguien configuró bind-address = 0.0.0.0, listen_addresses = '*' o bindIpAll para que un desarrollador pudiera conectarse desde casa,
  • se desactivó el modo protegido o la seguridad "para que funcione",
  • un grupo de seguridad en la nube o una regla de cortafuegos permite el puerto desde 0.0.0.0/0,
  • un -p 6379:6379 de Docker publica el puerto en todas las interfaces del host,
  • nunca se apagó un antiguo servidor de pruebas o de staging con su propia base de datos.

La documentación de Redis es directa sobre el riesgo: Redis está diseñado para clientes de confianza en entornos de confianza, y una instancia expuesta puede perder todos sus datos con un solo comando FLUSHALL.

Cómo comprobarlo desde fuera

La comprobación debe hacerse desde fuera de su red; de lo contrario, solo prueba el camino interno. Use una máquina en otra conexión (una VM en la nube, la zona wifi del móvil) y pruebe solo direcciones IP que sean suyas:

for port in 3306 5432 27017 6379 9200 9300; do
  nc -z -w 3 203.0.113.10 $port && echo "$port open" || echo "$port closed"
done

En el propio servidor, vea en qué direcciones escucha cada servicio:

sudo ss -tlnp | grep -E ':(3306|5432|27017|6379|9200|9300)\b'

127.0.0.1:5432 o una dirección privada es lo que quiere ver. 0.0.0.0:5432 o [::]:5432 significa que el servicio escucha en todas las interfaces y que solo un cortafuegos se interpone entre él e internet.

Los escáneres de internet también indexan los puertos abiertos de cada dirección IP pública. Para ver rápidamente lo que tienen registrado sobre una de sus direcciones, Shodan ofrece una consulta sencilla en https://internetdb.shodan.io/<your-ip>.

Cómo cerrarlo correctamente

Use 2 capas, para que un solo error no vuelva a exponer la base de datos:

  1. Escuche solo en interfaces privadas. bind-address = 127.0.0.1 (MySQL), listen_addresses = 'localhost' o una IP privada (PostgreSQL), net.bindIp (MongoDB), bind 127.0.0.1 con protected-mode yes (Redis), network.host en una dirección privada (Elasticsearch).
  2. Restrinja a nivel de red. El cortafuegos o el grupo de seguridad en la nube solo debe permitir el puerto de la base de datos desde sus servidores de aplicaciones.
  3. Acceso remoto mediante túnel. Los desarrolladores se conectan por túneles SSH o VPN, nunca a través de un puerto abierto.
  4. Exija autenticación en todas partes, también en redes internas: usuarios con privilegios mínimos, contraseñas largas y TLS para las conexiones que salen de un único host.
  5. Mantenga el software actualizado, para que, si alguna vez un puerto queda expuesto por error, no ejecute además una versión con vulnerabilidades conocidas.

Si una base de datos estuvo expuesta con autenticación débil o sin ella, considere que sus datos pueden haber sido copiados: cambie las credenciales, revise los registros y valore sus obligaciones de notificación.

Una lista de comprobación breve

  • Enumere todas las direcciones IP públicas que usa su empresa, incluidos los servidores antiguos.
  • Pruebe desde fuera los puertos de bases de datos habituales.
  • Asegúrese de que cada base de datos escucha solo en localhost o en una dirección privada.
  • Permita los puertos de bases de datos en el cortafuegos solo desde los servidores de aplicaciones.
  • Vuelva a comprobarlo tras cada migración, servidor nuevo o cambio en Docker.

Los servicios abiertos rara vez aparecen solos. Suelen estar en los mismos servidores de staging olvidados que además filtran archivos .env y copias de seguridad.

Cómo ayuda Datahorses

Datahorses vigila su empresa desde fuera cada día y muestra qué servicios puede ver un atacante en sus direcciones públicas, incluidos los puertos de bases de datos y el acceso remoto como RDP o SSH, junto con las vulnerabilidades conocidas de las versiones que revelan. No entramos en sus sistemas y no necesitamos accesos. Cada hallazgo llega con los pasos exactos para su desarrollador, como se describe en qué ocurre cuando encontramos algo. El panel de ejemplo muestra cómo es un informe así.

Más artículos

Todos los artículos