9. Considerazioni sulla sicurezza

Considerazioni sulla sicurezza

Al fine di rendere l'intero corpo delle considerazioni sulla sicurezza più accessibile, le considerazioni sulla sicurezza per i documenti di trasporto, autenticazione e connessione sono state raccolte qui.

Il protocollo di trasporto [SSH-TRANS] fornisce un canale confidenziale su una rete non sicura. Esegue l'autenticazione dell'host del server, lo scambio di chiavi, la cifratura e la protezione dell'integrità. Deriva anche un identificatore di sessione univoco che può essere utilizzato dai protocolli di livello superiore.

Il protocollo di autenticazione [SSH-USERAUTH] fornisce una suite di meccanismi che possono essere utilizzati per autenticare l'utente client al server. I singoli meccanismi specificati nel protocollo di autenticazione utilizzano l'identificatore di sessione fornito dal protocollo di trasporto e/o dipendono dalle garanzie di sicurezza e integrità del protocollo di trasporto.

Il protocollo di connessione [SSH-CONNECT] specifica un meccanismo per multiplexare più flussi di dati (canali) sul trasporto confidenziale e autenticato. Specifica anche canali per accedere a una shell interattiva, per il proxy-forwarding di vari protocolli esterni sul trasporto sicuro (inclusi protocolli TCP/IP arbitrari) e per accedere a sottosistemi sicuri sull'host del server.

9.1. Generazione di numeri pseudo-casuali

Questo protocollo lega ogni chiave di sessione alla sessione includendo dati casuali specifici della sessione nell'hash utilizzato per produrre le chiavi di sessione. Si dovrebbe prestare particolare attenzione per garantire che tutti i numeri casuali siano di buona qualità. Se i dati casuali qui (ad esempio, i parametri Diffie-Hellman (DH)) sono pseudo-casuali, allora il generatore di numeri pseudo-casuali dovrebbe essere crittograficamente sicuro (cioè, il suo prossimo output non è facilmente indovinabile anche conoscendo tutti gli output precedenti) e, inoltre, è necessario aggiungere un'entropia appropriata al generatore di numeri pseudo-casuali. [RFC4086] offre suggerimenti per le fonti di numeri casuali ed entropia. Gli implementatori dovrebbero notare l'importanza dell'entropia e l'avvertimento aneddotico ben intenzionato sulla difficoltà nell'implementare correttamente le funzioni di generazione di numeri pseudo-casuali.

La quantità di entropia disponibile per un determinato client o server può talvolta essere inferiore a quella richiesta. In questo caso, si deve ricorrere alla generazione di numeri pseudo-casuali nonostante l'entropia insufficiente o rifiutarsi di eseguire il protocollo. Quest'ultima opzione è preferibile.

9.2. Filtraggio dei caratteri di controllo

Quando si visualizza testo a un utente, come messaggi di errore o di debug, il software client DOVREBBE sostituire tutti i caratteri di controllo (tranne tabulazione, ritorno a capo e nuova riga) con sequenze sicure per evitare attacchi inviando caratteri di controllo del terminale.

9.3. Trasporto

9.3.1. Riservatezza

È al di là dello scopo di questo documento e del gruppo di lavoro Secure Shell analizzare o raccomandare cifrari specifici diversi da quelli che sono stati stabiliti e accettati nell'industria. Al momento della stesura di questo documento, i cifrari comunemente utilizzati includono 3DES, ARCFOUR, twofish, serpent e blowfish. AES è stato pubblicato dagli Standard federali di elaborazione delle informazioni degli Stati Uniti come [FIPS-197], e la comunità crittografica ha accettato anche AES. Come sempre, gli implementatori e gli utenti dovrebbero controllare la letteratura corrente per assicurarsi che non siano state trovate vulnerabilità recenti nei cifrari utilizzati all'interno dei prodotti. Gli implementatori dovrebbero anche controllare quali cifrari sono considerati relativamente più forti di altri e dovrebbero raccomandare il loro uso agli utenti rispetto ai cifrari relativamente più deboli. Sarebbe considerata buona forma per un'implementazione informare educatamente e discretamente un utente che un cifrario più forte è disponibile e dovrebbe essere usato quando viene scelto attivamente uno più debole.

