I tre sistemi messi sotto torchio sono stati un VAIO VGN-TZ37CN con Ubuntu 7.10, un Fujitsu U810 con Vista Ultimate SP1 e un MacBook Air con OSX 10.5.2.

Le regole del gioco

La sfida prevedeva di collegare il proprio notebook via cavo ethernet cross al notebook sotto attacco, e ogni partecipante aveva diritto a sessioni di 30 minuti per cercare di sfruttare una falla 0day per leggere un file all’interno del sistema. Era divisa in tre giornate: il primo giorno si poteva attaccare solo il sistema con installazione base, patchato alle ultime versioni, via rete. Il secondo giorno sono entrate in gioco le applicazioni base per Internet: browser, e-mail e IM. Il terzo giorno sono state installate applicazioni di terze parti.

Il primo giorno hanno retto tutti e tre.

I caduti in battaglia

Il secondo giorno il MacBook ha ceduto in soli 2 minuti. L’hacker ha sfruttato una falla in Safari ed è riuscito a leggere il contenuto del file bersaglio. La falla non è stata rilasciata al pubblico, ma comunicata ad Apple perché venga corretta, e l’hacker, o meglio GLI hacker (Charlie Miller, Jake Honoroff, e Mark Daniel) hanno ricevuto il premio: lo stesso MacBook Air e 10.000 $.

Il terzo giorno ha ceduto anche Vista, nonostante il nuovissimo SP1 installato. L’hacker,  Shane Macaulay, ha sfruttato un buco di Flash, appena installato tra le applicazioni di terze parti, per leggere il file bersaglio. Anche in questo caso il bug è stato segnalato ad Adobe e non rilasciato al pubblico. Shane si porta a casa il Fujitsu e 5.000 $ di premio.

E Linux?

Ha resistito a tutti gli attacchi, naturalmente.

Le regole complete del concorso non sono state pubblicate, purtroppo, quindi è difficile fare una valutazione del risultato. Per esempio: il file era nella home dell’utente o in una cartella di sistema. Ed apparteneva all’utente o all’amministratore? I permessi di accesso come erano impostati? Quali software sono stati testati?

Nel caso il file fosse nella home dell’utente, le falle sarebbero sì gravi, ma non gravissime, e completamente “a carico” dei produttori del software bucato (OK, Apple per Safari, ma Adobe per Flash), mentre se fosse stato un file di sistema, il problema sia di OSX che di Vista sarebbe veramente grave, perché avrebbe permesso a un software lato utente di leggere un file di sistema senza chiedere conferme di nessun tipo. Sarebbe una falla grave nel Sistema Operativo.

SSH continua a stupirmi ogni giorno. Sapevo che permetteva di trasferire file, tramite protocollo SFTP, come se si trattasse si un FTP (e con Nautilus si possono vedere i server remoti come fossero cartelle locali). Sapevo che ci si potesse forwardare X attraverso, anche se non ho ancora mai provato. Sapevo che ci si potevano fare tunnel generici. Ieri ho scoperto che lo si può usare come proxy SOCKS verso un proprio server, in modo da navigare “protetti” anche da reti pubbliche.

Oggi ho scoperto che lo si può usare direttamente da rsync senza bisogno di configurare nulla sul server. A patto di avere rsync installato sul server, naturalmente, ma non è necessario configurarlo in modalità daemon, né definire le “share” da esportare o le protezioni da attuare. Una porta aperta in meno! Vediamo come fare…

Uso di base

Per un uso normale, con autenticazione tramite password, si può usare direttamente rsync, aggiungendo un solo parametro, oltre ai soliti utente, nome server, cartella remota e cartella locale:

 rsync -ravz -e ssh utenteremoto@serverremoto:/path/alla/dir/remota/ /path/alla/dir/locale/

Fatto. Non serve altro. Le opzioni che ho usato sono quelle classiche: a per mantenere i permessi, r per fare una copia ricorsiva, v per aumentare la “verbosità” dell’operazione, z per comprimere i file in transito (utile se si fanno backup di log non compressi o di file di testo). L’opzione -e è quella che ci interessa qui: specifica la shell remota da utilizzare per la copia. rsync richiamerà automaticamente il suo omologo sul server remoto e gestirà automaticamente le differenze tra i file. In questo caso specifichiamo ssh come shell remota.

