9.2. Accesso remoto

È essenziale per un amministratore essere in grado di connettersi ad un computer remoto. I server, confinati nella propria stanza, sono raramente dotati di tastiere e monitor permanenti, ma sono connessi alla rete.

9.2.1. Accesso remoto: `telnet`

Il protocollo telnet, il più antico servizio di login remoto, è il peggiore in termini di sicurezza. I dati e le password vengono inviate in chiaro: proprio così, non criptati, lasciandoli vulnerabili ad essere spiati da parte di tutti gli utenti della rete. Se necessario, fare attenzione a rimuovere questo servizio obsoleto, che non è più installato in modo predefinito:

# apt-get remove telnetd

Vi è, tuttavia, un adattamento che consente di correggere i suoi difetti più invalidanti; utilizza il protocollo SSL (Secure Socket Layer) per autenticare il partner e cifrare le comunicazioni. I pacchetti telnetd-ssl e telnet-ssl forniscono, rispettivamente, il software server e client.

VOCABOLARIO Autenticazione, cifratura

Quando è necessario dare ad un client la possibilità di condurre o attivare azioni su un server, la sicurezza è importante. È necessario verificare l'identità del client, questa è l'autenticazione. Questa identità di solito consiste in una password che deve essere tenuta segreta, o qualsiasi altro client potrebbe ottenere la password. Questo è lo scopo della cifratura, che è una forma di codifica che consente a due sistemi di comunicare informazioni riservate su un canale pubblico, proteggendole dall'essere leggibili ad altri.

L'autenticazione e la cifratura sono spesso menzionate insieme, sia perché esse sono spesso usate insieme, sia perché sono di solito implementate con simili concetti matematici.

9.2.2. Accesso remoto sicuro: SSH

Il protocollo SSH (Secure SHell), contrariamente a telnet, è stato progettato tenendo a mente sicurezza ed affidabilità. Le connessioni con SSH sono sicure: il partner è autenticato e tutti gli scambi di dati sono cifrati.

SSH offre anche due servizi di trasferimento di file. scp è uno strumento a riga di comando che può essere utilizzato come cp, tranne che qualsiasi percorso a un altro computer è fatto precedere dal nome della macchina, seguito da due punti («:»).

$ scp file macchina:/tmp/

sftp è un comando interattivo, simile a ftp. In una singola sessione, sftp è in grado di trasferire più file, ed è possibile usarlo per manipolare i file remoti (eliminare, rinominare, modificare i permessi, ecc.).

Debian utilizza OpenSSH, una versione libera di SSH, mantenuta dal progetto OpenBSD (un sistema operativo libero basato sul kernel BSD, incentrato sulla sicurezza) e fork del software originale SSH sviluppato dalla società finlandese SSH Communications Security Corp. Questa società ha inizialmente sviluppato SSH come software libero, ma alla fine ha deciso di continuare il suo sviluppo sotto una licenza proprietaria. Il progetto OpenBSD quindi ha creato OpenSSH per mantenere una versione free di SSH.

FONDAMENTALIFork

Un «fork», in materia di software, significa un nuovo progetto che inizia come un clone di un progetto esistente, e che compete con esso. Da lì in poi, entrambi i software di solito divergono rapidamente in termini di nuovi sviluppi. Un fork è spesso il risultato di disaccordi all'interno del team di sviluppo.

L'opzione di fare il fork di un progetto è una diretta conseguenza della natura stessa del software libero, un fork è un evento sano quando permette la continuazione di un progetto come software libero (per esempio in caso di cambiamenti nella licenza). Un fork derivante da divergenze tecniche o personali è spesso uno spreco di risorse umane; un'altra soluzione sarebbe preferibile. Fusioni di due progetti che in precedenza hanno attraversato un fork non sono inedite.

Da Etch, OpenSSH è diviso in due pacchetti. La parte client è nel pacchetto openssh-client, mentre il server è nel pacchetto openssh-server. Il metapacchetto ssh dipende da entrambe le parti e facilita l'installazione di entrambi (apt-get install ssh).

APPROFONDIMENTO Accelerazione hardware per SSH

Alcuni hardware forniscono il supporto nativo di funzioni matematiche utilizzate per la cifratura, che sono in grado di accelerare i calcoli necessari, aumentando così le prestazioni di alcuni strumenti (e alleggerendo il carico sul processore principale). Questi strumenti comprendono in particolare la libreria OpenSSL, che è a sua volta utilizzata da OpenSSH.

