Tunneling ssh- SSH port forwarding: utile ma anche rischioso.

Il tunneling SSH nel quadro dei rischi aziendali.

Il tunneling ssh è utilissimo e sembrerebbe alquanto sicuro, ma crea anche un rischio che deve essere affrontato dai team di sicurezza IT aziendali.

E’ corretto affermare che le connessioni SSH sono protette da una forte crittografia. Questo rende il loro contenuto invisibile alla maggior parte delle soluzioni di monitoraggio della rete e di filtraggio del traffico. Ma proprio questa invisibilità comporta un notevole potenziale di rischio se utilizzata per scopi malevoli come l’esfiltrazione dei dati. Hacker  o il malware potrebbero sfruttare i tunnel SSH per nascondere le loro comunicazioni non autorizzate è prendere ciò che vogliono. In un tunneling ssh possono trovare un valido canale sicuro di comunicazione.

Attacco di back-tunneling

In un attacco di back-tunneling SSH l’aggressore imposta un server al di fuori della rete di destinazione (su un cloud). Una volta che l’aggressore si trova nel sistema di destinazione, si collega al server SSH esterno dall’interno. La maggior parte delle organizzazioni e degli uffici più piccoli, permette connessioni SSH in uscita. Questa connessione SSH è impostata con un’opzione che permette l’inoltro della porta TCP da una porta sul server esterno a una porta SSH su un server nella rete interna. L’impostazione di questo back-tunnel SSH richiede un unico comando a una linea all’interno, e può essere facilmente automatizzato. La maggior parte dei firewall offrono poca o nessuna protezione contro di esso.

Esistono diversi casi ampiamente noti e documentati di malware che sfruttano il protocollo SSH come mezzo per nascondere l’esfiltrazione di dati. In diversi casi malware hanno raccolto attivamente le chiavi SSH e le chiavi SSH catturate e sono state vendute anche sui forum molto particolari.

ssh tunneling
ssh tunneling

Attacchi di tunneling SSH 

Gli attacchi di tunneling SSH possono essere utilizzati anche per nascondere la fonte dell’attacco. È comune per gli hacker far rimbalzare gli attacchi su sistemi e dispositivi che permettono al port forwarding SSH di nascondere le loro tracce. Ciò consente loro di sondare le vulnerabilità, provare varie credenziali di accesso o eseguire strumenti di attacco contro la posta elettronica, il web, la telefonia e qualsiasi altro protocollo. Il rimbalzo di un attacco attraverso una dozzina di dispositivi casuali attraverso tunnel criptati che trasportano anche altro traffico lo rende virtualmente irrintracciabile. Akamai ha documentato milioni di dispositivi IoT utilizzati in questo modo.

Per contrastare questi rischi è necessaria la capacità di monitorare, controllare e verificare le connessioni SSH criptate. Per prevenire i rimbalzi, richiede una corretta configurazione e hardening dei sistemi operativi dell’internet degli oggetti.

Va inoltre notato che gli attacchi di tunneling non sono specifici di SSH – un programmatore competente può scrivere uno strumento per le porte di tunneling in poche ore e può eseguirlo su qualsiasi macchina della rete interna. Qualsiasi computer portatile o altro dispositivo sulla rete interna può farlo – deve solo essere in grado di comunicare con qualche (qualsiasi) servizio su Internet. Un tale strumento potrebbe essere fatto funzionare su SSL/TLS, potrebbe emulare HTTP, o potrebbe operare su UDP e utilizzare pacchetti che assomigliano a richieste e risposte DNS. SSH rende tutto più facile per i non programmatori. Si può solo proteggere da attacchi di tunneling contro persone che sono in grado di eseguire software all’interno o di connettere qualsiasi dispositivo alla rete interna, consentendo solo i protocolli che si possono ispezionare attraverso il firewall.

Utilizzare i tunnel IPsec per ottenere l’accesso iniziale.

