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.

Come avevo promesso ecco la seconda dose di Tips and Tricks per SSH!

Invito a leggere la prima parte QUI.

SSH Tunneling

Siccome oggi mi sento pigro, farò il copiaincolla di un commento (più precisamente questo, grazie Michelangelog )

Mi permetto di fare una piccola aggiunta ai tuoi ottimi suggerimenti.
Spesso farebbe comodo accedere alla macchina HOST_C dalla nostra macchina HOST_A
ma magari la macchina HOST_C non permette l’accesso alla nostra macchina oppure
non permette l’accesso ad una determinata porta, capita invece di avere accesso
alla macchina HOST_B e magari questa ha un accesso ad HOST_C.
Si può sfruttare l’ssh per creare un “tunnel” che in pratica ci permette tramite
la macchina HOST_B di avere un accesso alla porta desiderata su HOST_C.
Supponiamo di avere un istanza di oracle sulla porta 1523 di HOST_C a cui si
vuole accedere magari tramite un tool grafico come oracle sql developer,
la sintassi per il tunnel ssh è la seguente:
ssh -L PORTA_LOCALE:HOST_C:PORTA(host e porta a cui non possiamo accedere)
utente@HOST_B(host su cui abbiamo l’accesso)
ad esempio suppinendo che vogliamo sulla porta locale 9999 il forward della
porta 1523 di HOST_C
ssh -L 9999:HOST_C:1523 user@HOST_B
ora una semplice connessione localhost:9999 viene inoltrata su 1523 di HOST_C.

Direi che è tutto abbastanza chiaro no?

Reverse Tunnelling

Cosa succede se la macchina che vogliamo controllare è dietro un NAT ? È una situazione comune per tutti gli utenti di FastWeb, che fornisce sicuramente una connessione veloce, ma a patto di stare dietro un fastidioso NAT, che permette liberamente le connessioni in uscita ma non le connessioni in ingresso.

Se vi trovate in questa situazione e avete la fortuna di essere possessori di un VPS o abbiate un gentile amico in grado di fornirvi un accesso SSH potrete usufruire della fantastica capacità di reverse tunneling di SSH.

Il reverse tunneling consiste nel far aprire la prima connessione alla macchina dietro NAT ed incapsulando tutte le connessioni successive (sia in ingresso che in uscita) su quella prima connessione.

Supponiamo di avere tre macchine:

• remotehost: la macchina dietro NAT
• middlehost: la macchina ponte
• otherhost: la macchina “esterna”

Per poter controllare remotehost dal mondo esterno è necessario che il demone SSH su middle host abbia l’opzione “GatewayPorts yes” nel suo file di configurazione, una volta accertato questo è necessario istanziare la prima connessione da remotehost a middlehost in questo modo:

fpedrini@remotehost:~$ ssh -R 10022:localhost:22 fpedrini@middlehost

In questo modo la porta 10022 di “middlehost” rimarrà in ascolto per eventuali connessioni e le reindirizzerà sulla porta 22 di “remotehost”, è appunto il nostro reverse tunnel.

È anche possibile evitare di lasciare una shell di middlehost aperta sulla macchina remota, passando le opzioni -Nf ad ssh:

fpedrini@remotehost:~$ ssh -R -Nf 10022:localhost:22 fpedrini@middlehost

In questo modo il client ssh si metterà automaticamente in background.

Una volta aperto il reverse tunnel è possibile connettersi da “otherhost” a “remotehost” usando il seguente comando:

fpedrini@otherhost:~$ ssh remotehost@middlehost -p 10022

La connessione verrà effettuata alla porta 10022 di middlehost, che provvedrà a fare il forwarding verso la porta 22 di remotehost sfruttando il tunnel.

Nel caso non fosse possibile abilitare l’opzione “GatewayPorts yes” sul demone ssh di middle host avete un’ulteriore possibilità:

fpedrini@otherhost:~$ ssh user@middlehost
Password:
user@middlehost:~ ssh remoteuser@locahost -p 10022

In questo modo vi appoggerete direttamente a middlehost, e non dovrete modificare la sua configurazione.

Autenticazione con chiavi: ssh-copy-id e ssh-agent

SSH permette di autenticarsi su host remoti in diverse maniere, le più famose sono quella con password (che è il default) e quella con chiave.

