Guía de puertos de SQL Server: acceso a la base de datos en el puerto 1433

Un cliente SQL se conecta al servidor de escucha, negocia la configuración del protocolo, se autentica con autenticación SQL, autenticación de Windows, Entra ID u otro método compatible y luego envía consultas, transacciones y solicitudes de metadatos.

El puerto solo confirma que se puede localizar al oyente. El acceso real a la base de datos también depende del estado de inicio de sesión, los permisos de la base de datos, la configuración de cifrado, la configuración de la instancia, las cadenas de conexión, el DNS y las reglas de firewall en múltiples capas.

Una instancia predeterminada de SQL Server normalmente escucha en TCP 1433. Las instancias con nombre pueden usar puertos dinámicos a menos que configure un puerto estático. SQL Server Browser puede ayudar a los clientes a descubrir instancias con nombre, pero muchos entornos de producción prefieren puertos estáticos para una política de firewall más clara.

Si su cadena de conexión utiliza la sintaxis de servidor y puerto, verifique el puerto exacto. Si usa un nombre de instancia, verifique el Administrador de configuración de SQL Server, el registro de errores o la configuración del servidor para ver en qué puerto escucha realmente la instancia.

Abra el acceso a SQL solo desde servidores de aplicaciones, estaciones de trabajo de administración, herramientas de migración, servicios de informes o redes confiables que necesiten conectividad de base de datos. Se debe evitar el acceso público a menos que exista un requisito gestionado y monitoreado muy específico.

Para bases de datos en la nube, prefiera puntos finales privados, emparejamiento de VPC o VNet, VPN, rutas de bastión, redes de servicios o listas permitidas de firewall nativo del proveedor en lugar de permitir que todo Internet alcance 1433.

Antes de permitir TCP 1433, confirme que la instancia esté escuchando en la interfaz y el puerto esperados, que se conozca la política de cifrado, que los inicios de sesión tengan un alcance, que existan roles de base de datos con privilegios mínimos y que las copias de seguridad sean confiables.

Un verificador de puertos puede confirmar la accesibilidad de la red, pero no puede probar que la base de datos sea segura. Pruebe la cadena de conexión real con sqlcmd, SQL Server Management Studio, Azure Data Studio, comprobaciones del estado de las aplicaciones y registros del servidor.

En Windows Server, habilite TCP/IP para la instancia de SQL Server, configure un puerto estático si es necesario, reinicie el servicio y permita el TCP 1433 entrante en el Firewall de Windows Defender solo desde fuentes confiables.

En implementaciones de Linux SQL Server, confirme que mssql-server escucha en el puerto deseado y permita ese puerto en firewalld, ufw, nftables, iptables o grupos de seguridad en la nube. Mantenga el acceso a la administración separado del acceso a las aplicaciones.

Para servicios SQL administrados, utilice reglas de firewall del proveedor, puntos finales privados y controles de identidad. No asuma que abrir un punto final de base de datos en la nube equivale a exponer un único puerto de VM; La política de acceso a nivel de proveedor también es importante.

Comience con una verificación del puerto externo o interno con el nombre de host de la base de datos y TCP 1433, dependiendo de dónde se ejecutará el cliente. Si el puerto está abierto, pruebe la conexión real con sqlcmd, SSMS, Azure Data Studio o la cadena de conexión de la aplicación.

Si se requiere TLS, verifique la configuración de cifrado y confianza del certificado del cliente. Luego verifique los registros del servidor para detectar fallas de inicio de sesión, denegaciones de firewall, errores de permisos a nivel de base de datos y patrones de tiempo de espera de conexión.

Si el puerto 1433 está cerrado, es posible que SQL Server no se esté ejecutando, que TCP/IP esté deshabilitado, que la instancia use un puerto diferente o que un host, nube o firewall de red pueda bloquear la ruta. Las instancias con nombre suelen fallar porque el puerto dinámico real es diferente de lo que espera el cliente.

Si el puerto está abierto pero el inicio de sesión falla, inspeccione el modo de autenticación, el formato del nombre de usuario, el estado de la contraseña, los inicios de sesión deshabilitados, la asignación de usuarios de la base de datos, los permisos, los requisitos de cifrado y los registros de errores del servidor. Si las consultas se conectan pero son lentas, observe los bloqueos, índices, CPU, memoria, E/S y planes de consulta.

Mantenga SQL Server fuera de la Internet pública siempre que sea posible. Restrinja las fuentes, requiera cifrado, parchee el motor, deshabilite los inicios de sesión no utilizados, utilice roles con privilegios mínimos, rote las credenciales y audite los inicios de sesión fallidos y las acciones privilegiadas.

Realice copias de seguridad de bases de datos, pruebe restauraciones, supervise consultas lentas y el estado de la replicación, y separe el acceso administrativo del acceso a las aplicaciones. Un puerto de base de datos es una ruta directa a datos confidenciales, por lo que la accesibilidad de la red debe ir acompañada de controles sólidos de identidad y datos.