17. Considerazioni sulla sicurezza (Security Considerations)
Questa sezione considera gli attacchi che potrebbero essere condotti contro le distribuzioni TURN e discute come mitigare questi attacchi attraverso meccanismi nel protocollo o pratiche raccomandate nell'implementazione.
La maggior parte degli attacchi contro TURN viene mitigata dal server che richiede che le richieste siano autenticate. Per questo motivo, questa specifica rende obbligatorio l'uso dell'autenticazione. Il meccanismo obbligatorio da implementare è il meccanismo di credenziali a lungo termine di STUN. Altri meccanismi di autenticazione con le stesse proprietà di sicurezza o più forti POSSONO essere utilizzati. Tuttavia, è importante assicurarsi che possano essere invocati in modo interoperabile.
17.1. Attacchi esterni (Outsider Attacks)
Gli attacchi esterni sono quelli in cui l'attaccante non ha credenziali nel sistema e sta cercando di interrompere il servizio come visto dal client o dal server.
17.1.1. Ottenimento di allocazioni non autorizzate (Obtaining Unauthorized Allocations)
Un attaccante potrebbe desiderare di ottenere un'allocazione su un server TURN per un numero qualsiasi di scopi malevoli. Un server TURN fornisce un meccanismo per inviare e ricevere pacchetti nascondendo l'indirizzo IP effettivo del client. Questo rende il server TURN un obiettivo attraente per gli attaccanti che desiderano utilizzarlo per mascherare la loro vera identità.
Un attaccante potrebbe anche semplicemente desiderare di utilizzare i servizi di un server TURN senza pagarli. Poiché i servizi TURN richiedono risorse del fornitore, ci si aspetta che il loro utilizzo sia accompagnato da un costo.
Questi attacchi vengono prevenuti attraverso l'uso del meccanismo di credenziali a lungo termine, che consente al server TURN di determinare l'identità del richiedente e se il richiedente è autorizzato a ottenere un'allocazione.
17.1.2. Attacchi con dizionario offline (Offline Dictionary Attacks)
Il meccanismo di credenziali a lungo termine utilizzato da TURN è suscettibile ad attacchi con dizionario offline. Un attaccante in grado di intercettare uno scambio di messaggi tra un client e un server può determinare la password provando un certo numero di password candidate e vedendo se una di esse è corretta. Questo attacco funziona quando le password hanno bassa entropia (ad esempio, parole da un dizionario). Questo attacco può essere mitigato utilizzando password forti con grande entropia. Nei casi in cui è necessaria una mitigazione ancora più forte, il trasporto TLS può essere utilizzato tra client e server.
17.1.3. Aggiornamenti e permessi falsificati (Faked Refreshes and Permissions)
Un attaccante potrebbe desiderare di attaccare un'allocazione attiva inviandole una richiesta Refresh con scadenza immediata al fine di eliminarla e interrompere il servizio al client. Questo viene prevenuto attraverso l'autenticazione degli aggiornamenti. Allo stesso modo, un attaccante che desidera inviare una richiesta CreatePermission per creare un permesso verso una destinazione indesiderata viene impedito di farlo attraverso l'autenticazione. Le motivazioni per tali attacchi sono descritte nella Sezione 17.2.
17.1.4. Dati falsificati (Fake Data)
Un attaccante potrebbe desiderare di inviare dati a un client o peer come se provenissero rispettivamente dal peer o dal client. Per fare ciò, l'attaccante potrebbe inviare un'indicazione Data o un messaggio ChannelData falsificato al client o un'indicazione Send o un messaggio ChannelData falsificato al server TURN.
Poiché le indicazioni e i messaggi ChannelData non sono autenticati, questo attacco non viene prevenuto da TURN. Tuttavia, questo attacco è generalmente presente nelle comunicazioni basate su IP e non viene significativamente aggravato da TURN. Consideriamo una normale sessione IP tra gli host A e B che non utilizza TURN. Un attaccante può inviare un pacchetto a B che sembra provenire da A inviando il pacchetto con l'indirizzo IP falsificato di A. Questo attacco richiede che l'attaccante conosca gli indirizzi IP sia di A che di B. Con TURN, un attaccante che desidera inviare un pacchetto al client utilizzando un'indicazione Data deve conoscere l'indirizzo IP (e la porta) del client, l'indirizzo IP e la porta del server TURN, e l'indirizzo IP e la porta del peer (da includere nell'attributo XOR-PEER-ADDRESS). Per inviare un falso messaggio ChannelData al client, l'attaccante deve conoscere l'indirizzo IP e la porta del client, l'indirizzo IP e la porta del server TURN, e il numero di canale. Questa particolare combinazione è leggermente più facile da indovinare rispetto al caso non-TURN.
Questi attacchi sono meglio mitigati attraverso tecniche di autenticazione a livello di applicazione. Nel caso di traffico in tempo reale, l'uso di SRTP [RFC3711] può prevenire questi attacchi.
In alcuni casi, il server TURN potrebbe essere situato nella rete in modo tale da poter inviare a host che il client stesso non può raggiungere direttamente. Ad esempio, se il server si trova dietro un firewall che consente ai pacchetti provenienti dall'esterno del firewall di passare al server, ma non ad altri host dietro il firewall. In questi casi, un attaccante potrebbe essere in grado di inviare un'indicazione Send al server con un attributo XOR-PEER-ADDRESS contenente l'indirizzo di trasporto di uno degli altri host dietro il firewall. Se il server consente di inoltrare il traffico a qualsiasi peer, questo fornirebbe all'attaccante un modo per attaccare un host arbitrario dietro il firewall.
Per mitigare questo attacco, TURN richiede che il client stabilisca un permesso verso un host prima di inviargli dati. Pertanto, l'attaccante può attaccare solo gli host con cui il client ha già comunicato, a meno che l'attaccante non sia in grado di creare richieste autenticate. Inoltre, un amministratore del server può configurare il server per restringere l'intervallo di indirizzi IP e porte a cui inoltrerà i dati. Per fornire una sicurezza ancora maggiore, un amministratore del server può richiedere che il client utilizzi TLS per tutte le comunicazioni tra client e server.
17.1.5. Impersonificazione di un server (Impersonating a Server)
Quando un client apprende l'indirizzo inoltrato da un server TURN, utilizza quell'indirizzo inoltrato in un protocollo applicativo per ricevere traffico. Pertanto, un attaccante che desidera intercettare o reindirizzare quel traffico potrebbe tentare di impersonare il server TURN e fornire al client un indirizzo inoltrato falsificato.
Questo attacco viene prevenuto attraverso il meccanismo di credenziali a lungo termine, che fornisce integrità dei messaggi per le risposte e autentica che provengono dal server. Inoltre, un attaccante non può riprodurre vecchie risposte del server, perché l'ID di transazione nell'intestazione STUN lo impedisce. Gli attacchi di replay sono ulteriormente scoraggiati cambiando frequentemente il valore nonce.
17.1.6. Intercettazione del traffico (Eavesdropping Traffic)
TURN si occupa principalmente di autenticazione e integrità dei messaggi. La riservatezza è solo una preoccupazione secondaria, poiché i messaggi di controllo TURN non contengono informazioni particolarmente sensibili. Il contenuto protocollare principale dei messaggi è gli indirizzi IP dei peer. Se è importante impedire a un intercettatore su una connessione TURN di apprendere questo, TURN può essere eseguito su TLS.
La riservatezza dei dati applicativi inoltrati da TURN è meglio fornita dal protocollo applicativo stesso, poiché l'esecuzione di TURN su TLS non proteggerà i dati applicativi tra il server e il peer. Se la riservatezza dei dati applicativi è importante, l'applicazione dovrebbe cifrare o proteggere altrimenti i suoi dati. Ad esempio, per i media in tempo reale, la riservatezza può essere fornita utilizzando SRTP.
17.1.7. Attacco di loop TURN (TURN Loop Attack)
Un attaccante potrebbe tentare di far ciclare indefinitamente i pacchetti di dati tra due server TURN. L'attacco procede come segue. Innanzitutto, l'attaccante invia una richiesta Allocate al server A con un indirizzo sorgente del server B. Il server A invia la sua risposta al server B, e affinché l'attacco abbia successo, l'attaccante deve essere in grado di vedere o indovinare il contenuto di questa risposta in modo che l'attaccante possa apprendere l'indirizzo di trasporto inoltrato allocato. L'attaccante invia quindi una richiesta Allocate al server B con un indirizzo sorgente del server A. Ancora una volta, l'attaccante deve essere in grado di vedere o indovinare il contenuto della risposta in modo che l'indirizzo di trasporto inoltrato allocato possa essere appreso. Utilizzando le stesse tecniche di indirizzo sorgente falsificato, l'attaccante lega quindi un numero di canale sul server A all'indirizzo di trasporto inoltrato sul server B e lega similmente lo stesso numero di canale sul server B all'indirizzo di trasporto inoltrato sul server A. Infine, l'attaccante invia un messaggio ChannelData al server A.
Il risultato è un pacchetto di dati che cicla dall'indirizzo di trasporto inoltrato sul server A all'indirizzo di trasporto inoltrato sul server B, quindi dall'indirizzo di trasporto sul server B all'indirizzo di trasporto sul server A, quindi cicla di nuovo.
La mitigazione contro questo attacco è la seguente. Richiedendo che le richieste siano autenticate e/o randomizzando il numero di porta assegnato per l'indirizzo di trasporto inoltrato, il server costringe l'attaccante a intercettare o vedere le risposte inviate a terze parti (in questo caso, l'altro server) affinché l'attaccante possa autenticare la richiesta e apprendere l'indirizzo di trasporto inoltrato. Senza una di queste due misure, l'attaccante può indovinare il contenuto della risposta senza doverla vedere, il che rende l'attacco più facile da eseguire. Inoltre, richiedendo richieste autenticate, il server costringe l'attaccante ad avere credenziali che il server accetterà, il che lo rende un attacco interno invece che esterno e consente di risalire all'attacco fino al client che lo ha lanciato.
Ulteriore mitigazione può essere ottenuta imponendo limiti per nome utente sulla larghezza di banda utilizzata dalle allocazioni appartenenti a quel nome utente per l'inoltro dei dati, per limitare l'impatto di questo attacco su altre allocazioni. Ulteriore mitigazione può essere ottenuta decrementando il TTL quando si inoltrano pacchetti di dati (se il sistema operativo sottostante lo consente).
17.2. Considerazioni sui firewall (Firewall Considerations)
Una considerazione chiave sulla sicurezza per TURN è che TURN non dovrebbe indebolire le protezioni offerte da un firewall distribuito tra il client e il server TURN. Si prevede che i server TURN saranno spesso presenti sulla rete Internet pubblica, mentre i client potrebbero spesso trovarsi all'interno di una rete aziendale servita da un firewall aziendale. Se il server TURN fornisce una "porta sul retro" nell'azienda, TURN sarà bloccato da questi firewall.
Pertanto, un server TURN emula il comportamento di un dispositivo NAT che implementa il filtraggio dipendente dall'indirizzo [RFC4787], che è una proprietà comune in molti firewall. Quando un NAT o firewall implementa questo comportamento, i pacchetti provenienti da un indirizzo IP esterno sono autorizzati a essere inviati a un indirizzo IP interno e una porta solo se l'indirizzo IP interno e la porta hanno recentemente inviato un pacchetto a quell'indirizzo IP esterno. Un server TURN introduce il concetto di permessi, che fornisce esattamente lo stesso comportamento sul server TURN. Un attaccante non può inviare un pacchetto a un server TURN e aspettarsi che venga inoltrato a un client a meno che il client non abbia prima cercato di contattare l'attaccante.
È importante notare che le politiche di alcuni firewall sono ancora più rigorose del filtraggio dipendente dall'indirizzo. I firewall possono anche essere configurati per il filtraggio dipendente dall'indirizzo e dalla porta, o possono essere configurati per non consentire affatto il traffico in entrata. In questi casi, la comunicazione con un client sarebbe meno limitata di quanto il firewall normalmente consenta, se al client è consentito connettersi a un server TURN.
17.2.1. Permessi falsificati (Faked Permissions)
Nei firewall e nei dispositivi NAT, i permessi vengono concessi implicitamente dai pacchetti che attraversano dall'interno della rete verso il peer esterno. Pertanto, per definizione, i permessi non possono essere creati da alcuna entità al di fuori del firewall o NAT. Con TURN, questa restrizione non è più valida. Poiché il server TURN si trova all'esterno del firewall, un attaccante all'esterno del firewall può ora inviare messaggi al server TURN e tentare di creare permessi per se stesso.
Questo attacco viene bloccato perché tutti i messaggi che creano permessi (cioè ChannelBind e CreatePermission) sono autenticati.
17.2.2. Indirizzi IP nella lista nera (Blacklisted IP Addresses)
Molti firewall possono essere configurati con liste nere per impedire ai client dietro il firewall di inviare pacchetti o ricevere pacchetti da intervalli di indirizzi IP nella lista nera. Questo viene realizzato esaminando rispettivamente gli indirizzi sorgente e di destinazione dei pacchetti che entrano e escono dal firewall.
Questa capacità è presente anche in TURN, poiché al server TURN è consentito di restringere arbitrariamente l'intervallo di indirizzi di peer verso cui inoltrerà.
17.2.3. Esecuzione di server su porte note (Running Servers on Well-Known Ports)
Un client malevolo dietro un firewall potrebbe tentare di connettersi a un server TURN e ottenere un'allocazione, che può quindi utilizzare per eseguire un server. Ad esempio, il client potrebbe tentare di eseguire un server DNS o un server FTP.
Questo non è possibile con TURN. Un server TURN non accetterà mai traffico da un peer per il quale il client non ha installato un permesso. Pertanto, un peer non può semplicemente connettersi alla porta allocata per ottenere il servizio.
17.3. Attacchi interni (Insider Attacks)
In un attacco interno, il client ha credenziali legittime ma viola la relazione di fiducia che accompagna quelle credenziali. Questi attacchi non possono essere prevenuti attraverso mezzi crittografici ma devono essere considerati nella progettazione del protocollo.
17.3.1. DoS contro il server TURN (DoS against TURN Server)
Un client che desidera interrompere il servizio ad altri client potrebbe ottenere un'allocazione e quindi inondarlo di traffico, nel tentativo di sopraffare il server e impedirgli di servire altri client legittimi. Questo viene mitigato raccomandando che il server limiti la quantità di larghezza di banda che inoltrerà per un determinato nome utente. Questo non impedisce al client di inviare una grande quantità di traffico, ma consente al server di eliminare immediatamente il traffico in eccesso.
Poiché ogni allocazione utilizza un numero di porta sull'indirizzo IP del server TURN, il numero di allocazioni sul server è finito. Un attaccante potrebbe tentare di consumare tutte le allocazioni richiedendo un gran numero di allocazioni. Questo viene prevenuto attraverso la raccomandazione che il server imponga un limite sul numero di allocazioni attive contemporaneamente per un determinato nome utente.
17.3.2. Inoltro anonimo di traffico malevolo (Anonymous Relaying of Malicious Traffic)
Un server TURN fornisce un certo grado di anonimizzazione. Un client può inviare dati a un peer senza rivelare il proprio indirizzo IP. Pertanto, un server TURN potrebbe diventare uno strumento attraente per gli attaccanti per lanciare attacchi contro un obiettivo senza timore di rilevamento. Infatti, un client potrebbe concatenare più server TURN insieme, in modo che un numero arbitrario di relay venga utilizzato prima che il pacchetto di dati arrivi all'obiettivo.
Un amministratore preoccupato per questo attacco può mantenere registri che catturano l'IP sorgente effettivo e la porta del client, e possibilmente anche ogni permesso che quel client ha installato. Questo consentirebbe il tracciamento forense per determinare la sorgente originale, se un attacco viene scoperto essere inoltrato attraverso un server TURN.
17.3.3. Manipolazione di altre allocazioni (Manipulating Other Allocations)
Un attaccante potrebbe tentare di interrompere il servizio ad altri utenti del server TURN inviando richieste Refresh o CreatePermission che (attraverso lo spoofing dell'indirizzo sorgente) sembrano provenire da un altro utente del server TURN. TURN previene questo richiedendo che le credenziali utilizzate nei messaggi CreatePermission, Refresh e ChannelBind corrispondano alle credenziali utilizzate per creare l'allocazione iniziale. Pertanto, le richieste falsificate da un attaccante verranno rifiutate.
17.4. Altre considerazioni (Other Considerations)
Qualsiasi indirizzo inoltrato appreso tramite una richiesta Allocate non funzionerà correttamente con IPsec Authentication Header (AH) [RFC4302] in modalità trasporto o tunnel. Tuttavia, IPsec Encapsulating Security Payload (ESP) [RFC4303] in modalità tunnel dovrebbe comunque funzionare.