Una coppia di chiavi (una pubblica e una privata) è composta da due file che identificano in maniera univoca (e fino ad ora in maniera non replicabile a meno di bug) un utente su un determinato host.
Per autenticarsi con chiave su una macchina remota è necessario copiare su quella macchina la propria chiave pubblica, al tentativo di login, verrà controllata la corrispondenza chiave pubblica/chiave privata e nel caso il login verrà permesso.

Per generare la propria coppia di chiavi è sufficiente dare il comando ssh-keygen:

fpedrini@host:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/fpedrini/.ssh/id_rsa): [invio]
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
83:67:5b:bd:76:ae:76:ad:45:49:67:39:9a:2c:71:82 fpedrini@host
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|          .     .|
|         E o . +o|
|       .   .= +.+|
|      . S ...+ ..|
|       o +  .. . |
|        .   o ...|
|           ..o...|
|           ..oo. |
+-----------------+

In questo modo all’interno di ~/.ssh ci saranno due file: id_rsa e id_rsa.pub, il primo contiene la chiave privata, il secondo quella pubblica.

Per effettuare un login con chiave è necessario copiare il contenuto del file id_rsa.pub all’interno del file “~/.ssh/authorized_keys” della macchina remota.

Copiare la chiave pubblica su una macchina remota è un’operazione che, se eseguita male, può portare alla rimozione delle chiavi precedentemente installate.
Fortunatamente ssh-copy-id ci viene in aiuto, occupandosi da solo di copiare la chiave specificata sull’host remoto:

fpedrini@host:~$ ssh-copy-id -i id_rsa remotehost
fpedrini@remotehost's password:
Now try logging into the machine, with "ssh 'remotehost'", and check in:
 
  .ssh/authorized_keys
 
to make sure we haven't added extra keys that you weren't expecting.

D’ora in poi avremo la possibilità di entrare su remotehost usando solo la passphrase della chiave ssh.

Tuttavia non risolviamo il problema di dover inserire ad ogni login una password, che sia quella del sistema remoto o quella che sblocca la propria chiave, siamo sempre costretti ad rispondere alla tediosa (quando si tratta di connettersi a molti host) domanda “Password?”

Anche in questo caso ci viene in aiuto un tool chiamato ssh-agent, che permette di fare il caching della propria passphrase (rigorosamente in RAM) per la sessione corrente, in modo da dover inserire la propria passphrase una e una sola volta, indipendentemente dal numero di login che si faranno.

La maggior parte delle distribuzioni fa partire ssh-agent assieme alla sessione del X server, per verificare che ssh-agent sia vivo è sufficiente lanciare il comando ssh-add -L:

fpedrini@host:~$ ssh-add -L
Could not open a connection to your authentication agent.
fpedrini@host:~$ #l'agent non è attivo, lanciamolo!
fpedrini@host:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-sojRj30014/agent.30014; export SSH_AUTH_SOCK;
SSH_AGENT_PID=30015; export SSH_AGENT_PID;
echo Agent pid 30015;
fpedrini@host:~$ ssh-add -L
The agent has no identities.

Per aggiungere l’identità all’agent ssh è sufficiente lanciare

fpedrini@host:~$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/fpedrini/.ssh/id_rsa:
Identity added: /home/fpedrini/.ssh/id_rsa (/home/fpedrini/.ssh/id_rsa)
fpedrini@host:~$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwCN3/itjoIjM1yt3R78PiWm6xXpo8vn1/CCmg09o0P+KEr3QE429AfXern3IIP2l+3kpsTSyCOkBA0FoCJU2D9euhIoXyKVrB/sy4sE75rlnz0ab/YqUJWyGzXC6KFoaipgh+6rbN2FCoVF9m0mlBi4aNz4flHwsJskQ5vlMqpLO1YoB9yF7jSgLcjNT11+vbppi3AwMUVUWOx89aKuEHjL+qKNCIY1igEmSRpJ9K2OfW6otFRKp/sBcSo8U7HJjPn74I+NwAGFuf0dJXIs/3dTgcenhLCMurVrq8OWenKvHTpxkWmHGnkruhe3tvT/Jf76DcKOFxm7+a3K0uhLJ/w== /home/fpedrini/.ssh/id_rsa

Da questo momento la chiave è aggiunta ad ssh-agent.

Remote commands

Con SSH è possibile lanciare singoli comandi senza aprire una shell sulla macchina e digitare il comando voluto, permettendo così di automatizzare alcuni processi e annoiarsi un po’ di meno nell’esecuzione dei compiti tediosi di tutti i giorni.

