Credo che Teamviewer sia un servizio proxy per le connessioni VNC tunnellizzate. Quindi, la prima considerazione di sicurezza riguardo a quel servizio è che è MITM by design . Ci sono stati suggerimenti che il servizio è stato compromesso un paio di mesi fa.

(Tieni presente che sebbene VNC utilizzi la crittografia, l'intero scambio non è, per impostazione predefinita, incapsulato, ma è banale per configurare un tunnel SSL / ssh / VPN).

La considerazione successiva è che significa installare software di terze parti sui tuoi sistemi, ma poi se stai utilizzando una piattaforma Microsoft, stai già eseguendo software da più fornitori che probabilmente non è coperto dal software di gestione delle patch; mantenere il software aggiornato è uno dei mezzi più efficaci per proteggere i tuoi sistemi.

Finché la tua connessione RDP utilizza SSL, dovrebbe essere sicura almeno quanto Teamviewer e IMHO, molto di più così.

Modifica: secondo i commenti sembra esserci una combinazione di opzioni di configurazione nell'edizione aziendale di TeamViewer che potrebbe ridurre le mie preoccupazioni. Dato che non li ho mai usati, non posso dare una valutazione su quelli e su come funzionano bene. Secondo i commenti potrebbe essere una soluzione difettosa.

Sono un amministratore di server (Windows e Linux) e bloccherei qualsiasi tentativo di installare TeamViewer sui server per i seguenti motivi:

• tutti i dati viaggiano su un server di terze parti affidabile (?) e questo è su Internet: perché dovrei fidarmi di loro? Sei sicuro che non ci siano falle di sicurezza che permettano a qualcuno sul percorso dati di attaccare i sistemi? Confido che i loro server non vengano compromessi?
• dipende da Internet: i problemi di rete / Internet hanno maggiori probabilità di disabilitare la possibilità di amministrare in remoto i sistemi
• terzo- software closed source di terze parti con protocollo proprietario (non documentato?): devo fidarmi di loro e che il loro protocollo è sicuro?
• Non conosco la gestione degli utenti / diritti per TeamViewer ma questo potrebbe anche essere un problema. Per quanto ne so, TeamViewer ti dà la schermata dell'utente attualmente connesso, il che potrebbe dare problemi con gli audit (quale persona ha eseguito una determinata azione?) E i diritti utente (la persona che si connette ottiene i diritti dell'utente connesso precedente). Spero che tutti abbiano il proprio utente sul server e non utilizzino lo stesso utente (forse anche amministratore!).

Per me ci sono troppe bandiere rosse.

I nostri server si trovano in una sottorete isolata in cui il firewall / switch consente l'accesso solo a porte preconfigurate e consente agli utenti di connettersi con VPN a questa sottorete con il proprio nome utente / password. Seguiamo un approccio difesa in profondità : solo alcuni gruppi ottengono il privilegio di connettersi alla VPN con il proprio utente. All'interno della VPN, possono utilizzare RDP o SSH. Se dovesse esserci una vulnerabilità di sicurezza in RDP, l'aggressore dovrebbe prima accedere a VPN o LAN. Ciò significherebbe che potrebbero essere il nostro personale IT (di cui un'azienda deve fidarsi in una certa misura), avere accesso a VPN o accesso fisico o hackerare uno dei server. Accesso fisico significa irruzione nel datacenter; se questo accade, ci sono preoccupazioni maggiori. Lo stesso vale per qualcuno del personale IT che si rivolge alla posta. Se violano uno dei server, avrebbero 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 privilegi VPN.

E tutto questo solo nel caso in cui ci sia una vulnerabilità RDP. Molto probabilmente solo un utente malintenzionato classificato come una minaccia persistente avanzata ( APT), vale a dire qualcuno che utilizza tecniche sofisticate per prendere di mira il tuo sistema specifico in un attacco prolungato, avrebbe un exploit 0 giorni per RDP ed è più probabile che un tale utente malintenzionato possa utilizzare metodi / vulnerabilità più semplici in altri software.

