• Author / Uploaded
• Paco Giner Ayguadé

• Categories
• Transport Layer Security
• Clave (Criptografía)
• Servidor web
• Autenticación
• Contraseña

Citation preview

---

DOCUMENTO ANEXO A LOS ARCHIVOS DE APLICACIÓN Y JUEGOS DE PRUEBAS

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 0.- Aspectos introductorios y de configuración previa. Sin pretender ser muy exhaustivo, creo interesante partir de unos conceptos gráficos introductorios con el fin de contextualizar el trabajo que se va a llevar a cabo. Cabe significar que para usar CAS y Spring Security se ha considerado la versión 4.0.0 del Central Authentication Service (CAS) con la siguiente documentación de soporte: https://apereo.github.io/cas/4.0.x/installation/Configuring-Authentication-Components.html La arquitectura a construir es la que se desprende del siguiente esquema:

El diagrama siguiente muestra el acceso a un recurso protegido mediante CAS y Spring Security:

2

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 1.- Creación de un directorio de empresa usando OpenLDAP. El servidor OpenLDAP está disponible en el paquete slapd por tanto, lo instalaremos utilizando apt-get. También nos conviene instalar el paquete ldap-utils que contiene utilidades adicionales. Desde consola: apt-get install slapd ldap-utils

y se nos solicita la contraseña del administrador, sumininistrándole “admin”.

Posteriormente nos pide que confirmemos la contraseña: Los archivos de configuración del servidor LDAP se almacenan en la carpeta /etc/ldap/. En lugar de editar manualmente dichos archivos, es mejor lanzar el asistente de configuración de slapd. Para ello debemos ejecutar el siguiente comando: dpkg-reconfigure-slapd

Lo primero que nos pregunta el asistente es si deseamos omitir la configuración del servidor LDAP y obviamente responderemos que no, ya que precisamente lo que queremos es configurar el servidor LDAP.

3

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Después nos preguntará si queremos que se elimine la base de datos cuando quitemos slapd. Para evitar confusiones con bases de datos anteriores, lo mejor es responder Sí. Al solicitarnos el DNS domain name el facilitamos gameofthron.es y posteriormente al solicitarnos el nombre de la organización tecleamos gameofthron. Tras introducir y confirmar el password e introducir el tipo de base de datos habremos concluído la configuración inicial del servidor LDAP, que al igual que todos los servicios en Debian, dispone de un script de arranque y parada en la carpeta /etc/init.d // Arrancar o reiniciar el servidor LDAP sudo /etc/init.d/slapd restart // Parar el servidor LDAP sudo /etc/init.d/slapd stop

Para comenzar creamos el archivo .ldif que nos permite crear las “organizational units” (ou) necesarias para construir la estructura del directorio que se nos solicita:

4

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE El script que carga el fichero Ex1_3.ldif anterior es Ex1_3.sh

El comando slapadd necesita ejecutarse con privilegios, por tanto, se han elevado para ejecutar los scripts que lo contienen. En el script se comprueba si el proceso de LDAP se está ejecutando y se finaliza en el caso de ser así. Posteriormente se introducen los datos al LDAP con slapadd –c –v –l Ex1_3.ldif