Ad esempio se volessi lanciare il comando ‘w’ su remotehost, è sufficiente il seguente comando:

fpedrini@host:~$ ssh remotehost w
Password:
 16:05:17 up 347 days, 23:40,  0 users,  load average: 0,00, 0,02, 0,00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT

Fino a che si tratta di un comando singolo su una macchina singola, la differenza tra lanciare il comando tramite ssh e connettersi direttamente è decisamente esugua, ma nel caso si voglia lanciare lo stesso comando su una serie di macchine si può usare il seguente mini-script:

cat host_list.txt |
while read host;
do
    ssh $host w 
done

Ovviamente tutto questo funziona MOLTO meglio dopo aver installato la propria chiave sulle macchine contenute in host_list.txt.

Conclusione
Con questo secondo articolo abbiamo coperto la maggior parte delle “hidden features” (per modo di dire) di SSH, che sono spesso molto utili per alleviare la fatica della gestione di diverse macchine.

Qualsiasi utente Linux si troverà prima o poi nella condizione di dover fare login su una macchina remota, e scoprirà l’esistenza di SSH.

SSH (che poi sta per Secure SHell)è un protocollo nato per cifrare la comunicazione di dati tra i vari host di una rete e per rimpiazzare tutte le implementazioni di shell remote poco sicure proprio perchè non cifrate (vedi Telnet e RSH).

In questo articolo non esporrò l’utilizzo di base di ssh, ma alcuni suggerimenti molto utili e poco conosciuti.

ControlMaster

Questa feature di SSH permette di riutilizzare una connessione esistente per più sessioni ssh.

Al momento della prima connessione verso un host, il client ssh creerà un socket attraverso il quale passeranno tutte le sessioni aperte verso quella macchina. Il socket verrà creato nella posizione indicata dalla direttiva ControlPath.

Usando il ControlMaster, si ottengono diversi effetti benefici, ad esempio aprendo una nuova sessione su una macchina a cui si è già connessi, non sarà necessario fare di nuovo login, in quanto il client utilizzerà il socket autenticato nella sessione precedente.
Inoltre il ControlMaster permette anche l’autocompletamento dei path remoti e velocizza le operazioni di trasferimento file, come quelle effettuate tramite scp o sshfs.

Per attivare questa feature è necessario inserire nel file di configurazione del vostro client ssh (solitamente posto in ˜/.ssh/config) le due righe che seguono:

ControlMaster auto
ControlPath ~/.ssh/sock/%r@%h:%p

La prima riga attiva la feature ControlMaster in modalità ‘auto’, in questo modo all’apertura di ogni nuova connessione il client ssh si preoccuperà prima di controllare se esiste un socket da sfruttare, o in alternativa di crearlo.
I valori possibili per l’opzione ControlMaster sono:

• no: il default, nessun socket verrà creato
• ask: ad ogni tentativo di connessione, verrà chiesto se usare l’eventuale socket disponibile
• yes: il client userà il socket se è disponibile, altrimenti procederà con la connessione normale
• auto: il client userà il socket se è disponibile, altrimenti procederà con la connessione normale ed istanzierà il nuovo socket per le connessioni future
• autoask: un misto tra auto ed ask

La seconda riga specifica in quale path salvare i socket usati per le connessioni, in questo caso dentro a ~/.ssh/sock/%r@%h:%p.

La sequenza di caratteri specifica come dovrà essere chiamato il file, ecco il significato dei vari pattern:

• %r: il login name remoto
• %h: l’host remoto
• %p: la porta remota
• %l: l’hostname locale

È consigliabile inserire nel path almeno i parametri %r, %h e %p, in modo da identificare univocamente ogni socket.
A questo punto l’unica cosa che rimane da fare è creare la directory ‘sock’ all’interno di ~/.ssh/.

Connessione Persistente

Sempre sfruttando la funzionalità ControlMaster, è possibile effettuare una singola connessione persistente, che verrà messa in background, e sarà il ControlMaster per tutte le connessioni dirette ad una macchina.
Tale tecnica è utile nel caso si facciano molte connessioni di breve durata, come nel caso dell’utilizzo di tool come DistCC su SSH.
Per lanciare una connessione persistente è sufficiente lanciare il client ssh specificando le opzioni -MNf:

$ ssh -MNf fpedrini@host
fpedrini@host's password:
$

Da questo momento tutte le connessioni verso ‘host’ sfrutteranno il socket appena creato, senza dover rinegoziare ogni volta l’autenticazione.