Le organizzazioni utilizzano Internet Protocol Security (IPsec) per creare una VPN che protegge la comunicazione Internet attraverso una rete IP. Poiché i tunnel IPsec sono spesso utilizzati per creare un tunnel da un sito remoto verso un sito centrale, sono uno strumento di infiltrazione ideale per i cybercriminali. Un tunnel IPSec/L2TP viene utilizzato più spesso durante le fasi di scoperta e di attacco di incursione. Il tunnel viene utilizzato per ottenere l’accesso iniziale a un’organizzazione, effettuare ricognizioni e stabilire una testa di ponte. Questo tipo di attacco compromette in genere solo gli endpoint VPN stabiliti, poiché la creazione di un nuovo tunnel richiederebbe all’aggressore di penetrare le difese del livello perimetrale per accedere alla console amministrativa VPN, un compito molto più complesso dal punto di vista tecnico.



Un piede all’interno dei tunnel VPN Site-to-Site

Le grandi organizzazioni utilizzano una VPN site-to-site per collegare le loro reti di sedi principali a più uffici e partner commerciali. Essendo l’opzione più flessibile e adattabile, sono uno strumento perfetto per spostarsi rapidamente da un sito all’altro all’interno di una rete estesa. Gli aggressori utilizzano i tunnel site-to-site dopo aver compromesso il sistema interno iniziale come parte di una porzione pivot di un attacco. Questi tunnel sono ideali per la fase di ricognizione dell’attacco, quando gli aggressori cercano di accedere ad altri segmenti o dispositivi della rete. A causa dell’impatto sulle prestazioni, i tunnel VPN site-to-site sono raramente ispezionati, il che consente agli aggressori di passare inosservati durante l’utilizzo.

Diffusione di virus, worm e trojan da computer remoti alla rete interna

L’accesso remoto è un importante vettore di minaccia per la sicurezza della rete. Ogni computer remoto che non soddisfa i requisiti di sicurezza aziendale può potenzialmente trasmettere un'”infezione” dal suo ambiente di rete locale alla rete interna di un’organizzazione. Per mitigare questo tipo di rischio è necessario un software antivirus aggiornato sul computer remoto.

Tunneling frazionato

Lo split tunneling avviene quando un computer sul lato remoto di un tunnel VPN scambia simultaneamente il traffico di rete sia con la rete condivisa (pubblica) che con la rete interna (privata) senza prima collocare tutto il traffico di rete all’interno del tunnel VPN. Ciò offre l’opportunità agli aggressori sulla rete condivisa di compromettere il computer remoto e di utilizzarlo per accedere alla rete interna.  Molte organizzazioni hanno scelto di non consentire il split tunneling.

RCF6169

So benissimo che le RCF sono pallose da leggere, ma insegnano tanto. Non possono essere prese come lettura da “svago” ma se qualcosa ci affascina o vogliamo sapere il perchè, per me è l’unico modo di avere informazioni certe.

“Alcuni protocolli di tunnel sono facili da identificare, ad esempio se tutti i pacchetti di dati sono incapsulati usando una nota porta UDP o TCP che è unica per il protocollo.
Altri protocolli, tuttavia, o usano porte dinamiche per il traffico dati o condividono porte con altri protocolli (per esempio, tunnel su HTTP).

L’implicazione di ciò è che i dispositivi in rete che desiderano ispezionare passivamente (e forse applicare selettivamente la politica a ) tutto il traffico incapsulato devono ispezionare tutti i pacchetti TCP o UDP (o almeno tutti i pacchetti che non fanno parte di una sessione che non è nota per essere un tunnel).
Questo è un errore in quanto deve essere applicato un euristico per determinare se un pacchetto è effettivamente parte di un tunnel. Questo può essere troppo lento da utilizzare in pratica, specialmente se significa che tutti i pacchetti TCP o UDP devono essere tolti dal “fast path” del dispositivo.

Controllo euristico

Un euristico che può essere usato sui pacchetti per determinare se sono o meno legati al tunnel è il seguente. Per ogni protocollo tunnel conosciuto, tentare di analizzare il pacchetto come se fosse un pacchetto di quel protocollo destinato all’host locale (cioè, dove l’host locale ha l’indirizzo di destinazione nell’intestazione IP interna, se presente). Se tutti i controlli di sintassi passano, fino all’intestazione IP interna (se il tunnel non usa la crittografia), allora trattare il pacchetto come se fosse un pacchetto di quel protocollo destinato al tunnel.

E’ possibile che i pacchetti non tunnelati vengano trattati come se fossero pacchetti tunnelati usando questo euristico, ma i pacchetti tunnelati (dei tipi di tunnel conosciuti) non dovrebbero sfuggire all’ispezione, in assenza di bug di implementazione.

