¡¡Hola, chicos!!
En este artículo me gustaría compartir con ustedes un pequeño estudio sobre cómo conectarse usando la conexión DAC (Conexión de administrador dedicada) sin el navegador SQL. Esta idea surgió de una pregunta enviada en mi curso. Seguridad de SQL Server – Módulo 1, donde Fabiano Ferreira envió la siguiente pregunta: "en el script stpchecklist_seguranca, hay una validación acerca de que el Navegador SQL se ejecuta con una sola instancia y se trata como un error. Sin embargo, ¿el Navegador SQL no se utiliza para permitir el uso de la conexión a través de conexiones de administrador remoto? Si es así, ¿sería un error dejarlo activo?" – ¡Y esa fue una pregunta EXCELENTE!

¿Qué es la conexión DAC (Conexión de administrador dedicada)?

Como sabes, la conexión DAC (conexión de administrador dedicada) permite que SQL Server reserve una ranura de conexión para que, en casos extremos, como en el caso de que se estén utilizando todas las conexiones o que un activador de inicio de sesión impida las conexiones, aún pueda iniciar sesión en la instancia e intentar solucionar el problema, sin tener que reiniciar el servicio SQL. Para obtener más información sobre la conexión DAC, haga clic en este enlace aquí.

¿Qué es el navegador SQL? ¿Cómo funciona?

SQL Browser es el servicio de SQL Server que "traduce" el nombre de la instancia al puerto que está utilizando. Daré un ejemplo de cómo son las instancias del servidor dirceu-vm:

En otras palabras, hay instancias SQL2008, SQL2012, SQL2014, SQL2016, SQL2017 y SQL2019 en este servidor (Ej: dirceu-vm\sql2017). Cuando realice un intento de conexión usando esta instancia, SQL Browser identificará el nombre de la instancia informada (SQL2017) y devolverá qué puerto está usando esta instancia, de acuerdo con la configuración:

En el caso anterior, mi instancia está usando un puerto dinámico, es decir, ingresa el valor "0" en este campo y cada vez que se inicia el servicio, esta instancia usará un puerto aleatorio. En este escenario, donde un servidor tiene varias instancias, el Navegador SQL es importante, ya que identifica el nombre de la instancia solicitada en la conexión y devuelve qué puerto dinámico está utilizando esa instancia en ese momento.

Conexión a una instancia con el navegador SQL activado:

Tenga en cuenta que en el ejemplo anterior, no necesitaba informar el número de puerto que está usando esta instancia, porque desde el momento en que ingreso el nombre de la instancia, el servicio SQL Browser identificará qué puerto está usando esta instancia y realizará la conexión por mí. Si deshabilita el navegador SQL, deberá informar manualmente a la conexión qué puerto está utilizando la instancia. Como este puerto cambia cada vez que se inicia el servicio, es difícil saber qué puerto es para cada instancia.

Ahora, usemos un puerto fijo para nuestra instancia (1437):

En el ejemplo anterior, ya sé qué puerto usará mi instancia, ya que está arreglado y lo definí. Aunque el servidor tenga varias instancias, si todas tienen un puerto fijo, puedes dejar SQL Browser desactivado, ya que la conexión mediante el formato “servidor, puerto” se puede realizar sin mayores dificultades (aunque el patrón “servidor\instancia” es más fácil de memorizar, es cierto).

Conexión a una instancia con el navegador SQL deshabilitado:

¿Por qué deshabilitar el navegador SQL?

Después de la explicación anterior sobre el Navegador SQL, quedó claro que SQL Server no necesita esta característica para funcionar normalmente (excepto en entornos de clúster. En este caso, el Navegador SQL no se puede deshabilitar), ya que termina exponiendo el nombre y los puertos utilizados por cada instancia en la red. Si buscas listas de control de seguridad en Internet o buenas prácticas de seguridad, verás que la mayoría recomienda desactivar este servicio.

Aunque no creo que esto sea un grande mejora de la seguridad, dado que el riesgo de mantener el navegador SQL en ejecución es relativamente bajo, creo que vale la pena implementar cualquier dificultad adicional que pueda ofrecer a un atacante potencial.

