Esiste un modo sicuro per avere un server terminal rivolto pubblicamente?

Question

Esiste un modo sicuro per avere un server terminal rivolto pubblicamente?

#1 da (12 voti)
#2 da (1 voti)
#3 da (1 voti)

17

TL; DR Stiamo osservando la porta di apertura 3389 per un terminal server, tutto il consiglio che ho visto è che è un suicidio ma senza una buona spiegazione del perché. E 'davvero così male?

Stiamo cercando di configurare un server terminal per consentire al personale di accedere da remoto. Useranno un sacco di dispositivi tra cui iPad, Android Divices, Windows (XP a 8), OSX, Linux, praticamente qualsiasi cosa con un client RDP.

Voglio che questo sia stupido e che lavori su tutto. Il mio piano è quello di impostare remote.example.com (ovviamente con il nostro vero nome di dominio) per puntare al nostro server e poi proteggerlo con:

Firewall tutto tranne la porta 3389.
Imposta il livello di crittografia al massimo (con un certificato) e non consentire "Negoziare"
Blocca gli account con più di 7 tentativi falliti e osserva forse alcuni script da bloccare in base agli indirizzi IP con accessi non riusciti ( link )
Altre cose ovvie come aggiornamenti del sistema operativo e antivirus.

Tuttavia, quando parlo di impostare un RDP pubblico di fronte, le risposte sono generalmente in linea con:

"Non aprire la porta 3389 mettere una VPN di fronte ad esso" - ma per quanto posso vedere i due argomenti principali per questo sono la crittografia (RDP non lo fa già? ) e una migliore autenticazione perché la forza bruta della forza RDP. Abbiamo già una configurazione VPN PPTP ma utilizza lo stesso account username / password combo per autenticarsi come il nostro Terminal Server, quindi non vedo un server terminal che aggiunge alla nostra superficie di attacco. L'unica argomentazione che ritengo sia di importanza fondamentale è la creazione di una VPN (come Cisco) che supporta l'autenticazione a due fattori, che suona bene ma riduce enormemente il numero di dispositivi supportati.

"Non farlo, usa un Gateway RD" Per quanto posso vedere leggendo link i vantaggi di un Gateway RD sono:

Gestisci più server da un singolo punto di ingresso con controllo a grana fine su chi può connettersi a cosa e così via. - Sembra buono, ma abbiamo solo un server terminal.

Utilizza la porta 443 / HTTPS per consentire alle persone dietro firewall in uscita configurati in modo non corretto di connettersi: sembra eccezionale ma RDP offre già la crittografia e la modifica della porta non aggiunge sicurezza. Inoltre, per l'estrema facilità di non dover gestire i firewall in uscita, viene a mancare il supporto della maggior parte dei client RDP (l'ultima volta che ho controllato che i client OSX non potessero connettersi al Gateway RD)

"Non usare RDP, usa (Hamachi / Team Viewer / Jump Desktop / VNC ... seriamente / qualche altro tool RDP) è più sicuro" Per me uno di questi suggerimenti passa dal mettere tutte le uova in un cesto (Microsoft) a mettere tutte le uova in un altro paniere (Hamachi) ma senza vantaggi tangibili per la sicurezza.

Sono solo sprezzante? Una cattiva idea è quella di impostare un server RDP di fronte pubblico?

access-control rdp

posta Hybrid 09.04.2013 - 10:56

fonte

3 risposte

1

È possibile utilizzare OpenVPN, che è separato dai metodi VPN di Windows. È possibile installare un server ssh (come Bitvise WinSSHD) e tunnelare tutto il traffico su SSH. Non posso dirti se questo è più sicuro della situazione attuale però.

risposta data 22.05.2014 - 12:51

fonte

1

Ci sono alcuni modi per proteggere RDP.

Non utilizzare la porta pubblica # 3389. È il modo migliore per ridurre la forza bruta atemps.
Consenti solo determinati indirizzi IP (o intervallo di IP) all'IP pubblico. Usa router intelligenti. Uso mikrotik ( link ) o Cisco.
Configura il blocco del firewall per molti tentativi. Uso strumenti di terze parti per bloccare il traffico. Uno strumento gratuito è tratto dal link . Ce ne sono molti altri ma questo mi piace perché è gratuito. Questo strumento analizza i log degli eventi per gli accessi non riusciti e quindi aggiunge IP a Windows Firewall per il blocco.

risposta data 14.01.2016 - 17:19

fonte

Leggi altre domande sui tag access-control rdp

Lastpass hack: rischi di abuso L'uso di una VPN protegge contro KRACK?

score 12 · Accepted Answer

RDP è un protocollo complesso che richiede implementazioni complesse e quindi può contenere bug. Le versioni iniziali del protocollo non includevano molta crittografia. Le versioni successive sono migliori e possono utilizzare un sistema di crittografia fatto in casa (che può o non può utilizzare un certificato per incorporare la chiave pubblica del server), o SSL / TLS (che utilizza necessariamente un certificato del server). Nota che, in quest'ultimo caso, i record TLS sono incapsulati in pacchetti specifici per RDP, quindi non puoi accontentarti dicendo "questo è solo SSL".

Non esiste una ragione concettuale che renda l'RDP intrinsecamente insicuro; ma l'intera torre dei protocolli interni e la mancanza generale di documentazione decente sono un problema. È già difficile sapere quali funzionalità saranno supportate da un determinato client. L'implementazione di Microsoft ha avuto il suo sacco di exploit remoti, ad es. questo e quello che .

La risposta di Microsoft è che se si desidera la sicurezza, è necessario Remote Desktop Gateway, che aggiunge un altro livello, ma all'esterno: uno standard SSL / TLS, con autenticazione utente e RDP in (così si finisce con un sandwich SSL-RDP-SSL-RDP). L'idea è che un server SSL pubblico è una situazione nota con codice che è stato completamente sottoposto a debugging, attraverso anni di esposizione (in IIS, per server Web HTTPS). Gateway RD non impedirà i buchi RDP, ma gli exploit saranno limitati alle persone che possono passare attraverso SSL esterno, cioè persone che possono aprire una sessione sul server stesso e che hanno già molta potenza. Ovviamente RD Gateway non è gratuito, quindi è interesse di Microsoft vendere licenze per questo.

Si noti che il supporto client per Gateway RD non è un dato, quando il software client non è l'implementazione di Microsoft.

Per riassumere , c'è solo una fonte autorevole per RDP (Microsoft) e loro stessi hanno rinunciato all'idea di affermare che il loro prodotto è sufficientemente libero da errori di pubblico. Questo non promette nulla di buono. Alcuni dei discorsi allarmistici sull'argomento potrebbero essere spinti dall'urgenza di vendere licenze RD Gateway, ma è logico che rendere sicura l'implementazione RDP di Microsoft sia difficile, a causa della complessità e della lunga storia del codice.