A continuación se procede a crear el archivo .ldif que contiene las sentencias para añadir a los trabajadores de la empresa al directorio junto con la información proporcionada en el enunciado. En este caso va a ser necesario almacenar los passwords cifrados en el interior de LDAP, por lo que, dado que esta estructura va a usarse posteriormente elijo con el criterio de máxima seguridad el algoritmo SSHA, que es una versión de SHA con salt: “This is the salted version of the SHA scheme. It is believed to be the most secure password storage scheme supported by slapd.” (https://www.openldap.org/doc/admin24/security.html). Para obtener el password cifrado y proporcionárselo al archivo .ldif se usa el comando slappasswd –h {SSHA} –s password

5

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

Quedando el fichero Ex1_4_1.ldif con los trabajadores como sigue:

6

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Se procede de forma análoga en el archivo que contiene las sentencias para añadir los clientes y proveedores y se nombra Ex1_4_2.ldif

7

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Finalmente se crea el fichero .ldif que contiene las sentencias para crear los encargados de departamento y enlazarlos con los trabajadores correspondientes y se nombra Ex1_4_3.ldif

Y con el fin de cargar los archivos Ex_1_4_x.ldif, se proporciona una script cuyo funcionamiento interno es similar al explicado con anterioridad.

A continuación adjunto pantalla del resultado de la ejecución.

8

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

Una vez cargados los datos, podemos usar la herramienta JXplorer (http://jxplorer.org) que es un navegador y editor de LDAP multiplataforma. Se trata de un cliente LDAP de propósito general compatible con los estándares que se puede usar para buscar, leer, y editar cualquier directorio LDAP estándar, o cualquier servicio de directorio con una interfaz LDAP o DSML. Nosotros lo podemos usar para verificar tanto la estructura como los datos. Esta sería la pantalla donde se introducen los datos de conexión:

9

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Y en la siguiente captura se puede apreciar la estructura; si nos posicionamos en cada componente de la estructura, el editor nos proporciona los valores que lleva asociados.

Fuente: http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m6/openldap.html

10

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 2.- Securizar una aplicacion Web con autenticación vía servidor single sign-on. Tras descargar la versión de Apache-Tomcat 8.5.30 (binary distribution-core) de https://tomcat.apache.org/donwnload-80.cgi, se descomprime y copia el Tomcat en dos carpetas bajo /opt del entorno de trabajo (VirtualBox 5.2.8 r121009(Qt5.6.2) + Debian 9.0). Una carpeta se denomina CAS y otra APP, y tienen inicialmente el mismo contenido. Ello nos permite además de la operativa que iremos viendo a lo largo del ejercicio, tener instalaciones limpias y evitarnos deshacer algunas configuraciones que eran necesarias para hacer funcionar JAAS, ya que usaremos la aplicación que se entregó en la práctica 1 y que estaba diseñada para ejecutarse en este entorno. En la práctica tenemos dos Tomcat ejecutándose simultáneamente en la misma máquina por lo que van a intentar usar los mismos puertos por defecto, lo que implicaría que no sería posible que los dos servidores funcionaran a la vez, puesto que si arrancáramos un segundo Tomcat con puertos coincidentes daría error y se cerraría. Este problema lo evitamos cambiando los puertos por defecto del servidor web. Se ha procedido editando el archivo server.xml de la carpeta CAS en la ruta /opt/CAS/apache-tomcat-8.5.30/conf/server.xml

sumándole de forma decimal 10 a cada puerto; así HTTP escucha peticiones en el puerto 8090 en lugar del 8080, redirige al 8453 en lugar del 8443 y el AJP 1.3 connector on port 8009 pasa a ser 8019.

Instalación básica del CAS Seguídamente se procede a descargar el zip con el CAS server 4.0.0 de http://github.com/Jasig/cas/releases/download/v4.0.0/cas-server-4.0.0-release.zip y una vez descomprimida se obtiene el cas-server-webapp-4.0.0.war de la carpeta /modules del zip descargado y se coloca en la carpeta /webapps del servidor tomcat situado en la carpeta CAS, ruta: /opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0.war Arrancamos tomcat con ./startup.sh desde /opt/CAS/apache-tomcat-8.5.30/bin y se descomprime automáticamente la carpeta con el CAS Server y queda situada en: /opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0

Si

para conectar con el servidor CAS http://localhost:8090/cas-server-webapp-4.0.0/login podemos comprobar la conexión e iniciar sesión con el usuario casuser y la contraseña Mellon, que vienen harcodeadas el fichero de configuración del CAS (deployerConfigContex.xml)

11

abrimos

un

navegador

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

Instalación básica de la aplicación de ejemplo Utilizando el tomcat APP (situado en la carpeta APP), no será necesario cambiar los puertos en este servidor debido a que ya los hemos cambiado en el otro servidor y hemos comprobado que no hay puertos coincidentes. A continuación extraemos la aplicación web facilitada en el enunciado del paquete simplecasclient.zip y se sitúa en la carpeta /webapps del servidor apache-tomcat APP. Esta aplicación implementa controles de acceso mediante roles sobre dos carpetas llamadas “secure” y “extreme” contemplando un único usuario llamado “casuser” con un rol asignado que solo se da acceso a la carpeta “secure” realizándose la autenticación de usuario al conectar con un servidor CAS. Arrancamos el apache-tomcat y usamos un navegador para conectar con la aplicación CASificada mediante la URL http://localhost:8080/simplecasclient/

12

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Y podemos comprobar que la aplicación funciona correctamente y se conecta con el servidor CAS al introducir el usuario “casuser”, el cual tiene asignado el rol “ROLE_USER” que no permite acceder a la carpeta “extreme”. De la misma forma se crea un usuario “paco” con un “ROLE_ADMIN” para permitir el acceso a la carpeta extreme, con éxito. Una vez configurado el entorno de trabajo básico y comprobada la conectividad, se va a proceder al desarrollo de la práctica. En primer lugar incorporo la web que queremos hacer funcionar en este entorno; para ello copio exclusivamente la carpeta IDwebapp procedente de la Práctica 1 dentro de la carpeta webapps de APP en la siguiente ruta /opt/APP/apache-tomcat-8.5.30/webapps/Idwebapp Ello significa que no se consideran ni la configuracion JAAS, ni las clases implementadas, ni los archivos donde se encontraban usuarios y contraseñas... las configuraciones están por defecto debido a que se ha instalado el servidor de nuevo. A partir de aquí habrá que realizar modificaciones en el código sobre todo de menu.jsp como veremos más adelante.

Añadimos nuevos usuarios. Vamos a la ruta /opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEBINF/deployerConfigContext.xml eliminamos el usuario “casuser” y añadimos los nuevos usuarios. Esto solo lo realizamos para comprobar paso a paso que estamos realizando el ejercicio correctamente, puesto que no es de recibo que hayan contraseñas harcodeadas. Cuando conectemos con OpenLDAP corregiremos este extremo.

Protegemos los recursos. Necesitamos indicar el uso de Spring Security, lo que se consigue mediante el que deberá ser igual que /opt/APP/apache-tomcat-8.5.30/webapps/simplecasclient/WEB-INF/web (el cual ya hemos probado que funciona) archivo

/opt/APP/apache-tomcat-8.5.30/webapps/Idwebapp/WEB-INF/web.xml

Creamos las políticas de seguridad para interceptar las URL en el archivo /opt/APP/apache-tomcat-8.5.30/webapps/Idwebapp/WEB-INF/applicationContext-security.xml

13

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

Relacionamos los usuarios y sus roles en el mismo archivo anterior

Modificaciones en código de la web procedente de la Práctica 1 Fundamentalmente hay unos cambios que hacer sobre todo en menu.jsp. En primer lugar hay que añadir a los roles el prefijo “ROLE_” para compatibilizarlo con el código que se ha introducido debido a que con la configuración por defecto, Spring Security requiere que los roles contengan este prefijo. Posteriormente será necesario eliminar %@page import="util.MyInfo,util.User" que no usamos las clases java que creamos en la práctica anterior, y añadir:

%

También debemos eliminar:

14

Francisco José Giner Ayguadé

puesto

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Puesto que el cierre de sesión de forma provisional (dado que acabaremos cerrando la sesión CAS) ahora es:

Finalmente, eliminamos

Sistema de Gestión

Bienvenido/a ()

En primer lugar porque la clase de java ya no es necesaria, en segundo lugar porque el control de usuario está externalizado y finalmente porque los métodos empleados no funcionan en este entorno. Para obtener el login se consigue con

En este punto se prueba la aplicación y se comprueba que su funcionamiento es correcto antes de pasar a la utilización de CAS + OpenLDAP para autenticar. Para ello son necesarias una librerías que podemos usar copiando el contenido de la carpeta lib de simplecasclient de la ruta /opt/APP/apache-tomcat-8.5.30/webapps/simpleasclient/WEB-INF/lib/* en la carpeta /lib correspondiente de IDwebapp. Se mantiene una copia del sistema en este momento del desarrollo para verificar el funcionamiento, si resultara de interés.

Utilización de CAS + OpenLDAP para autenticar. Para que el servidor CAS pueda interactuar con un servidor OpenLDAP es necesario añadir algunas librerías adicionales en la carpeta /lib del servidor CAS. Este punto y la modificación de la configuración es lo que vamos a tratar para que funcione el sistema. Segun la web https://apereo.github.io/cas/4.0.x/installation/LDAP-Authentication.html podemos observar que es posible usar LDAP Supporting Direct Bind, además de contar con la siguiente dependencia org.jasig.cas.cas-server-support.ldap. El hecho de caracterizar el sistema como LDAP Supporting Direct Bind surge porque se cumplen dos requisitos definidos en el enunciado: -

Todos los usuarios están en una sola sucursal en el directorio, p. ou = Usuarios, dc = ejemplo, dc = org. El nombre de usuario proporcionado en el formulario de inicio de sesión de CAS forma parte del DN, p. uid =% s, ou = Usuarios, dc = exmaple, dc = org.

Ello permite que podamos usar una plantilla para la autenticación LDAP donde no se requiere búsqueda para calcular el DN necesario para una operación de vinculación.

15

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Si visitamos https://mvnrepository.com/artifact/org.jasig.cas/cas-server-supportldap/4.0.0 podemos descargar la versión 4.0.0. en formato .jar y la situamos en /opt/CAS/apachetomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEB-INF/lib/cas-server-support-ldap-4.0.0.jar

Comprobamos que tenemos dentro de la carpeta anterior (../WEB-INF/lib) las dependencias que hay en la siguiente captura de pantalla, con especial atención a la versión, y descargamos las que falten en formato .jar y las situamos en la misma carpeta. Debido al procedimiento seguido solo falta org.ldaptive.ldaptive en su versión 1.0.3

Una vez instalado lo configuramos para que se use en lugar de usar el listado de contraseñas que hay en el archivo para lo que borramos dentro del deployerConfigContext.xml la bean primaryAuthenticationHandler y posteriormente añadimos el código que se encuentra en el tutorial para conectar el módulo y OpenLDAP usando Direct Bind, que se encuentra en https://apereo.github.io/cas/4.0.x/installation/LDAP-Authentication.html#ldap_supporting_direct_bind

con la salvedad que aun no podemos usar ssl por lo que comentamos la propiedad “sslConfig” de la bean “connectionConfig” y la bean “sslConfig”. En los ejemplos de configuración del módulo de LDPA nos encontramos que para buscar a los usuarios dentro de la organización usa ${ldap.auth.baseDN} por lo que sustituimos la propiedad ${ldap.baseDN} por la anteriormente mencionada. Posteriormente sustituimos el módulo usado para autenticar

por

Para finalizar se añade el código que se encuentra en el link de supporting direct bind, al que hemos hecho referencia, para configurar las propiedades LDAP en el archivo cas.properties /opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEB-INF/cas.properties

Sustituyendo

16

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE ldap://directory.ldaptive.org por ldap://localhost

para seleccionar el servidor local ldap.useStartTLS=false

porque aun no está configurado ssl ou=Users,dc=example,dc=org por ou=employees,dc=gameofthron,dc=es para que los usuarios puedan acceder al sistema y que usuario con clave puedan realizar operaciones sobre el servidor LDAP ldap.authn.managerPassword=nonsense por ldap.authn.managerPassword=admin sustitución de contraseña de administrador #ldap.authn.format=%[email protected] se comenta para desactivarla ldap.authn.format=uid=%s,ou=employees,dc=gameofthron,dc=es

se descomenta para activarla. Se mantiene una copia del sistema en este momento del desarrollo para verificar el funcionamiento, si resultara de interés. En el video 1 se muestra el funcionamiento de la aplicación, no obstante, realizo captura de pantalla para significar la URL de conexión, así como que todavía se trata de una conexión no segura. Por supuesto, tiene un funcionamiento correcto una vez logueado con cualquiera de los usuarios y contraseñas que proporciona el enunciado, seguro en tanto que se ha utilizado el algoritmo de cifrado más seguro posible dentro de esta técnica e independiente de la web, para lo que hay habilitados dos servidores con el objetivo de aplicar el control de acceso a una aplicación web java, mediante el servidor CAS single sign-on que se encarga de realizar la autenticación de los usuarios, y el framework Spring Security que nos proporciona la etapa de autorización mediante roles. En el próximo punto se trata de utilizar SSL y los correspondientes certificados que permitan proteger las comunicaciones.

17

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

2.3.3.- Utilización de SSL y certificados para proteger todas las comunicaciones. a.- Autenticación segura OpenSSL y OpenLDAP Los permisos que los usuarios tienen sobre los sistemas se basan en la autentificación del usuario. Aunque ya se han desarrollado sofisticados métodos de autentificación como sistemas de tarjeta electrónica (DNI electrónico) o sistemas biológicos como la huella dactilar o el iris del ojo, la realidad es que requieren de elementos caros para su aplicación. En entornos educativos y en pequeñas y medianas empresas, se sigue utilizando el mecanismo tradicional de autentificación del usuario mediante su nombre de usuario (login) y su contraseña (password). Desde que el usuario introduce su contraseña hasta que ésta llega al servidor para comprobar la autentificación, el paquete de datos que contiene la contraseña viaja por los cables de red atravesando concentradores (hubs), conmutadores (switches) y enrutadores (routers) hasta llegar al servidor. Durante el trayecto, cualquier persona con los conocimientos necesarios podría quedarse con una copia del paquete de datos para, posteriormente analizarlo y tratar de descubrir el nombre y la contraseña del usuario sin que éste se percatase. Con la finalidad de dificultar que alguien trate de descubrir contraseñas analizando los datos que las contienen, existe la posibilidad de cifrar los paquetes de datos en el PC antes de enviarlos por la red, de manera que lleguen al servidor cifrados. De esta forma, aunque un usuario malintencionado capture un paquete de datos con la información del usuario y la contraseña, será muy dificil, por no decir imposible, que sea capaz de descifrarlos ya que se utiliza cifrado asimétrico. El cifrado asimétrico permite la generación de una pareja de claves comunmente denominadas clave pública y clave privada en el servidor. La pareja de claves es tal que, todo lo cifrado con una, solo se puede descifrar con la otra. El servidor tiene guardada en un lugar seguro la clave privada. Cuando un cliente intenta autentificarse, el servidor le trasfiere la clave pública para que cifre los datos con dicha clave antes de enviarlos. El cliente utiliza la clave pública del servidor para cifrar los datos, así al llegar el paquete al servidor, éste podrá descifrarlo porque dispone de la clave privada. Si un usuario malintencionado intercepta el paquete de datos cifrado con la clave pública, no podrá hacer nada porque no dispone de la clave privada. Si el usuario malintencionado intercepta el primer paquete que envía el servidor con la clave pública, no le servirá para nada ya que no le permitirá descifrar los datos emitidos por el PC que se va autentificar.

18

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

La estructura que se pretende es la que sigue, independientemente que la nomenclatura mostrada en gráfica no se adapta totalmente al ejercicio, pero nos da una idea muy aproximada.

Fuente: https://wiki.jasig.org/display/CASUM/HOWTO+Setup+Dual+Authentication+in+CAS+-+SSL+Client+Auth+and+LDAP

LDAP seguro - ldaps Al igual que el servidor web apache utiliza el puerto 80 para transmitir información sin encifrar (protocolo http) y el puerto 443 para transmitir información cifrada (protocolo https), openLDAP también se puede configurar para que utilice las prestaciones de cifrado que ofrece OpenSSL. Normalmente las consultas al servidor LDAP se realizan por el puerto 389 (protocolo ldap) pero dichas consultas se transmiten sin cifrar. Para realizar consultas seguras cifrando los datos con SSL, es necesasrio utilizar el puerto 636 (protocolo ldaps o protocolo ldap seguro). Para ello, el servidor deberá disponer de un certificado firmado por una entidad certificadora (CA) y habrá que configurar slapd para que utilice los certificados. Se deberán realizar los siguentes pasos:       

Crear una nueva entidad certificadora Crear una petición de firma de certificado del servidor Firmar el certificado con la CA Copiar los certificados a la carpeta deseada, renombrar y proteger Configurar slapd para que utilice los certificados Modificar script de inicio de slapd para que utilice protocolo seguro ldaps Reiniciar slapd Crearemos un script que realizará automáticamente todos los pasos. Guardaremos el script en /tmp/ldap-seguro.sh: # ------- Script /tmp/ldap-seguro.sh ------apt-get install gnutls-bin sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem" echo cn = CertPaco>/etc/ssl/ca.info echo ca>>/etc/ssl/ca.info echo cert_signing_key>>/etc/ssl/ca.info certtool --generate-self-signed --load-privkey /etc/ssl/private/cakey.pem --outfile /etc/ssl/certs/cacert.pem sh -c "certtool --generate-privkey > /etc/ssl/private/ldap_slapd_key.pem" echo echo echo echo echo

--template

/etc/ssl/ca.info

organization = CertPaco>/etc/ssl/ldap.info cn = localhost>>/etc/ssl/ldap.info tls_www_server>>/etc/ssl/ldap.info encryption_key>>/etc/ssl/ldap.info signing_key>>/etc/ssl/ldap.info

certtool --generate-certificate --load-privkey /etc/ssl/private/ldap_slapd_key.pem --load-ca-certificate /etc/ssl/certs/cacert.pem --load-ca-privkey /etc/ssl/private/cakey.pem --template /etc/ssl/ldap.info --

19

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE outfile /etc/ssl/certs/ldap_slapd_cert.pem ldapmodify -Y EXTERNAL -H ldapi:/// > /etc/default/slapd /etc/init.d/slapd restart # ----------- FIN del Script -----------

Una vez guardado el script, solo queda ejecutarlo: // Ejecutar script /tmp/ldap-seguro.sh sudo sh /tmp/ldap-seguro.sh

En las siguientes capturas de pantalla podemos observar el resultado de la ejecución del script. Al finalizar el script se habrá reiniciado el servidor slapd y admitirá conexiones seguras por el puerto 636. root@debian:/tmp# ./sudo /temp/ldap-seguro.sh bash: ./sudo: No existe el fichero o el directorio root@debian:/tmp# sudo sh /tmp/ldap-seguro.sh Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho gnutls-bin ya está en su versión más reciente (3.5.8-5+deb9u3). Los paquetes indicados a continuación se instalaron de forma automática y ya no son necesarios. libstax-java libstax2-api-java libwoodstox-java linux-image-4.9.0-4-amd64 Utilice «sudo apt autoremove» para eliminarlos. 0 actualizados, 0 nuevos se instalarán, 0 para eliminar y 52 no actualizados. Generating a 3072 bit RSA private key... Generating a self signed certificate... X.509 Certificate Information: Version: 3 Serial Number (hex): 5ae96c9912f182c3e95fe7ae Validity: Not Before: Wed May 02 07:45:29 UTC 2018 Not After: Thu May 02 07:45:29 UTC 2019 Subject: CN=CertPaco Subject Public Key Algorithm: RSA Algorithm Security Level: High (3072 bits) Modulus (bits 3072): 00:bc:bf:c8:11:20:be:0d:85:75:70:62:23:96:21:b5 2c:7f:75:3d:2c:46:19:c7:a3:5e:e9:4c:8a:ae:0e:f3 30:c5:6f:5c:3a:b8:4f:02:86:dc:ab:77:1a:6b:ac:99 ba:9d:42:84:ce:6e:f6:11:34:50:e9:ba:6b:85:12:67 bc:b9:11:ca:bc:fa:77:7b:dc:25:d0:ab:0b:8e:d6:eb 96:24:34:a2:c3:f9:6a:bc:28:50:e6:d0:25:57:7a:36 77:c1:90:34:72:cc:d7:91:c1:57:6d:db:89:52:e8:4a 02:fa:24:b9:16:58:5e:52:0d:cb:88:a1:d2:20:8f:8d 85:54:2d:0d:f5:ad:de:58:2a:3c:50:31:67:33:99:1a 2b:0e:8a:db:0d:37:81:cd:ae:ff:28:ca:dd:1b:b9:8a 8e:e9:d7:d2:de:f3:f9:98:c1:e1:d0:26:f6:b0:54:24 2f:c2:5b:7f:c4:4a:47:03:ac:00:72:44:e1:7a:5f:50 84:0b:89:05:6b:96:58:f0:16:b2:36:d4:21:00:f0:f2 48:23:5a:7b:fa:13:27:18:21:63:87:32:92:9f:6f:19

20

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 44:99:d3:e2:76:31:83:81:f1:b4:71:61:f9:1f:67:55 8c:b3:0e:e5:50:6d:c5:66:4e:21:8e:13:c8:06:c2:89 d3:17:52:38:e4:c4:60:92:01:52:a0:bc:41:0e:47:52 95:19:59:3a:23:fe:76:c9:de:54:5e:28:c4:14:63:dd 2f:f3:5b:c5:be:f3:61:4e:59:c1:02:9f:11:f0:23:73 ce:7b:86:e0:ef:be:e7:e2:58:8d:5d:28:44:c5:8b:b8 9d:5c:de:78:63:68:37:f6:10:91:01:b7:ad:96:eb:05 f6:10:54:b6:00:5a:53:4e:64:0e:e7:54:54:10:87:e8 70:62:22:3d:1e:81:1a:8e:1b:59:52:60:fc:fb:c8:b8 47:08:b2:68:cb:6c:71:2b:02:3f:35:dc:8f:1d:73:75 4d Exponent (bits 24): 01:00:01 Extensions: Basic Constraints (critical): Certificate Authority (CA): TRUE Key Usage (critical): Certificate signing. Subject Key Identifier (not critical): 5aca733ee26c20272500de1c95e45155bfdb58f3 Other Information: Public Key ID: sha1:5aca733ee26c20272500de1c95e45155bfdb58f3 sha256:ea135e4fdbcd74fbaa905a1f3429f932df1912759d24bc9c07e7f40a4ecab32d Public key's random art: +--[ RSA 3072]----+ |o .o+o..... | |o o o.. . | | o o . . | | . . . | | o S . o | | o o. + = o| | + .= . o .E| | .o+. | | oo... | +-----------------+

Signing certificate... Generating a 3072 bit RSA private key... Generating a signed certificate... X.509 Certificate Information: Version: 3 Serial Number (hex): 5ae96c99327447f54aa336ee Validity: Not Before: Wed May 02 07:45:29 UTC 2018 Not After: Thu May 02 07:45:29 UTC 2019 Subject: O=CertPaco,CN=localhost Subject Public Key Algorithm: RSA Algorithm Security Level: High (3072 bits) Modulus (bits 3072): 00:ac:8d:a7:48:3e:ce:1d:4c:f4:9c:92:9e:08:e8:bc 19:56:f1:3e:f2:a7:93:d7:fb:22:bc:57:6a:1b:8e:87 40:38:dc:3b:09:30:8e:74:ff:51:30:1c:ce:e7:89:e3 99:da:d7:51:08:7c:79:66:c5:41:a5:1e:17:07:8f:d4 68:8f:b3:de:48:02:77:0d:fe:92:d0:a8:88:be:f7:7d ac:44:e6:6c:2f:f5:48:ab:b6:4d:e9:12:5a:25:e9:5d 18:38:bf:16:2f:72:c5:d9:e3:76:d2:e6:6f:23:82:a9 7e:1f:04:b6:61:5e:15:d2:d0:ce:ef:62:9c:45:6d:cc 02:b4:f4:8c:29:b8:ab:5a:93:8c:8d:aa:07:1e:da:b0 d4:7c:c4:25:1b:a7:f4:c9:8d:3b:00:7b:f7:0a:0c:45 6d:44:f6:35:96:0f:eb:98:e7:91:42:6b:88:9e:43:96 fb:0c:e4:de:43:6a:58:66:4c:78:1c:d2:14:4f:ff:c1 73:d3:0e:bc:b6:55:11:f2:00:a7:65:5f:d4:21:1e:5c 18:c5:24:02:ac:72:f9:d6:de:66:11:a1:ad:b3:db:87 3e:aa:51:52:0b:8e:a6:f7:fb:94:21:35:72:14:a4:fe 9e:91:57:3e:f3:16:74:79:53:35:53:b3:9f:e7:2d:f9 ad:bf:5c:2d:0c:f7:b2:c9:53:4b:24:6d:99:4f:68:b7 ff:a3:85:a1:9e:d1:68:55:66:ad:74:bf:0f:13:11:57 3d:43:97:db:75:62:6b:87:86:e8:ae:b7:67:38:9b:d7 6c:d2:bc:81:4d:27:1b:e3:11:88:69:63:6c:c9:17:6d b2:12:38:56:6d:ab:45:e6:3c:59:10:b5:86:74:62:29 ed:0d:27:fa:a4:80:6d:b7:54:b3:56:17:09:f6:02:c5

21

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE d9:6b:99:2e:82:03:76:dc:c7:2e:22:19:25:25:fe:1c 94:db:6f:1e:6b:a5:81:9d:8d:92:82:bd:15:e2:71:f5 0f Exponent (bits 24): 01:00:01 Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Purpose (not critical): TLS WWW Server. Key Usage (critical): Digital signature. Key encipherment. Subject Key Identifier (not critical): a12976818881548675ec152a725b610de4d5eefc Authority Key Identifier (not critical): 5aca733ee26c20272500de1c95e45155bfdb58f3 Other Information: Public Key ID: sha1:a12976818881548675ec152a725b610de4d5eefc sha256:f8fe2e0fe7d836228fd4a9b7020a37ed1857ddd8a37dbabbb615ddd7989abe4d Public key's random art: +--[ RSA 3072]----+ |+.++o*ooo | |.+..+o+o . | |...oo+o o | | o +. + o | | .o + S | | . o o | | . | | E | | | +-----------------+ Signing certificate... SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" El usuario `openldap' ya es un miembro de `ssl-cert'. [ ok ] Restarting slapd (via systemctl): slapd.service. root@debian:/tmp#

Probando el acceso por ssl Si nuestro servidor LDAP está funcionando en modo seguro, estará escuchando en el puerto 636 ya que es el puerto utilizado por el protocolo ldaps. Para probarlo, iniciamos JXplorer pero la conexión la realizamos a dicho puerto y el nivel de seguridad seleccionamos SSL + User + Password ya que la autentificación va a ser por usuario y contraseña pero utilizando SSL:

22

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Ldaps utiliza el puerto 636 Al intentar conectar, nos aparecerá la información del certificado. Podremos aceptar el certificado para esta sesión (This session only) o para siempre (Always).

Podemos ver el certificado:

Aceptar certificado

23

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE Una vez que hemos conectado, podemos apreciar en la parte inferior que la conexión se ha realizado al puerto 636:

Siempre debemos conectarnos al servidor LDAP utilizando el protocolo seguro ldaps debido a que en las conexiones al servidor LDAP, enviamos contraseñas y si estas viajan en texto plano, serían fácilmente descubiertas por algún usuario avanzado que coloque un sniffer en la red y almacene los paquetes de datos. Fuente: Se ha hecho uso en este apartado de contenido licenciado (CC BY-SA 3.0) con modificaciones para adaptarse al ejercicio propuesto, procedente de: http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m6/autentificacin_segura_openssl_y_openldap.html

En este punto corresponde probar si la aplicación funciona con LDAP securizado; para ello hemos modificado las líneas marcadas en rojo del archivo cas.properties en la ruta de la carpeta CAS ../WEB~INF/cas.properties ======================================== # General properties #======================================== ldap.url=ldaps://localhost:636 # LDAP connection timeout in milliseconds ldap.connectTimeout=3000 # Whether to use StartTLS (probably needed if not SSL connection) ldap.useStartTLS= false ldap.trustedCert=file:///etc/ssl/certs/cacert.pem #======================================== # LDAP connection pool configuration #======================================== ldap.pool.minSize=3 ldap.pool.maxSize=10 ldap.pool.validateOnCheckout=false ldap.pool.validatePeriodically=true # Amount of time in milliseconds to block on pool exhausted condition # before giving up. ldap.pool.blockWaitTime=3000 # Frequency of connection validation in seconds # Only applies if validatePeriodically=true

24

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE ldap.pool.validatePeriod=300 # Attempt to prune connections every N seconds ldap.pool.prunePeriod=300 # Maximum amount of time an idle connection is allowed to be in # pool before it is liable to be removed/destroyed ldap.pool.idleTime=600 #======================================== # Authentication #======================================== # Base DN of users to be authenticated ldap.authn.baseDn=ou=employees,dc=gameofthron,dc=es # Manager DN for authenticated searches ldap.authn.managerDN=cn=admin,dc=gameofthron,dc=es # Manager password for authenticated searches ldap.authn.managerPassword=admin # Search filter used for configurations that require searching for DNs #ldap.authn.searchFilter=(&(uid={user})(accountState=active)) ldap.authn.searchFilter=(uid={user}) # Search filter used for configurations that require searching for DNs ldap.authn.format=uid=%s,ou=employees,dc=gameofthron,dc=es #ldap.authn.format=%[email protected]

Con ello indicamos la URL de LDAP por el puerto seguro 636 y le suministramos la información de la ubicación del certificado. Asimismo comentamos el puerto LDAP no seguro en el archivo de configuración slapd (ruta etc/default) ya que slapd normalmente sirve LDAP en el puerto TCP 389 y en este caso hay que indicarle que atienda solicitudes en el puerto TCP 636 (LDAPS). En este punto tras comprobar que el usuario openldap tiene los oportunos permisos de acceso, creamos un nuevo bean con la configuración de SSL en deployerConfigContext.txt.





Una vez reiniciado el servicio mediante root@debian:/etc/init.d# ./slapd restart y reiniciados los servidores tomcat, podemos observar que efectivamente funciona aunque el resto de comunicaciones aun no es segura.

25

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

b.- Autenticación segura SSL con Tomcat La forma más común en que SSL se integra en las comunicaciones de Internet es a través del protocolo HTTPS. Llamar a HTTPS un "protocolo" no es del todo exacto, ya que es simplemente una combinación de los protocolos HTTP y SSL. Cuando decimos que se envió un mensaje usando HTTPS, lo que realmente estamos diciendo es que el mensaje se cifró primero usando SSL, se transmitió y se recibió usando el protocolo HTTP normal, y luego se descifró por el receptor, también con SSL. Resumiendo:  SSL ofrece seguridad a través del cifrado  el proceso de encriptación es posible a través del uso de certificados digitales verificados por una tercera autoridad certificadora.  la implementación más común de este proceso es el protocolo de combinación HTTPS. La configuración de SSL para Tomcat se puede dividir en dos tareas principales: crear un almacén de claves funcional y configurar los conectores y aplicaciones de Tomcat. PARTE I. Certificados de seguridad Pas 1 - Creando el Keystore/Truststore (almacén de claves donde guardar los certificados en los que el servidor confía) Un programa llamado keytool, que se incluye con JDK, realiza el trabajo de crear el nuevo almacén de claves. Para crear un nuevo almacén de claves usando este programa, ingresar en por linea de comandos: # keytool -genkey -alias tomcat -keyalg RSA -keystore got_es.jks -keysize 2048 -dname "CN=localhost, OU=CertificaPaco, O=Paco, L=ALC, ST=ALC, C=ES" Introduzca la contraseña del almacén de claves:changeit Volver a escribir la contraseña nueva:changeit Introduzca la contraseña de clave para (INTRO si es la misma contraseña que la del almacén de claves):

Lo último que pedirá keytool es que se especifique la contraseña clave, que es la contraseña específica de estos certificados específicos. En lugar de ingresar nada en este aviso, simplemente presionamos ENTER. Esto hará que keytool establezca la contraseña de la clave en un valor equivalente a la contraseña del almacén de claves. Las contraseñas coincidentes son REQUERIDAS para que Tomcat pueda acceder al certificado. Si se eligen dos contraseñas diferentes, cualquier intento de acceder al almacén de claves provocará un bloqueo. Paso 2: Creación de la solicitud de firma de certificado Ahora que ha creado su almacén de claves, es hora de crear un archivo llamado solicitud de firma de certificado, o CSR, que será utilizado por la autoridad de certificación de su elección para generar el certificado que SSL presentará a otras partes durante el protocolo de enlace. # keytool -certreq -keyalg RSA -alias tomcat -file certgot.csr -keystore got_es.jks Introduzca la contraseña del almacén de claves:changeit

26

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE También se puede usar la herramienta de claves para crear este archivo tal como se muestra a continuación. # keytool -export -alias tomcat -file certgot.crt -keystore got_es.jks Introduzca la contraseña del almacén de claves:changeit Certificado almacenado en el archivo

De esta manera keytool ha creado un archivo llamado certgot.crt, que se puede enviar a la CA. Al usar este archivo, se genera un certificado personalizado para el servidor. Paso 3 - Instalar el nuevo certificado SSL verifica la autenticidad del certificado de un sitio utilizando algo llamado "cadena de confianza", lo que básicamente significa que, durante el intercambio, SSL inicia un apretón de manos adicional con la Autoridad de certificación especificada en el certificado de su sitio, para verificar que uno mismo no hizo su propia CA. Para "anclar" la cadena de confianza de su certificado, debe descargar un certificado adicional, llamado "Certificado de raíz", de su CA, y luego importar este certificado y el nuevo de su sitio en su almacén de claves. En nuestro caso vamos a importar el certificado de confianza al almacén de certificados de Java y puesto que contamos con dos servidores Tomcat, se utilizará el mismo certificado para las dos aplicaciones. root@debian:/home/paco/Escritorio/certificados# keytool -J-Duser.language=en -import -trustcacerts alias tomcat -file certgot.crt -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts Enter keystore password: Owner: CN=localhost, OU=CertificaPaco, O=Paco, L=ALC, ST=ALC, C=ES Issuer: CN=localhost, OU=CertificaPaco, O=Paco, L=ALC, ST=ALC, C=ES Serial number: 4448aac9 Valid from: Sun May 06 18:14:47 CEST 2018 until: Sat Aug 04 18:14:47 CEST 2018 Certificate fingerprints: MD5: 04:AC:CE:61:01:75:78:49:F0:0D:D0:6B:B0:F1:1C:F7 SHA1: 59:97:B9:08:1A:18:AD:0D:75:4C:63:26:1A:BE:76:66:43:2B:51:04 SHA256: 84:68:DD:BE:FF:B2:DB:98:3B:AF:3A:62:99:0B:4E:2C:15:E9:DB:A9:38:7A:76:06:00:0F:B5:96:C5:48:CE:E5 Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 33 D5 17 52 63 7F 9D 67 F1 AC 85 46 3F B9 97 30 3..Rc..g...F?..0 0010: 3C 0B 86 A1 back

Ello se realiza mediante la adición el código siguiente en el archivo

applicationContext-

security.xml, Consultado https://www.dineshonjava.com/customize-http-403-access-denied-page/ (6/5/2018)

31

Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

Acceso a la aplicación desde el navegador: https://localhost:8443/IDwebapp/ Acceso solo al servidor CAS: https://localhost:8453/cas-server-webapp-4.0.0/login Descarga de la máquina virtual Virtualbox configurada con la práctica: https://drive.google.com/open?id=1Np8L4YLl5-cNVCGtBdR4iJuU1OSnPaXp Otra bibliografía externa a la recomendada y/u oficial consultada: https://www.digicert.com/es/sfc-creacion-java.htm https://www.elarraydejota.com/administracion-de-autoridades-de-certificacion-de-confianza-endebian/ https://www.mulesoft.com/tcat/tomcat-ssl https://coderanch.com/t/681099/application-servers/Tomcat-SSL-config-Tomcat https://wiki.jasig.org/display/CASUM/HOWTO+Setup+Dual+Authentication+in+CAS++SSL+Client+Auth+and+LDAP https://docs.oracle.com/cd/E19509-01/820-3503/ggfka/index.html https://stackoverflow.com/questions/21633274/should-we-point-keystore-and-truststore-to-thesame-jks-file https://stackoverflow.com/questions/21833732/configure-truststore-in-tomcat http://magmax.org/blog/creando-tu-propia-entidad-certificadora-ssl/ https://www.dynacont.net/documentation/linux/openssl/ https://wiki.pentaho.com/display/ServerDoc2x/Enabling+SSL+on+the+CAS+Server https://rubensa.wordpress.com/2010/03/03/recipe-for-creating-sample-certificates-from-scratch/

Firmado por FRANCISCO JOSE GINER AYGUADE - NIF:21462005S el día 07/05/2018 con un certificado emitido por ACCVCA-120

32

Francisco José Giner Ayguadé