Il cifrario "none" è fornito per il debug e NON DOVREBBE essere utilizzato se non per tale scopo. Le sue proprietà crittografiche sono sufficientemente descritte in [RFC2410], che dimostrerà che il suo uso non soddisfa l'intento di questo protocollo.

I meriti relativi di questi e altri cifrari possono anche essere trovati nella letteratura corrente. Due riferimenti che possono fornire informazioni sull'argomento sono [SCHNEIER] e [KAUFMAN]. Entrambi descrivono la modalità di operazione CBC di alcuni cifrari e la debolezza di questo schema. Essenzialmente, questa modalità è teoricamente vulnerabile agli attacchi di testo cifrato scelto a causa dell'alta prevedibilità dell'inizio della sequenza di pacchetti. Tuttavia, questo attacco è considerato difficile e non considerato completamente praticabile, specialmente se vengono utilizzate dimensioni di blocco relativamente grandi.

Inoltre, un altro attacco in modalità CBC può essere mitigato attraverso l'inserimento di pacchetti contenenti SSH_MSG_IGNORE. Senza questa tecnica, un attacco specifico può avere successo. Perché questo attacco (comunemente noto come attacco Rogaway [ROGAWAY], [DAI], [BELLARE]) funzioni, l'attaccante dovrebbe conoscere il vettore di inizializzazione (IV) del blocco successivo che sta per essere cifrato. In modalità CBC questo è l'output della cifratura del blocco precedente. Se l'attaccante non ha ancora modo di vedere il pacchetto (cioè, è nei buffer interni dell'implementazione SSH o anche nel kernel), allora questo attacco non funzionerà. Se l'ultimo pacchetto è stato inviato alla rete (cioè, l'attaccante ha accesso ad esso), allora può utilizzare l'attacco.

Nel caso ottimale, un implementatore dovrebbe aggiungere un pacchetto extra solo se il pacchetto è stato inviato alla rete e non ci sono altri pacchetti in attesa di trasmissione. Gli implementatori potrebbero voler verificare se ci sono pacchetti non inviati in attesa di trasmissione; sfortunatamente, non è normalmente facile ottenere queste informazioni dal kernel o dai buffer. Se non ci sono pacchetti non inviati, allora DOVREBBE essere inviato un pacchetto contenente SSH_MSG_IGNORE. Se viene aggiunto un nuovo pacchetto al flusso ogni volta che l'attaccante conosce l'IV che dovrebbe essere usato per il pacchetto successivo, allora l'attaccante non sarà in grado di indovinare l'IV corretto, quindi l'attacco non avrà mai successo.

Come esempio, considerate il seguente caso:

Client Server

TCP(seq=x, len=500) ----> contiene Record 1

[passano 500 ms, nessun ACK]

TCP(seq=x, len=1000) ----> contiene Records 1,2

ACK

L'algoritmo di Nagle + le ritrasmissioni TCP significano che i due record vengono uniti in un singolo segmento TCP.
Record 2 non è all'inizio del segmento TCP e non lo sarà mai perché riceve un ACK.
Tuttavia, l'attacco è possibile perché Record 1 è già stato visto.

Come questo esempio indica, è insicuro utilizzare l'esistenza di dati non scaricati nei buffer TCP propriamente detti come guida per determinare se è necessario un pacchetto vuoto, poiché quando viene eseguita la seconda write() i buffer conterranno il Record 1 non-ACKed.

D'altra parte, è perfettamente sicuro avere la seguente situazione:

Client Server

TCP(seq=x, len=500) ----> contiene SSH_MSG_IGNORE

TCP(seq=y, len=500) ----> contiene Data

A condizione che l'IV per il secondo record SSH sia fissato dopo che i dati per il pacchetto Data sono determinati, allora dovrebbe essere eseguito quanto segue:

leggi dall'utente cifra pacchetto nullo cifra pacchetto dati

9.3.2. Integrità dei dati

Questo protocollo consente di disabilitare il meccanismo di integrità dei dati. Gli implementatori DOVREBBERO diffidare dall'esporre questa funzionalità per qualsiasi scopo diverso dal debug. Gli utenti e gli amministratori DOVREBBERO essere esplicitamente avvertiti ogni volta che viene abilitato il MAC "none".

Finché non viene utilizzato il MAC "none", questo protocollo fornisce l'integrità dei dati.

Poiché i MAC utilizzano un numero di sequenza a 32 bit, potrebbero iniziare a perdere informazioni dopo che sono stati inviati 232 pacchetti. Tuttavia, seguire le raccomandazioni di rekeying dovrebbe prevenire questo attacco. Il protocollo di trasporto [SSH-TRANS] raccomanda il rekeying dopo un gigabyte di dati, e il pacchetto più piccolo possibile è di 16 byte. Pertanto, il rekeying DOVREBBE avvenire dopo 228 pacchetti al massimo.

9.3.3. Replay

L'uso di un MAC diverso da "none" fornisce integrità e autenticazione. Inoltre, il protocollo di trasporto fornisce un identificatore di sessione univoco (legato in parte a dati pseudo-casuali che fanno parte del processo di algoritmo e scambio di chiavi) che può essere utilizzato dai protocolli di livello superiore per legare i dati a una determinata sessione e prevenire il replay di dati da sessioni precedenti. Ad esempio, il protocollo di autenticazione ([SSH-USERAUTH]) utilizza questo per prevenire il replay di firme da sessioni precedenti. Poiché gli scambi di autenticazione con chiave pubblica sono crittograficamente legati alla sessione (cioè, allo scambio di chiavi iniziale), non possono essere riprodotti con successo in altre sessioni. Si noti che l'identificatore di sessione può essere reso pubblico senza danneggiare la sicurezza del protocollo.

Se due sessioni hanno lo stesso identificatore di sessione (hash degli scambi di chiavi), allora i pacchetti di una possono essere riprodotti contro l'altra. Deve essere sottolineato che le probabilità di tale occorrenza sono, inutile dirlo, minime quando si utilizzano metodi crittografici moderni. Ciò è tanto più vero quando si specificano output di funzioni hash più grandi e parametri DH.

Il rilevamento del replay utilizzando numeri di sequenza monotonicamente crescenti come input al MAC, o HMAC in alcuni casi, è descritto in [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025] e [RFC4120]. Il costrutto sottostante è discusso in [RFC2104]. Essenzialmente, un numero di sequenza diverso in ogni pacchetto assicura che almeno questo input alla funzione MAC sarà unico e fornirà un output MAC non ricorrente che non è prevedibile da un attaccante. Se la sessione rimane attiva abbastanza a lungo, tuttavia, questo numero di sequenza si avvolgerà. Questo evento può fornire a un attaccante un'opportunità di riprodurre un pacchetto precedentemente registrato con un numero di sequenza identico, ma solo se i peer non hanno effettuato il rekeying dalla trasmissione del primo pacchetto con quel numero di sequenza. Se i peer hanno effettuato il rekeying, allora il replay sarà rilevato poiché il controllo MAC fallirà. Per questa ragione, deve essere enfatizzato che i peer DEVONO effettuare il rekeying prima di un avvolgimento dei numeri di sequenza. Naturalmente, se un attaccante tenta effettivamente di riprodurre un pacchetto catturato prima che i peer abbiano effettuato il rekeying, allora il ricevitore del pacchetto duplicato non sarà in grado di validare il MAC e verrà scartato. Il motivo per cui il MAC fallirà è che il ricevitore formulerà un MAC basato sul contenuto del pacchetto, il segreto condiviso e il numero di sequenza previsto. Poiché il pacchetto riprodotto non utilizzerà quel numero di sequenza previsto (il numero di sequenza del pacchetto riprodotto sarà già stato superato dal ricevitore), il MAC calcolato non corrisponderà al MAC ricevuto con il pacchetto.

9.3.4. Man-in-the-middle

Questo protocollo non fa alcuna assunzione o previsione per un'infrastruttura o mezzi per distribuire le chiavi pubbliche degli host. Si prevede che questo protocollo sarà talvolta utilizzato senza prima verificare l'associazione tra la chiave host del server e il nome host del server. Tale uso è vulnerabile agli attacchi man-in-the-middle. Questa sezione descrive questo e incoraggia gli amministratori e gli utenti a comprendere l'importanza di verificare questa associazione prima di avviare qualsiasi sessione.

Ci sono tre casi di attacchi man-in-the-middle da considerare. Il primo è quando un attaccante posiziona un dispositivo tra il client e il server prima che la sessione venga iniziata. In questo caso, il dispositivo di attacco sta cercando di imitare il server legittimo e offrirà la sua chiave pubblica al client quando il client avvia una sessione. Se dovesse offrire la chiave pubblica del server, allora non sarebbe in grado di decifrare o firmare le trasmissioni tra il server legittimo e il client a meno che non avesse anche accesso alla chiave privata dell'host. Il dispositivo di attacco avvierà anche, simultaneamente a questo, una sessione al server legittimo, mascherandosi come il client. Se la chiave pubblica del server era stata distribuita in modo sicuro al client prima dell'avvio di quella sessione, la chiave offerta al client dal dispositivo di attacco non corrisponderà alla chiave memorizzata sul client. In tal caso, l'utente DOVREBBE ricevere un avviso che la chiave host offerta non corrisponde alla chiave host memorizzata nella cache del client. Come descritto nella Sezione 4.1, l'utente può essere libero di accettare la nuova chiave e continuare la sessione. È RACCOMANDATO che l'avviso fornisca informazioni sufficienti all'utente del dispositivo client in modo che l'utente possa prendere una decisione informata. Se l'utente sceglie di continuare la sessione con la chiave pubblica memorizzata del server (non la chiave pubblica offerta all'inizio della sessione), allora i dati specifici della sessione tra l'attaccante e il server saranno diversi tra la sessione client-attaccante e le sessioni attaccante-server a causa della casualità discussa sopra. Da ciò, l'attaccante non sarà in grado di far funzionare questo attacco poiché l'attaccante non sarà in grado di firmare correttamente i pacchetti contenenti questi dati specifici della sessione dal server, poiché non ha la chiave privata di quel server.

Il secondo caso che dovrebbe essere considerato è simile al primo caso in quanto si verifica anche al momento della connessione, ma questo caso sottolinea la necessità della distribuzione sicura delle chiavi pubbliche del server. Se le chiavi pubbliche del server non sono distribuite in modo sicuro, allora il client non può sapere se sta parlando con il server previsto. Un attaccante può utilizzare tecniche di ingegneria sociale per passare chiavi del server a utenti ignari e può quindi posizionare un dispositivo di attacco man-in-the-middle tra il server legittimo e i client. Se ciò è consentito, allora i client formeranno sessioni client-attaccante, e l'attaccante formerà sessioni attaccante-server e sarà in grado di monitorare e manipolare tutto il traffico tra i client e i server legittimi. Gli amministratori del server sono incoraggiati a rendere disponibili le impronte digitali delle chiavi host per il controllo tramite mezzi la cui sicurezza non si basa sull'integrità delle chiavi host effettive. I possibili meccanismi sono discussi nella Sezione 4.1 e possono anche includere pagine Web sicure, pezzi di carta fisici, ecc. Gli implementatori DOVREBBERO fornire raccomandazioni su come farlo al meglio con la loro implementazione. Poiché il protocollo è estensibile, le future estensioni del protocollo possono fornire meccanismi migliori per affrontare la necessità di conoscere la chiave host del server prima di connettersi. Ad esempio, rendere l'impronta digitale della chiave host disponibile attraverso una ricerca DNS sicura, o utilizzare Kerberos ([RFC4120]) su GSS-API ([RFC1964]) durante lo scambio di chiavi per autenticare il server sono possibilità.

Nel terzo caso man-in-the-middle, gli attaccanti possono tentare di manipolare i pacchetti in transito tra i peer dopo che la sessione è stata stabilita. Come descritto nella Sezione 9.3.3, un attacco riuscito di questa natura è molto improbabile. Come nella Sezione 9.3.3, questo ragionamento assume che il MAC sia sicuro e che sia infeasibile costruire input a un algoritmo MAC per dare un output noto. Questo è discusso in modo molto più dettagliato nella Sezione 6 di [RFC2104]. Se l'algoritmo MAC ha una vulnerabilità o è abbastanza debole, allora l'attaccante potrebbe essere in grado di specificare determinati input per produrre un MAC noto. Con ciò, potrebbero essere in grado di alterare il contenuto di un pacchetto in transito. In alternativa, l'attaccante potrebbe essere in grado di sfruttare la vulnerabilità o la debolezza dell'algoritmo per trovare il segreto condiviso esaminando i MAC dai pacchetti catturati. In entrambi questi casi, un attaccante potrebbe costruire un pacchetto o pacchetti che potrebbero essere inseriti in un flusso SSH. Per prevenire ciò, gli implementatori sono incoraggiati a utilizzare algoritmi MAC comunemente accettati, e gli amministratori sono incoraggiati a seguire la letteratura corrente e le discussioni sulla crittografia per assicurarsi di non utilizzare un algoritmo MAC che ha una vulnerabilità o debolezza recentemente scoperta.

In sintesi, l'uso di questo protocollo senza un'associazione affidabile del legame tra un host e le sue chiavi host è intrinsecamente insicuro e NON È RACCOMANDATO. Tuttavia, può essere necessario in ambienti non critici per la sicurezza e fornirà comunque protezione contro gli attacchi passivi. Gli implementatori di protocolli e applicazioni in esecuzione sopra questo protocollo dovrebbero tenere presente questa possibilità.

9.3.5. Denial of Service

Questo protocollo è progettato per essere utilizzato su un trasporto affidabile. Se si verificano errori di trasmissione o manipolazione dei messaggi, la connessione viene chiusa. La connessione DOVREBBE essere ristabilita se ciò accade. Gli attacchi denial of service di questo tipo (tagliatore di fili) sono quasi impossibili da evitare.

Inoltre, questo protocollo è vulnerabile agli attacchi denial of service perché un attaccante può forzare il server a eseguire le attività intensive di CPU e memoria dell'impostazione della connessione e dello scambio di chiavi senza autenticazione. Gli implementatori DOVREBBERO fornire funzionalità che rendano ciò più difficile, ad esempio, consentendo solo connessioni da un sottoinsieme di client noti per avere utenti validi.

9.3.6. Canali nascosti

Il protocollo non è stato progettato per eliminare i canali nascosti. Ad esempio, il padding, i messaggi SSH_MSG_IGNORE e diversi altri punti nel protocollo possono essere utilizzati per passare informazioni nascoste, e il destinatario non ha un modo affidabile per verificare se tali informazioni vengono inviate.

9.3.7. Forward Secrecy

Si dovrebbe notare che gli scambi di chiavi Diffie-Hellman possono fornire perfect forward secrecy (PFS). PFS è essenzialmente definito come la proprietà crittografica di un protocollo di stabilimento delle chiavi in cui il compromesso di una chiave di sessione o di una chiave privata a lungo termine dopo una determinata sessione non causa il compromesso di alcuna sessione precedente [ANSI-T1.523-2001]. Le sessioni SSH risultanti da uno scambio di chiavi utilizzando i metodi diffie-hellman descritti nella sezione Scambio di chiavi Diffie-Hellman di [SSH-TRANS] (inclusi "diffie-hellman-group1-sha1" e "diffie-hellman-group14-sha1") sono sicure anche se il materiale di chiave/autenticazione privato viene successivamente rivelato, ma non se le chiavi di sessione vengono rivelate. Quindi, data questa definizione di PFS, SSH ha PFS. Tuttavia, questa proprietà non viene trasmessa ad alcuna delle applicazioni o protocolli che utilizzano SSH come trasporto. Il livello di trasporto di SSH fornisce riservatezza per l'autenticazione tramite password e altri metodi che si basano su dati segreti.

Naturalmente, se i parametri privati DH per il client e il server vengono rivelati, allora la chiave di sessione viene rivelata, ma questi elementi possono essere eliminati dopo il completamento dello scambio di chiavi. Vale la pena sottolineare che questi elementi non dovrebbero essere autorizzati a finire nello spazio di swap e che dovrebbero essere cancellati dalla memoria non appena lo scambio di chiavi è completato.

9.3.8. Ordinamento dei metodi di scambio di chiavi

Come indicato nella sezione sulla negoziazione degli algoritmi di [SSH-TRANS], ogni dispositivo invierà un elenco di metodi di scambio di chiavi preferiti. Il metodo più preferito è il primo nell'elenco. È RACCOMANDATO che gli algoritmi siano ordinati per forza crittografica, i più forti per primi. Ulteriori indicazioni su questo sono fornite in [RFC3766].

9.3.9. Analisi del traffico

Il monitoraggio passivo di qualsiasi protocollo può dare a un attaccante alcune informazioni sulla sessione, l'utente o informazioni specifiche del protocollo che altrimenti non sarebbe in grado di raccogliere. Ad esempio, è stato dimostrato che l'analisi del traffico di una sessione SSH può produrre informazioni sulla lunghezza della password - [Openwall] e [USENIX]. Gli implementatori dovrebbero utilizzare il pacchetto SSH_MSG_IGNORE, insieme all'inclusione di lunghezze casuali di padding, per contrastare i tentativi di analisi del traffico. Possono anche essere trovati e implementati altri metodi.

9.4. Protocollo di autenticazione

Lo scopo di questo protocollo è eseguire l'autenticazione dell'utente client. Si presume che questo venga eseguito su un protocollo di livello di trasporto sicuro, che ha già autenticato la macchina server, stabilito un canale di comunicazione cifrato e calcolato un identificatore di sessione univoco per questa sessione.

Sono consentiti diversi metodi di autenticazione con caratteristiche di sicurezza diverse. Spetta alla politica locale del server decidere quali metodi (o combinazioni di metodi) è disposto ad accettare per ciascun utente. L'autenticazione non è più forte della combinazione più debole consentita.

Il server può entrare in un periodo di sospensione dopo ripetuti tentativi di autenticazione infruttuosi per rendere la ricerca delle chiavi più difficile per gli attaccanti. Si dovrebbe fare attenzione affinché ciò non diventi un vettore di auto-denial of service.

9.4.1. Trasporto debole

Se il livello di trasporto non fornisce riservatezza, i metodi di autenticazione che si basano su dati segreti DOVREBBERO essere disabilitati. Se non fornisce una forte protezione dell'integrità, le richieste di modificare i dati di autenticazione (ad esempio, un cambio di password) DOVREBBERO essere disabilitate per impedire a un attaccante di modificare il testo cifrato senza essere notato, o rendere i nuovi dati di autenticazione inutilizzabili (denial of service).

L'assunzione sopra indicata, che il protocollo di autenticazione viene eseguito solo su un trasporto sicuro che ha precedentemente autenticato il server, è molto importante da notare. Le persone che implementano SSH sono ricordate delle conseguenze degli attacchi man-in-the-middle se il client non ha un'associazione a priori molto forte del server con la chiave host di quel server. Specificamente, per il caso del protocollo di autenticazione, il client può formare una sessione con un dispositivo di attacco man-in-the-middle e divulgare credenziali utente come il loro nome utente e password. Anche nei casi di autenticazione in cui non vengono divulgate credenziali utente, un attaccante può comunque ottenere informazioni che non dovrebbe avere catturando le battiture dei tasti in modo molto simile a come funziona un honeypot.

9.4.2. Messaggi di debug

Si dovrebbe prestare particolare attenzione nella progettazione dei messaggi di debug. Questi messaggi possono rivelare quantità sorprendenti di informazioni sull'host se non progettati correttamente. I messaggi di debug possono essere disabilitati (durante la fase di autenticazione dell'utente) se è richiesta un'alta sicurezza. Gli amministratori delle macchine host dovrebbero fare tutti i tentativi per compartimentare tutti i messaggi di notifica degli eventi e proteggerli dall'osservazione ingiustificata. Gli sviluppatori dovrebbero essere consapevoli della natura sensibile di alcuni messaggi di evento e debug normali e potrebbero voler fornire indicazioni agli amministratori su modi per tenere queste informazioni lontane dalle persone non autorizzate. Gli sviluppatori dovrebbero considerare di minimizzare la quantità di informazioni sensibili ottenibili dagli utenti durante la fase di autenticazione, in conformità con le politiche locali. Per questa ragione, è RACCOMANDATO che i messaggi di debug siano inizialmente disabilitati al momento della distribuzione e richiedano una decisione attiva da parte di un amministratore per consentirne l'abilitazione. È anche RACCOMANDATO che venga presentato un messaggio che esprime questa preoccupazione all'amministratore di un sistema quando viene intrapresa l'azione per abilitare i messaggi di debug.

9.4.3. Politica di sicurezza locale

L'implementatore DEVE garantire che le credenziali fornite validino l'utente dichiarato e DEVE anche garantire che la politica locale del server permetta all'utente l'accesso richiesto. In particolare, a causa della natura flessibile del protocollo di connessione SSH, potrebbe non essere possibile determinare la politica di sicurezza locale, se presente, che dovrebbe applicarsi al momento dell'autenticazione perché il tipo di servizio richiesto non è chiaro in quell'istante. Ad esempio, la politica locale potrebbe consentire a un utente di accedere ai file sul server, ma non di avviare una shell interattiva. Tuttavia, durante il protocollo di autenticazione, non è noto se l'utente accederà ai file, tenterà di utilizzare una shell interattiva o anche entrambi. In ogni caso, dove esiste una politica di sicurezza locale per l'host del server, DEVE essere applicata e fatta rispettare correttamente.

Gli implementatori sono incoraggiati a fornire una politica locale predefinita e rendere noti i suoi parametri agli amministratori e agli utenti. A discrezione degli implementatori, questa politica predefinita può essere sulla linea di tutto-va dove non ci sono restrizioni imposte agli utenti, o può essere sulla linea di eccessivamente-restrittiva, nel qual caso, gli amministratori dovranno apportare attivamente modifiche ai parametri predefiniti iniziali per soddisfare le loro esigenze. In alternativa, può essere un tentativo di fornire qualcosa di pratico e immediatamente utile agli amministratori del sistema in modo che non debbano fare molto sforzo per far funzionare SSH. Qualunque scelta venga fatta deve essere applicata e fatta rispettare come richiesto sopra.

9.4.4 Autenticazione a chiave pubblica

L'uso dell'autenticazione a chiave pubblica presume che l'host client non sia stato compromesso. Presume anche che la chiave privata dell'host del server non sia stata compromessa.

Questo rischio può essere mitigato dall'uso di passphrase sulle chiavi private; tuttavia, questa non è una politica applicabile. Si suggerisce l'uso di smartcard o altra tecnologia per rendere le passphrase una politica applicabile.

Il server potrebbe richiedere sia l'autenticazione tramite password che a chiave pubblica; tuttavia, ciò richiede che il client esponga la sua password al server (vedere la sezione sull'autenticazione tramite password di seguito.)

9.4.5. Autenticazione tramite password

Il meccanismo della password, come specificato nel protocollo di autenticazione, presume che il server non sia stato compromesso. Se il server è stato compromesso, l'uso dell'autenticazione tramite password rivelerà una combinazione nome utente/password valida all'attaccante, che può portare a ulteriori compromissioni.

Questa vulnerabilità può essere mitigata utilizzando una forma alternativa di autenticazione. Ad esempio, l'autenticazione a chiave pubblica non fa alcuna assunzione sulla sicurezza sul server.

9.4.6. Autenticazione basata sull'host

L'autenticazione basata sull'host presume che il client non sia stato compromesso. Non ci sono strategie di mitigazione, se non quella di utilizzare l'autenticazione basata sull'host in combinazione con un altro metodo di autenticazione.

9.5. Protocollo di connessione

9.5.1. Sicurezza degli endpoint

La sicurezza degli endpoint è assunta dal protocollo di connessione. Se il server è stato compromesso, qualsiasi sessione terminale, port forwarding o sistemi a cui si accede sull'host sono compromessi. Non ci sono fattori mitiganti per questo.

Se il client è stato compromesso e il server non riesce a fermare l'attaccante al protocollo di autenticazione, tutti i servizi esposti (sia come sottosistemi che attraverso il forwarding) saranno vulnerabili agli attacchi. Gli implementatori DOVREBBERO fornire meccanismi per gli amministratori per controllare quali servizi sono esposti per limitare la vulnerabilità di altri servizi. Questi controlli potrebbero includere il controllo di quali macchine e porte possono essere target nelle operazioni di port-forwarding, quali utenti sono autorizzati a utilizzare le funzionalità di shell interattiva o quali utenti sono autorizzati a utilizzare i sottosistemi esposti.

9.5.2. Proxy forwarding

Il protocollo di connessione SSH consente il proxy forwarding di altri protocolli come SMTP, POP3 e HTTP. Ciò può essere una preoccupazione per gli amministratori di rete che desiderano controllare l'accesso di determinate applicazioni da parte degli utenti situati al di fuori della loro posizione fisica. Essenzialmente, il forwarding di questi protocolli può violare le politiche di sicurezza specifiche del sito, poiché possono essere tunnelizzati in modo non rilevabile attraverso un firewall. Gli implementatori DOVREBBERO fornire un meccanismo amministrativo per controllare la funzionalità di proxy forwarding in modo che le politiche di sicurezza specifiche del sito possano essere rispettate.

Inoltre, è disponibile una funzionalità di proxy forwarding inverso, che, ancora una volta, può essere utilizzata per aggirare i controlli del firewall.

Come indicato sopra, la sicurezza degli endpoint è assunta durante le operazioni di proxy forwarding. Il fallimento della sicurezza degli endpoint comprometterà tutti i dati passati attraverso il proxy forwarding.

9.5.3. X11 Forwarding

Un'altra forma di proxy forwarding fornita dal protocollo di connessione SSH è il forwarding del protocollo X11. Se la sicurezza degli endpoint è stata compromessa, il forwarding X11 può consentire attacchi contro il server X11. Gli utenti e gli amministratori dovrebbero, come prassi normale, utilizzare meccanismi di sicurezza X11 appropriati per prevenire l'uso non autorizzato del server X11. Gli implementatori, gli amministratori e gli utenti che desiderano esplorare ulteriormente i meccanismi di sicurezza di X11 sono invitati a leggere [SCHEIFLER] e analizzare i problemi precedentemente segnalati con le interazioni tra il forwarding SSH e X11 nelle vulnerabilità CERT VU#363181 e VU#118892 [CERT].

Il forwarding del display X11 con SSH, di per sé, non è sufficiente per correggere i problemi ben noti con la sicurezza X11 [VENEMA]. Tuttavia, il forwarding del display X11 in SSH (o altri protocolli sicuri), combinato con display reali e pseudo che accettano connessioni solo su meccanismi IPC locali autorizzati da permessi o liste di controllo degli accessi (ACL), corregge effettivamente molti problemi di sicurezza X11, purché non venga utilizzato il MAC "none". È RACCOMANDATO che le implementazioni del display X11 permettano per impostazione predefinita l'apertura del display solo su IPC locale. È RACCOMANDATO che le implementazioni del server SSH che supportano il forwarding X11 permettano per impostazione predefinita l'apertura del display solo su IPC locale. Su sistemi mono-utente, potrebbe essere ragionevole permettere per impostazione predefinita l'apertura del display locale su TCP/IP.

Gli implementatori del protocollo di forwarding X11 DOVREBBERO implementare il meccanismo di spoofing del controllo degli accessi magic cookie, come descritto in [SSH-CONNECT], come meccanismo aggiuntivo per prevenire l'uso non autorizzato del proxy.