Nei precedenti articoli pubblicati nella serie “SSH in CHROOT: Una gabbia per la shell sicura” parte 1 e parte 2, veniva affrontato il tema della messa in sicurezza di SSH attraverso una Patch che obbligava determinati utenti a rimanere chiusi all’interno di una gabbia virtuale.
Dalla versione 5 di SSH però è possibile sfruttare un meccanismo nativo che implementa il CHROOT. Ecco spiegato come.
Capire la versione di SSH installata nel sistema
Prima di procedere con la configurazione del pacchetto è bene accertarsi che la versione di SSH installata nel sistema sia uguale o superiore alla 4.8p1, su sistemi Debian e derivati, l’interrogazione è possibile attraverso il seguente comando:
# dpkg -l openssh-*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Nome Versione Descrizione
+++-=======================================-=======================================-==============================================================================================
ii openssh-blacklist 0.4.1 list of default blacklisted OpenSSH RSA and DSA keys
ii openssh-blacklist-extra 0.4.1 list of non-default blacklisted OpenSSH RSA and DSA keys
ii openssh-client 1:5.1p1-5 secure shell client, an rlogin/rsh/rcp replacement
ii openssh-server 1:5.1p1-5 secure shell server, an rshd replacement
Mentre in sistemi RedHat e derivati è sufficiente interrogare l’elenco pacchetti installati con rpm:
$ rpm -qa openssh*
openssh-4.3p2-16.el5
openssh-askpass-4.3p2-16.el5
openssh-clients-4.3p2-16.el5
openssh-server-4.3p2-16.el5
Nei casi riportati, sul sistema Debian (versione Lenny) la versione di SSH supporta nativamente il Chroot mentre il sistema RedHat (versione 5) no. In questo caso è necessario eseguire l’aggiornamento del pacchetto se ne si vorrà sfruttare la nuova funzionalità, ricompilando localmente la versione 5 partendo dai sorgenti disponibili presso il sito ufficiale del progetto OpenSSH oppure scaricando un rpm precompilato da repository pubblici come http://www.rpmfind.net.
Come funziona il CHROOT nativo
Il metodo con cui il demone SSH, previa configurazione, costruisce la gabbia per l’utente che effettua la login può essere diviso in due tipologie: l’accesso diretto via ssh e quello via sftp.
Nel primo caso la directory nella quale l’utente effettuerà il login dovrà contenere la struttura essenziale di file e directory necessaria alla navigazione all’interno del sistema, mentre attraverso il funzionamento sftp il demone non necessiterà di un ambiente nativo, ma sfruttando il comando interno sftp, fornirà l’interfaccia di accesso al sistema.
Predisposizione del sistema
I test che verranno effettuati nel corso dell’articolo partiranno dal presupposto che esista un gruppo denominato test e che tutte le utenze facenti parte di questo gruppo vengano ingabbiate.
Verrà quindi creato un utente denominato test con cui verranno effettuate le prove:
$ adduser test
Il comando crea automaticamente il gruppo omonimo.
Terminata la creazione dell’utente di test è necessario creare la struttura relativa alla gabbia. Per far questo è possibile utilizzare lo script create_chroot_env.sh contenuto nel file ssh-in-chroot-scripts.tar presentato nella precedente serie di articoli.
Lanciando il comando come segue:
$ ./create_chroot_env.sh /chroot
nella cartella /chroot verrà creato un ambiente con tutti i requisiti imposti da ssh per l’implementazione della gabbia.
Requisito essenziale per il corretto funzionamento del sistema è che la cartella nella quale verrà impostata la gabbia sia accessibile in scrittura alla sola utenza di root. Avendo lanciato lo script come utente root (non sarebbe possibile altrimenti utilizzare il path definito) tale requisito è pienamente rispettato.
Configurazione del demone per l’utilizzo via ssh
A questo punto la configurazione del server ssh andrà variata per supportare il chroot esclusivamente per le utenze facenti parte del gruppo test attraverso l’aggiunta delle seguenti righe nel file /etc/ssh/sshd_config:
Match Group test
ChrootDirectory /chroot/
terminata la modifica le configurazioni andranno ricaricate attraverso il seguente comando:
$ /etc/init.d/ssh reload
Verifica del funzionamento
Per verificare il funzionamento della gabbia è sufficiente effettuare il login nel sistema e controllare come e se sia possibile muoversi all’interno di questo:
$ ssh test@172.16.1.130
test@172.16.1.130's password:
Linux anomalia 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jun 9 23:09:39 2009 from 172.16.1.1
-bash-3.2$ pwd
/
-bash-3.2$ ls
bin dev etc home lib
-bash-3.2$ cd ..
-bash-3.2$ pwd
/
-bash-3.2$ ls
bin dev etc home lib
l’output illustrato conferma le aspettative: a login effettuato non è possibile scorrere il path precedente alla cartella /. La gabbia funziona.
Configurazione del demone per l’utilizzo via sftp
La configurazione impostata non prevede l’utilizzo di sftp, infatti un tentativo di connessione non andrebbe a buon fine:
$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password:
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer
per fare in modo che questo tipo di connessione sia utilizzabile, è necessario modificare nuovamente /etc/ssh/sshd_config sostituendo la riga
Subsystem sftp /usr/lib/openssh/sftp-server
con
Subsystem sftp internal-sftp
In questo modo si indica ad ssh di utilizzare per il comando sftp non lo script locale /usr/lib/openssh/sftp-server ma la versione interna al demone.
Verifica del funzionamento
A questo punto dopo aver ricaricato il demone, è possibile provare nuovamente la login via sftp:
$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password:
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer
rasca@anomalia:~$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password:
sftp> ls
bin dev etc home lib
sftp> cd ..
sftp> ls
bin dev etc home lib
Come da pronostico, il login ha avuto successo.
E’ da notare che in questo caso la directory di arrivo dell’utenza è sempre la / del chroot ma si può fare in modo che questa corrisponda ad una qualsiasi cartella o alla home dell’utente modificando il parametro ChrootDirectory nel file di configurazione di ssh. E’ consentito l’utilizzo delle diciture speciali %h, corrispondente alla homedir dell’utente, e %u, corrispondente al nome dell’utente.
ChrootDirectory %h
E’ chiaro che ogni directory scelta dovrà possedere il requisito essenziale di essere di proprietà di root e non scrivibile da alcun gruppo.
Conclusioni
Rispetto alla soluzione presentata nei precedenti articoli, che comportava l’applicazione di una patch ai sorgenti di ssh, quanto illustrato ha l’indubbio vantaggio di sfruttare un’implementazione nativa che non necessita di operazioni sul pacchetto. Certo i requisiti richiesti, in particolare relativamente alla proprietà della cartella madre del chroot, sono piuttosto rigidi ed obbligano a riflettere su come distribuire le utenze.
La soluzione migliore, come sempre, è quella più funzionale allo scopo che ci si prefigge.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