Además, cuando ingresa "servidor, puerto", puede cambiar este puerto de vez en cuando y con el impacto de solo cambiar la cadena de conexión de las aplicaciones y realizar un cambio muy simple en el protocolo de instancia para cambiar el puerto (en esta captura de pantalla anterior). Cambiar el nombre de la instancia también implica realizar modificaciones más complejas en la base de datos, además de las aplicaciones, y si usa el nombre de la instancia para algún monitoreo o rutina, este cambio puede afectar esto.

¿Qué pasa con la conexión DAC? ¡Deshabilitar el navegador SQL no funciona!

Con el navegador SQL activado, simplemente agregue el prefijo ADMIN: antes del nombre del servidor\instancia para conectarse usando el DAC (si esta conexión no se está usando, por supuesto):

Y entonces, puedo conectarme usando el DAC:

Pero luego, cuando desactivo el navegador SQL e intento conectarme usando DAC, aparece este mensaje de error:

En otras palabras, ¡el DAC no funciona sin el navegador SQL!

¡Cálmate, jóvenes! Explicaré por qué sucede esto. Así como "traduce" el nombre de la instancia al número de puerto, el servicio del navegador SQL también identifica el prefijo "ADMIN:" en la conexión y devuelve el número de puerto de la conexión DAC para esa instancia y, por lo tanto, la conexión se realiza exitosamente usando el DAC.

En otras palabras, como el navegador SQL está deshabilitado, no realizó esta "traducción" para el puerto utilizado por la conexión DAC en esta instancia (cada instancia solo puede tener 1 conexión DAC) y luego SQL Server no pudo identificar a qué puerto se conectará. La “magia” para usar la conexión DAC sin el navegador SQL es simplemente informar el puerto utilizado por el DAC de esta instancia en el formato “servidor, puerto”.

Cuando usamos la instancia predeterminada, el puerto de conexión DAC predeterminado es 1434, pero cuando tengamos instancias con nombre y, sobre todo, varias instancias, el puerto será dinámico. Y para saber qué puerto está utilizando la conexión DAC, podemos utilizar las siguientes consultas:

Usando sp_readerrorlog

sp_readerrorlog 0, 1, 'Dedicated admin connection'

Usando el DMV sys.dm_tcp_listener_states

SELECT 
    [port] 
FROM 
    sys.dm_tcp_listener_states 
WHERE 
    is_ipv4 = 1 
    AND [type] = 0 
    AND ip_address <> '127.0.0.1'

Usando el DMV sys.dm_server_registry

SELECT 
    * 
FROM 
    sys.dm_server_registry 
WHERE 
    value_name = 'TcpDynamicPorts' 
    AND registry_key LIKE '%\AdminConnection\Tcp'

Usando el registro de SQL Server

Una vez que hayamos identificado qué puerto utiliza la conexión DAC (en el caso de este ejemplo, es 49830), simplemente introdúzcalo en la cadena de conexión:

Y ahora comprobaré que estoy usando la conexión DAC:

SELECT DISTINCT
    A.endpoint_id,
    A.local_net_address,
    A.local_tcp_port,
    B.[name],
    A.session_id,
    @@SPID AS MEU_session_id
FROM
    sys.dm_exec_connections A
    JOIN sys.endpoints B ON A.endpoint_id = B.endpoint_id
WHERE
    A.endpoint_id IS NOT NULL
    AND A.local_tcp_port IS NOT NULL
    AND B.is_admin_endpoint = 1

¡Y eso es todo, amigos!
¡Espero que hayas disfrutado este artículo!

Para obtener más información sobre todos los aspectos de la seguridad en SQL Server, asegúrese de realizar mi curso. Seguridad en SQL Server – Módulo 1, donde hablo de diversas configuraciones, buenas prácticas y consejos para mejorar la seguridad de tu entorno SQL Server y también sería MUY interesante realizar el curso Conceptos básicos de Windows para el administrador de bases de datos de SQL Server, de la leyenda Rodrigo Ribeiro, donde habla de varios temas muy importantes que un DBA debe saber, incluida la conexión DAC, incluso muestra cómo cambiar este puerto :).

Un abrazo y nos vemos en el próximo artículo.