¿Qué amenazas de seguridad representan la seguridad para la cuenta SA y otros nombres de cuenta conocidos?

¿Un nombre de cuenta conocido como sa representa una amenaza para la seguridad de la base de datos? Cuando se usa la autenticación de Windows en SQL Server, ¿impone la misma política de contraseña (si se configuró para decir el bloqueo de la cuenta después de 5 veces)?

¿Un nombre de cuenta conocido como sa representa una amenaza para la seguridad de la base de datos?

Una cuenta de usuario "dios" con un nombre conocido generalmente se considera una idea peor que un usuario dios con un nombre menos conocido. Hace que los ataques de fuerza bruta sean un poco más fáciles ya que el atacante solo tiene que adivinar la contraseña y no el nombre de usuario y la contraseña.

También tener un usuario de dios de todos modos puede ser peligroso. En general, es mejor tener usuarios específicos con derechos específicos para lo que deben hacer. Este tipo de seguridad basada en privilegios es más fácil de implementar desde cero que de adaptarlo a su entorno más adelante.

Deshabilitar sa y otorgar a los usuarios específicos derechos de administrador específicos según sea necesario en el servidor SQL es esencialmente la misma recomendación que deshabilitar rooty entregar derechos de administrador según sea necesario a través de sudoLinux y similares. Siempre puede volver a habilitar sauna vez conectado directamente a la máquina con los privilegios adecuados en caso de que algo salga mal y termine eliminando todos los derechos que sus usuarios necesitan para operar (y solucionar el problema) de la misma manera que puede diseñar el acceso raíz a un Linux cuadro si tiene acceso físico al cuadro, por lo que deshabilitar la cuenta no es una bala mágica (pero una vez que un atacante tiene acceso físico a su máquina, o acceso administrativo completo a través de RDC o SSH, todas las apuestas están desactivadas de todos modos).

Cuando se usa la autenticación de Windows en SQL Server, ¿impone la misma política de contraseña (si se configuró para decir el bloqueo de la cuenta después de 5 veces)?

Cuando se utiliza la autenticación integrada de Windows, el servidor SQL no tiene control sobre los bloqueos de cuentas y demás, simplemente asigna un usuario de Windows a un usuario de SQL y le pide al sistema operativo que confirme el hecho de que el usuario ha proporcionado las credenciales adecuadas. Para los usuarios humanos interactivos, esto significa que cualquier bloqueo ocurriría cuando el usuario intentara autenticarse con Windows, no cuando iniciaron sesión en SQL Server.

No es una mala idea hacer que el usuario administrador predeterminado (admin / root / postgres / sa / etc) no exista en su sistema. Siempre puede crear una cuenta privilegiada con un nombre diferente.

Por lo menos, las personas que intentan explotar su sistema no lo tienen tan fácil como si estuvieran trabajando a ciegas (por ejemplo, inyección SQL sin tener un shell interactivo ni poder ver la salida directa de sus comandos)

En cuanto a los bloqueos de cuentas: si alguien logró llegar lo suficientemente lejos como para poder intentar iniciar sesión en su máquina, a menos que permita específicamente el inicio de sesión directo de los usuarios, ya habrá perdido la batalla. Personalmente, no estoy a favor de los bloqueos en su mayor parte, porque le da a alguien la capacidad de crear una denegación de servicio si logran obtener el nombre de cualquiera de sus usuarios. (¿y hacer que bloqueen al súper usuario?

Recomiendo revisar los CIS Benchmarks ... no los tienen para todas las bases de datos, pero tienen recomendaciones para Oracle, MS SQL, DB2 y MySQL. Si está ejecutando algo más, aún vale la pena revisar los tipos generales de cosas que recomiendan.

No vi a nadie más mencionar esto, así que lo agregaré. Con SQL Server 2005+ si su servidor es parte de un dominio y el dominio tiene una política de contraseña, puede habilitar la política de contraseña para que se aplique en los inicios de sesión de SQL. Esto incluye los requisitos de complejidad de la contraseña y la capacidad de forzar cambios de contraseña al iniciar sesión.

Tenga en cuenta que esto a veces puede causar problemas con algunos instaladores de software que no se han actualizado para trabajar con SQL 2005+ y crear inicios de sesión SQL con contraseñas inseguras.

Hay dos modos de autenticación utilizados en SQL Server: autenticación de Windows y modo mixto (habilita la autenticación de Windows y la autenticación de SQL Server)

El primer modo es menos vulnerable a los ataques de fuerza bruta, ya que es probable que el atacante se encuentre con un bloqueo de inicio de sesión (la función de Política de bloqueo de cuenta) después de un número finito de intentos de ataque. Todos los entornos de producción, si utilizan el modo de autenticación de Windows, deben utilizar la función de política de bloqueo, ya que hace que los ataques de fuerza bruta sean imposibles

Cuando se trata de la vulnerabilidad de ataque de fuerza bruta de autenticación de SQL Server, la situación no es tan favorable. La autenticación de SQL Server no tiene características que permitan detectar cuándo el sistema está bajo un ataque de fuerza bruta. Además, SQL Server es muy receptivo cuando se trata de validar las credenciales de autenticación de SQL Server. Puede manejar fácilmente intentos de inicio de sesión repetidos, agresivos y de fuerza bruta sin un rendimiento general negativo que pueda indicar tales ataques. Esto significa que la autenticación de SQL Server es un objetivo perfecto para descifrar contraseñas mediante ataques de fuerza bruta

Además, los métodos de fuerza bruta están evolucionando con cada método de encriptación y complejidad de contraseña recientemente introducido. Por ejemplo, los atacantes que usan tablas de arco iris (las tablas precalculadas para revertir los valores hash criptográficos para cada combinación posible de caracteres) pueden descifrar fácil y rápidamente cualquier contraseña hash

Para proteger su SQL Server de ataques de fuerza bruta, debe considerar lo siguiente:

• No use el modo de autenticación de SQL Server: obligue al atacante a cerrar el inicio de sesión mediante la autenticación de Windows
• En caso de que necesite usar el modo de autenticación de SQL Server, deshabilite o elimine el inicio de sesión SA, de esa manera el atacante debe adivinar y emparejar tanto el nombre de usuario como la contraseña

La cuenta sa, cuando está habilitada, puede hacer cualquier cosa en el servidor SQL. Si un atacante entrara en esta cuenta, podría hacer cualquier cosa en la instancia de SQL Server (y posiblemente en el sistema operativo host) que quisiera.

Las SA (y otros nombres de cuenta conocidos) son puntos conocidos que los hackers pueden atacar. Algunos de los Oracle estaban mal documentados y, por lo tanto, las contraseñas predeterminadas no siempre se cambiaban. Una vez que tiene el control de la cuenta SA en SQL Server, usted controla el servidor en el que se ejecuta y puede ejecutar cualquier código o instalar lo que desee. En mis días de más vaquero, recuerdo que no se me permitió (necesitaba documentación que no iba a llenar) instalar un control ActiveX en un servidor web que también alojaba SQL Server, así que usé xp_cmdshell para copiar e instalar el control .