GT-SCHEMA RedIRIS

Generador

Documento

Resultado de los questionarios

Actualización del software  Evitaremos bugs corregidos y disfrutaremos de las mejoras introducidas. [:OJO:] A partir de la versión 2.4 no hay soporte para la base de datos lmdb como backend; en su lugar se aconseja migrar a Berkeley DB (bdb). Tampoco tiene soporte para el sistema de mantenimiento de réplicas slurp, por tanto es necesario migrar al syncrep. Estos dos procesos son sencillos de realizar.

¿La versión de tu OpenLDAP coincide con la úlitma versión estable?

Criterio a nivel Sistema Operativo  En este apartado se analizan una serie de reglas básicas a nivel de sistema operativo: cómo se ejecuta el demonio slapd, permisos sobre ficheros y directorios y la conveniencia de cifrar o no la base de datos.

Reglas básicas  La securización del sistema operativo excede el alcance de este documento, aparte de las siguientes reglas básicas: ¿Existe un plan de actualización periódica del sistema operativo y se aplican regularmente los parches de seguridad que se publican? ¿Se emplea un sistema dedicado para dar el servicio? ¿Se filtran los accesos al sistema a través de un firewall? [OJO] Es preferible Iptables que TCP wrappers; Este último consume más recursos de procesado ya que requiere aceptar las conexiones antes de denegarlas. Ejecución del demonio slapd  El demonio slapd se puede lanzar utilizando diversos parámetros que analizamos a continuación. [OJO] Parar el demonio con kill -9 deja la base de datos inconsistente; En su lugar utilizar kill -INT. ¿El demonio slapd se arranca con un usuario no privilegiado del sistema? Se utilizan los parámetros "slapd -u openldap -g openldap". ¿Si la máquina tiene varias interfaces, se controla qué interfaces y puertos escucha el demonio? Se utiliza el parámetro "slapd -h protocolo://interfaz:puerto ¿Se ejecuta en un entorno enjaulado CHROOT? Se utiliza el parámetro "slapd -r directorio" (Si es un servidor dedicado no parece imprescindible) ¿El servidor LDAP es accesible a través de internet? El servidor LDAP suele convertirse en punto de entrada a la mayoría de los aplicativos de la institución, por lo que solo debería estar accesible a los servidores de la red interna. Permisos sobre los directorios y archivos del openLDAP  Los directorios y archivos deben tener los mínimos privilegios para evitar ser accedidos por usuarios no autorizados. Comprueba los permisos y propietario de los ficheros: "-rw-r----- root ldap sladp.conf" "-rw-r--r-- root ldap ldap.conf" Los Schemas, pertenecerán a root y podrán leerlo todos: "drwxr-xr-x root root Schemas/" "-rw-r—r-- root root *.schema" Base de datos: solo debe ser accedida por el usuario ldap: "drwx------ ldap ldap database/" "-rw------- ldap ldap *.db?" Ficheros log de la base de datos solo deben ser accedidos por el usuario ldap: "-rw------- ldap ldap log.00*" Se debe definir una política de rotación de estos log, por la seguridad de eliminarlos del sistema y evitar ocupar espacio inútilmente. Incluir la directiva DB_LOG_AUTOREMOVE en el fichero DB_CONFIG. [OJO] No se podrá recuperar la base de datos ante desastres, pero es más habitual recuperarla de backups almacenados en ficheros ldif. Ficheros ldif, Son ficheros creados para realizar modificaciones o como backups del directorio. Solo deben pertenecer a root. Se debe definir una política para su creación y custodia y para la eliminación de los archivos ldif obsoletos. ¿Cifras la base de datos?

SSL/TLS Integridad y confidencialidad  Con SSL/TLS se provee de dos elementos importantes de seguridad: por un lado demuestra al cliente la autenticidad del servidor y por otro permite la confidencialidad en la comunicación al cifrar la transmisión de datos. Se pueden configurar ambas opciones. SSL requiere un puerto diferente para el tráfico cifrado, suele ser el 636. TLS es un refinamiento de SSL , es más flexible; Permite que los clientes que se conecten al puerto estándar 389 de LDAP puedan escoger entre transmisiones en claro o cifradas. Se negociará StartTLS al inicio de la comunicación entre el servidor y el cliente. Es preferible utilizar TLS a SSL excepto en dos casos: que algún cliente no lo soporte o que se requiera realizar en un firewall convencional un filtrado por puertos del tráfico cifrado y del no cifrado. Pueden configurarse ambos protocolos simultáneamente.

