Panoramica su SSH
L’esigenza di poter disporre di un servizio di accesso remoto e trasferimento file sicuri, su una infrastruttura di rete intrinsecamente insicura quale l’Internet pubblica, ha portato alla definizione di un nuovo protocollo ufficiale denominato SSH (Secure SHell).
Il protocollo è costituito da 3 componenti principali:
- Transport Layer Protocol (generalmente indicato come SSH_TRANS), responsabile della fase di autenticazione del server e dell’introduzione di funzioni crittografiche per garantire integrità e riservatezza ai dati scambiati;
- User Authentication Protocol (generalmente indicato come SSH_USERAUTH), responsabile della fase di autenticazione del client;
- Connection Protocol (indicato come SSH_CONN), cui è delegata la responsabilità di multiplare più canali logici (o sessioni) su un unico tunnel crittato.
SSH prevede che tra due client e server venga preliminarmente instaurato un tunnel a livello SSH_TRANS.
All’interno di questo tunnel vengono veicolati tanto i messaggi per l’autenticazione del client quanto quelli contenenti le informazioni scambiate tra le applicazioni finali.
La porta servizio riservata al protocollo SSH è la 22/tcp.
L’introduzione di SSH comporta l’aggiunta di un ulteriore livello di incapsulamento per i dati scambiati tra le applicazioni.
Tutti i messaggi SSH posseggono il seguente formato:
- il campo Data Length (32bit) riporta la lunghezza (in byte) del resto del messaggio SSH, escluso il campo MAC che si trova in coda.
- La presenza di un campo Random PAD di lunghezza variabile rende necessaria la presenza di un secondo campo, Pad Length (8bit), che ne stabilisce la dimensione.
- Il campo Random PAD segue il campo dati vero e proprio e può avere lunghezza massima di 255 byte.
La scelta della lunghezza del campo è fatta rispettando la regola che l’intero messaggio (escluso il campo MAC) deve essere scomponibile esattamente in blocchi da 8 byte.
La codifica del campo dati e della produzione del MAC può essere ottenuta secondo numerosi algoritmi crittografici alternativi che vengono negoziati al momento dell’instaurazione di un tunnel SSH_TRANS.
La versione 2 di SSH supporta gli algoritmi di seguito elencati:
Per la riservatezza delle informazioni presenti nel campo dati sono disponibili 3-DES, Blowfish, Twofish, AES, ARC4, Idea, Cast-128 e Serpent, utilizzati in accordo allo schema di codifica a blocchi CBC.
Per assicurare l’integrità dei dati scambiati, SSH si avvale di uno schema HMAC con possibilità di utilizzo, quali funzioni elementari di digest, sia di MD5 sia di SHA.
Lo scambio dellechiavi comuni avviene secondo lo schema Diffie-Hellman e per la segnatura dei messaggi possono essere negoziati sia l’algoritmo DSA che quello RSA.
Le chiavi pubbliche utilizzate all’interno del protocollo possono essere anche veicolate sotto forma di certificati X509v3.
Il protocollo SSH stabilisce anche la lunghezza minima (16 byte + MAC) e massima (35000 byte) del messaggio prodotto a livello SSH_TRANS.
Una volta instaurata una connessione SSH tra client e server, e aver autenticato con successo il server cui si è connessi, entra in azione il protocollo SSH_USERAUTH.
Lo schema previsto per l’autenticazione del client si compone di due messaggi.
Il primo messaggio (Auth_request) viene inviato dal client al server e contiene indicazioni dello username, del servizio richiesto e del metodo di autenticazione che si intende utilizzare.
Il resto del messaggio dipende dal metodo indicato.
Sono al momento implementati tre metodi:
- publickey: per produrre la segnatura che viene utilizzata per testare l’identità del richiedente si utilizza la chiave privata del singolo utente, usando come testo inchiaro l’intero messaggio Auth_request;
- password: il client invia semplicemente la password dell’utente in chiaro all’interno del messaggio;
- hostbased: per produrre la segnatura che viene utilizzata per testare l’identità del richiedente si utilizza la chiave privata della stazione che ospita il client.
Nonostante sia il client a inviare il primo messaggio, è il server ad avere il completo controllo sul processo di autenticazione.
Il client infatti può solo scegliere un metodo di autenticazione tra quelli proposti dal server per la connessione SSH.
Se le credenziali utente sono verificate, il server risponde con un secondo messaggio (Auth_response) stabilendo l’esito della fase di autenticazione del client.
Sono ammesse due sole repliche da parte del server: Success o Failure.
Struttura e Parametri SSH
Una volta completata la fase di autenticazione del client è possibile passare all’apertura delle sessioni SSH per la trasmissione dei dati tra gli applicativi finali.
I parametri scambiati durante l’apertura di una nuova sessione SSH dipendono dalla natura del protocollo applicativo che si prevede di incapsulare con SSH.
La componente SSH_CONN prevede la possibilità di negoziare sessioni diverse per veicolare traffico di tipo interattivo, emulazione di terminale virtuale, esecuzione remota comandi e/o per trasferimento di file.
Tutte le sessioni di SSH, indipendentemente dalla loro specializzazione, vengono denominate channel.
Più canali possono essere multiplati su una singola connessione SSH.
Ciascun channel è contraddistinto da un identificativo univoco e possiede un meccanismo per il controllo del flusso indipendente dagli altri.
Una volta aperto un SSH channel non è ancora possibile utilizzarlo per veicolare i dati degli applicativi se non possiede una finestra di trasmissione permessa (allowed windows) di valore diverso da 0.
Il processo di apertura/utilizzo/chiusura di una sessione SSH prevede lo scambio di vari messaggi.
Il primo messaggio (SSH_MSG_CHANNEL_OPEN), stabilisce il tipo di canale di cui si richiede l’apertura, l’identificativo univoco associato al canale, il valore iniziale della finestra di trasmissione, la lunghezza massima del pacchetto.
Alla ricezione di un simile messaggio l’altro partecipante risponde con un messaggio di conferma o di fallimento (rispettivamente SSH_MSG_CHANNEL_OPEN_CONFIRMATION o SSH_MSG_CHANNEL OPEN_FAILURE).
Una volta aperto un SSH channel questo deve essere specializzato per il tipo di servizio che si intende veicolare attraverso la sessione.
La specializzazione avviene tramite invio di messaggi denominati SSH_MSG_CHANNEL_REQUEST.
Sono al momento definiti i seguenti tipi di Request:
- pty-req (per la richiesta di emulazione di pseudo terminale);
- x11-req (per emulazione terminale X11);
- env (per l’invio di variabili di ambiente al sistema remoto);
- shell (per aprire una login shell sul sistema remoto);
- exec (per mandare in esecuzione un generico comando sul sistema remoto);
- subsystem (per mandare in esecuzione un sottosistema predefinito di comandi, definiti all’interno dell’architettura SSH; al momento è stato definito il subsystem “sftp” per fornitura di un servizio di File Transfer sicuro, che emula formalmente i comandi e le funzioni definite dal protocollo FTP).
Il valore iniziale della finestra di trasmissione deve essere diverso da zero per poter veicolare dati.
Una volta esaurita la finestra di trasmissione è possibile aggiustarne il valore corrente, sommando al valore residuo N byte secondo quanto indicato in un messaggio denominato SSH_MSG_CHANNEL_WINDOW_ADJUST.
Tutti i dati scambiati sono incapsulati in un apposito messaggio SSH_MSGCHANNEL_DATA che riporta l’identificativo univoco del “channel” a cui i dati si riferiscono.
In questo modo è sempre possibile stabilire la sessione SSH di appartenenza anche in presenza di molteplici sessioni SSH contemporaneamente attive sulla stessa connessione.
Una volta terminata la trasmissione dati su una specifica sessione SSH, una entità può inviare un messaggio SSH_MSG_CHANNEL_EOF dichiarando conclusa la trasmissione.
A questo messaggio non è prevista replica e di fatto la ricezione di un simile messaggio non impedisce alla seconda entità coinvolta di continuare la trasmissione dati nell’altra direzione.
La chiusura della sessione vera e propria richiede l’invio e il riscontro di un diverso messaggio denominato SSH_MSG_CHANNEL_CLOSE.
Il protocollo SSH_CONN prevede inoltre la possibilità di incapsulare generici servizi TCP/IP in una sessione SSH (modalità tcpip-forward).
In tal caso è necessario stabilire preventivamente quali porte servizio devono essere accedute via SSH e per quali sistemi remoti il servizio è da ritenersi valido.
L’associazione (ovvero il binding) tra indirizzo server e porta servizio vale globalmente per tutte le sessioni SSH aperte, entro una prestabilita connessione SSH, per servire le specifiche richieste degli applicativi.
In conclusione è possibile affermare che SSH rappresenta una valida soluzione per assicurare elevata protezione e sicurezza nell’accesso a numerose applicazioni TCP/IP di larga diffusione (Telnet, FTP), senza richiederne modifica, ma provvedendo piuttosto a fornire una tecnologia affinchè i protocolli preesistenti possano essere incapsulati in una SSH_CONN negoziata con adeguati parametri di sicurezza.
Il solo inconveniente riscontrabile nell’uso di SSH è che una eventuale analisi esterna dei flussi di dati scambiati non permette di stabilire la natura delle applicazioni che sono trasportate sul secure channel.
Se questo rappresenta un vantaggio per gli utenti legittimi contro l’analisi condotta da un attaccante a livello di rete, è vero anche che rende estremamente difficile stabilire policy di sicurezza aziendali basate su restrizione alle singole applicazioni.
Un utente abilitato a utilizzare SSH infatti può aggirare ogni regola restrittiva imposta, incapsulando preventivamente l’applicazione non consentita in un SSH channel.