Per alcuni protocolli, può essere possibile monitorare gli scambi di impostazione per sapere di aspettarsi che i dati saranno scambiati su alcune porte in un secondo momento.

Se il tunnel permette l’accesso in entrata da Internet pubblico, l’apertura creata in un dispositivo NAT a causa di un cliente del tunnel aumenta la sua Superficie di attacco a Internet. Se sono presenti vulnerabilità, questa maggiore esposizione può essere utilizzata dagli aggressori e dai loro programmi.

Quindi, se il tunnel consente l’accesso in entrata solo da una rete privata (ad esempio, una rete remota alla quale si è collegati in VPN), l’apertura creata nel dispositivo di NAT aumenta ancora la sua superficie di attacco, anche se non così tanto come nel caso di Internet pubblico.”



In tutti i casi

Attivare l’autenticazione a due fattori 

I vostri server SSH dovrebbero essere protetti con l’autenticazione a due fattori configurata su di essa. Si tratta di una delle principali protezioni che si possono aggiungere ai vostri server SSH per proteggerli da accessi non autorizzati, poiché ogni login utente deve essere legato ad un utente 2FA configurato. Anche se un hacker riesce ad entrare in possesso della vostra password o a penetrare nel vostro server SSH, verrà comunque bloccato dal 2FA. Se proprio siete a digiuno , potreste tentare  con l’autenticazione a due fattori tramite Google Authenticator.

Utilizzare chiavi pubbliche/private per l’autenticazione 

L’autenticazione con chiavi pubbliche/private è certamente più sicura e rappresenta una soluzione molto migliore dell’autenticazione con password.

Questo è particolarmente importante se il computer è visibile su Internet. L’utilizzo di chiavi criptate per l’autenticazione è utile in quanto non sarà più necessario inserire una password. Una volta che l’autenticazione a coppie di chiavi pubbliche/private è stata configurata sul server, è possibile disattivare completamente l’autenticazione con password; ciò significa che nessuno senza una chiave autorizzata potrà accedere. Anche gli hacker più inventivi non potranno più interferire o intrufolarsi in una sessione e non ci saranno più tentativi di cracking della password.

Non utilizare lo split tunneling 

Se i dispositivi di proprietà dell’utente stanno accedendo alla rete, il rischio è che tali dispositivi non soddisfino la conformità alle policy di base dell’organizzazione e stiano creando un possibile vettore di attacco per entrare nella rete dell’organizzazione. E ora, consentendo lo split tunneling, si crea una situazione più ampia. Se il dispositivo remoto dell’utente è conforme, è comunque possibile che l’utente remoto venga infettato da malware o da un virus mentre è connesso alla VPN split tunneling. Un’infezione potrebbe diffondersi dal dispositivo dell’utente remoto attraverso la connessione VPN.

In termini di sicurezza, il rischio maggiore di attivare lo split tunneling è la perdita di una strategia di difesa approfondita. Abilitando lo split tunneling si dispone ora di una connessione aperta alla rete che può inviare/ricevere traffico che non passa attraverso i dispositivi di sicurezza perimetrali dell’organizzazione come firewall, IPS o IDS. Ciò creerà una situazione in cui la vostra organizzazione non potrà monitorare il traffico web sul dispositivo remoto attraverso la connessione VPN.

BAA & tunneling ssh

Le protezioni per mitigare il rischio di split tunneling dovrebbero includere prima di tutto un BAA (business associate agreement ) valido, che richiede alla terza parte di richiedere controlli di sicurezza per verificare che le postazioni di lavoro remote siano protette. In secondo luogo, dovrebbe essere implementata anche la formazione degli utenti e una politica di utilizzo molto stringente. Per quanto riguarda i controlli tecnici, dovrebbe essere utilizzato un agente VPN, in grado di eseguire un controllo della macchina che si collega e verificare che il dispositivo sia conforme alle specifiche di sicurezza. Questo controllo dello “stato di salute” dovrebbe verificare che le patch del sistema operativo siano installate, che sia installato un anti-virus, che sia in esecuzione e che si stia aggiornando regolarmente.

Key: SSH tunnel , RCF6169 , tunneling ssh , back-tunneling