Ho una specie di conflitto con il responsabile della sicurezza della mia azienda. Dice che Remote Desktop Protocol (RDP) non è abbastanza sicuro e dovremmo usare TeamViewer . Usiamo RDP non solo per accedere alle risorse locali all'interno della nostra rete aziendale, ma anche per l'accesso alle risorse (con Windows 2012 e versioni successive) nel cloud hosting.
In entrambi gli scenari, quanto è sicuro utilizzare RDP?
Credo che Teamviewer sia un servizio proxy per le connessioni VNC con tunnelling. Quindi, la prima considerazione di sicurezza riguardo a quel servizio è che è MITM di design . Ci sono stati suggerimenti che il servizio era compromesso un paio di mesi fa .
(Si noti che sebbene VNC utilizzi la crittografia, l'intero scambio non è, per impostazione predefinita, incapsulato, ma è banale impostare un tunnel SSL / ssh / VPN).
La prossima considerazione è che significa installare software di terze parti sui tuoi sistemi, ma se stai utilizzando una piattaforma Microsoft, stai già eseguendo software da più fornitori che probabilmente non è coperto dal software di gestione delle patch; tenere aggiornato il software è uno dei mezzi più efficaci per proteggere i tuoi sistemi.
Finché la connessione RDP utilizza SSL, dovrebbe essere almeno altrettanto sicuro di Teamviewer e IMHO, molto di più.
Modifica Secondo i commenti sembra esserci una combinazione di opzioni di configurazione nell'edizione aziendale di TeamViewer che potrebbe ridurre le mie preoccupazioni. Dal momento che non li ho mai usati, non posso dare una valutazione su questi e quanto bene funzionano. Secondo i commenti potrebbe essere una soluzione bacata.
Sono un amministratore del server (Windows e Linux) e vorrei bloccare qualsiasi tentativo di installare TeamViewer sui server per i seguenti motivi:
Per me, ci sono troppe bandiere rosse.
I nostri server si trovano in una sottorete isolata in cui il firewall / switch consente solo porte preconfigurate e consente agli utenti di connettersi con VPN a questa sottorete con il loro nome utente / password. Seguiamo un approccio di difesa in profondità : solo determinati gruppi ottengono il privilegio di connettersi alla VPN con il loro utente. All'interno della VPN, possono utilizzare RDP o SSH. Se dovesse esserci una vulnerabilità di sicurezza in RDP, l'utente malintenzionato dovrebbe prima accedere a VPN o LAN. Ciò significherebbe che sarebbe il nostro personale IT (di cui una società deve fidarsi in una certa misura), ottenere l'accesso a VPN o accesso fisico o hackerare uno dei server. Accesso fisico significa irrompere nel datacenter; se questo accade, ci sono preoccupazioni più grandi. Lo stesso vale per qualcuno del personale IT che va in giro. Se violano uno dei server, hanno anche bisogno di una vulnerabilità di escalation dei privilegi per attaccare perché sono account bloccati. Per l'accesso VPN, avrebbe bisogno di una vulnerabilità nella VPN o ottenere l'account di qualcuno con i privilegi VPN.
E tutto questo solo nel caso in cui ci sia una vulnerabilità RDP. Molto probabilmente solo un attaccante classificato come minaccia persistente avanzata ( APT ), vale a dire qualcuno che usa tecniche sofisticate per indirizzare il tuo sistema specifico in un attacco prolungato, avrebbe un exploit a 0 giorni per RDP ed è più probabile che un tale aggressore sarebbe in grado di utilizzare metodi / vulnerabilità più semplici in altri software.
Oltre alle altre ottime risposte, TeamViewer offre meno sicurezza fisica perché richiede lo sblocco dello schermo per facilitare una sessione remota.
Cioè, chiunque passi davanti a una tastiera e monitor di una sessione amministrata in remoto può osservarlo e eventualmente occuparsi della sessione se l'utente remoto non sta prestando attenzione.
Si noti che è possibile oscurare lo schermo dopo l'installazione di un driver video, tuttavia ciò deve essere fatto su ogni connessione lascia una finestra di opportunità.
Inoltre, ora ti stai fidando della sicurezza della soppressione dello schermo di TeamViewer piuttosto che della sicurezza della schermata di blocco di Windows - assicurati di esserne a tuo agio.
Per iniziare, non so nulla su TeamViewer, quindi non cercherò di commentarlo.
I server RDP storici hanno utilizzato "Protezione RDP", che è in effetti un protocollo interrotto e vulnerabile al MITM. Non farlo. Anche 2003r2 può fare TLS per RDP, quindi non c'è alcun motivo moderno per cui dovresti essere costretto a usare la sicurezza RDP.
I server moderni supporteranno TLS, quindi la sicurezza di RDP è direttamente correlata alla sicurezza di TLS. Con le modifiche del registro puoi applicare un sottoinsieme di TLS che ti piace: forzare a 1.2, limitare ad alcuni pacchetti di crittografia, forse altre cose.
Inoltre, qui c'è un angolo specifico RDP in quanto il server può limitare le connessioni solo a quelle che supportano "Autenticazione a livello di rete". NLA utilizza ancora TLS, è solo una modifica del protocollo per eseguire l'autenticazione in precedenza nello scambio. Credo che questo sia inteso a proteggere da un attacco denial of service in cui gli utenti non autenticati tentano ripetutamente di connettersi senza autenticazione.
Se dovessi decrittografare e tracciare una sessione TLS RDP usando NLA, vedresti quanto segue:
Supponendo che si stia utilizzando una versione moderna di RDP e configurata correttamente (ad es. abilitare NLA, ordinare i certificati appropriati), il rischio principale di esporlo direttamente a Internet tende a essere il problema dell'esposizione di un nome utente / password di autenticazione sistema a Internet, che consente agli aggressori di tentare di eseguire la bruta forza degli account di Active Directory (supponendo che si tratti di un ambiente AD e non di un gruppo di server autonomi).
Questo non è il massimo perché si finisce con un rischio DoS con blocco account bloccato o con un rischio di accesso non autorizzato senza blocco account (qualcuno sceglierà sempre una password debole o userà quella che viene violato altrove), quindi se stai esponendo RDP direttamente raccomanderei l'autenticazione a due fattori agli utenti a cui è consentito l'accesso tramite questo meccanismo.
Per quanto riguarda TeamViewer, non c'è il rischio di un accesso diretto, ma ci si sta fidando di loro come organizzazione ed è stato sottolineato da altre risposte che hanno avuto problemi di sicurezza di recente.
Espanderò la spiegazione di Daniel Bungert dei protocolli coinvolti e il motivo per cui lavorano insieme. Avendo scritto un proxy MitM per RDP, ho molta familiarità con il funzionamento interno della maggior parte dei protocolli coinvolti. (Più di quanto mi piacerebbe essere ...)
Puoi configurarlo per operare solo su TLS. Questo offre una grande sicurezza nel suo pieno, ogni messaggio è avvolto con la crittografia TLS. Esistono politiche di gruppo che è possibile gestire che imposteranno i protocolli di crittografia TLS consentiti. È possibile utilizzare questo per specificare solo quelli con lunghezze chiave o algoritmi che si ritengono adatti. Queste sono le impostazioni generali di Windows e non specifiche per rdp. La tua unica preoccupazione sarebbero gli utenti che accettano certificati errati, nel qual caso è possibile un attacco MitM.
Tuttavia, è possibile configurarlo ulteriormente per operare solo con l'autenticazione NLA. In particolare, utilizzerà CredSSP con NTLM. Ciò impedisce a MitM di utilizzare il certificato utilizzato nel livello TLS (insieme ad altre cose) per crittografare la password. Non è più possibile inoltrare la password crittografata perché il servizio rdp di destinazione non autentica un hash generato con un certificato diverso dal proprio. Il motivo per cui il mio mitm funziona è perché conosciamo le password che vengono utilizzate per connettersi al proxy e con ciò possiamo estrarre informazioni e generare un nuovo hash per il servizio rdp di destinazione. Un proxy rdp dannoso non avrà questo vantaggio.
Quindi, con TLS e NLA configurati, rdp è sicuro dagli utenti che potrebbero accettare certificati errati. Questo neutralizza le preoccupazioni di Overmind sugli attacchi di mitm.
Vado con una specie di VPN dal computer remoto dell'utente a un firewall al lavoro, quindi eseguo RDP su quel collegamento crittografato.
Il problema di lasciare una porta aperta è che alla fine è stato trovato e avrai dei tentativi di accesso a forza bruta. O rallenterà l'ambiente, o causerà il blocco degli account, oppure troverà un nome utente con una password debole (c'è sempre un utente ...)
Puoi esplorare l'autenticazione a 2 fattori con app per smartphone, token hardware o password monouso prestampate.
Ricorda che la sicurezza è l'opposto della convenienza.
Questo è iniziato come commento.
È importante sottolineare la domanda "Chi è in difetto". Se si utilizza un servizio di terze parti e non si riesce a fornire è il loro fallimento di fornire. Se usi qualcosa in casa e fallisce, ora è colpa della casa. Queste distinzioni hanno molto peso. Potrebbe non significare nulla per la sicurezza reale, ma a volte può andare in disparte.
Ad esempio se è necessario ottenere la certificazione per un contratto e tale certificazione dice qualcosa con l'effetto di:
You must use secure remote management methods, unencrypted remote management methods are not allowed. Contracting with a third party to provide services is allowed. Encryption must be foo strength and bar requirements. Common services that meet theses requirements are LogMeIn and TeamViewer. Common services that do not meet these requirements are GoToMyPC and plain VNC.
Quindi potrebbe essere presa la decisione di utilizzare Team Viewer.
Quindi c'è il rischio per il business. Si potrebbe sostenere che Teamviewer è meno rischioso, in quanto si utilizza un servizio in buona fede che dovrebbe essere sicuro. Allo stesso tempo, il RDP potrebbe essere più rischioso perché ora puoi mettere al corrente la conoscenza della tua squadra rispetto alla comprensione casuale delle persone.
Alla fine, anche se questo non ha alcuna connessione reale con la sicurezza reale, è importante ricordare che le aziende non fanno sicurezza perché fanno soldi (normalmente). Lo fanno come mitigazione del rischio e perché devono continuare a fare soldi. L'utilizzo di un servizio di terze parti può eliminare parte del rischio per l'azienda.
Come già detto dovresti usare RDP + Encryption se possibile. Ma, non ho visto alcuna menzione delle misure di sicurezza di base contro gli attacchi (bruti o meno) nelle risposte fornite.
QUALSIASI software / porta / e che rimane aperto al pubblico verrà scansionato / trovato. Periodo. RDP o no. Crittografia o no. Se l'accesso pubblico non è necessario perché permetterlo?
La creazione e l'amministrazione di un elenco 'consenti' basato su IP Blocks può richiedere molto tempo e un problema (se molti host accedono), ma non dovrebbe essere trascurato. Che si tratti di 1 IP o centinaia di IP di rete separati.
Hai menzionato un server basato su "cloud". Ad esempio, su AWS / ec2, si dovrebbe usare un gruppo di sicurezza EC2 per consentire alcune reti IP o di amministrazione e negare il resto. La maggior parte dei provider ha metodi simili.
Il punto è (e in aggiunta alle risposte fornite): RDP sarebbe la mia scelta, ma niente di perfetto. Diventa ancora più imperfetto se non blocchi le reti indesiderate.
Su RDP è possibile eseguire un attacco MiTM e quindi tutto il traffico dal server RDP al client RDP e viceversa passerà attraverso il nostro sistema MiTM. Questo è il motivo per cui non è considerato sicuro.
Come per Teamviewer, devi fidarti di una terza parte, che non è l'opzione che molti vorrebbe fare.
Come nel caso migliore, dovresti configurare la tua VPN basata su certificati.
Leggi altre domande sui tag rdp windows-server