SQL Server Security: Bloqueo y desbloqueo de Logins

Hace unos días estaba hablando sobre SQL Server Security con un cliente, el cual me realizó una pregunta encontré bastante interesante. La pregunta era sobre los bloqueos de los inicios de sesión, me preguntaba si había una manera de bloquearlos para evitar ataques de fuerza bruta. Este cliente trabajaba con distintos servidores de bases de datos, no solamente SQL Server, y encontraba esta falta como una carencia del producto.

En este artículo vamos a ver como configurar nuestros inicios de sesión en SQL Server para que se bloqueen en función de un número de intentos que habrá que especificar.

El primer intento

Cuando intentamos crear un nuevo inicio de sesión nos encontramos con el siguiente formulario:

A priori no vemos ninguna opción visible para especificar nada acerca de un posible bloqueo de la cuenta. Si miramos en la pestaña “Estado” o “Status” tenemos las siguientes opciones:

Ahora vemos algunas configuraciones acerca de los permisos para conectar al servidor y para habilitar o deshabilitar el inicio de sesión, pero todavía no hay ni rastro de la posibilidad de bloquear la cuenta. Nuestra primera reacción, al igual que nuestro cliente, es pensar que no es posible bloquear nuestros inicios de sesión o cuentas en SQL Server, pero esto no es cierto y ahora veremos como hacerlo posible.

Bloquear inicios de sesión

Tal y como hemos comentado en la sección anterior, no existe manera de especificar un número de intentos para el bloqueo de un inicio de sesión cuando intentamos crearlo, bien desde Management Studio o bien desde código T-SQL (en el caso de T-SQL solo aparece la opción de desbloquear un inicio de sesión con el comando ALTER, para el bloqueo no hay ninguna opción.

Para activar la opción de bloqueo de inicios de sesión debemos hacerlo a nivel de Sistema operativo. En Windows Server tenemos una opción que nos permite introducir el número de intentos. Por otro lado, recordar que en SQL Server tenemos dos modos de autenticarnos:

– Autenticación Windows

Usuarios Windows (locales o de dominio)

Grupos de usuarios (locales o de dominio)

– Autenticación SQL Server

Incluye autenticación Windows

Inicios de sesión SQL (usuario y password)

Nota: Para más información podemos leer la documentación online.

Al aplicar esta configuración, quedan incluidos todos los inicios de sesión con autenticación Windows y todos los inicios de sesión de SQL que se hayan creado con la opción check_policy=ON. Si creamos inicios de sesión que no cumplan las políticas de seguridad de Windows, esta opción de bloqueo no afectará ya que, como veremos en la siguiente sección, dicha propiedad se configura a nivel de seguridad en el sistema operativo.

Configurando bloqueos de inicios de sesión: SQL Server Security

Lo primero que vamos a hacer es configurar nuestro servidor para especificar la propiedad lockout threshold, así que lo primero que haremos es ejecutar gpedit.msc para configurarlo.

Como vemos en la imagen anterior, cuando se nos abra el formulario navegamos a través de Computer Configuration -> Security Settings -> Account Policies -> Account Lockout Policy. Una vez aquí encontraremos la propiedad que andábamos buscando, Account Lockout Threshold. Por definición esta propiedad esta establecida con el valor 0, esto significa que no hay bloqueo en los inicios de sesión de SQL Server ni en las cuentas del propio servidor. De modo que lo que vamos a hacer es cambiarlo para establecer un límite, en este caso vamos a poner 2 intentos. Para ello doble clic sobre la propiedad Account Lockout Threshold.

Establecemos el nuevo valor, para este caso el 2, y modificamos el valor. Cuando tratamos de modificar esta propiedad, el sistema operativo nos alerta que necesita cambiar otras propiedades relacionadas:

Estas propiedades también pueden ser cambiadas al gusto del administrador, podemos elegir el tiempo de bloqueo de la cuenta o inicio de sesión y cada cuanto se reinicia el contador de bloqueos. Estos temas ya son dependientes de cada política de seguridad y de cada administrador aunque lo más normal seria que si se bloquea una cuenta sea el administrador quien la desbloquee después de saber que ha pasado y porque se ha bloqueado.

Al final se nos queda la siguiente configuración:

Ya tenemos nuestro sistema operativo configurado, asumimos que con las cuentas del servidor ya funciona pero lo que realmente nos interesa probar en este artículo son los inicios de sesión de SQL Server. Para ello nos creamos un nuevo inicio de sesión:

   1: USE [master]

   2: GO

   3: CREATE LOGIN [test1] WITH PASSWORD=N'p4$$w0rd',

   4: DEFAULT_DATABASE=[master],

   5: CHECK_POLICY=ON

   6: GO

Fijémonos que hemos creado un inicio de sesión SQL Server con la opción de check_policy=ON. Si lo pusiéramos en OFF no funcionaria.

Ahora vamos a intentar bloquear la cuenta pasando credenciales erróneas 2 veces, así veremos como al cuenta se bloquea. Durante los dos primeros intentos (la cuenta no esta bloqueada) obtenemos los siguientes mensajes de error:

El tercer intento establecemos las credenciales correctamente y obtenemos el siguiente error:

Ahora si que nos dice el mensaje que la cuenta se ha bloqueado y que el administrador es quien puede desbloquearla para que vuelva a funcionar. De modo que para desbloquearla lo que hacemos es ejecutar el comando ALTER LOGIN tal y como sigue:

   1: ALTER LOGIN [test1] with password=N'p4$$w0rd'unlock

   2: go

Así ya tenemos nuestro inicio de sesión desbloqueado y tenemos de nuevo dos intentos para que se vuelva a bloquear.

SQL Server Security: Conclusión

Se recomienda como buena práctica utilizar este tipo de configuraciones, no solo para SQL Server sino también a nivel de sistema operativo. De este modo nos estamos protegiendo contra ataques de fuerza bruta minimizando el número de intentos para hackear un inicio de sesión.

Personalmente no he visto esta opción establecida en demasiados clientes y considero que es una de las que deberían ser incluidas en nuestras políticas de seguridad como administradores. Como siempre dependerá del escenario que tengamos, idealmente esta opción encaja mejor en sistemas donde el acceso es por usuario y cada usuario tiene su inicio de sesión. Para escenarios donde tengamos que los usuarios conectan a través de una o varias aplicaciones habrá que ser más cautelosos con el número de intentos, ya que si ponemos un umbral de dos intentos como en la demostración podríamos encontrarnos con que ante un ataque la aplicación quedase bloqueada, por ello es que en estos casos seria mejor aumentar dicho umbral de intentos para dar más margen y una política de detecciones de logins fallidos que nos alerte antes del bloqueo del inicio de sesión y por tanto de la aplicación.

Si te ha gustado nuestro artículo sobre SQL Server Security, seguro que encontrarás más que te interesan en nuestro blog. Desde SolidQ, te invitamos a suscribirte a nuestra newsletter para que no te pierdas ninguno 🙂