¿Por qué la autenticación del sistema operativo se considera una seguridad deficiente para las bases de datos Oracle?


29

Oracle está desaprobando la autenticación del sistema operativo de acuerdo con la Guía de seguridad de la base de datos de Oracle , que dice

Tenga en cuenta que el parámetro REMOTE_OS_AUTHENT fue desaprobado en Oracle Database 11g Release 1 (11.1), y se conserva solo por compatibilidad con versiones anteriores.

Además, la mayoría de las herramientas y la información de seguridad consideran que la autenticación del sistema operativo (externo) es un problema de seguridad. Estoy tratando de entender por qué este es el caso. Aquí hay algunas ventajas que veo de la autenticación del sistema operativo:

  1. Sin OS, las aplicaciones de autenticación deben almacenar contraseñas en una variedad de aplicaciones, cada una con su propio modelo de seguridad y vulnerabilidades.
  2. La autenticación de dominio ya tiene que ser segura porque si no lo es, la seguridad de la base de datos solo ralentiza el acceso a la base de datos, pero no puede evitarla.
  3. Los usuarios que solo tienen que recordar una contraseña de dominio pueden crear contraseñas de dominio más seguras más fácilmente de lo que pueden crear contraseñas de bases de datos aún menos seguras a medida que aumenta el número de bases de datos diferentes a las que deben conectarse.

¿Dónde vio que Oracle estaba desaprobando la autenticación externa?
Justin Cave

1
@Justin Cave Actualizaré la pregunta con esa información.
Leigh Riffel

2
Gracias por la actualización. Sin embargo, solo por claridad, Oracle no está desaprobando la autenticación externa, está desaprobando la autenticación externa remota, que generalmente es mucho menos segura (como Gaius analiza a continuación)
Justin Cave

Respuestas:


16

Considere el siguiente escenario:

  1. Hay un usuario de Unix nombrado gaiusen el servidor de Oracle con autenticación externa, por lo que en Oracle hay un usuario correspondiente llamado ops$gaius. Cuando inicie sesión en un shell, también puedo iniciar sesión directamente en mi esquema de Oracle, y mis trabajos cron tampoco necesitan una contraseña incrustada en el script.
  2. Se permite la autenticación remota del sistema operativo, en el supuesto de que la LAN es 100% seguro y los clientes se puede confiar (igual que el rlogin/ rshsolía ser normalmente permitido)
  3. Un atacante conecta su computadora portátil a la LAN por cualquier medio, sabe que trabajo allí y crea un usuario local en su computadora portátil llamado gaiusy ejecuta SQL * Plus como ese usuario
  4. Oracle ve (es decir, OSUSERen V$SESSION) es gaiusy registra a ese usuario remoto comoops$gaius

Eso no es solamente ridículamente fácil de parodia, pero poner mi sombrero de cínico, Oracle no puede hacer más dinero vendiendo que su fantasía de sesión único producto ... que por cierto no cumplir con todos los puntos que usted plantea como ventajas del sistema operativo -Nivel aut. Dos contraseñas mejores que una son completamente falsas; la mayoría de las personas los configurarán para que sean iguales de todos modos (no hay ningún mecanismo en Oracle para evitar esto).

El principio general es que es extremadamente difícil defender en software cuando un atacante tiene acceso físico. Y nunca confíes en el cliente.


2
Es incluso peor que eso. Vea '¿Por qué las cuentas OPS $ son un riesgo de seguridad en un entorno cliente / servidor?' (culpan a Windows, pero tienes razón, es cualquier cosa en la red)
Joe

3
¿Cómo el servidor está en un dominio de Windows factor en esto? es decir, ¿el atacante tendría que unir su computadora al dominio para tener una cuenta que incluya el dominio, o podría el atacante simular la presencia del dominio sin tener que unirse a su computadora?
Leigh Riffel

Supongo que fue escrito originalmente en un momento en que todos los servidores eran Unix y todos los escritorios eran Windows
Gaius

3
@Leigh: puede hacer que la autenticación remota del sistema operativo sea más segura con los clientes de Windows configurando OS_AUTHENT_PREFIX para que sea un dominio confiable de Windows. Eso requiere que el cliente remoto esté (o parezca estar) en ese dominio de confianza. Eso eleva sustancialmente el listón sobre un trivial "conecte la computadora a un puerto libre, agregue un usuario local y usted está en" ataque, pero aún así es bastante fácil de vencer.
Justin Cave

1
comparar y contrastar si estaba haciendo una autenticación AD / Kerberos real, y tomando un ticket del usuario y verificándolo con el KDC, lo que supongo es lo que hace SqlServer cuando se configura para usar la autenticación de Windows.
araqnid

8

Aumenta los puntos únicos de falla y aumenta la superficie de riesgo de sus datos.

Un atacante que obtenga acceso al sistema, con la autenticación del sistema operativo, tendrá acceso a la base de datos. Al requerir un acceso más seguro a la base de datos, el atacante potencial debe escalar sus privilegios en el sistema comprometido para obtener acceso root u oráculo, en lugar de cualquier usuario.

