Kerberos+LDAP+NFSv4: Diferenzas entre revisións
Sen resumo de edición |
Sen resumo de edición |
||
Liña 38: | Liña 38: | ||
#Instalación do software: |
#Instalación do software: |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
apt-get install krb5-kdc krb5-admin-server |
apt-get install krb5-kdc krb5-admin-server |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
Liña 48: | Liña 48: | ||
<ol start='2'><li>Debemos modificar ''/etc/krb5.conf'' para incluir a información do noso dominio kerberos na sección ''[domain-realm]'' e un apartado para configurar os ''log'' de kerberos</li></ol> |
<ol start='2'><li>Debemos modificar ''/etc/krb5.conf'' para incluir a información do noso dominio kerberos na sección ''[domain-realm]'' e un apartado para configurar os ''log'' de kerberos</li></ol> |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
mkdir /var/log/kerberos |
mkdir /var/log/kerberos |
||
chmod 750 /var/log/kerberos |
chmod 750 /var/log/kerberos |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
<syntaxhighlight> |
<syntaxhighlight lang='text'> |
||
[domain-realm] |
[domain-realm] |
||
.iesrodeira.com = IESRODEIRA.COM |
.iesrodeira.com = IESRODEIRA.COM |
||
Liña 64: | Liña 64: | ||
</syntaxhighlight> |
</syntaxhighlight> |
||
<ol start='3'><li>A continuación creamos a base de datos para Kerberos, para o que necesitará recolectar información aleatoria (tardará un pouco) e solicitarnos unha ''password'' que será imprescindible para o decodificado da base de datos:</li></ol> |
<ol start='3'><li>A continuación creamos a base de datos para Kerberos, para o que necesitará recolectar información aleatoria (tardará un pouco) e solicitarnos unha ''password'' que será imprescindible para o decodificado da base de datos:</li></ol> |
||
<syntaxhighlight lang='text'> |
|||
krb5_newrealm |
krb5_newrealm |
||
service krb5-admin-server restart && service krb5-kdc restart |
|||
</syntaxhighlight> |
|||
<ol start='4'><li>Xa podemos empezar a engadir servidores e usuarios a base de datos Kerberos ('''principals''') mediante a utilidade ''kadmin.local''. Os ''principals'' Kerberos teñen a forma '''''SPEC'''@REALMKERBEROS'' (no noso caso '''''SPEC'''@IESRODEIRA.COM''), donde ''SPEC'' normalmente ten a forma de ''usuario/rol'' ou ''servizo/hostname'' (por exemplo, ''root/admin'', ou ''nfs/nfs.iesrodeira.com''). Estas ''SPEC'' se poden utilizar logo no ficheiro ''/etc/krb5kdc/kadm5.acl'' para establecer ACLS especificando permisos.</li></ol> |
<ol start='4'><li>Xa podemos empezar a engadir servidores e usuarios a base de datos Kerberos ('''principals''') mediante a utilidade ''kadmin.local''. Os ''principals'' Kerberos teñen a forma '''''SPEC'''@REALMKERBEROS'' (no noso caso '''''SPEC'''@IESRODEIRA.COM''), donde ''SPEC'' normalmente ten a forma de ''usuario/rol'' ou ''servizo/hostname'' (por exemplo, ''root/admin'', ou ''nfs/nfs.iesrodeira.com''). Estas ''SPEC'' se poden utilizar logo no ficheiro ''/etc/krb5kdc/kadm5.acl'' para establecer ACLS especificando permisos.</li></ol> |
||
::As password para os ''principals'' poden organizarse mediante políticas (''policies'') que forzan distintos graos de fortaleza (''-minlength, -minclasses, -maxlife, -minlife, -maxfailure, -failurecountinterval, -lockoutduration''), creando primeiro as políticas como por exemplo: |
::As password para os ''principals'' poden organizarse mediante políticas (''policies'') que forzan distintos graos de fortaleza (''-minlength, -minclasses, -maxlife, -minlife, -maxfailure, -failurecountinterval, -lockoutduration''), creando primeiro as políticas como por exemplo: |
||
<syntaxhighligth lang=' |
<syntaxhighligth lang='text'> |
||
add_policy -minlength 8 -minclasses 1 user |
add_policy -minlength 8 -minclasses 1 user |
||
add_policy -minlength 8 -minclasses 3 admin |
add_policy -minlength 8 -minclasses 3 admin |
||
Liña 76: | Liña 78: | ||
::Para posteriormente crear o ''principal'' cunha política determiñada: |
::Para posteriormente crear o ''principal'' cunha política determiñada: |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
addprinc -policy user root/admin |
addprinc -policy user root/admin |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
::Ou cambiar de política un ''principal'' existente: |
::Ou cambiar de política un ''principal'' existente: |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
modprinc -policy admin root/admin |
modprinc -policy admin root/admin |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
::Polo tanto, creamos as políticas e un ''principal'' para poder acceder a configuración Kerberos dende calqueira equipo cliente: |
::Polo tanto, creamos as políticas e un ''principal'' para poder acceder a configuración Kerberos dende calqueira equipo cliente: |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
add_policy -minlength 6 -minclasses 1 user |
add_policy -minlength 6 -minclasses 1 user |
||
add_policy -minlength 8 -minclasses 2 admin |
add_policy -minlength 8 -minclasses 2 admin |
||
Liña 99: | Liña 101: | ||
Podemos comprobar o correcto funcionamento creando un ticket para o ''principal'' creado, listando o ticket (''TGT'') e destruíndolo: |
Podemos comprobar o correcto funcionamento creando un ticket para o ''principal'' creado, listando o ticket (''TGT'') e destruíndolo: |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
kinit -p root/admin |
kinit -p root/admin |
||
klist |
klist |
||
Liña 106: | Liña 108: | ||
<ol start='5'><li>Creamos un principal no ''PDC'' para o servidor ''PDC'' mediante a utilidade ''kadmin'' cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.</li></ol> |
<ol start='5'><li>Creamos un principal no ''PDC'' para o servidor ''PDC'' mediante a utilidade ''kadmin'' cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.</li></ol> |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
addprinc -randkey host/krbldap-pdc.iesrodeira.com |
addprinc -randkey host/krbldap-pdc.iesrodeira.com |
||
ktadd host/krbldap-pdc.iesrodeira.com |
ktadd host/krbldap-pdc.iesrodeira.com |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
Unha boa idea sería crear o ficheiro ''/etc/logrotate.d/krb5-kdc'' cun contido similar a este: |
Unha boa idea sería crear o ficheiro ''/etc/logrotate.d/krb5-kdc'' cun contido similar a este: |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
/var/log/kerberos/krb5lib.log /var/log/kerberos/kadmin.log /var/log/kerberos/krb5lib.log { |
/var/log/kerberos/krb5lib.log /var/log/kerberos/kadmin.log /var/log/kerberos/krb5lib.log { |
||
daily |
daily |
||
Liña 126: | Liña 128: | ||
</syntaxhighlight> |
</syntaxhighlight> |
||
Tamén sería unha boa práctica alterar a vida dos ''tickets'': |
Tamén sería unha boa práctica alterar a vida dos ''tickets'': |
||
<syntaxhighlight lang=' |
<syntaxhighlight lang='text'> |
||
~# kadmin.local |
~# kadmin.local |
||
Authenticating as principal root/admin@EXAMPLE.COM with password. |
Authenticating as principal root/admin@EXAMPLE.COM with password. |
||
Liña 140: | Liña 142: | ||
=== Servidor Slave (''BDC'') === |
=== Servidor Slave (''BDC'') === |
||
*Debemos instalar o paquete ''krb5-user'' e contestar ás preguntas: |
*Debemos instalar o paquete ''krb5-user'' e contestar ás preguntas: |
||
<syntaxhighlight lang='text'> |
|||
apt-get install krb5-user |
apt-get install krb5-user |
||
</syntaxhighlight> |
|||
{{boxinfo|O ficheiro ''/etc/krb5.conf'' e o script de rotación de logs ''/etc/logrotate.d/krb5-kdc'' serán idénticos aos do controlador primario (''KDC'').}} |
{{boxinfo|O ficheiro ''/etc/krb5.conf'' e o script de rotación de logs ''/etc/logrotate.d/krb5-kdc'' serán idénticos aos do controlador primario (''KDC'').}} |
||
Revisión como estaba o 30 de setembro de 2013 ás 15:04
Kerberos
Kerberos é un protocolo de autenticación que permite a ordenadores nunha rede insegura identificarse mutuamente de xeito seguro. Tanto os clientes coma o servidor verificarán a identidade un do outro. Kerberos básase en criptografía de chave simétrica e precisa dun terceiro de confianza, ainda que existen extensións que permiten o uso de criptografía de chave asimétrica. Kerberos establece tamén unha duración das autorizacións, de xeito que únicamente é necesario autenticarse unha vez ata que caduque a concesión.
O funcionamento de Kerberos emprega 2 entidades (servidores), o Servidor de Autenticación (SA) e o Servidor de Tickets de Acceso (TGS) co obxecto de asegurar o acceso a un servicio ofrecido por un Proveedor de Servizo (SS) como NFS. Estes dous servidores forman parte do servidor kerberos, que atenderá as solicitudes mediante o seguinte intercambio de mensaxes:
- O usuario introduce no cliente o seu usuario e contrasinal
- O cliente transforma o contrasinal con cifrado de un so sentido, creando a chave segreda do cliente.
- O cliente envía unha mensaxe en claro ao SA solicitando servicio para o usuario identificado.
- O SA verifica que o usuario está na súa base de datos obtendo a súa contrasinal da BBDD e xerando a chave segreda do cliente que cotexará coa recibida. Si coinciden se crearán dúas mensaxes que se envían ao cliente:
- Mensaxe A
- O SA Crea unha mensaxe cifrada coa chave segreda do cliente, chamada Client/TGS Session Key.
- Mensaxe B
- O SA obteń o contrasinal do TGS da BBDD e xenera con ela unha mensaxe cifrada que conten: ID de cliente, dirección IP do cliente, periodo de validez do ticket, e o Client/TGS Session Key. Esta mensaxe é o Ticket Granting Ticket (TGT).
- O cliente descifra a Client/TGS Session Key da Mensaxe A, que se utilizará para a comunicación co TGS.
- Cando o cliente precise un servicio, necesitará solicitarllo ao TGS mediante as seguintes mensaxes:
- Mensaxe C
- Composta polo TGT e a ID do servicio solicitado.
- Mensaxe D
- Cifrado coa Client/TGS Session Key obtida da Mensaxe A e composta polo ID de cliente e unha marca de tempo, chamada Autenticador.
- O TGS descifra o TGT da Mensaxe C obtendo a Client/TGS Session Key necesaria para descifrar a Mensaxe D (Autenticador) e obtendo así o ID de cliente e a marca de tempo
- O TGS con esta información crea unha mensaxe composta pola ID de cliente,IP do cliente,Periodo de validez e a Client/Server Session Key xenerada para a comunicación. Esta mensaxe se cifra coa Chave Segreda do Servizo e se chama Client-To-Server Ticket (Mensaxe E). Tamén se crea outra mensaxe composta pola Client/Server Session Key cifrada coa Client/TGS Session Key (Mensaxe F). Se envían estas dúas mensaxes ao cliente
- Unha vez recibidas estas mensaxes, o cliente poderá autenticarse para acceder ao servizo enviando ao Proveedor do Servizo (SS) a Mensaxe E, e unha nova mensaxe cifrada coa Client/Server Session Key obtida da Mensaxe F que terá o ID do cliente e unha Marca de Tempo.
- O proveedor de servizo (SS) descifrará a Mensaxe E coas súa chave sergreda obtendo así a Client/Server Session Key que lle permitirá descifrar a Mensaxe F e crear unha mensaxe de autorización de acceso ao servizo (Mensaxe H) composta pola marca de tempo obtida da Mensaxe F+1 e cifrada coa Client/Server Session Key.
- O cliente descifra a mensaxe de autorización e confirma a corrección da marca de tempo. Si é correcto, poderá empezar a utilizar o servizo.
Instalación de Kerberos
En Linux existen dúas versións de Kerberos: Heimdall e MIT. Utilizaremos MIT.
Os tickets kerberos teñen periodos de validez establecidos, polo que resulta importante a sincronización dos distintos ordenadores da rede. Para manter a sincronización podemos facer uso de ntp ou do paquete ntpdate, que combinado con cron nos permitirá manter o tempo en sincronía en todos os ordenadores da rede. Se recomenda a versión 5 de Kerberos, xa que a versión 4 ten diversas vulnerabilidades e debilidades no cifrado. E tamén necesario que todos os equipos que utilicen Kerberos sexan resoltos de modo axeitado, tanto de modo directo como inverso, polo que e convinte un servidor DNS, e incluso engadir ao /etc/hosts os servidores e clientes implicados para asegurar o posible fallo do DNS.
Kerberos soporta replicación a múltiples servidores, recomendándose o uso de polo menos dous, un maestro que será o servidor Primario (PDC) e outro Secundario que estará dispoñible para cubrir posibles fallos do maestro (BDC). Os clientes Kerberos utilizarán o servidor secundario automáticamente no caso de fallo do primario.
Instalaremos o servidor Kerberos:
- Instalación do software:
apt-get install krb5-kdc krb5-admin-server
Durante a instalación se solicitará:
- O nome do dominio Kerberos (Realm), que normalmente será o noso dominio en maiúsculas: IESRODEIRA.COM
- Os servidores Kerberos para o dominio, que serán en primeiro lugar o PDC, e logo o BDC: krbldap-pdc.iesrodeira.com krbldap-bdc.iesrodeira.com
- O nome do servidor administrativo (PDC): krbldap-pdc.iesrodeira.com
- Debemos modificar /etc/krb5.conf para incluir a información do noso dominio kerberos na sección [domain-realm] e un apartado para configurar os log de kerberos
mkdir /var/log/kerberos
chmod 750 /var/log/kerberos
[domain-realm]
.iesrodeira.com = IESRODEIRA.COM
iesrodeira.com = IESRODEIRA.COM
[logging]
kdc=FILE:/var/log/kerberos/krb5kdc.log
admin_server=FILE:/var/log/kerberos/kadmin.log
default=FILE:/var/log/kerberos/krb5lib.log
- A continuación creamos a base de datos para Kerberos, para o que necesitará recolectar información aleatoria (tardará un pouco) e solicitarnos unha password que será imprescindible para o decodificado da base de datos:
krb5_newrealm
service krb5-admin-server restart && service krb5-kdc restart
- Xa podemos empezar a engadir servidores e usuarios a base de datos Kerberos (principals) mediante a utilidade kadmin.local. Os principals Kerberos teñen a forma SPEC@REALMKERBEROS (no noso caso SPEC@IESRODEIRA.COM), donde SPEC normalmente ten a forma de usuario/rol ou servizo/hostname (por exemplo, root/admin, ou nfs/nfs.iesrodeira.com). Estas SPEC se poden utilizar logo no ficheiro /etc/krb5kdc/kadm5.acl para establecer ACLS especificando permisos.
- As password para os principals poden organizarse mediante políticas (policies) que forzan distintos graos de fortaleza (-minlength, -minclasses, -maxlife, -minlife, -maxfailure, -failurecountinterval, -lockoutduration), creando primeiro as políticas como por exemplo:
<syntaxhighligth lang='text'>
add_policy -minlength 8 -minclasses 1 user add_policy -minlength 8 -minclasses 3 admin
</syntaxhighlight>
- Para posteriormente crear o principal cunha política determiñada:
addprinc -policy user root/admin
- Ou cambiar de política un principal existente:
modprinc -policy admin root/admin
- Polo tanto, creamos as políticas e un principal para poder acceder a configuración Kerberos dende calqueira equipo cliente:
add_policy -minlength 6 -minclasses 1 user
add_policy -minlength 8 -minclasses 2 admin
addprinc -policy admin root/admin
- E editaremos /etc/krb5kdc/kadm5.acl, especificando */admin *, indicando que todos os usuarios co rol admin teñen todos os privilexios de administración. A partir deste momento poderemos administrar o servicio Kerberos dende calqueira cliente coa utilidade kadmin, crear tickets coa utilidade kinit, examinalos (klist) e eliminalos (kdestroy).
- [domain_realm] conten o mapeo ao dominio correcto
- default_realm ten o valor correcto
- o realm está definido na sección [realms]
Podemos comprobar o correcto funcionamento creando un ticket para o principal creado, listando o ticket (TGT) e destruíndolo:
kinit -p root/admin
klist
kdestroy
- Creamos un principal no PDC para o servidor PDC mediante a utilidade kadmin cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.
addprinc -randkey host/krbldap-pdc.iesrodeira.com
ktadd host/krbldap-pdc.iesrodeira.com
Unha boa idea sería crear o ficheiro /etc/logrotate.d/krb5-kdc cun contido similar a este:
/var/log/kerberos/krb5lib.log /var/log/kerberos/kadmin.log /var/log/kerberos/krb5lib.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
postrotate
/etc/init.d/krb5-kdc restart > /dev/null
/etc/init.d/krb5-admin-server restart > /dev/null
endscript
}
Tamén sería unha boa práctica alterar a vida dos tickets:
~# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: modprinc -maxlife "1 day" -maxrenewlife "90 day" krbtgt/IESRODEIRA.COM@IESRODEIRA.COM
Principal "krbtgt/IESRODEIRA.COM@IESRODEIRA.COM" modified.
kadmin.local: q
e modificando o ficheiro /etc/krb5kdc/kdc.conf para reflexar os cambios cambiando as liñas:
max_life = 1d 0h 0m 0s max_renewable_life = 90d 0h 0m 0s
Servidor Slave (BDC)
- Debemos instalar o paquete krb5-user e contestar ás preguntas:
apt-get install krb5-user
- Creamos un principal no PDC para o servidor esclavo mediante a utilidade kadmin cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.
addprinc -randkey host/krbldap-bdc.iesrodeira.com ktadd host/krbldap-bdc.iesrodeira.com
- Instalamos a parte servidor. Necesitaremos xinetd para configurar o servicio de propagación kpropd.
apt-get install krb5-kdc xinetd
- Engadimos o servizo kpropd a xinetd creando o ficheiro /etc/xinetd.d/krb_prop e poñendo:
service krb_prop { disable = no socket_type = stream protocol = tcp user = root wait = no server = /usr/sbin/kpropd }
- Inciamos o servizo xinetd
service xinetd restart
- Configuramos a propagación da base de datos Kerberos do primario ao secundario
- Creamos o ficheiro cos controladores Kerberos do noso reino en /etc/krb5kdc/kpropd.acl nos dous controladores. O contido será o seguinte:
host/krbldap-pdc.iesrodeira.com@IESRODEIRA.COM host/krbldap-bdc.iesrodeira.com@IESRODEIRA.COM
- No controlador primario creamos un backup da base de datos Kerberos e a enviamos ao controlador secundario
kdb5_util dump /var/lib/krb5kdc/slave_datatrans kprop krbldap-bdc.iesrodeira.com
- De volta no controlador secundario creamos un ficheiro cunha copia da chave mestra Kerberos:
kdb5_util stash
- Xa podemos iniciar o servizo co comando service krb5-kdc start
A propagación das modificacións da base de datos Kerberos no controlador primario non se propagan ao secundario de xeito automático, polo que é aconsellable crear un script que se encarge da migración de xeito periódico mediante a utilidade cron. Crearemos o ficheiro /etc/cron.hourly/krb5-prop co seguinte contido:
#!/bin/sh
slavekdcs=krbldap-bdc.iesrodeira.com
/usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
error=$?
if [ $error -ne 0 ]; then
echo "Kerberos database dump failed"
echo "with exit code $error. Exciting."
exit 1
fi
for kdc in $slavekdcs; do
/usr/sbin/kprop $kdc > /dev/null
error=$?
if [ $error -ne 0 ]; then
echo "Propagation of database to host $kdc"
echo "failed with exit code $error."
fi
done
exit 0
LDAP
LDAP (LightWeight Directory Access Protocol) é un protocolo de acceso a bases de datos de directorio (Servicios de Directorio) que implementa un subconxunto do estándar X.500. Os servicios de directorio caracterízanse por ser sistemas con moitos accesos de lectura e moi poucas insercións e actualizacións, polo tanto están optimizadas para consultas rápidas.
Este tipo de bases de datos poden almacenar e organizar, por exemplo, a información sobre usuarios dunha rede e os recursos da mesma.LDAP xunto con Kerberos forma o núcleo do sistema de Active Directory de Microsoft Windows, e de moitas outras implementacións como Novell eDirectory ou o RedHat Directory Service.
As bases de datos LDAP teñen forma de árbore, dandolle ao administrador a posibilidade de crear as distintas ramas (DIT, Directory Information Tree), especificando en primeiro lugar a raíz da árbore, que normalmente é o dominio da organización, como pode ser dc=iesrodeira, dc=com (dc é unha abreviatura de Domain Component).
As distintas entradas na árbore LDAP se representan habitualmente en formato LDIF (LDAP Data Interchange Format) que indican o nome (dn) da nova entrada e os seus atributos.
Realizaremos unha instalación de OpenLDAP para almacenar a base de datos dos usuarios e servicios Kerberos, e configuraremos os clientes do modo apropiado. Neste exemplo, o servicio LDAP e Kerberos estarán na mesma máquina, si estiveran en máquinas distintas sería convinte que a comunicación se realizase de xeito seguro mediante SSL.