Sequenze di Escape

Le sequenze di escape di SSH mettono il client in una modalità diversa dalla normale da cui eseguire diverse operazioni, come ad esempio eseguire il forward di una porta senza rieffettuare la connessione oppure mandare in background il client ssh per recuperarlo successivamente tramite il comando ‘fg’.

Di default le sequenze di escape vengono attivate dalla pressione della tilde (~: sulla tastiera italiana AltGr+ì) subito dopo un ritorno a capo (dato con enter), il carattere che segue la tilde specificherà l’azione da eseguire.
Per scoprire quali sono le sequenze di escape accettate è sufficiente digitare, all’interno di una sessione, la sequenza <ENTER>~?, l’output sarà simile al seguente:

fpedrini@host:~$ ~?
Supported escape sequences:
  ~.  - terminate connection (and any multiplexed sessions)
  ~B  - send a BREAK to the remote system
  ~C  - open a command line
  ~R  - Request rekey (SSH protocol 2 only)
  ~^Z - suspend ssh
  ~#  - list forwarded connections
  ~& - background ssh (when waiting for connections to terminate)
  ~?  - this message
  ~~  - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

Di particolare interesse sono, a mio avviso, le sequenze “~C” e “~#”, la prima fa accedere alla commandline di SSH per poter, ad esempio, effettuare il forward di una porta, mentre la seconda mostra tutte le connessioni aperte tra la macchina locale e quella remota:

fpedrini@host:~$ ~C
ssh> -Lport:host:hostport
fpedrini@host:~$
fpedrini@host:~$ ~#
The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
  #2 client-session (t4 r1 i0/0 o0/0 fd 10/11 cfd 9

L’altra sequenza molto interessante è “~.”, che permette di killare una connessione ssh rimasta appesa senza dover essere costretti ad aprire un altro terminale e uccidere brutalmente il client ssh.

Sock Proxying

SSH è in grado di agire anche da proxy SOCK feature molto comoda nel caso in cui le regole dei vari firewall/proxy aziendali troppo restrittivi per quanto riguarda l’accesso al Web, ma permettano il traffico via SSH all’esterno della LAN.

Per attivare tale feature è sufficiente il seguente comando:

ssh -D 1234 utente@host -C

Da questo momento, tutte le connessioni effettuate attraverso la porta 1234 del vostro pc verranno forwardate all’host remoto che le farà uscire verso internet, l’unica cosa da fare per poter navigare liberamente è configurare il vostro browser per fargli usare come proxy “localhost:1234″.
L’opzione -C invece, non ha nulla a che fare con il forwarding delle connessioni, serve solo ad attivare la compressione del protocollo SSH.

Conclusioni

Questi tre piccoli trucchetti sono solo alcune delle funzionalità più utili di SSH, ma sono forse quelli meno conosciuti e che sono più difficili da capire durante la lettura della manpage.

Per tutte le altre funzionalità, rimando comunque alla manpage e ai numerosi howto presenti su internet.

Dopo aver creato ed installato i pacchetti ssh con la patch per effettuare il chroot è tempo di creare fisicamente la gabbia sul disco ed un’utenza di test.

Creazione della gabbia
L’ambiente chroot in cui si muoverà l’utenza dopo aver effettuato il login dovrà essere composto sulla base delle limitazioni che si decideranno di applicare. Per il progetto descritto sinora è stato utilizzato uno script denominato create_chroot_env.sh (scaricabile nella sezione “allegati”) che accetta come parametro una directory nella quale è creato un ambiente base che comprende unicamente gli eseguibili necessari all’esecuzione della shell “bash”, del comando per il listing delle directory “ls” e di ssh stesso, in modo da consentire all’utente il collegamento sicuro ad altre macchine remote.

Una volta scaricato lo script è sufficiente eseguirlo passando come parametro la cartella nella quale verrà creata la gabbia chroot, /chroot:

./create_chroot_env.sh /chroot

Lo script creerà i path base, copierà gli eseguibili e le librerie ad essi associate ed infine creerà i device fondamentali al funzionamento del sistema chroot. Nulla vieta di modificarecreate_chroot_env.sh per aggiungere un programma diverso da quelli menzionati all’ambiente.

Ovviamente insieme ad ogni eseguibile aggiunto andranno aggiunte anche le librerie necessarie al suo funzionamento. Tali librerie sono ricavabili ad esempio attraverso il comando ldd. Per il comando ftp ad esempio l’esito di ldd sarà il seguente:

