Diferencia entre revisiones de «Autenticación segura contra o LDAP. Uso de TLS/SSL: LDAPS»

De Manuais Informática - IES San Clemente.
Ir a la navegación Ir a la búsqueda
 
(Sin diferencias)

Revisión actual del 02:12 11 ene 2017

¿Por que usar TLS/SSL?

  • Cando usamos un servidor LDAP para autenticar os usuarios dun dominio, é conveniente que a comunicación entre o cliente e o servidor no proceso de autenticación se faga de forma segura.
  • Como imos ver enseguida no escenario 1.E pódese espiar que usuario inicia a sesión dende un cliente e o seu contrasinal.

00 Dominios Linux Escenarios parte 01 E.jpg

  • Para evitalo, temos que tentar cifrar a información entre o cliente e o servidor como se amosa no escenario 1.F

00 Dominios Linux Escenarios parte 01 F.jpg


  • A razón é simple: se o tráfico de autenticación faise en claro, calquera pode capturar os paquetes intercambiados entre cliente e servidor para obter o contrasinal do usuario.
  • O método utilizado para a codificación do contrasinal admite varias opcións, e no noso caso úsase por defecto o algoritmo CRYPT, que ten un nivel de seguridade bastante aceptable pero sempre é susceptible a ataques usando dicionarios de contrasinais se os contrasinais dos usuarios non son suficientemente fortes, polo que sería conveniente establecer unha seguridade maior para o intercambio desta información.

Captura do contrasinal

  • Imos instalar en uclient02 o programa Ettercap para capturar os paquetes entre uclient01 e dserver00.
  • Estamos interesados nos paquetes que se intercambian entre si, no momento que un usuario do directorio inicia sesión nun cliente, neste caso en uclient01.

Solución

  • Podemos usar TLS/SSL (Transport Layer Secutiry/Secure Sockets Layer) para cifrar a sesión entre cliente e servidor, de forma que será máis difícil (nunca imposible, por suposto) capturar a información que se intercambian no proceso de autenticación e, sobre todo, o contrasinal do usuario.
  • Na seguinte imaxe móstrase a captura dos paquetes intercambiados entre un cliente e un servidor LDAP nunha autenticación segura con TLS/SSL:

Platega U910 Server Snif Protocolo LDAPS.png

Requirimentos para o uso de TLS/SSL

Para configurar o noso servidor LDAP para usar TLS/SSL no proceso de autenticación, precisamos instalar e configurar unha serie de compoñentes:

  • Servidor de DNS: Para poder cifrar a comunicación entre o cliente e o servidor, teremos que xerar un certificado dixital para o servidor asociado a un nome completo de dominio (FQDN) que asignaremos ao servidor. Este nome de DNS será utilizado polos clientes para conectarse ao servidor LDAP. Polo tanto, imos aproveitar o servidor de DNS do escenario 1.B no que ese nome completo de dominio estará asociado á dirección IP do servidor LDAP.
  • Autoridade de certificación: A continuación, teremos que crear unha autoridade de certificación para crear un certificado dixital para o servidor no que os clientes terán que confiar. Nos seguintes apartados indícase os pasos que teremos que seguir.

Introdución aos certificados dixitais


  • Un certificado dixital é un documento dixital (unha restra de bytes) mediante a que unha entidade fiable, coñecida como autoridade de certificación (aínda que nos referiremos a ela habitualmente como CA), garante que unha chave pública correspóndese cunha entidade concreta.
  • Con entidade concreta moitas veces nos referimos a un nome de equipo ou un dominio de DNS, e desta forma poderemos asegurarnos de que nos estamos conectando a o equipo auténtico e que a información que enviamos só poderá ser recibida por ese equipo.
  • O formato estándar que máis se usa para os certificados dixitais é o X.509, que é o que usaremos no noso caso.
  • Segundo este formato, o certificado cunha serie de campos entre os que destacan a versión, o número de serie, a validez do certificado, o seu emisor (a CA que o emite), o suxeito para o que se emite o certificado e a chave pública do suxeito.

