Las bases de datos basadas en directorios como LDAP cuentan hoy en día con un doble uso.
Uso 1:
El primero de ellos es más genérico y extenso. Utiliza un árbol LDAP como una base de datos más. Utilízalo como te plazca. Ten en cuenta que al ser una base de datos jerárquica tiene ventajas e inconvenientes con respecto a las bases de datos relacionales. Sus principales ventajas serán la velocidad de acceso y las búsquedas restringidas en aquellos entornos en los que la modificación y el alta de nuevos datos sea de un nivel muy bajo y dónde lo que más se potencie sea la operación de búsqueda.
Uso 2:
En otra segunda utilización nos encontramos con un uso más concreto para la gestión de redes. No deja de ser un uso como el anterior, de una base de datos más, pero en este caso pensado en un entorno concreto, la gestión, la seguridad, la autorización y la autenticación de objetos y usuarios en un sistema informático. Entornos comunes para el famoso "singelsainon".
Hasta aquí todo bien, pero... hay algo que me llama la atención en esto. ¿Qué es? Pues el uso “compartido”. Me explico. Cuando tu montas un árbol LDAP lo siguiente que hay que hacer es decidir que uso le vas a dar y configurar “el esquema”. Es decir, las clases de objetos que vas a crear y mantener en este sistema. Si no vas a gestionar un sistema de seguridad de red no se debe cargar un esquema de seguridad de red…,y al revés, si tienes un sistema de gestión de red… no lo conviertas en un listín de teléfonos.
Hoy en día es común encontrase con “Listines de Teléfonos” LDAP totalmente públicos en los que se ofertan datos más que sensibles y útiles para atacantes a sistemas.
Veamos un ejemplo con la Universidad de Michigan. En ella, como en muchas otras universidades y organismos alrededor del mundo, se ofrece un “Listín de Teléfonos” a través de LDAP. En este caso en esta URL: http://directory.umich.edu/.
Este servicio es un buscador público al que se puede acceder sin ningún problema para consultar información sobre las personas de la universidad. Si ahí buscamos a alguien del sistema, por ejemplo, a “java” (por homenajear a George Lucas) vemos que nos salen los datos de un cierto usuario y del que se muestra, por ejemplo, el tipo de bebida que más le gusta. Información útil y necesario si vas a hacer una fiesta para CollegeFuckFest.
Bien, algunos datos están restringidos por el programador de la web y se nos han mostrado solo los atributos que parecen “más lógicos” para el “Listín de Teléfonos”, como por ejemplo la bebida que más le gusta a Java.
Java Bebe cerveza
Si vemos los datos que aparecen, nos damos cuenta rápidamente que las leyes de protección de datos no son iguales en todo el mundo…, pero continuemos.
Esta aplicación web nos ha mostrado los datos que le parecen pertinentes a este sitio y no solo eso, sino que también restringe el tipo de objetos sobre los que preguntar y los contenedores dónde ejecutar las cadenas de búsqueda. Es decir, “se protege” cierta información del árbol LDAP.
No obstante, la Universidad también permite conexiones al árbol LDAP mediante otro tipo de clientes, y basta con buscar en la guía de información y encontrar como se configuran las conexiones. En esta parte de la Guía de Información nos informan de cual es nombre del servidor LDAP: ldap://ldap.itd.umich.edu
El servidor está publicado en Internet y con acceso anónimo, es decir, público, como un buen “Listín de Teléfonos” al servicio de todo el mundo.
Sin embargo, al haber utilizado un esquema “más generalista”, hay información mucho más útil publicada. Utilizando un cliente LDAP puro, como LDAP Browser, se puede realizar la conexión al árbol LDAP público y ver qué información ofrece. Para conectarse a servidores LDAP públicos basta con conocer la dirección y el puerto. El puerto por defecto es el 389.
IP y puerto LDAP
y en segundo lugar acceder sólo a los objetos e información pública, para ello se marta la opción de enlace anónimo.
Conexión pública sin credenciales
Y el resto es navegar por el árbol para ver la información que se ofrece públicamente:
Navegando por el árbol LDAP
En muchos de estos árboles LDAP públicos se oferta mucha información que puede ser potencialmente peligrosa. Las versiones LDAP v2 en adelante ofertan todo un conjunto de permisos y privilegios que pueden utilizarse para restringir a nivel LDAP qué objetos, qué atributos y que clases pueden ser accedidas por qué usuarios y con que privilegios. Es decir, la gestión de la seguridad completa.
Como recomendaciones de seguridad añadidas habría que tener en cuenta el uso de LDAPs o SASL para autenticar las conexiones que hagan binding con credenciales para que no se puedan interceptar las credenciales como se vio en este ejemplo: "Capturando credenciales LDAP". Y por supuesto proteger las aplicaciones web contra LDAP Injection & Blind LDAP Injection.
Saludos malignos!!
Saludos Malignos!
Uso 1:
El primero de ellos es más genérico y extenso. Utiliza un árbol LDAP como una base de datos más. Utilízalo como te plazca. Ten en cuenta que al ser una base de datos jerárquica tiene ventajas e inconvenientes con respecto a las bases de datos relacionales. Sus principales ventajas serán la velocidad de acceso y las búsquedas restringidas en aquellos entornos en los que la modificación y el alta de nuevos datos sea de un nivel muy bajo y dónde lo que más se potencie sea la operación de búsqueda.
Uso 2:
En otra segunda utilización nos encontramos con un uso más concreto para la gestión de redes. No deja de ser un uso como el anterior, de una base de datos más, pero en este caso pensado en un entorno concreto, la gestión, la seguridad, la autorización y la autenticación de objetos y usuarios en un sistema informático. Entornos comunes para el famoso "singelsainon".
Hasta aquí todo bien, pero... hay algo que me llama la atención en esto. ¿Qué es? Pues el uso “compartido”. Me explico. Cuando tu montas un árbol LDAP lo siguiente que hay que hacer es decidir que uso le vas a dar y configurar “el esquema”. Es decir, las clases de objetos que vas a crear y mantener en este sistema. Si no vas a gestionar un sistema de seguridad de red no se debe cargar un esquema de seguridad de red…,y al revés, si tienes un sistema de gestión de red… no lo conviertas en un listín de teléfonos.
Hoy en día es común encontrase con “Listines de Teléfonos” LDAP totalmente públicos en los que se ofertan datos más que sensibles y útiles para atacantes a sistemas.
Veamos un ejemplo con la Universidad de Michigan. En ella, como en muchas otras universidades y organismos alrededor del mundo, se ofrece un “Listín de Teléfonos” a través de LDAP. En este caso en esta URL: http://directory.umich.edu/.
Este servicio es un buscador público al que se puede acceder sin ningún problema para consultar información sobre las personas de la universidad. Si ahí buscamos a alguien del sistema, por ejemplo, a “java” (por homenajear a George Lucas) vemos que nos salen los datos de un cierto usuario y del que se muestra, por ejemplo, el tipo de bebida que más le gusta. Información útil y necesario si vas a hacer una fiesta para CollegeFuckFest.
Bien, algunos datos están restringidos por el programador de la web y se nos han mostrado solo los atributos que parecen “más lógicos” para el “Listín de Teléfonos”, como por ejemplo la bebida que más le gusta a Java.
Java Bebe cerveza
Si vemos los datos que aparecen, nos damos cuenta rápidamente que las leyes de protección de datos no son iguales en todo el mundo…, pero continuemos.
Esta aplicación web nos ha mostrado los datos que le parecen pertinentes a este sitio y no solo eso, sino que también restringe el tipo de objetos sobre los que preguntar y los contenedores dónde ejecutar las cadenas de búsqueda. Es decir, “se protege” cierta información del árbol LDAP.
No obstante, la Universidad también permite conexiones al árbol LDAP mediante otro tipo de clientes, y basta con buscar en la guía de información y encontrar como se configuran las conexiones. En esta parte de la Guía de Información nos informan de cual es nombre del servidor LDAP: ldap://ldap.itd.umich.edu
El servidor está publicado en Internet y con acceso anónimo, es decir, público, como un buen “Listín de Teléfonos” al servicio de todo el mundo.
Sin embargo, al haber utilizado un esquema “más generalista”, hay información mucho más útil publicada. Utilizando un cliente LDAP puro, como LDAP Browser, se puede realizar la conexión al árbol LDAP público y ver qué información ofrece. Para conectarse a servidores LDAP públicos basta con conocer la dirección y el puerto. El puerto por defecto es el 389.
IP y puerto LDAP
y en segundo lugar acceder sólo a los objetos e información pública, para ello se marta la opción de enlace anónimo.
Conexión pública sin credenciales
Y el resto es navegar por el árbol para ver la información que se ofrece públicamente:
Navegando por el árbol LDAP
En muchos de estos árboles LDAP públicos se oferta mucha información que puede ser potencialmente peligrosa. Las versiones LDAP v2 en adelante ofertan todo un conjunto de permisos y privilegios que pueden utilizarse para restringir a nivel LDAP qué objetos, qué atributos y que clases pueden ser accedidas por qué usuarios y con que privilegios. Es decir, la gestión de la seguridad completa.
Como recomendaciones de seguridad añadidas habría que tener en cuenta el uso de LDAPs o SASL para autenticar las conexiones que hagan binding con credenciales para que no se puedan interceptar las credenciales como se vio en este ejemplo: "Capturando credenciales LDAP". Y por supuesto proteger las aplicaciones web contra LDAP Injection & Blind LDAP Injection.
Saludos malignos!!
Saludos Malignos!
Que miedo....
ResponderEliminarEn el eventazo se hablo de este tema, pero me gustaria saber donde se podria encontrar informacion o sugerencias para mantener el LDAP seguro y evitar esta situacion ¿Es un problema de permisos?¿De configuracion?¿Donde se puede encontrar mas informacion?
De paso, de donde se puede descargar la presentacion que hiciste con el abuelo, de LDAP.
Muy facil:
ResponderEliminar- no permitir Bind anónimo
- sólo permitir conexiones LDAP mediante SSL (para que no se puedan sniffar, MITM, etc).
- restringir (control de acceso) qué atributos y/o ramas puede leer/escribir un usuario. Es decir, crear "usuarios de binding" para distinas aplicaciones o usos, y asignar ACIs según los permisos que se le quiera dar a cada usuario y según qué elementos del ldap (atributos, ramas, ...).
-Roman
Se me ha ido el dedo..
ResponderEliminars/romano/romansoft
;-)
@roman,
ResponderEliminaren palabras de Obelix, "están locos estos romanos".
:P
"Pa cuando meto yo la pata..." ;)
Gracias por la respuesta.
ResponderEliminar;)
sr. M0k0, si es que el RoMaNSoFt es un empollón de clase... ;)
ResponderEliminar@maligno: estas cosas no se explican en clase... (al menos a mí no me lo explicaban). O se explicaban a última hora, que tampoco cuenta (era la hora del futbolín [cuando quieras te doy unas lecciones xD]!!! :-)).
ResponderEliminar@m0k0: de nada. Bonito nick xD
-r
@maligno
ResponderEliminar"root beer" es la zarzaparrilla esa asquerosa (¡qué mala es!). No es alcohólica y no se si encontrarás mucha de esa en el CollegeFuckFest.
Un saludo
@Romansoft: Gracias, se me ocurrio un dia que se me disparo la alergia. ;)
ResponderEliminarSi hay clases me apunto... Y si hay cerveza tambien. XD
Cerveza... ¿dónde? :D
ResponderEliminarClases al futbolin??
ResponderEliminarque yo soy gato chaval. Al fubtolín madrileño no me ganais, ahora si sacais el futbolín ese con rampas, jugadores de chapas y en los que se puede meter gol con la media y el hueco entonces .... mejor jugamos a las chapas!!
@maligno: tu eres de los que tiene que hacer cambios en la delantera para meter gol, ¿no? :) Eso es como hackear un linux teniendo la clave de root! :)
ResponderEliminar