Questa sezione del documento descrive l'installazione e la configurazione delle macchine e del software che svolge il ruolo di KDC. È possibile intervenire con aggiustamenti sulle configurazioni suggerite ma saranno presentati alcuni punti chiave che è importante tenere a mente quando si configura il KDC e anche se si sceglie di praticare una strategia di configurazione alternativa è necessario aver compreso il materiale che viene presentato quì.
Le macchine eseguono il demone Kerberos e conservano le password e le informazioni sui criteri, perciò è molto importante per la salvaguardia della rete che questi server siano messi in sicurezza. Bisognerà prendere ogni misura possibile per scongiurare la compromissione di questi server; le raccomandazioni per la sicurezza contenute in questa sezione rivestono fondamentale importanza.
La raccomandazione principale è di usare macchine dedicate per erogare il servizio KDC di kerberos; l'hardware dovrà essere inaccessibile alle minacce materiali e anche il sistema GNU Linux andrà rinforzato il più possibile. Dalla compromissione del KDC deriverebbe la compromissione dell'intera infrastruttura Kerberos.
Il servizio Kerberos non ha grosse richieste riguardo all'hardware e ha capacità di ridondanza, quindi l'hardware del server può essere esiguo. Per i server Kerberos che ho distribuito ho usato macchine con un processore Pentium III e due dischi in RAID 1 hardware, sufficienti per svolgere da quaranta a centomila autenticazioni al giorno. Anche se il server può essere dotato di schede di rete ridondanti, bisogna evitare di tenerle attive entrambe contemporaneamente perché Kerberos scrive l'indirizzo IP del KDC nei ticket e se durante il processo di autenticazione il client contatta il KDC attraverso interfacce multiple possono insorgere difficoltà.
È importante evidenziare che il servizio Kerberos andrebbe eseguito su hardware dedicato. Riservare una macchina a Kerberos significa che soltanto gli amministratori di Kerberos avranno bisogno di accedere a quella macchina e che sulla macchina non saranno in esecuzione altri servizi, salvo probabilmente SSH. Tutte le password degli utenti saranno conservate presso i server Kerberos, quindi sarà bene limitare il più possibile l'accesso fisico alle macchine interessate; usando hardware riservato a Kerberos sarà più semplice adempiere a questo requisito, magari chiudendo il server con la sua console in un proprio armadio.
Per approfittare della capacità nativa di Kerberos di fornire ridondanza bisogna avere almeno due macchine che funzionano da KDC. Kerberos è progettato per essere distribuito con un server principale (master) e uno o più server secondari (slave); non c'è limite al numero di secondari.
Installando GNU Linux su server dedicati all'esecuzione dei servizi kerberos si percorreranno ulteriori passi per garantirne la sicurezza.
Per prima cosa si installerà soltanto il software assolutamente necessario per il servizio Kerberos, costituito dal sistema operativo di base e dai pacchetti Kerberos, escludendo X e qualunque applicazione grafica. SSH è opzionale e andrà installato se si desidera poter amministrare i server a distanza; del resto i server saranno parecchio più sicuri se si permetterà di accedervi soltanto mediante il terminale collegato direttamente ad essi.
In un sistema GNU Linux basato su Fedora Core, il servizio kerberos è fornito dai pacchetti:
krb5-server krb5-libs
La documentazione e le librerie di sviluppo non andranno installate sul KDC perché non si intende usare questa macchina per altre attività che non siano l'espletamento del servizio KDC.
Nel passo successivo ci si accerterà che non vi siano porte aperte oltre a quelle necessarie e che tutti gli aggiornamenti di sicurezza siano stati applicati. Il procedimento per controllare quali aggiornamenti di sicurezza vanno applicati dipende dal programma di gestione dei pacchetti in uso. Per determinare su quali porte la macchina è in ascolto si può usare il comando netstat; per esempio su una macchina che ha in esecuzione soltanto ssh, si leggerà:
bash$ netstat -an | grep -i listen | less tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
Infine si dovrà configurare il server in modo che possano accedervi soltanto i server che devono comunicare con lui per esigenze di autenticazione, editando i file /etc/hosts.allow and /etc/hosts.deny insieme al file iptables.
I nomi dei realm [domini di protezione] sono sensibili alle maiuscole e devono esere unici sulla rete; è buona pratica usare come nome del realm il nome del dominio di secondo livello scritto in lettere maiuscole. Se si sta configurando Kerberos soltanto per una sottorete anziché per la rete intera, si potrebbe usare un nome di dominio figlio da far corrispondere alla sottorete.
Quando si sceglie la topologia dei realm si deve prendere in considerazione l'assetto complessivo dell'organizzazione; se si hanno uffici remoti o sottogruppi indipendenti è bene che essi appartengano a un realm separato. La topologia dei realm di Kerberos deve riflettere la topologia del sistema di gestione e non la struttura fisica della rete.
Infine si dovrà tener presente l'esistenza di sistemi preesistenti, come distribuzioni precedenti di Kerberos o raggruppamenti di rete che si intende mantenere (per esempio domini di Windows NT).
Se si installa Kerberos in una rete che ne ospita già una distribuzione, nella rete globale o in una sottorete, bisogna evitare una collisione di nomi. Il caso più comune in cui succede di distribuire kerberos in un ambiente in cui è già stato installato precedentemente è dove esiste un cluster IBM SP; la soluzione migliore è creare appositamente per il cluster SP un realm con un nome di dominio almeno di terzo livello e usare un nome di dominio di secondo livello per il realm Kerberos principale.
In questo documento si utilizzerà un esempio che aiuterà a illustrare il disegno e la configurazione di un'infrastruttura. Soggetto dell'esempio sarà una mitica università fondata per educare le persone ai contenuti liberi e per compiere ricerche sull'argomento, l'Università GNU di Dublino in Irlanda. L'esempio comprende due server Kerberos usati per autenticare gli studenti e il corpo docente. Il nome di dominio dell'università è gnud.ie quindi per il realm Kerberos si userà GNUD.IE.
Adesso è necessario configurare Kerberos, creare un amministratore, determinare un criterio di sicurezza e inizializzare il database dei principal di Kerberos.
Il primo passaggio consiste nell'editare il file di configurazione /etc/krb5.conf. In questo file si imposta il realm, si estende la definizione del realm specificando i server kerberos e infine si imposta il dominio del realm. Nell'esempio il contenuto del file è il seguente:
default_realm = GNUD.IE
[realms]
GNUD.IE = {
kdc = kerberos1.gnud.ie:88
kdc = kerberos2.gnud.ie:88
admin_server = kerberos1.gnud.ie:749
default_domain = gnud.ie
}
[domain_realm]
.gnud.ie = GNUD.IE
gnud.ie = GNUD.IE
Il database di Kerberos si crea e inizializza con il comando:
{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util create -s
Il flag -s fa in modo che il KDC crei un file riservato per autenticare sé stesso; si usa il flag -r per specificare un realm. Quando si crea un nuovo database è necessario specificare il realm soltanto se nel file krb5.conf sono definiti più realm.
A questo punto Kerberos domanderà di predisporre una master password per il database; è molto importante non dimenticarla. Non sarà possibile compiere alcuna azione amministrativa sul server se non si ricorderà la master password.
Ora è necessario editare il file delle acl [access control list] sul KDC per concedere l'accesso come amministratore. Normalmente questo file si trova in /var/Kerberos/krb5kdc/kadm5.acl. Può essere necessario specificarne la posizione nel file kdc.conf, il cui percorso è precisato nel file /etc/krb5.conf ed ha come valore predefinito /var/Kerberos/krb5kdc/kdc.conf. Considerando l'esempio dell'Università GNU di Dublino si dovrà modificare il file delle acl perché contenga la riga:
*/admin@GNUD.IE *
Questa impostazione significa che a ogni account che termina con un /admin nel realm GNUD.IE sono concessi tutti i diritti d'accesso.
Una volta impostato l'accesso per gli utenti amministratori bisogna creare tali utenti; questo si fa utilizzando il comando kadmin.local, impartito da una shell di root sul KDC e usando il suo sottocomando addprinc. Di solito il nome dell'account amministrativo è admin; nell'esempio della Università GNU di Dublino è scritto come:
{Kerberos1}bash# /usr/Kerberos/sbin/kadmin.local -q "addprinc admin/admin"
Sul server andranno eseguiti i dèmoni krb5kdc e kadmin. Se è necessario potrà essere eseguito anche krb524 per fornire la compatibilità con i client Kerberos 4. Tuttavia prima di far partire krb524 si rammenti l'avvertimento riguardante le debolezze nella sicurezza di Kerberos 4 e ci si accerti di avere davvero bisogno di questa funzionalità. Sui KDC si possono configurare i dèmoni krb5kdc e kadmin per avviarsi automaticamente, tramite il comando chkconfig.
{Kerberos1}bash# /sbin/chkconfig krb5kdc on
{Kerberos1}bash# /sbin/chkconfig kadmin on
Alternativamente si possono avviare manualmente, impartendo i comandi:
{Kerberos1}bash# /etc/rc.d/init.d/krb5kdc start
{Kerberos1}bash# /etc/rc.d/init.d/kadmin start
Questo è sufficiente per ottenere un KDC funzionante.
Si crea un principal di Kerberos per un utente con il comando:
{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local: addprinc <username>
Se Kerberos deve supportare un vasto numero di account, si può scrivere uno script per creare i principal in massa.