Oltre alle altre ottime risposte, TeamViewer offre meno sicurezza fisica perché richiede che lo schermo sia sbloccato per facilitare una sessione remota.

Ovvero, chiunque passi davanti a una tastiera e monitor di una sessione amministrata in remoto può osservarlo ed eventualmente assumere il controllo della sessione se l'utente remoto non sta prestando attenzione.

Nota, sembra possibile oscurare lo schermo dopo l'installazione di un display driver, tuttavia questo deve essere fatto su ogni connessione lasciando una finestra di opportunità.

Inoltre, ora ti affidi alla sicurezza della cancellazione dello schermo di TeamViewer piuttosto che alla sicurezza della schermata di blocco di Windows: assicurati che ti senti a tuo agio.

Per iniziare, non so nulla di TeamViewer, quindi non cercherò di commentarlo.

I server RDP storici utilizzavano "RDP Security", che in effetti è un protocollo rotto e vulnerabile al MITM. Non farlo. Anche 2003r2 può eseguire TLS per RDP, quindi non c'è alcun motivo moderno per cui dovresti essere costretto a utilizzare RDP Security.

I server moderni supporteranno TLS, quindi la sicurezza di RDP è direttamente correlata alla sicurezza di TLS. Con le modifiche al registro puoi applicare un sottoinsieme di TLS che ti piace: forzare a 1.2, limitare a determinate suite di cifratura, forse altre cose.

Inoltre, qui c'è un angolo specifico RDP in cui il server può limitare 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. Ritengo che ciò sia inteso a proteggere da un attacco di negazione del servizio in cui utenti non autenticati tentano ripetutamente di connettersi senza autenticarsi.

Se dovessi decrittografare e tracciare una sessione TLS RDP utilizzando NLA, vedresti quanto segue:

• X.224 Exchange, non crittografato, 1 pacchetto in ciascuna direzione per determinare se client e server possono parlare NLA
• Handshake TLS
• Scambio NLA (in realtà [MS-CSSP]) per eseguire l'autenticazione
• Scambio normale del protocollo RDP per [MS-RDPBCGR]

Supponendo che tu stia utilizzando una versione moderna di RDP e la configuri correttamente (es. abilita NLA, risolvi i certificati appropriati) il rischio principale di esporlo direttamente a Internet tende ad essere il problema di esporre un'autenticazione con nome utente / password sistema a Internet, ovvero che stai consentendo agli aggressori di tentare di forzare gli account Active Directory (supponendo che si tratti di un ambiente AD e non di un insieme di server autonomi).

Questo non è " Ottimo se si finisce con un rischio DoS con blocco dell'account impostato o un rischio di accesso non autorizzato senza alcun blocco dell'account impostato (qualcuno sceglierà sempre una password debole o ne userà una che viene violata altrove), quindi se stai esponendo RDP direttamente consiglierei l'autenticazione a due fattori agli utenti a cui è consentito l'accesso tramite questo meccanismo.

Per quanto riguarda TeamViewer, non c'è il rischio di accesso diretto ma ci si fida di loro come organizzazione e è stato sottolineato da altre risposte che hanno avuto problemi di sicurezza di recente tly.

Espanderò la spiegazione di Daniel Bungert dei protocolli coinvolti e del 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 vorrei essere ...)

Puoi configurarlo per funzionare solo su TLS. Ciò offre una grande sicurezza di per sé, ogni messaggio è avvolto con crittografia TLS. Esistono criteri di gruppo che è possibile gestire che imposteranno i protocolli di crittografia TLS consentiti. Puoi usarlo per specificare solo quelli con lunghezze di chiave o algoritmi che ritieni adatti. Queste sono impostazioni generali di Windows e non specifiche per rdp. La tua unica preoccupazione sarebbe che gli utenti accettassero certificati non validi, nel qual caso è possibile un attacco MitM.