¿Está configurado TLS y/o SSL?

Autenticación de usuarios  Uno de los principales usos de un directorio es la autenticación de usuarios desde diferentes aplicativos

¿Tienes creadas ACLs sobre el atributo userPassword permitiendo solo al propio usuario autenticarse y cambiarla? Es un error de seguridad que un usuario privilegiado lea las password de los usuarios. Suele hacerse cuando, para validar a un usuario, se efectúa una búsqueda con un filtro "alias_del_usuario Y password" para evitar un segundo bind con las credenciales del usuario. Es un error. ¿Cada aplicativo utiliza un usuario privilegiado diferente para conectarse con el directorio? Es también recomendable que se creen ACLs para permitir solo el acceso a estos usuarios privilegiados desde ciertas máquinas, utilizando "by peername.ip=x.x.x.x auth" ¿Tienes crados grupos de administración para definir roles? Cuando se modifican las ACLs, si se utiliza la configuración por archivo slapd.conf, es preciso reiniciar el demonio cuando se realiza algún cambio, por lo que es mas práctico utilizar la pertenencia a un grupo para dar permisos a ciertos usuarios.

Contraseñas  En este punto analizaremos la importancia del esquema de almacenamiento de las contraseñas y como implementar y mantener una política de contraseñas, exigiendo complejidad y cambios periódicos, bloqueando temporalmente cuentas tras varias conexiones fallidas.

¿Cuál es el esquema de almacenamiento de las contraseñas? Aunque se utilicen esquemas de almacenamiento cifrados, se deben proteger como si estuvieran en texto plano. [OJO] El atributo userPassword es multivaluado pero para usar el overlay ppolicy este atributo solo debe tener un valor. Política de contraseñas: overlay PPOLICY  Crear una política de contraseñas, es importante, pero puede ser complejo de implementar y que los usuarios se adapten a ella. ¿Se controla que las contraseñas de los usuarios sean suficientemente fuertes? Se aconseja que la longitud sea mínimo de 6 caracteres con números, mayúsculas, minúsculas y algún carácter especial. Evitar que contengan el alias o que pertenezcan al diccionario. ¿Se obliga a los usuarios a relizar cambios de password periódicamente? Tras varios intentos de login fallidos ¿bloqueas la cuenta del usuario temporal o permanentemente?. Ppolicy ofrece la posibilidad de realizar estos bloqueos después de un número de intentos de bind fallidos dentro de un intervalo de tiempo dado y que este bloqueo sea temporal (durante un tiempo especificado) o permanente (hasta que el administrador lo desbloquee).

Configuración  La configuración del demonio se puede realizar de dos maneras:Con el archivo slapd.conf o con el directorio slapd.d. Las directivas se estructuran en dos bloques: Directivas Globales, al principio del documento, y de backend o bases de datos. En un mismo directorio se pueden manejar varios backend; Las directivas especificadas en estos bloques sobreescribirán las directivas globales.