ldd /usr/bin/ftp
linux-gate.so.1 =>  (0xb7f74000)
libreadline.so.5 => /lib/libreadline.so.5 (0xb7f27000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7ef6000)
libc.so.6 => /lib/libc.so.6 (0xb7da9000)
libdl.so.2 => /lib/libdl.so.2 (0xb7da4000)
/lib/ld-linux.so.2 (0xb7f75000)

aggiungendo l’eseguibile /usr/bin/ftp e le librerie ricavate da ldd nella cartella lib/ dell’ambiente chroot, sarà possibile lanciare ftp dalla gabbia creata. Una nota di attenzione va posta sulle librerie ottenute con ldd che in realtà sono link simbolici. Nell’esempio appena riportato libreadline.so.5 è in realtà un link simbolico a libreadline.so.5.2, di conseguenza anche quest’ultimo file andrà copiato nella directory lib della gabbia chroot.

Creazione della prima utenza “carcerata”

Per completare il progetto manca solo la creazione di un utente con password che sia carcerato all’interno dell’ambiente chroot:

useradd -s /bin/bash -m -d /home/chroottest -g users chroottest
passwd chroottest

Il primo comando crea l’utente, lo assegna al gruppo users e crea la home directory, il secondo assegna la password per il login. La cartella “/home/chroottest” andrà spostata nella gabbia con i permessi limitati al solo utente:

mv /home/chroottest /chroot/home/
chmod 700 /chroot/home/chroottest/

Il comando useradd ha creato la riga relativa all’utente nel file di sistema /etc/passwd, tale riga deve essere presente nel file passwd dell’ambiente chroot. Tale operazione è possibile attraverso questo comando:

cat /etc/passwd | grep "^chroottest" >> /chroot/etc/passwd

A completamento della configurazione dell’utenza è necessaria la modifica della home directory all’interno del file passwd di sistema, vero nodo focale del progetto:

usermod -d /chroot/./home/chroottest  chroottest

Questa definizione della home directory permetterà al demone ssh di identificare l’utente come un prigioniero della gabbia e muoverlo prima di aprire una shell all’interno del path che segue il carattere “.”.

Il processo descritto può essere automatizzato con uno script come create_chroot_user.sh (scaricabile nella sezione “allegati”) al quale verrà passato il parametro relativo al nome utente :

./create_chroot_user.sh chroottest
Enter new UNIX password:
Retype new UNIX password:
passwd: password aggiornata correttamente

Primo login

Per verificare che le operazioni eseguite abbiano portato al risultato sperato è sufficiente effettuare una connessione ssh alla macchina con l’utente chroottest:

ssh chroottest@192.168.0.3
chroottest@192.168.0.3's password:
Last login: Thu Jan 31 19:31:18 2008 from 192.168.0.1
chroottest@debian:~$pwd
/home/chroottest

e verificare come non sia possibile retrocedere oltre la directory “/”:

chroottest@debian:~$ cd /
chroottest@debian:/$ ls
bin  dev  etc  home  lib
chroottest@debian:/$ cd ..
chroottest@debian:/$ ls
bin  dev  etc  home  lib

L’utente chroottest è prigioniero della gabbia creata e possiede un set di comandi limitato a quanto è stato stabilito in origine. Il progetto può dirsi quindi completo.

Siti ufficiali

OpenSSH
Patch CHROOT per OPENSSH

Bibliografia

Le pagine del Securing Debian Manual relative al chroot di ssh

Allegati

Script per la creazione della gabbia e dell’utente : ssh-in-chroot-scripts

La serie comprende questi articoli :

SSH in CHROOT: Una gabbia per la shell sicura (1 di 2)
SSH in CHROOT: Una gabbia per la shell sicura (2 di 2)

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Febbraio 2008.

OpenSSH è lo strumento per la connessione a sistemi remoti più utilizzato negli ambienti Linux: è sicuro, veloce e facile da installare. Un utente che si collega ad un Server attraverso ssh effettua un vero e proprio login nel sistema ed ha pieno accesso alle funzionalità che questo offre.

Su alcuni sistemi può però nascere l’esigenza di dover garantire l’accesso ssh ad utenze non privilegiate, che non abbiano cioè la possibilità di aggirarsi per il sistema. Certo una gestione oculata dei permessi di accesso ed esecuzione ai file critici può bastare per proteggersi, ma esiste una via più radicale per affrontare la questione, si tratta cioè della creazione di una gabbia che consenta all’utente l’utilizzo del sistema limitato ai comandi ed ai file definiti dall’amministratore : il chroot di ssh.

