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:

How to login SQL Server Security

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:

image_thumb_1_3A7043D7

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.

How to login SQL Server Security 2

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.

image_thumb_3_3A7043D7

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:

Suggested value changes SQL Server Security

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:

image_thumb_5_3A7043D7

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:

SQL Server Security Error

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

image_thumb_7_3A7043D7

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 🙂

0 Shares:
7 comments
  1. ¡Muchas gracias! Gran aporte…

    ¿Es posible activar esta politica solo para SQL Server?

    Se los pregunto por lo siguiente:

    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

    Sin más que agregar quedo de ustedes, saludos.

  2. Buenas tardes

    Nuevamente consultadolos, ¿Por que en versiones posteriores de SQL no se muestra el mensaje de cuenta bloqueda?

    Me aparece un error 18456 unicamente en SQL Server 2016.

      1. Muchas Gracias por responder, es correcto lo que mencionas la metodología sigue siendo la misma.

        Incluso si desde un management version 2016 intentas loguearte a un motor SQL 2008 te muestra el mensaje de cuenta bloqueada, sin embargo no lo muestra si haces lo mismo desde un motor SQL 2016.

        Bloquea la cuenta y todo, inclusive en sys.messages aparece el mensaje respectivo de cuenta de bloqueo, solo que no lo muestra desde el management.

        No se si se trate de algun permiso a nivel instancia, alguna configuracion, ya no se…

        Gracias por tu apoyo Enrique.

        Saludos.

  3. Enrique, buenos días! Muchas gracias por tu aporte!!

    Llegue hasta tu articulo buscando una manera de BLOQUEAR las IP REMOTAS que fallen en su login después de X numero de intentos, es eso posible?

    Pues estamos teniendo intentos de acceso remoto a nuestro SQL SERVER 2016 y en este momento lo estamos solucionando mediante el FIREWALL de WINDOWS SERVER poniendo la restricción de IP’s permitidas en la REGLA DE ENTRADA para el puerto TCP 1433.

    En este momento ocupamos permitir el acceso remoto a varios usuarios y tenemos que estar actualizando la lista de IP’s permitidas en la regla de entrada anteriormente mencionada.

    Hay alguna forma de que sin necesidad de esta regla podamos hacer algo automatizado, una especie de FAIL2BAN que luego de X intentos de acceso mediante el puerto TCP 1433 mande esa IP a una lista negra e impida que continué intentando conectarse a SQL SERVER?

    Muchas gracias, apreciare cualquier ayuda que puedas darme al respecto!

    Saludos,
    Dante.

    1. en principio efectivamente lo que estás haciendo es correcto. SQL Server es un servicio y como tal, debes permitir-denegar antes de que el proceso malicioso llegue a el. Un firewall es la opción correcta para llevar a cabo ese cribado
      un saludo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

Expresiones, parámetros y funciones en Azure Data Factory

Hay ocasiones, cuando estamos construyendo pipelines con Azure Data Factory, que queremos repetir patrones para extraer y procesar la información cambiando de manera dinámica, en tiempo de ejecución, valores, orígenes/destinos de los datasets, incluso los mismos linked services. Esto es posible mediante el uso de parámetros, expresiones y funciones. Vamos a ver cómo implementarlo con un ejemplo práctico en el que se nos plantea el siguiente supuesto. Se nos ha pedido que extraigamos todos los días los datos del día anterior de distintas tablas del DW a ficheros en un blob storage que además se nombre como la tabla de origen. Si no pudiéramos utilizar contenido dinámico tendríamos que crear dos datasets (uno de origen y otro de destino) y añadir una actividad de copia por cada tabla a exportar.
Leer más

Extraer datos de Twitter desde un servicio creado con Python en Visual Studio 2017

En el post que os traemos hoy vamos a ver como crear (con Visual studio 2017) mediante un script en python un programa que podremos ejecutar como un servicio de windows y que extraiga en tiempo real los twitts relacionados con determinadas palabras o hashtags, los almacene en una base de datos sql server, para luego explotarlos con powerbi. El objetivo de este script es el de conectar al api de streaming de twitter al que le pasaremos una lista de hashtags o terminos y nos devolverá de forma indefinida en tiempo real los twitts que se van publicando que contienen estos terminos.