Anche se un progetto per la standardizzazione dei driver è in corso (in particolare a livello di kernel), la varietà di hardware è tuttora gestita inmodo non equo e omogeneo. Ad esempio, il sistema Padlock incluso nel processore Via C3 è solo parzialmente supportato. Sebbene il kernel Linux offra vari algoritmi di cifratura, la libreria OpenSSL 0.9.8 in Squeeze gestisce solo la delegazione della cifratura AES all'hardware dedicato a questo scopo, ma non degli algoritmi SHA: è necessario ricompilarla con una patch.

→ http://www.logix.cz/michal/devel/padlock/

9.2.2.1. Autenticazione basata su chiave

Ogni volta che qualcuno si collega tramite SSH il server remoto richiede una password per autenticare l'utente. Questo può essere problematico se si vuole automatizzare una connessione, o se si utilizza uno strumento che richiede collegamenti frequenti su SSH. È per questo che SSH offre un sistema di autenticazione basato su chiave.

L'utente genera una coppia di chiavi sulla macchina client con ssh-keygen -t rsa; la chiave pubblica è conservata in ~/.ssh/id_rsa.pub, mentre la corrispondente chiave privata è conservata in ~/.ssh/id_rsa. Successivamente l'utente usa ssh-copy-id server per aggiungere la propria chiave pubblica nel file ~/.ssh/authorized_keys presente sul server. Se la chiave privata non è stata protetta con una «passphrase» al momento della sua creazione, tutti gli accessi successivi sul server funzioneranno senza una password. In caso contrario, la chiave privata dovrà essere decifrata ogni volta inserendo la «passphrase». Fortunatamente, ssh-agent ci permette di mantenere in memoria le chiavi private in modo da non dover reinserire continuamente la password. Per questo, è sufficiente utilizzare ssh-add (una volta per ogni sessione di lavoro), a condizione che la sessione sia già associata ad un'istanza funzionante di ssh-agent. Debian la attiva come impostazione predefinita nelle sessioni grafiche, ma è possibile disattivare questo comportamento cambiando /etc/X11/Xsession.options. Per una sessione della console, è possibile avviarla manualmente tramite eval $(ssh-agent).

SICUREZZA Protezione della chiave privata

Chi ha la chiave privata può effettuare il login sull'account così configurato. Per questo motivo l'accesso alla chiave privata viene protetto da una "passphrase". Chi viene in possesso di una copia di una chiave privata (ad esempio, ~/.ssh/id_rsa) deve comunque sapere questa frase per essere in grado di utilizzarla. Questa protezione aggiuntiva non è, tuttavia, inespugnabile, e se si pensa che questo file è stato compromesso, è meglio disabilitare la chiave sui computer in cui è stata installata (rimuovendola dal file authorized_keys) e sostituendola con una nuova chiave generata.

CULTURA Problemi di OpenSSL in Debian Etch

La libreria OpenSSL, come inizialmente fornita in Debian Etch, aveva un problema serio nel suo generatore di numeri casuali (RNG). Infatti, il manutentore Debian ha fatto un cambiamento in modo che la libreria non fosse la fonte di avvertimenti per i programmi che la utilizzavano e che potevano essere analizzati con strumenti di test di memoria, come ad esempio valgrind. Sfortunatamente, questo cambiamento comportava anche che la RNG impiegasse una sola fonte di entropia, corrispondente al numero di processo (PID) i cui possibili 32.000 valori non offrono abbastanza casualità.

→ http://www.debian.org/security/2008/dsa-1571

Nello specifico, quando OpenSSL veniva impiegato per generare una chiave, produceva sempre una chiave all'interno di un insieme noto di centinaia di migliaia di chiavi (32.000 moltiplicato per un piccolo numero di lunghezze di chiave). Questo riguardava le chiavi SSH, le chiavi SSL ed i certificati X.509 utilizzati da numerose applicazioni, come ad esempio OpenVPN. Un cracker doveva quindi solo provare tutte le chiavi per ottenere un accesso non autorizzato. Per ridurre l'impatto del problema, il demone SSH è stato modificato in modo da rifiutare le chiavi problematiche che sono elencate nei pacchetti openssh-blacklist e openssh-blacklist-extra. Inoltre, il comando ssh-vulnkey consente l'identificazione delle chiavi eventualmente compromesse nel sistema.