Seguono il nome utente (sul server), il nome del server stesso (o il suo IP) e il path alla directory che vogliamo copiare, raggruppati. Quindi il path locale dove vogliamo copiare i file. Sarà sufficiente invertire questi due componenti (prima il locale e poi il remoto) per caricare i file sul server, invece di scaricarli. Rimangono validi tutti gli altri switch di rsync (cancellazione dei file, tipi di controllo per determinare l’aggiornamento, ecc.)

Naturalmente questo sistema ci chiederà la password dell’utente sul server remoto ogni volta che faremo la sincronizzazione, quindi è poco adatto ad essere usato, per esempio, con cron.

Autenticazione tramite chiavi pubblica e privata

Per questo ci viene in aiuto ssh. Possiamo generare una coppia di chiavi, una pubblica e una privata, da utilizzare per autenticarci sul server senza bisogno della password. Ecco il comando per generarla:

ssh-keygen -t dsa -b 1024 -f chiave-ssh

Questo comando crea una chiave DSA a 1024 bit e la memorizza in due file: la parte privata nel file “chiave-ssh”, e quella pubblica in “chiave-ssh.pub”.

La chiave privata va tenuta al sicuro, non deve essere vista da nessuno. Assicuratevi che abbia permessi 600 (rw——-) e come proprietario l’utente stesso. Copiatela in ~/.ssh (la cartella .ssh nella home dell’utente), e assicuratevi che la stessa cartella .ssh abbia permessi 700 (rwx——).

La chiave pubblica, invece, mandatela sul server in qualche modo. Io ho attivato SFTP, quindi mi basta un

scp chiave-ssh.pub utenteremoto@serverremoto:~/

Ora collegatevi al serverremoto, e aggiungete questa chiave al portachiavi, che si chiama authorized_keys e si trova, sorpresa sorpresa, nella directory .ssh

cat chiave-ssh.pub >>.ssh/authorized_keys

Poi potete cancellare il file con la chiave pubblica, tanto lo avete appena accodato al portachiavi (attenzione a non fare il redirect con un solo >, altrimenti cancellerete eventuali altre chiavi pubbliche conservate lì dentro).

Assicuratevi che anche questo file (authorized_keys) abbia permessi 600.

Abbiamo concluso la fase preparatoria, ora potrete usare la chiave pubblica sia per loggarvi su quel server via ssh, sia per fare SFTP, sia con rsync. Per esempio, per collegarvi:

ssh -i .ssh/chiave-ssh utenteremoto@serverremoto

Mentre per usare rsync dovrete ricordare di racchiudere la linea di comando di ssh tra virgolette:

rsync -e "ssh -i .ssh/chiave-ssh" utenteremoto@serverremoto:/dir/da/copiare /dir/locale/

Una piccola dritta

Il sistema descritto sopra è ottimo per tenere le chiavi separate tra diversi server. In pratica potete avere una coppia di chiavi (pubblica e privata) per ogni server al quale dovete collegarvi.

Ma potete anche semplificare il processo e usare la stessa coppia di chiavi per tutti i server. In questo caso generate le chiavi e memorizzate la parte pubblica su tutti i server come ho scritto sopra. In locale, invece, copiate la chiave privata nella directory .ssh ma chiamatela “id_dsa” (per le chiavi DSA) o “id_rsa” (per le chiavi RSA):

cp chiave-ssh .ssh/id_dsa

Assicuratevi sempre che abbia permessi 600.

Così facendo non sarà più necessario specificare la parte “-i nomechiaveprivata”, perché ssh se la andrà a cercare direttamente.

Possibili problemi

Ricordate che se perdete la chiave privata dovrete entrare col solito sistema a password, ma se qualcuno ve la ruba potrà entrare su tutti i server che la utilizzano senza bisogno di altre autorizzazioni! In questo caso conviene fare immediatamente il giro di tutti i server e rimuovere la chiave pubblica dal file authorized_keys, e quindi rigenerare una nuova coppia di chiavi (sono sempre diverse).

Se il login automatico non funziona, verificate sul server che non siano disabilitati i login con chiave pubblica (di solito nel file /etc/ssh/sshd_config):

RSAAuthentication     yes
PubkeyAuthentication  yes
AuthorizedKeysFile    .ssh/authorized_keys

Consiglio di usare l’autenticazione DSA, e possibilmente di disabilitare il protocollo SSH1 e lasciare attivo solo SSH2, molto più sicuro.

Se ancora non funziona niente, aumentate il logging di ssh sul server tramite il parametro LogLevel (potete impostarlo a DEBUG per avere molto output, o a DEBUG3 per averne anche troppo).