¿Tienes habilitado ldapv2 para permitir compatibilidad con algunas aplicaciones antiguas?. Por defecto ldapv2 no está habilitado y al habilitarlo perdemos las capacidades y mejoras que aporta ldapv3 tales como: permite especificaciones de schemas mas potente, descubrimiento del schema, permite referrals, SSL/TLS, SASL, Permite renombrar los objetos, Unicode-> internacionalización y Extensibilidad. ¿Permites bind anónimos y sesiones no autenticadas?. los bind anónimos y las sesiones no autenticadas se deberían evitar. disallow anonymous requiere authc Límites  Se deben especificar ciertos límites de número de entradas devueltas en una consulta, o tiempos de búsqueda o de timeout. Estos límites configurados en el bloque de directivas globales pueden ser sobreescritos en las directivas de los backend. Por ejemplo, el usuario que se utiliza en la replicación no debe ser afectado por estos límites. ¿Limitas el número de entradas que será devuelto al realizar una consulta con la directiva "sizelimit"?. Por defecto son 500 entradas; Se debería de limitar por ejemplo a 50, de esta manera se incrementa el trabajo para los atacantes con ldap injection y se evita cargar al servidor. Se devolverán todos los registros encontrados hasta llegar al límite establecido más un mensaje de error “size limit exceed”. ¿Limitas el tiempo de espera para forzar la desconexión de sesiones idle con la directiva "idletimeout"? Para reducir los recursos consumidos por estas sesiones y evitar posibles ataques de denegación de servicio. Una conexión idle está conectada al servidor pero sin realizar ninguna operación. Por defecto no está establecido. ¿Limitas en los tiempos de búsqueda con la directiva "timelimit"? Por defecto son 3600 segundos. Cuando se hacen búsquedas por atributos no indexados se hace un recorrido secuencial por todo el directorio, lo cual sucede por un error en la aplicación que realiza la búsqueda o por un intento de ataque con ldap injection.(o también una mala configuración de los índices) ¿Utilizas Security Strength Factor para controlar los criterios de integridad y confidencialidad que se requerirán para realizar ciertas tareas? Por ejemplo: security ssf=1 update_ssf=112 simple_bind=112 En este ejemplo se obliga míniam integridad en cualquier operación sobre el directorio, en operaciones de actualización de datos y, para realizar un bind simple, se requiere cifrado de la comunicación con una llave de cifrado de 112 bits como mínimo. SSF se puede usar de un modo más granulado en las ACLs. ¿Tienes configurada la directiva "rootdnpw"? Sirve para especificar la password del rootdn; Es preferible no utilizarla en el archivo de configuración, y sobre todo no en claro. Se puede crear una entrada en el directorio para el rootdn, de esta forma cuando se acceda con este usuario se realizará un bind y se podrá controlar desde donde se permitirán estas conexiones. Para conseguir el cifrado de una password se puede usar el comand slappasswd. Se debe tener una política de complejidad y cambio periódico para esta contraseña ya que no es afectada por las políticas impuestas en ppolicy.

Autorización: ACLs  En OpenLDAP el mecanismo para autorizar o denegar accesos a ciertas partes del directorio son las ACLs (Listas de Control de Accesos). Su gran versatilidad y su potencia hacen imposible un análisis pormenorizado de todas las casuísticas, por lo cual, en este apartado solo se exponen una serie de consejos generales resaltando los errores más típicos a tratar de evitar.