Un'analisi più approfondita di questo incidente mette in luce che è il risultato di molteplici (piccoli) problemi, sia a livello del progetto OpenSSL, così come con il manutentore del pacchetto Debian. Una libreria ampiamente utilizzata come OpenSSL non dovrebbe, senza modifiche, generare avvisi quando viene testata da valgrind. Inoltre, il codice (in particolare quelle parti tanto delicate come la RNG) dovrebbe essere meglio commentato per evitare tali errori. Il manutentore di Debian, da parte sua, volendo un'approvazione delle sue modifiche dagli sviluppatori di OpenSSL, ha semplicemente spiegato le sue modifiche senza fornire loro la corrispondente patch da revisionare. Egli, inoltre, non si è chiaramente identificato come il manutentore del pacchetto Debian corrispondente. Infine, nelle sue scelte di manutenzione, non ha chiaramente documentato le modifiche apportate al codice originale, tutte le modifiche sono effettivamente memorizzate in un repository Subversion, ma finirono tutte concentrate in una singola patch durante la creazione del pacchetto sorgente.

In queste condizioni è difficile trovare le misure correttive per evitare il ripetersi di questi incidenti. La lezione da trarre è che ogni divergenza che Debian introduce nel software originale deve essere giustificata, documentata, presentata nel progetto principale, quando possibile, e ampiamente pubblicizzata. È in base a questa prospettiva che sono stati sviluppati il nuovo formato dei pacchetti sorgente («3.0 (quilt)») e il sistema di tracciamento delle patch di Debian.

→ http://patch-tracker.debian.org

9.2.2.2. Utilizzo di applicazioni X11 remote

Il protocollo SSH consente la trasmissione dei dati grafici (sessione «X11», dal nome del più diffuso sistema grafico in Unix), il server mantiene un canale dedicato per tali dati. In particolare, un programma grafico eseguito da remoto può essere visualizzato sul server X.org dello schermo locale e l'intera sessione (ingresso e visualizzazione) sarà sicura. Poiché questa funzionalità consente alle applicazioni remote di interferire con il sistema locale, è disabilitata in modo predefinito. È possibile abilitare questa funzionalità specificando X11Forwarding yes nel file di configurazione del server (/etc/ssh/sshd_config). Infine, l'utente deve anche richiederla aggiungendo l'opzione -X alla riga di comando di ssh.

9.2.2.3. Creazione di tunnel cifrati con il port forwarding

Le opzioni -R e -L consentono a ssh di creare «tunnel cifrati» tra due macchine, inoltrando in modo sicuro una porta TCP locale (vedere il riquadro FONDAMENTALI TCP/UDP) ad un computer remoto o viceversa.

VOCABOLARIO Tunnel

Internet, e la maggior parte delle LAN che vi sono collegate, opera in modalità a pacchetto e non in modalità connessa, il che significa che un pacchetto emesso da un computer verso un altro verrà fermato in vari router intermedi per trovare la strada verso la destinazione. È ancora possibile simulare il funzionamento in collegamento in cui il flusso è racchiuso in pacchetti IP normali. Questi pacchetti seguono il loro percorso abituale, ma il flusso viene ricostruito invariato a destinazione. Questo viene chiamato «tunnel», analogo ad una galleria stradale in cui i veicoli viaggiano direttamente dall'ingresso (input) all'uscita (output) senza incontrare alcun incrocio, al contrario di un percorso sulla superficie che comporterebbe incroci e cambiamenti di direzione.

È possibile utilizzare questa opportunità per aggiungere la cifratura al tunnel: il flusso che scorre attraverso di esso è quindi irriconoscibile dall'esterno, ma viene riportato alla forma decifrata all'uscita del tunnel.

ssh -L 8000:server:25 intermediario stabilisce una sessione SSH con l'host intermediario e ascolta sulla porta locale 8000 (vedere Figura 9.2, «Inoltro di una porta locale con SSH»). Per ogni connessione stabilita su questa porta, ssh avvierà una connessione dal computer intermediario alla porta 25 sul server legando insieme entrambe le connessioni.

Anche ssh -R 8000:server:25 intermediario stabilisce una sessione SSH al computer intermediario, ma è in questa macchina che ssh è in ascolto sulla porta 8000 (vedere Figura 9.3, «Inoltro di una porta remota con SSH»). Ogni connessione stabilita sulla porta farà sì che ssh aprirà una connessione dalla macchina locale alla porta 25 del server legando insieme entrambe le connessioni.

In entrambi i casi, le connessioni sono realizzate sulla porta 25 dell'host server, e passano attraverso il tunnel SSH stabilito tra la macchina locale e la macchina intermediario. Nel primo caso, l'ingresso del tunnel è locale sulla porta 8000, ed i dati si muovono verso la macchina intermediario prima di essere diretti al server sulla rete «pubblica». Nel secondo caso, l'ingresso e l'uscita del tunnel sono invertiti, l'ingresso è la porta 8000 sulla macchina intermediario, l'uscita è sulla macchina locale, ed i dati vengono poi indirizzati al server. In pratica, il server è di solito o la macchina locale o l'intermediario. In questo modo SSH rende sicura la connessione da un'estremità all'altra.