Tuttavia, è possibile configurarlo ulteriormente per funzionare solo con l'autenticazione NLA. In particolare, questo utilizzerà CredSSP con NTLM. Ciò impedisce MitM perché il certificato utilizzato nel livello TLS viene utilizzato (insieme ad altre cose) per crittografare la password. Non è quindi più possibile inoltrare semplicemente la password crittografata perché il servizio rdp di destinazione non autenticherà 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 le 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 è al sicuro dagli utenti che potrebbero accettare certificati non validi. Questo contrasta le preoccupazioni di Overmind sugli attacchi mitm.

Andrei con una sorta di VPN dal computer remoto dell'utente a un firewall al lavoro, quindi eseguirò RDP su quel collegamento crittografato.

Il problema nel lasciare una porta aperta è che alla fine lo è trovato e avrai tentativi di accesso a forza bruta. O questo rallenterà semplicemente il tuo ambiente, o porterà al blocco degli account, oppure troveranno un nome utente con una password debole (c'è sempre quell'unico utente ....)

Puoi esplorare 2 fattore di autenticazione con app per smartphone, token hardware o password monouso prestampate.

Ricorda, la sicurezza è l'opposto della comodità.

Questo è iniziato come un commento.

È importante sottolineare la "domanda chi è in colpa". Se utilizzi un servizio di terze parti e loro non riescono a fornire, è il loro fallimento nel fornire. Se usi qualcosa in casa e non funziona, ora è colpa della casa. Tali distinzioni hanno molto peso. Potrebbe non significare nulla per la sicurezza effettiva, ma a volte può andare in disparte.

Ad esempio, se è necessario ottenere la certificazione per un contratto e tale certificazione dice qualcosa sull'effetto di:

È necessario utilizzare metodi di gestione remota sicuri, gestione remota non crittografata metodi non sono consentiti. È consentito stipulare contratti con una terza parte per fornire servizi. La crittografia deve essere basata sulla forza e sui requisiti della barra. I servizi comuni che soddisfano questi requisiti sono LogMeIn e TeamViewer. I servizi comuni che non soddisfano questi requisiti sono GoToMyPC e il semplice VNC.

Quindi si potrebbe decidere di utilizzare Team Viewer.

Poi c'è il rischio per l'azienda. Si potrebbe sostenere che Teamviewer è meno rischioso, perché stai utilizzando un servizio in buona fede che dovrebbe essere sicuro. Allo stesso tempo, l'RDP può essere più un rischio perché ora stai confrontando la conoscenza del tuo team con la comprensione di persone a caso.

Alla fine, anche se questo non ha alcun legame reale con la sicurezza reale, è importante ricordare che le aziende non fanno sicurezza perché le fa guadagnare (normalmente). Lo fanno come mitigazione del rischio e perché devono continuare a fare soldi. L'utilizzo di un servizio di terze parti può eliminare alcuni dei rischi per l'azienda.

Come accennato, dovresti usare RDP + Encryption, se possibile. Tuttavia, non ho visto alcuna menzione di misure di sicurezza di base contro gli attacchi (bruti o di altro tipo) nelle risposte fornite.

QUALSIASI software / porta che viene lasciato aperto al pubblico è verrà scansionato / trovato. Periodo. RDP o no. Crittografia o no. Se l'accesso pubblico non è necessario, perché consentirlo?

La creazione e l'amministrazione di un elenco "consenti" basato su blocchi IP può richiedere molto tempo e un problema (se molti host accedono), ma non dovrebbe esserlo trascurato. Che si tratti di 1 IP o centinaia di IP di rete separati.

Hai menzionato un server basato su "cloud". Quindi, ad esempio, su AWS / ec2, si dovrebbe utilizzare un gruppo di sicurezza EC2 per consentire alcuni IP o reti di amministrazione e negare il resto. La maggior parte dei provider ha metodi simili.

Il punto è (e oltre alle risposte fornite): RDP sarebbe la mia scelta, ma niente di perfetto. Diventa ancora più imperfetto se non stai bloccando le reti indesiderate.

Su RDP puoi 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.

Per quanto riguarda Teamviewer, devi fidarti di una terza parte, che non è l'opzione che molti sceglierebbero.

Per quanto riguarda un migliore caso, dovresti impostare la tua VPN basata su certificati.