¿En las ACLs añades al rootdn o la condicción "by *none"? Un error común es añadir el rootdn a las ACLs; Cuando es un usuario que tiene implícitos permisos totales sobre todo el directorio, las ACLs no afectan al rootdn. Otro error es poner como última condición en una ACL “ by * none” la cual también esta implícita y no es necesario escribirla. ACLs globales  Las ACLS en el bloque de las directivas globales (las escritas antes de definir los backend), afectarán a todos los backend. Se debe proteger en este bloque solo las siguientes partes del directorio: rootDSE y cn=Subschema. ¿Permites acceso de lectura a todo el mundo al rootDSE? Es una entrada especial que provee información sobre el propio servidor, da información sobre qué controles, características y extensiones serán comprendidas y están habilitadas en el servidor. Su DN es una cadena vacía; Se debe permitir su lectura a todo el mundo. access to dn= "" by * read ¿Permites acceso de lectura a los usuarios autenticados al registro cn=Subschema? Es un registro especial donde se almacena toda la información de los esquemas, incluyendo la definición de atributos y de objectclass, también las reglas de búsqueda, formatos, sintaxis y estructuras. Se debe permitir leer a los usuarios autenticados: access to dn=”cn=Subschema” by user read ACLs en los Backend  Las directivas especificadas en los backend sobreescribirán a las globales. ¿Tienes definidas ACLs relacionadas con el origen de la conexión?. En primer lugar se deben escribir las reglas relacionadas con el origen de la conexión, es decir, limitar desde que IPs o nombre de dominio se pueden conectar ciertas cuentas administrativas o grupos. ¿En el proveedor controlas los accesos del usuario réplica? Este usuario debe tener acceso a toda las ramas que se van a replicar, o a todo el directorio si la réplica es completa. 'access to * by dn="cn=replica,dc=ejemplo,dc=es" read by * break' Además no debe ser afectado por los límites (sizelimit o timelimit). En el proveedor se debe controlar desde donde se podrá conectar dicho usuario, es decir solo desde los ldap consumidores y que las conexiones se realicen sobre TLS para asegurar la confidencialidad en la comunicación: 'access to dn=” cn=replica,dc=ejemplo,dc=es” by peername.ip=”192.168.13.12” tls_ssf=128 auth' ¿Tienes definidas ACLs para el atributo userPassword?. Se debe restringir lo más posible, de hecho ningún usuario debería poder leerlo. Con el tipo de acceso =xw solo se permite autenticar contra el atributo y actualizarlo pero no leerlo. 'access to attrs=userPassword,usalPassword by self =xw by anonymous auth'. Se permite a algun otro usuario acceso a este atributo, por ejemplo para administradores que creen nuevas cuentas o que tengan permiso para bloquearlas cambiando las password. Debe estar controlados lo mas posible. 'by dn=”usuario privilegiado” =xw' ¿Permites a los usuarios cambiar todos sus atributos?. Por ejemplo posixAccount es una clase para permitir usar LDAP con NIS . En esta clase se requieren los atributos gidNumber, uidNumber, homeDirectory, uid y cn, y se permiten los atributos descripción gecos loginShell y userPassword. No se debe permitir a los propios usuarios modificar la mayoría de estos atributos ya que podrían escalar privilegios en los sistemas. ¿Utilizas los grupos para crear ACLs? Se pueden dar permisos a todos los usuarios que pertenezcan a un grupo. Ejemplo: 'access to dn.subtree=”cn=personas,dc=ejemplo,dc=es” by group=”cn=administradores,ou=grupos,dc=ejemplo,dc=es” write by self read' En este ejemplo se permite escribir en la rama personas al grupo de administradores y leer al propio usuario, el resto no tiene acceso. [OJO] Los grupos deben pertenecer al objectClass groupOfNames y sus miembros se especifican con el atributo member, en otro caso se debe especificar en la ACL ej: 'access to dn.subtree=”ou=personas,dc=ejemplo,dc=es” by group/grupoUsal/memberUid=”cn=adminUsal,ou=grupos,dc=ejemplo,dc=es” write by * break' Se puede expresar ACLs con expresiones regulares; Además se pueden agrupar dichas expresiones entre paréntesis para poder ser utilizadas como variables en las frases “by”. ¿Sigues los siguientes consejos cuando diseñas ACLs con expresiones regulares para evitar errores frecuentes? Es preferible “.+” que “.*” dn.regex=”.*,dc=ejemplo,dc=es” En este caso la expresión puede abarcar cualquier rama del dominio ejemplo.es pero también el propio dominio ya que .* implica ninguno o mas caracteres. Utilizar marcas de principio y fin “^.+,dc=ejemplo,dc=es$” Utilizar ámbitos en lugar de expresiones regulares es más eficiente, en este caso dn.children=dc=usal,dc=es Preferible usar la expresión “[^,]+” que “.*” ya que la segunda puede abarcar mas RDNs de los esperado: ejemplo dn.regex=”cn=.*,dc=ejemplo,dc=es” podría resultar en cn=personas,dc=ejemplo,dc=es pero también cn=admin,ou=grupos,dc=ejemplo,dc=es. ¿Utilizas "set" al diseñar ACLs? Se pueden diseñar ACLs complejas utilizando set, permite operadores booleanos y acceso a valores de atributos. Crea reglas compuestas por condiciones unidas por los operadores unión e intersección. ¿Sueles utilizar el comando slapacl para testear las ACLs? Existe desde la versión 2.3, se utiliza para testear si las ACLs escritas tienen el comportamiento deseado. Este comando no se conecta con el servidor a través del protocolo LDAP, sino que arranca su propio SLAPD . Se le puede pasar cualquier nivel de log con el parámetro -d. Se utiliza: slapacl -x -D”que DN trata de acceder al directorio” -b”Recurso al que pretende acceder” “atributo/tipo de privilegio” -d nivel de log Ejmplo: slapacl -D"uid=inma,dc=ejemplo,dc=es" -b "uid=reyes,dc=ejemplo,dc=es" "userPassword/write" Resultado: authcDN: "uid=inma,dc=ejemplo,dc=es” write access to userPassword: DENIED

	Replicas  Las ACLs no viajan con los datos por lo que es importante mantener actualizadas las mismas políticas de seguridad en todas las réplicas del directorio.
	¿Las ACLs son las mismas en todas las réplicas?