Proceso de xeración e comprobación dunha sinatura dixital

  • Os certificados dixitais son utilizados nos métodos de cifrado asimétricos ou de chave pública, que baséanse na utilización dun par de chaves:
    • A chave pública, que como o seu nome indica é pública e pode ser coñecida por calquera,
    • e a chave privada que só pode ser coñecida polo seu propietario.
  • Estas chaves teñen as propiedades de que a información cifrada usando a chave pública só pode ser descifrada coa chave privada, mentres que unha información cifrada coa chave privada só pode ser descifrada usando a chave pública.
  • Desta forma, cando un equipo cifra unha información utilizando a chave pública do destinatario (que obterá dun certificado dixital), só o destinatario poderá descifrar a mensaxe coa súa chave privada (que só el coñece), e polo tanto estamos garantindo a confidencialidade da información.
  • Por outra banda, cando un equipo cifra unha mensaxe coa súa chave privada, calquera pode descifralo usando a súa chave pública (polo que non garantimos así a confidencialidade), pero estamos garantindo a identificación e autenticación do remitente (xa que se podemos descifralo coa chave pública quere dicir que o remitente coñece a chave privada), dando lugar á sinatura dixital.
  • O uso de certificados dixitais nos dous equipos que establecen unha comunicación, e o uso dos métodos de cifrado de chave pública, permiten garantir todos os requirimentos dunha conexión segura.
  • A combinación dos certificados dixitais e as entidades necesarias para a súa emisión cos métodos de cifrado e chave pública xunto co hardware e as políticas de seguridade que permiten levar a cabo as operacións de cifrado de xeito seguro conforman o que se coñece como a Infraestrutura de Chave Pública (PKI). Na seguinte imaxe móstranse os compoñentes básicos dunha PKI:

800px-Public-Key-Infrastructure.svg.png

  • Un usuario solicita un certificado dixital a unha autoridade de rexistro (RA), que se encarga da verificar a autenticidade do usuario, e enviar a súa verificación á autoridade de certificación (CA), que emite o certificado para o usuario.
  • Con este certificado, o usuario pode firmar dixitalmente documentos, xa que cifrándoos coa súa chave privada e enviando o seu certificado a autoridade de validación (VA) poderá confirmar que realmente é o usuario o que emitiu o documento.