Este problema es una función del acceso externo a la base de datos. Si no hay acceso externo y la máquina está completamente asegurada, entonces la cuestión de los permisos es discutible. Sin embargo, si los desarrolladores tienen acceso, los permisos de usuario a nivel del sistema operativo aumentan el alcance de posibles desastres de seguridad.

Considere el uso de acceso multinivel para limitar el alcance de las infracciones de seguridad y brindar a cualquier usuario, aplicación o cliente el acceso que necesitan sin la necesidad de crear cuentas de nivel de sistema operativo para cada instancia.


Ya veo, así que para simplificar demasiado, dos requisitos de nombre de usuario / contraseña son más seguros que uno. Tus puntos suenan razonables.
Leigh Riffel

Esta es una respuesta sutilmente incorrecta: el problema no es la autenticación externa sino la autenticación externa remota . Explicaré a continuación.
Gaius

@Gaius ¿No sería extremadamente limitada la autenticación del sistema operativo externo casi hasta el punto de no tener valor si no fuera remota? ¿Está diciendo que Oracle no está desaprobando la autenticación usando el sistema operativo, sino solo desaprobando la autenticación del sistema operativo desde una computadora remota?
Leigh Riffel

@Leigh: el caso de uso principal para la autenticación del sistema operativo de las cuentas locales es para tareas de tipo DBA en las que se ejecutan un montón de scripts de shell en el servidor de la base de datos que necesitan acceder a cuentas muy potentes en el servidor de la base de datos. La autenticación del sistema operativo le permite evitar tener contraseñas de nivel DBA sin cifrar en esos scripts de shell.
Justin Cave

@Justin trabajos por lotes en general, implementados como scripts de shell o lo que sea, en crons individuales
Gaius

4

Gaius ya ha señalado por qué la autenticación remota del sistema operativo (a diferencia de la autenticación del sistema operativo estándar en la que permite que los usuarios locales de la máquina accedan a la base de datos sin especificar una contraseña por separado) es relativamente insegura.

Esperaría que Oracle se esté moviendo en esta dirección porque quiere alentar a las personas a usar usuarios empresariales (o el conjunto de gestión de identidad completo) en lugar de usuarios autenticados del sistema operativo remoto. Los usuarios empresariales tienen las mismas ventajas que los usuarios autenticados del sistema operativo remoto, pero Oracle en realidad está saliendo y accediendo a su servidor de Active Directory para autenticar al usuario. Obtiene los mismos beneficios de inicio de sesión único sin dejar el control de seguridad en la máquina del cliente.


La autenticación LDAP puede abrir otra lata de gusanos ... Publicaré una respuesta más larga.
Joe

+1 Gracias por señalar Seguridad de usuario empresarial. Ya hemos estado considerando la seguridad avanzada y esto lo hace aún más atractivo.
Leigh Riffel

4

Señala específicamente la autenticación de estilo de identificación, pero también me gustaría señalar que otros métodos para vincular la base de datos o cualquier otro inicio de sesión a los inicios de sesión del sistema operativo son igual de malos. (ya sean archivos de contraseña locales, LDAP o lo que sea para el almacenamiento real de las credenciales)

Si permite conexiones remotas a la base de datos (o al servidor web, o lo que sea que esté haciendo la autenticación), algunos sistemas operativos ignorarán las reglas que podrían establecerse para dificultar las cuentas de fuerza bruta (por ejemplo, bloquear las direcciones IP de donde provienen los intentos fallidos; bloquear usuarios por un período después de un número determinado de fallas, etc.). Normalmente, estas reglas están vinculadas sshdy no con el sistema de autenticación en su conjunto.

Entonces, si alguien puede conectarse a la base de datos / servidor web / lo que sea de forma remota, puede forzar la contraseña, ya que las bases de datos no tienden a tener los mismos mecanismos para retrasar los intentos, y luego ingresar una vez que encuentran las credenciales necesarias.


2
No estoy seguro de seguir el razonamiento aquí. Si tiene que Oracle se autentique contra LDAP, tendría que romper LDAP para obtener la contraseña; no habría una copia local del hash de la contraseña a fuerza bruta como lo habría para un usuario regular de Oracle. Si le preocupan los atacantes que superan su autenticación LDAP, probablemente tenga mayores problemas que la forma en que está autenticando a los usuarios de Oracle. Y es bastante fácil configurar Oracle para bloquear cuentas después de varios intentos fallidos, restringir las direcciones IP permitidas, etc. Gran parte de eso, de hecho, es el comportamiento predeterminado en 11g.
Justin Cave

@Justin: solo es un problema si lo vincula para que las credenciales para iniciar sesión en el sistema operativo sean las mismas que las credenciales para iniciar sesión en la base de datos (o servidor web, etc.). Y parece que Oracle mejoró la autenticación que la última vez que la usé, pero la mayoría de las otras bases de datos no. (y Apache tampoco, por lo que los usuarios de MacOS X Servers deberían cambiar mod_auth_appley mod_auth_digest_applepor las versiones predeterminadas, aunque no he probado si el problema todavía existe en 10.6)
Joe
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.