LOGs  Se ofrecen diferentes niveles de log que se pueden usar solos o en combinación con otros simplemente sumándolos o separándolos con un espacio. Si see utiliza el sistema syslog, es mejor ponerlo en modo no síncrono (-/ruta/ldap.log) para evitar que afecte al rendimiento.

¿Cual es el loglevel configurado?. Los mas útiles: 256 conexiones operaciones y resultados (utilizarlo siempre como base unido a algún otro nivel) 512 entradas enviadas 4 heavy trace debugging (muy útil para depurar errores en alguna conexión) no es excesivamente verboso para analizarlo al vuelo pero si para registrar. 64 analiza el archivo de configuración 128 muestra chequeos de ACLs es muy verboso pero es la única opción para comprobar prohibiciones.

Backups  Con el comando slapcat se puede realizar un dump completo de la base de datos a un archivo ldif. En las versiones actuales de OpenLDAP se puede realizar sin parar el servidor; Por esto, para evitar inconsistencias, realizarlo en momentos en los que se prevea que el número de actualizaciones o modificaciones en el directorio sea mínimo. Se debe tener especificaas en un documento la política de copias de seguridad. Es conveniente que estas copias se guarden cifradas.

¿Está especificada en un documento la política de copias de seguridad?. Es conveniente que estas copias se guarden cifradas. Con el comando slapcat se puede realizar un dump completo de la base de datos a un archivo ldif. En las versiones actuales de OpenLDAP se puede realizar sin parar el servidor. Por ello, para evitar inconsistencias, realizarlo en momentos en los que se prevea que el número de actualizaciones o modificaciones en el directorio sea mínimo.

Aplicaciones WEB que se conectan al directorio  La mayor parte de los ataques a un directorio se producen a través de las aplicaciones web que lo utilizan. Como se ha visto en el documento de “Ataques y amenazas a un directorio” las posibilidades son numerosas. El principal agujero de seguridad es recoger los datos enviados desde el cliente y utilizarlos sin haberlos filtrado previamente, permitiendo posibles inyecciones de de código en las consultas del programador.

¿Se filtran los datos que llegan desde el cliente al servidor web, antes de enviar consultas o peticiones al servidor LDAP? ¿Se revisan los datos que se envían al cliente y se comprueba la cantidad de información que se transmite,(que debe estar limitada)? ¿La autenticación de usuarios se realiza correctamente: BIND con usuario privilegiado, se realiza un SEARCH para buscar el DN del usuario a partir de un atributo (habitualmente el alias de correo) y se realiza un BIND con el dn y la contraseña del usuario? ¿Los datos transmitidos entre el cliente y el servidor web es envían cifrados con HTTPs? ¿En el servidor web Apache esta habilitado y configurado el módulo modSecurity? ¿Esta implementado un Single Sing On para acceder a todas las aplicaciones de la intranet? Que cada aplicativo de la institución realice un acceso al LDAP para autenticar a los usuarios (a parte de incomodo para ellos) es muy inseguro porque se multiplican las posibilidades de que haya vulnerabilidades. ¿Hay ACLs para conceder los mínimos privilegios posibles sobre las identidades que ejecutan servicios a través de la web?

Gestión de identidad  La institución debe tener descrita una política de gestión de identidades, es decir, el ciclo de vida de cada usuario en el directorio. Es un importante agujero de seguridad mantener usuarios con ciertos privilegios después de que su relación con la misma haya terminado. Puede que existan servicios que se ofrezcan indefinidamente como el correo electrónico en cuyo caso, aunque no se elimine dicha entrada, se deben actualizar los grupos o roles a los pertenece un usuario cuando cambia su relación con la institución.

¿Está definida una política de gestión de identidades?