Ho molte istanze in diversi cloud, anche approfittando di alcune offerte gratuite per sviluppatori: Amazon Web Services (AWS), Digital Ocean, HP Cloud, ma anche cloud regionali come Moresi.Com, Enter o le mie istanze virtuali sui miei sistemi in housing.
Insomma, un bel po’ di sistemi Linux distribuiti nel mondo, forse come molti informatici. E su questo si incastra il problema di avere la mia identità e quella dei miei utenti/sviluppatori distribuita in questi sistemi. Mentre in una intranet avrei usato LDAP senza esitazioni, creare un LDAP esposto ad Internet potrebbe non essere una buona idea.
Allora come fare a risolvere questo problema e contemporaneamente avere un ottimo livello di sicurezza? La risposta potrebbe essere quella di usare il nuovo modulo NSS per SecurePass.
Fino ad adesso SecurePass è stato sempre usato come un “two factor authentication” nel cloud, soltanto sfruttando la parte di autenticazione nel sistema operativo. Ma la nuova versione beta è in grado di ospitare gli “extended attributes”, che sono informazioni arbitrarie che un amministratore o una applicazione puo’ usare per ogni utente di SecurePass.
Useremo SecurePass per autenticare l’utente e tenere le informazioni Unix atttraverso questa nuova funzionalità. In particolare, useremo:
- il sottosistema PAM per autenticare gli utenti via RADIUS
- il nuvo modulo NSS di SecurePass per ottenere informazioni di UID/GID/….
SecurePass e gli extended attributes
La prossima generazione del servizio SecurePass (attualmente in beta) è in grado di ospitare informazioni arbitrarie per ogni profilo utenti. Questa funzionalità è chiamata “Extended Attributes” (o xattrs) e -come potete immaginare- sono organizzate in modalità chiave/valore.
Dovete avere i SecurePass tools per modificare gli extended attributes di un utente. Le nuove release di Debian Jessie and Ubuntu Vivid Vervet, avranno un pacchetto per questo, quindi potrete fare:
# apt-get install securepass-tools
Per altre distribuzioni Linux (o Unix), potete usare il python package installer (PIP) per installare i tools. Installate come pre-requisito pycurl e poi:
# pip install securepass-tools
Anche se i SecurePass tools hanno la possibilità di avere un file di configurazione locale, per questo tutorial raccomandiamo di creare un file /etc/securepass.conf, in modo da essere usato anche dal modulo NSS. Il file di configurazione e’ simile a quanto sotto:
[default] app_id = xxxxx app_secret = xxxx
Dove app_id e app_secrets sono API keys valide per accedere a SecurePass beta.
Attraverso la riga di comando, saremo in grado di impostare UID, GID e tutti gli attributi Unix per ogni utente:
# sp-user-xattrs user@domain.net set posixuid 1000
Mentre posixuid e’ l’attributo minimo per avere un login su Unix con il modulo NSS, i seguenti attributi sono validi:
- posixuid → UID dell’utente
- posixgid → GID dell’utente
- posixhomedir → Home directory
- posixshell → Shell preferita
- posixgecos → Gecos (il default è lo username)
Installazione e configurazione del modulo NSS SecurePass
Similmente a quanto avviene per i tools, Debian Jessie e Ubuntu Vivid Vervet hanno un pacchetto nativo per SecurePass
# apt-get install libnss-securepass
Per le precedenti releases di Debian e Ubuntu, ma anche per CentOS e RHEL, è sempre possibile installare il modulo. I sorgenti sono disponibili su:
https://github.com/garlsecurity/nss_securepass
Poi:
./configure make make install (solo Debian/Ubuntu)
Per CentOS/RHEL/Fedora bisogna installare il modulo NSS nel posto giusto:
/usr/bin/install -c -o root -g root libnss_sp.so.2 /usr/lib64/libnss_sp.so.2 ln -sf libnss_sp.so.2 /usr/lib64/libnss_sp.so.2
Il file di configurazione /etc/securepass.conf va esteso per avere le informazioni di default per il modulo NSS. Bisogna creare una sezione [nss] come da basso:
[nss] realm = mydomain.com default_gid = 100 default_home = "/home" default_shell = "/bin/bash"
Il realm va impostato come quello registrato su SecurePass, il modulo NSS farà append del dominio/realm corrispondente all’utente Unix. Io preferisco impostare il GID corrispondente al gruppo “users”, che di solito su Linux è il gruppo 100. Fate in modo che questo gruppo esista a livello di sistema operativo. Se non si impostano i default su home e shell, i default dei default sono “/home” e “/bin/false”
Dobbiamo ora configurare il Name Service Switch (NSS) per usare SecurePass. Cambiamo il file /etc/nsswitch.conf aggiungendo “sp” alla riga passwd come segue:
$ grep sp /etc/nsswitch.conf passwd: files sp
Controllate che il sottosistema NSS stia funzionando con il modulo SecurePass facendo una query alla tabella passwd come segue:
$ getent passwd user user:x:1000:100:My User:/home/user:/bin/bash
$ id user uid=1000(user) gid=100(users) groups=100(users)
A questo punto abbiamo configurato gli utenti a sistema operativo, ma gli stessi non potranno collegarsi perche’ manca una password corrispondente. Useremo SecurePass per autenticare gli utenti.
Configurare PAM per SecurePass
Se stai usando CentOS o RHEL, bisogna avere EPEL configurato. Per attivare EPEL, seguite le istruzioni su http://fedoraproject.org/wiki/EPEL
La configurazione seguente non è stata provata con SE-Linux abilitato (controllate che sia disabilitato o in modalita’ permissive).
Su CentOS/RHEL, installate il modulo PAM RADIUS con:
# yum -y install pam_radius
Su Debian/Ubuntu, installate il modulo PAM RADIUS con:
# apt-get install libpam-radius-auth
Nota: al momento della scrittura del presente articolo, EPEL 7 è ancora in beta e non contiene il modulo PAM RADIUS. E’ stata fatta una richiesta attraverso il Bugzilla di RedHat per includere questo pacchetto in EPEL 7
Accediamo all’interfaccia di amministrazione SecurePass e aggiungiamo un nuovo device RADIUS. Dobbiamo solo settare l’IP Pubblico del server, un fully qualified domanin name (FQDN) e la secret pass per l’autenticazione Radius. Se siete sotto NAT, questo corrisponde all’IP pubblico di uscita dei pacchetti. Dopo l’aggiunta avremo un piccolo riassunto con i dati del device appena aggiunto. Per questo esempio, useremo “secret”.
Configurate il modulo PAM RADIUS attraverso il file /etc/pam_radius.conf e aggiungete le seguenti righe:
radius1.secure-pass.net secret 3 radius2.secure-pass.net secret 3
Ovviamente “secret” è la stessa che abbiamo impostato attraverso l’interfaccia di amministrazione di SecurePass administration interface. A questo punto bisogna modificare il file di configurazione di PAM.
In CentOS, modificate il file /etc/pam.d/password-auth-ac; in Debian/Ubuntu modificate il file /etc/pam.d/common-auth ed assicuratevi che il modulo pam_radius_auth.so sia nella lista.
auth required pam_env.so auth sufficient pam_radius_auth.so try_first_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
Conclusioni
E’ difficile avere a che fare con tante istanze Linux distribuite; ci sono problemi che spaziano dal mantenere il software sempre aggiornato, al logging centralizato fino alla gestione delle utenze. Nel cloud, infatti, non è sempre possibile usare i software che tradizionalmente venivano usati nelle intranet. Alcuni tools, come SecurePass, possono aiutare nella gestione quotidiana.
Per poter accedere alla Beta di SecurePass, bisogna attivare SecurePass su: http://www.secure-pass.net/open
E successivamente mandare una mail a support@secure-pass.net richiedendo l’accesso alla beta.