Significato di chroot e sua applicazione alla shell sicura

Il termine chroot (CHange ROOT) indica una forma di accesso diversa dallo standard, in un sottosistema generalmente contenente un numero di directory ed un set di comandi limitato.

Gli ambienti chroot vengono impiegati laddove si ha la necessità di far girare dei servizi in sicurezza in modo che se questi vengono in qualche modo violati, non consentono all’attaccante di aggirarsi per il sistema.

Il concetto di chroot applicato ad ssh si basa sulla stessa filosofia: restringere il set di file visionabili e comandi eseguibili i attraverso una gabbia, un filesystem ridotto all’essenziale.

osshChroot : la patch per openssh

Per utilizzare il chroot con ssh è necessario applicare una patch ai sorgenti originali del pacchetto openssh creata da Ricardo Cerqueira e mantenuta da James Dennis.

Tale patch modifica il comportamento in cui il demone openssh legge le informazioni dell’account dal file di sistema /etc/passwd. Infatti il codice aggiunto prevede che se nella home directory dell’utente che vuole effettuare il login esiste un carattere “.” (punto), allora prima di proseguire con la direzione della console alla homedir viene invocato il comando chroot sulla directory precedente il punto.

Questo significa, ad esempio, che se è stato costruito un ambiente chroot nella directory /chroot ed esiste un utente foo la cui homedir è /chroot/./home/foo, questo effettuerà il login nell’ambiente chroot creato sotto /chroot che corrisponderà per l’utente a / e la directory in cui si troverà sarà /home/foo.

Grazie a questa funzionalità sarà semplice separare utenti privilegiati da utenti “carcerati” all’interno della gabbia /chroot.

Patching, compilazione e creazione del pacchetto openssh

La procedura descritta si riferisce alla compilazione del pacchetto openssh in Debian Etch 4.0.

Per predisporre il sistema a compilare sorgenti e generare pacchetti è necessario installare i due pacchetti (e le dipendenze ad essi correlate) build-essential e devscripts:

apt-get install build-essential devscripts

Il sistema è pronto a compilare e produrre pacchetti, una volta reperiti i sorgenti di openssh attraverso il comando apt-get:

apt-get source openssh

E’ sufficiente scaricare la patch osshChroot tramite wget :

wget http://chrootssh.sourceforge.net/download/osshChroot-4.2p1.diff

Ed applicarla ai sorgenti:

cd openssh-4.3p2/
patch -p1 < ../osshChroot-4.2p1.diff

quindi attraverso la modifica del file debian/changelog o attraverso il comando debchange inseriamo le note per questo pacchetto, che riguardano essenzialmente la patch per il chroot e che hanno questa forma:

openssh (1:4.3p2-9chroot) unstable; urgency=high
 
[ RaSca ]
 
* chroot patch
 
-- root <root@debian.testlan.local>  Wed,  6 Feb 2008 16:00:08 +0100

prima di lanciare la compilazione dei sorgenti andranno soddisfatte tutte le dipendenze delle librerie del pacchetto openssh. Attraverso l’opzione build-dep del comando apt-get si può automatizzare questo processo:

apt-get build-dep openssh

E’ possibile quindi avviare la compilazione e generazione dei pacchetti attraverso il comando debuild:

debuild

I pacchetti verranno generati nella directory sottostante quella dei sorgenti:

cd ..
ls -1 *.deb
openssh-client_4.3p2-9_i386.deb
openssh-server_4.3p2-9_i386.deb
ssh_4.3p2-9_all.deb
ssh-askpass-gnome_4.3p2-9_i386.deb
ssh-krb5_4.3p2-9_all.deb

e potranno essere installati nel sistema attraverso il comando dpkg :

dpkg -i ssh_4.3p2-9chroot_all.deb openssh-client_4.3p2-9chroot_i386.deb openssh-server_4.3p2-9chroot_i386.deb

Nel prossimo articolo verrà analizzata la creazione dell’ambiente chroot e della prima utenza che vi effettuerà il login.

La serie comprende questi articoli :

SSH in CHROOT: Una gabbia per la shell sicura (1 di 2)
SSH in CHROOT: Una gabbia per la shell sicura (2 di 2)

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Febbraio 2008.