mysql tcp port: guía técnica, configuración y seguridad

El puerto TCP que utiliza MySQL suele ser el primer punto de control en la conectividad de bases de datos. Entender cómo funciona, cómo cambiarlo y qué implicaciones de seguridad tiene evita interrupciones y reduce la superficie de ataque. Este texto ofrece instrucciones concretas, comandos de diagnóstico y un mini-caso práctico para aplicar cambios en entornos reales.

Qué representa el puerto TCP de MySQL

El puerto TCP normalmente asociado a MySQL es el 3306. Es el canal por el que clientes y servicios remotos establecen sesiones con el servidor de base de datos. Aunque cambiar el puerto no resuelve problemas de seguridad complejos, afecta a la conectividad, a reglas de firewall y a la forma en que se detectan servicios activos en la red.

Configurar y cambiar el puerto en my.cnf

Cambiar el puerto se realiza en la configuración del demonio de MySQL. El parámetro relevante en la sección [mysqld] es port. Si existe una directiva skip-networking, el servidor no escuchará en TCP aunque se configure el puerto.

Ubicaciones habituales del archivo de configuración

En distribuciones Linux las rutas comunes son /etc/mysql/my.cnf, /etc/my.cnf o archivos en /etc/mysql/mysql.conf.d/. En instalaciones desde paquetes es frecuente que exista una cadena de archivos incluidos; en contenedores la configuración puede estar embebida en el Dockerfile.

Ejemplo de modificación

Para cambiar a 3307, agregar o editar en la sección [mysqld]:

port=3307

Después de guardar, reiniciar el servicio con el mecanismo del sistema (systemd, init, etc.). Ejemplo: sudo systemctl restart mysql. Confirmar que el servidor escucha en el puerto nuevo antes de cambiar reglas de firewall.

Seguridad: firewall, SELinux y medidas complementarias

El ajuste del puerto debe ir acompañado de controles de acceso. El puerto abierto por defecto es objetivo frecuente de escaneos automatizados. Las siguientes medidas combinadas fortalecen la postura de red:

1. Filtrado por IP: limitar las conexiones al puerto sólo a direcciones o rangos necesarios en firewall (iptables, nftables, cloud security groups).
2. Autenticación y usuarios mínimos: revisar cuentas, eliminar root remoto, evitar usuarios con privilegios excesivos.
3. TLS: obligar cifrado TLS para conexiones remotas; configurar certificados y exigir require_secure_transport=ON en MySQL 8+.
4. Auditoría de acceso: habilitar logs de conexión y revisar intentos fallidos para detectar patrones de ataque.
5. Restricción por puerto alternativo: usar puertos no estándar solo como medida de reducción de ruido, no como defensa principal.

Diagnóstico y pruebas: comandos útiles

Al realizar cambios en el puerto, conviene verificar varios puntos: que el demonio escucha, que el sistema operativo permite la conexión y que las reglas de red no bloquean el tráfico.

Comandos frecuentes:

• ss -tlnp | grep 3306 — lista sockets TCP en escucha y el PID asociado.
• netstat -tlnp | grep 3306 — alternativa en sistemas que lo tengan.
• telnet servidor 3306 o nc -zv servidor 3306 — prueba rápida de conexión TCP.
• mysql -h direccion -P 3306 -u usuario -p — prueba de conexión con cliente MySQL.
• journalctl -u mysql -e — revisar errores al arrancar tras cambiar la configuración.

Un escenario común: el demonio arranca pero no existe escucha TCP. Revisar si aparece skip-networking o si bind-address está limitado a 127.0.0.1.

Escenarios avanzados: múltiples instancias, NAT y balanceadores

Cuando se despliegan varias instancias de MySQL en la misma máquina, cada instancia necesita su propio puerto y directorio de datos. Esto obliga a coordinar puertos, sockets Unix y archivos de configuración.

En topologías con NAT o balanceadores, el puerto del cliente puede diferir del puerto interno. Por ejemplo, una nube pública puede exponer el 443 y redirigir a 3306 internamente mediante TLS/SSL offloading o TCP proxy. En estos casos, documentar mappings y mantener reglas de salud para el balanceador evita desconexiones inesperadas.

También hay que considerar límites de sistema: aumentar el número de conexiones concurrentes implica ajustar open_files_limit y max_connections y validar que la red soporte el tráfico sin pérdida.

Caso práctico: migrar MySQL a un puerto distinto para reducir ruido de escaneo

Contexto: en una instancia de staging que recibe escaneos masivos, el equipo opta por mover MySQL de 3306 a 33306 para evitar sondas automáticas. Pasos seguidos de forma ordenada:

1. Verificar que no existen conexiones activas críticas: show processlist; realizar ventanilla de mantenimiento si procede.
2. Editar el archivo de configuración en /etc/mysql/my.cnf añadiendo port=33306 bajo [mysqld].
3. Asegurarse que bind-address está correctamente configurado. Para accesos remotos controlados usar la IP(s) del host o 0.0.0.0 si el firewall restringe el acceso.
4. Actualizar reglas de firewall: permitir 33306 sólo desde las IP autorizadas y bloquear 3306 si no se usa.
5. Reiniciar el servicio: sudo systemctl restart mysql; comprobar con ss -tlnp | grep 33306.
6. Actualizar aplicaciones y variables de entorno que usen puerto 3306, preferiblemente con fallbacks y pruebas en preproducción.
7. Monitorear logs y patrones de conexión 24–72 horas para detectar efectos colaterales.

Resultado habitual: se reduce la aparición en listados automáticos de servicios, pero es imprescindible no depender solo del cambio de puerto para seguridad. En un mini-caso real de una plataforma interna, la migración a 33306 eliminó miles de intentos de conexión automatizados por semana sin impacto en clientes que se actualizaron en paralelo.

Conclusión: el puerto TCP de MySQL es un componente operativo que afecta seguridad, disponibilidad y arquitectura. Cambiarlo es sencillo, pero debe acompañarse de controles de acceso, pruebas y documentación. Para entornos productivos se recomienda combinar filtrado por IP, TLS obligatorio y auditoría de accesos. Implementar cambios en fases controladas y validar con comandos como ss, nc y el cliente MySQL minimiza riesgos y permite recuperar con rapidez si aparece cualquier incidencia.