Creación dos certificados dixitais

  • Unha vez introducidos os conceptos básicos sobre os certificados dixitais, veremos que é o que imos facer no noso caso.
  • O método de cifrado TLS/SSL utiliza un método de cifrado de chave pública para a autenticación do servidor (e tamén se podería facer do cliente, aínda que nós non o faremos) para xerar e intercambiar a partir de aí unha chave privada compartida e usar un método de cifrado simétrico ou de chave privada (no que se cifra e descifra a información coa mesma chave privada que só o emisor e receptor coñecen).
  • Usaremos en openssl, que xa ven instalado por defecto (http://es.wikipedia.org/wiki/OpenSSL)
  • Os pasos que seguiremos son os que se usan nunha infraestrutura de chave pública, openssl, son os seguintes:
    • Crearemos unha autoridade de certificación (CA).
    • Crearemos unha solicitude de firma de certificado (CSR) para que a CA cree o certificado para o servidor (asociado ao nome DNS do servidor).
    • Xeraremos coa CA o certificado do servidor a partir da CSR.
    • Teremos que copiar no equipo cliente o certificado da CA, para que cando reciba o certificado do servidor confíe nel ao estar emitido por esa CA.
    • Se non se está familiarizado cos certificados e as CAs pode resultar farragoso, pero só hai que seguir o que se indica.


Crear a Autoridade de Certificación (CA)

En derver00, primeiro, creamos os directorios para almacenar os certificados da CA e os ficheiros relacionados:

mkdir /etc/ssl/CA
mkdir /etc/ssl/newcerts

Creamos dous ficheiros que a CA precisará para manter un número de serie que lle asignará a cada certificado e almacenar os certificados emitidos:

touch /etc/ssl/CA/index.txt
sh -c "echo '01' > /etc/ssl/CA/serial"


No ficheiro de configuración da CA /etc/ssl/openssl.cnf, modificaremos os seguintes parámetros dentro da sección [ CA_default]:

dir             = /etc/ssl              # Where everything is kept
...
database        = $dir/CA/index.txt     # database index file.
...
certificate     = $dir/certs/cacert.pem # The CA certificate
serial          = $dir/CA/serial        # The current serial number

Creamos o certificado raíz para a propia CA, que será firmado por si mesma:

openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

  • Teremos que introducir un contrasinal para a CA (podemos poñer abc123.), e os datos do certificado.
  • A continuación móstrase un exemplo para estes datos.
  • É importante ter en conta que o que poñamos en Organization Name, deberá ser o mesmo valor que logo poñamos neste mesmo campo no certificado do servidor:
Generating a 1024 bit RSA private key
......++++++
........++++++
unable to write 'random state'
writing new private key to 'cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Galicia
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:IES Calquera
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:dserver00.iescalquera.local
Email Address []:


  • Instalamos (movemos) nos directorios da CA tanto a chave privada como o certificado creado:
mv cakey.pem /etc/ssl/private/
mv cacert.pem /etc/ssl/certs/

Xenerar a solicitude de firma do certificado (CSR)

En primeiro lugar teremos que crear unha chave para xerar a CSR, que será almacenada no ficheiro server.key. Teremos que introducir un contrasinal que será necesario para abrir esta chave (Como exemplo, podemos poñer o mesmo contrasinal abc123.):

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus
..++++++
............................................................................................................++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:
root@dserver00:~# openssl rsa -in server.key -out server.key.insecure
Enter pass phrase for server.key:
writing RSA key


O problema que temos con esta chave que acabamos de crear é que para poder abrila fai falta proporcionar o contrasinal que lle asignamos, e entón cada vez que se arrancara o servidor LDAP habería que introducir este contrasinal para que puidese ter acceso á chave privada do servidor, e isto supón un problema xa que calquera reinicio do servizo obriga a unha intervención manual. Por iso, o que imos facer é crear a partir da chave xa creada unha chave que non requira contrasinal:

openssl rsa -in server.key -out server.key.insecure
  
Enter pass phrase for server.key:
writing RSA key

E gardamos en server.key a chave sen contrasinal, que será a que usaremos:

mv server.key server.key.secure
mv server.key.insecure server.key

E por último creamos o CSR:

openssl req -new -key server.key -out server.csr
  • Introduciremos os datos necesarios para a solicitude do certificado, destacando o:
    • Organization Name, que deberá coincidir co que introducimos para a CA,
    • e o Common Name, que deberá ser o nome DNS do servidor para o que emitiremos o certificado:
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Galicia
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:IES Calquera
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:dserver00.iescalquera.local
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

A CSR será almacenada no ficheiro server.csr, que xa pode ser enviada á autoridade de certificación para que xenere o certificado.

Xerar o certificado a partir do CSR

Ah!! pero se a autoridade de certificación tamén somos nós!! Ben, pois imos crear un certificado a partir da CSR:

openssl ca -in server.csr -config /etc/ssl/openssl.cnf

Primeiro pedirásenos o contrasinal da CA (o que asignamos cando creamos o certificado da CA, no noso caso abc123.), e a continuación móstransenos os datos do certificado que se vai xerar (tomados da CSR):

Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Mar  4 23:25:23 2010 GMT
            Not After : Mar  4 23:25:23 2011 GMT
        Subject:
            countryName               = ES
            stateOrProvinceName       = Galicia
            organizationName          = IES calquera
            commonName                = server00.iescalquera.local
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                DF:FC:73:0D:36:B0:AF:DA:47:F7:E3:57:F9:41:FD:FF:88:AF:17:AE
            X509v3 Authority Key Identifier: 
                keyid:01:C8:B2:AD:1B:B7:86:45:3E:CA:37:CC:C1:95:8E:A8:22:C3:D1:9B

Certificate is to be certified until Mar  4 23:25:23 2011 GMT (365 days)

E procedemos a asinar... (respondemos que si (y) ás dúas preguntas de confirmación).

  • Listo!! xa temos un certificado dixital para dserver00.iescalquera.local
  • Copiamos todo o texto entre as liñas -----BEGIN CERTIFICATE----- and ----END CERTIFICATE----- (incluíndo estas dúas liñas), e o pegamos no ficheiro server.crt (que o podemos crear cun editor)
  • Por exemplo, este ficheiro pode conter algo así:
-----BEGIN CERTIFICATE-----
MIICpzCCAhCgAwIBAgIBATANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJFUzEQ
MA4GA1UECBMHR2FsaWNpYTEVMBMGA1UEChMMSUVTIGNhbHF1ZXJhMSMwIQYDVQQD
ExpzZXJ2ZXIwMC5pZXNjYWxxdWVyYS5sb2NhbDAeFw0xMDAzMDQyMzI1MjNaFw0x
MTAzMDQyMzI1MjNaMFsxCzAJBgNVBAYTAkVTMRAwDgYDVQQIEwdHYWxpY2lhMRUw
EwYDVQQKEwxJRVMgY2FscXVlcmExIzAhBgNVBAMTGnNlcnZlcjAwLmllc2NhbHF1
ZXJhLmxvY2FsMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/QWqoi12reBRA
/3p6+KyWTAoN3XqLU8VaNhpAAP4LTRuuzeeCKxkPyj2QZk+rWehmqkqbwX6Zdrqi
BSfeKuoRokTV7e2bbMJmaomEbvez5bwr7sDSXl2UyFhVyJWtQBkI8m2pkqjWt9Fn
2OotV+c43HNncXN3/mGoVwpE7OMivwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCG
SAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4E
FgQU3/xzDTawr9pH9+NX+UH9/4ivF64wHwYDVR0jBBgwFoAUAciyrRu3hkU+yjfM
wZWOqCLD0ZswDQYJKoZIhvcNAQEFBQADgYEAVHDWexRWbz6nPWVA+x/4KaXA9KaE
atZ1cu2Mep+29duZyAFcQEf4pivXCallmkmbAhurpUH61SLFHOb7YHl71EPLvru0
U3kDx48wSDGqBzdCKWhoh1SBrFryxlovEredZ44q/1AxldJ8py9r77e2kqJ7u+TC
6v0/CnJRUYvWZh0=
-----END CERTIFICATE-----

Copiamos o certificado e a chave ao directorio de almacenamento da CA:

cp server.crt /etc/ssl/certs
cp server.key /etc/ssl/private

Configuración do servidor LDAP

Permitimos o acceso ao certificado ao usuario openldap, xa que é o usuario co que se executa o servidor LDAP:

#Se non existe o grupo local ssl-cert, creámolo.
#addgroup ssl-cert, 

adduser openldap ssl-cert
chmod 750 /etc/ssl/private
chgrp ssl-cert /etc/ssl/private
chmod 640 /etc/ssl/private/server.key
chgrp ssl-cert /etc/ssl/private/server.key

E reiniciamos o servizo slapd:

/etc/init.d/slapd restart

Unha vez que temos creados o certificado e chave para o servidor e o certificado da CA, temos que configurar o servidor LDAP para que faga uso deles nas conexións seguras, para iso precisamos engadir entradas na rama cn=config:

ldapmodify -Y EXTERNAL -H ldapi://
  • Pegaremos os seguintes datos (é como cargalos dende un ficheiro). Imos modificar a rama cn=config:
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/server.key

E prememos as teclas Control+D para procesar os datos introducidos.

Editamos o ficheiro /etc/default/slapd para establecer no parámetro SLAPD_SERVICES o seguinte valor:

SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"
  • Reiniciamos de novo o servidor LDAP e comprobamos os portos nos que está escoitando o servidor ldap:
netstat -natp | grep 'slapd' 
tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN      8444/slapd      
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      8444/slapd      
tcp6       0      0 :::636                  :::*                    LISTEN      8444/slapd      
tcp6       0      0 :::389                  :::*                    LISTEN      8444/slapd 

Vemos que está escoitando no porto 389 (non seguro, ldap) e no 636 (porto seguro, ldaps)

Configuración do cliente LDAP

Agora quédanos configurar o equipo cliente (uclient01) para que realice a autenticación co servidor LDAP de forma segura, usando o protocolo ldaps en lugar de ldap:


O ficheiro de configuración /etc/nslcd.conf

  • O ficheiro de configuración do servizo anterior, queda como segue:
  • Observar as liñas 12 e 29.
uadmin@uclient01:~$ sudo cat  /etc/nslcd.conf 
[sudo] password for uadmin: 
# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.

# The user and group nslcd should run as.
uid nslcd
gid nslcd

# The location at which the LDAP server(s) should be reachable.
uri ldaps://dserver00.iescalquera.local

# The search base that will be used for all queries.
base dc=iescalquera,dc=local

# The LDAP protocol version to use.
#ldap_version 3

# The DN to bind with for normal lookups.
#binddn cn=annonymous,dc=example,dc=net
#bindpw secret

# The DN used for password modifications by root.
#rootpwmoddn cn=admin,dc=example,dc=com

# SSL options
#ssl off
tls_reqcert allow


# The search scope.
#scope sub


  • Sempre podemos modificar o ficheiro á man e logo reiniciar o servizo manualmente:
sudo service nslcd restart
  • Por exemplo na liña 12 podemos poñer uri ldap://dserver00.iescalquera.local, reiniciariamos nslcd e xa non teriamos ldap seguro.

Comprobación con Ettercap

  • Agora toca revisar se o usuario e o contrasinal viaxan cifrados entre uclient01 e dserver00
  • Temos activado o Etthercap en uclient02 como ao principio desta sección.

Instantáneas do escenario 1.F

  • Ao igual que se fixo nos escenarios anteriores, convén crear a instantánea do escenario 1.F tanto no servidor dserver00 como nos clientes uclient01 e uclient02.


-- Antonio de Andrés Lema e Carlos Carrión Álvarez