Domanda:
Quanto è sicuro RDP?
prot
2016-08-09 14:09:29 UTC
view on stackexchange narkive permalink

Ho una sorta di conflitto con il responsabile della sicurezza della mia azienda. Dice che il protocollo RDP (Remote Desktop Protocol) non è abbastanza sicuro e dovremmo invece utilizzare TeamViewer. Utilizziamo RDP non solo per accedere alle risorse locali all'interno della nostra rete aziendale ma anche per l'accesso alle risorse (con Windows 2012+) nell'hosting cloud.

In entrambi gli scenari quanto è sicuro usare RDP?

Come viene utilizzato (o proposto di essere utilizzato) il PSR?Aprire la porta 3389 di fronte a Internet su tutti i server di produzione e chiamarla un giorno è una cattiva idea per la sicurezza.Ci sono molte opzioni all'interno di Windows per rendere RDP più efficace, quindi la risposta a quanto sia sicuro un metodo di gestione remota di hosting cloud basato su RDP sarebbe: "forse"
TeamViewer è molto, molto meno sicuro di RDP.Con una configurazione RDP correttamente configurata, puoi avere un sistema abbastanza sicuro, ma con TW, i tuoi sistemi vengono compromessi [se ** fanno ** un errore] (http://www.theregister.co.uk/2016/06/ 01 / teamviewer_mass_breach_report /).
Non permetterei mai a teamviewer come soluzione di accesso remoto.RDP all'interno di una VPN
Nella maggior parte dei provider di servizi cloud come azure e aws, puoi configurare gruppi di sicurezza e consentire solo il traffico rdp da iOS autorizzato
Uno dei problemi con TW, che RDP impedisce per impostazione predefinita, è: "Chi muove il mio mouse !?";)
Scusa, ma come fa una persona del genere ad arrivare a un punto della vita in cui ha il titolo di "Security Lead Engineer"?Hanno vinto una lotteria?
@underscore_d Non correlato alla domanda ... ma apparentemente erano un membro di un team di sicurezza e promossi a capo del team, o sono stati assunti direttamente come capo del team.Proprio come qualsiasi altro lavoro al mondo.
@TylerH e come hanno ottenuto una posizione in quel team di sicurezza (e non l'hanno persa) in primo luogo?
@underscore_d Non sappiamo ancora come fosse organizzata la rete di prot.L'ingegnere capo della sicurezza potrebbe opporsi all'esposizione di un server RDP a Internet, non all'uso di RDP stesso.
@enkryptor ma in che modo sostituire RDP con la TV renderebbe le cose migliori, se non molto peggiori?La TV mostra ancora le porte conosciute, giusto?e _è_ un MITM?e ha avuto incidenti nella memoria recente?e significa [il computer a cui ti connetti viene lasciato con la tua sessione in esecuzione in modalità sbloccata, rivolta al pubblico, disponibile a chiunque pensi di accendere lo schermo] (http://security.stackexchange.com/a/133468/ 81253)?Se l'OP ha dettagli che lo renderebbero ragionevole, allora certo, potrebbe rivelarsi una decisione molto ben ragionata ... ma non la vedo così com'è
@underscore_d "La TV mostra ancora le porte note, giusto?"- no, il suo client lavora attraverso il server.Non è necessario aprire le porte di ascolto
Really TV serve a fornire supporto IT per workstation alle persone in remoto.È abbastanza buono per questo e molto utile che la persona che stai aiutando possa chattare con te e vedere lo schermo mentre fornisci supporto.Questo è ciò a cui limiterei la TV.Per l'accesso remoto ai server come altri hanno affermato che RDP su VPN è una soluzione molto migliore.
Se non si desidera aprire una porta di ascolto per RDP, è possibile connettersi alla macchina tramite connessione inversa (ad esempio tunnel SSH inverso).
RDP su SSH (lo uso da Linux per accedere a box Windows e Linux da remoto).
Dieci risposte:
#1
+90
symcbean
2016-08-09 16:18:02 UTC
view on stackexchange narkive permalink

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ì.

Come fai a sapere se RDP utilizza TLS?(Presumo che tu intendessi TLS invece di SSL effettivo.)
Sì, TLS.La connessione tunnel utilizza la porta 443 per impostazione predefinita (il vecchio stile RDP utilizza 3389 dalla memoria).C'è anche un'opzione durante la configurazione del server.
RDP utilizzerà una connessione TLS se il server è configurato con un certificato (Windows Server 2012 e versioni successive utilizzano un certificato autofirmato per impostazione predefinita, Windows desktop non IIRC) anche sulla porta 3389.
@TheD RDP sulle versioni desktop di Windows utilizza anche TLS, anche se con certificati autofirmati (a meno che non si unisca a un dominio).
@symcbean È possibile eseguire TeamViewer in modalità locale, nel qual caso ci si connette tramite un indirizzo IP invece di utilizzare un "ID TeamViewer" e rimbalzare sui loro server.Lo uso sempre su VPN (e anche su LAN senza connessione Internet).Questo cambia qualcuno dei tuoi punti?
@JasonC Riduce TeamViewer a un semplice clone RDP / VNC, con tutti gli svantaggi che RDP ha, oltre alla natura di terze parti di TeamViewer (un'altra parte di cui fidarsi).
#2
+71
H. Idden
2016-08-10 00:24:38 UTC
view on stackexchange narkive permalink

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.

Molti di questi punti scompaiono quando esegui TeamViewer in modalità locale.In tal caso ti connetti tramite IP invece di un numero ID e non tocchi mai i loro server (funziona anche su una LAN senza connessione Internet).
@JasonC Non ho ancora visto questa funzione.Avrò bisogno di controllare questo.Questo cambierebbe indead alcuni di questi punti.Ma il problema relativo alla capacità di controllo e al fatto che si ottiene lo schermo / utente come se fosse stato lasciato dall'ultimo rimane ancora (potrebbe o non potrebbe essere un problema a seconda dell'azienda).
L'utilizzo della "modalità locale" non è ovvio;lato server, vai in Extra -> Opzioni -> Generale e scegli "accetta esclusivamente" per "Connessioni LAN in entrata".Stranamente, a volte l'interfaccia utente diventa buggata e devi farlo anche sul lato * client * per inserire indirizzi IP invece di ID (aggiungendo all'elenco delle stranezze TV che infrangono la fiducia).Il lato client potrebbe comportarsi meglio nelle versioni più recenti.
Fino all'ultimo punto, la TV ha un software aziendale per controllare tutto ciò.Quindi non è proprio un punto
@Insane grazie per le informazioni.Questa funzionalità è stata aggiunta dopo l'ultima volta che ho esaminato TeamViewer in modo più completo.
Grazie per tutti i commenti.Ho aggiunto le informazioni alla risposta.
#3
+36
SilverlightFox
2016-08-10 14:34:56 UTC
view on stackexchange narkive permalink

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.

Di tutti i punti positivi contro la TV qui, questo potrebbe essere quello che salta fuori e urla "evita come una piaga" il più sfacciato di tutti.Non so se ridere o piangere.
@underscore_d Tieni presente che questa è una cosa che le persone potrebbero desiderare intenzionalmente in alcuni scenari, come il supporto remoto: se l'utente dall'altra parte può vedere (più o meno) quello che stai facendo, è più rassicurante per loro, cherende meno probabile che provino a sostenere che hai fatto qualcosa di dannoso durante la tua sessione di supporto.
#4
+26
Daniel Bungert
2016-08-09 21:04:22 UTC
view on stackexchange narkive permalink

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]
Potrebbe anche voler sottolineare che forzare TLS 1.2 può rompere altre cose (vale a dire SQL Server).È una buona misura di sicurezza, ma fai attenzione quando lo abiliti.
@cybermonkey Il software di rottura che non supporta TLS 1.2 è * una buona cosa *: P
#5
+16
Rory McCune
2016-08-09 21:32:18 UTC
view on stackexchange narkive permalink

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.

#6
+10
Jean-Bernard Pellerin
2016-08-11 22:53:05 UTC
view on stackexchange narkive permalink

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.

#7
+7
Criggie
2016-08-11 02:23:03 UTC
view on stackexchange narkive permalink

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à.

#8
+6
coteyr
2016-08-13 01:22:15 UTC
view on stackexchange narkive permalink

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.

Ho avuto questa esatta conversazione con il mio CIO su più questioni.Anche se riconosce che le soluzioni proposte dal nostro team sono probabilmente superiori, il valore di trasferire gli scenari peggiori a una terza parte vale di più dal punto di vista esecutivo.
#9
+4
bshea
2016-08-10 22:07:38 UTC
view on stackexchange narkive permalink

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.

Vedi anche @Criggie answer re: VPN -> anche un'altra opzione molto buona ..
#10
+3
Overmind
2016-08-09 17:05:58 UTC
view on stackexchange narkive permalink

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.

RDP utilizza i certificati per autenticare il server.Puoi attaccarlo solo con MiTM, se accetti certificati non validi!
Quindi sembra che il blocco del certificato o semplicemente l'uso di RDP su una VPN (che è anche il metodo prescritto di TeamViewer, no?) Dovrebbe essere sicuro?
@Josef Quanto è spaventoso l'avvertimento sul certificato non valido e la maggior parte degli utenti lo riconoscerà e farà qualcosa o lo accetterà comunque?
Se configuri correttamente i criteri di gruppo e hai una CA interna che ha firmato i certificati, non ci sono messaggi da accettare, funziona solo con certificati validi e non funziona con altri.È così che si fa in un'azienda.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...