quanta minaccia alla sicurezza sarebbe?

Avresti due tipi di rischi:

1. Potrebbe esserci un difetto nel codice del server. Questa è una situazione generica per ogni server, ma un server Desktop remoto è noto per essere relativamente complesso, e quindi probabilmente ha bug più sfruttabili, ad esempio, di un server SSH. La stessa Microsoft offre un prodotto aggiuntivo chiamato Gateway Desktop remoto (precedentemente noto come Gateway Servizi terminal ) che funge da passaggio intermedio. Il gateway esegue un server SSL "normale" sulla porta 443 e può eseguire un'autenticazione dell'utente, ma è molto più semplice (e quindi si presume che sia più potente) di un server Desktop remoto completo, poiché in realtà non gestisce il Protocollo Desktop remoto: lo inoltra semplicemente al server Desktop remoto effettivo.

   Si noti che tra i possibili "difetti" in Desktop remoto è configurazione , in particolare per quanto riguarda i certificati. Un server di base Desktop remoto può utilizzare vari livelli di crittografia, alcuni personalizzati, alcuni incapsulati SSL. Un punto critico è che, a seconda della configurazione e su come l'utente lo gestisce, il client potrebbe non convalidare correttamente il certificato del server (in particolare quando il certificato del server è stato generato automaticamente ed è auto- firmato). In tal caso, il client è aperto a un attacco Man-in-the-Middle . Anche in questo caso, il Gateway rende le cose più robuste, in quanto implementa un modello di server SSL molto simile al Web che è più difficile da configurare in modo errato.

2. Se un utente è autorizzato ad aprire una sessione sul server, in virtù della presentazione di una password corrispondente e tale password è debole, un utente malintenzionato potrebbe eseguire un attacco dizionario , che significa provare le password possibili finché non viene trovato quello giusto. Si tratterebbe di un attacco di dizionario online e potresti notare automaticamente un attacco così continuo a causa dell'enorme quantità di eventi di "accesso non riuscito". Tuttavia, se l'utente malintenzionato ha esito positivo, può eseguire codice arbitrario sulla macchina. L'escalation dei privilegi su una macchina locale tende a funzionare (i difetti localmente sfruttabili sono molto più comuni di quelli remoti), quindi in pratica hai perso.

   L'unica buona difesa contro le password deboli è quella di educare gli utenti a scegliere password più forti. Come misura di mitigazione, puoi anche limitare l'accesso a Desktop remoto a alcuni utenti specifici; per impostazione predefinita, solo i membri del gruppo Remote Desktop Users locale potranno aprire una sessione. Il tuo primo passo dovrebbe essere quello di decidere chi è autorizzato a farlo sulla macchina (come suggerisce @Hennes, dato che la macchina è un controller di dominio, l'elenco delle persone a cui è consentito aprire una sessione dovrebbe essere limitato al solo l'amministratore o stai sbagliando)

Remote Desktop Gateway non è gratuito e tende a richiedere una macchina aggiuntiva. Un'alternativa più economica è quella di implementare una soluzione VPN come OpenVPN (il software di base è GPL, non è necessaria alcuna licenza). Questo è funzionalmente equivalente. Tuttavia, non farà nulla contro le password deboli.