Figura 9.2. Inoltro di una porta locale con SSH

Figura 9.3. Inoltro di una porta remota con SSH

9.2.3. Utilizzo di desktop remoti grafici

VNC (Virtual Network Computing) permette l'accesso remoto a desktop grafici.

Questo strumento è usato soprattutto per l'assistenza tecnica; l'amministratore può visualizzare gli errori che l'utente si trova ad affrontare, e mostrargli la cosa corretta da fare, senza dover essere fisicamente presente.

In primo luogo, l'utente deve autorizzare la condivisione della sessione. Gli ambienti desktop grafici GNOME e KDE includono, rispettivamente, vino e krfb, che forniscono una interfaccia grafica che permette di condividere una sessione esistente tramite VNC (che si trova, rispettivamente, nei menu in Sistema → Preferenze → Desktop remoto e K → Internet → Condivisione del desktop). Per gli altri ambienti desktop grafici, il comando x11vnc (dal pacchetto Debian con lo stesso nome) serve allo stesso scopo, è possibile renderlo disponibile per l'utente con un'icona esplicita.

Quando la sessione grafica è messa a disposizione da VNC, l'amministratore deve connettersi con un client VNC. GNOME ha vinagre e tsclient a questo scopo, mentre KDE include krdc (nel menu K → Internet → Client per connessione a desktop remoto). Ci sono altri client VNC che utilizzano la riga di comando, come ad esempio xvnc4viewer nel pacchetto Debian con lo stesso nome. Una volta connesso, l'amministratore può vedere cosa sta succedendo, lavorare sulla macchina in remoto, e mostrare all'utente come procedere.

SICUREZZA VNC su SSH

Se si desidera connettersi a VNC, e non si desidera che i dati siano trasmessi in chiaro sulla rete, è possibile incapsulare i dati in un tunnel SSH (vedere Sezione 9.2.2.3, «Creazione di tunnel cifrati con il port forwarding»). È sufficiente sapere che VNC usa la porta 5900 per impostazione predefinita per il primo schermo (chiamato «localhost: 0»), 5901 per il secondo (chiamato «localhost: 1»), ecc.

Il comando ssh -L localhost:5901:localhost:5900 -N -T macchina crea un tunnel tra porta locale 5901 nell'interfaccia localhost e la porta 5900 della macchina host. Il primo «localhost» limita SSH in modo che ascolti solo sull'interfaccia della macchina locale. Il secondo «localhost» indica l'interfaccia sul computer remoto che riceverà il traffico di rete in entrata su «localhost:5901». Così vncviewer localhost:1 collegherà il client VNC allo schermo remoto, anche se si indica il nome della macchina locale.

Quando la sessione VNC è chiusa, bisogna ricordarsi di chiudere il tunnel, uscendo anche dalla corrispondente sessione SSH.

VNC funziona anche per utenti mobili, o dirigenti di società, che a volte hanno bisogno di effettuare il login da casa per accedere a un desktop remoto simile a quello che utilizzano sul posto di lavoro. La configurazione di tale servizio è più complicata: per prima cosa si installa il pacchetto vnc4server, e si modifica la configurazione del display manager in modo da accettare richieste XDMCP query (per gdm, questa operazione può essere fatta graficamente attraverso il menu Sistema → Amministrazione → Schermata di accesso e quindi la scheda «Remoto»; si noti che questo vale solo per gdm e non per gdm3, che è la versione installata in Squeeze). Infine avviare il server VNC con inetd in modo che una sessione venga avviata automaticamente quando un utente tenta di effettuare l'accesso. Ad esempio, si può aggiungere questa riga a /etc/inetd.conf:

5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none

Deviare le connessioni in entrata al display manager risolve il problema dell'autenticazione, in quanto solo gli utenti con account locali supereranno la schermata di accesso di gdm (o l'equivalente di kdm, xdm, ecc.). Poiché questo sistema consente più connessioni simultanee senza alcun problema (se il server è abbastanza potente), può anche essere utilizzato per fornire desktop completi per gli utenti mobili (o per sistemi desktop meno potenti, configurati come thin client). Gli utenti devono semplicemente accedere allo schermo del server con vncviewer server:50, perché la porta utilizzata è 5950.