Remote Desktop Protocol (RDP) resta uno strumento essenziale per amministrare sistemi Windows e pubblicare sessioni remote, ma diventa un rischio elevato quando è esposto direttamente a Internet o protetto soltanto da username e password. CISA include esplicitamente RDP tra i servizi che non dovrebbero essere pubblicati direttamente sul web; Microsoft raccomanda Network Level Authentication e fornisce architetture come Remote Desktop Gateway con MFA per ridurre il rischio di accesso non autorizzato.
Il punto non è “rendere sicura la porta 3389”. La strategia corretta è ridurre la superficie di attacco, verificare l’identità prima della sessione, limitare i privilegi, proteggere le credenziali amministrative, segmentare il traffico RDP e rendere ogni accesso osservabile. Se un server non richiede realmente RDP, la misura più efficace rimane disabilitarlo.
RDP e ransomware: perché il rischio non è solo il brute force
Un attaccante può ottenere un account valido tramite password spray, credential stuffing, phishing, malware infostealer o compromissione di un fornitore. Se trova un servizio RDP pubblicato o raggiungibile da un segmento troppo ampio, può usarlo per stabilire una sessione interattiva, raccogliere ulteriori credenziali, elevare i privilegi, spostarsi lateralmente e distribuire payload ransomware.
Per questo la difesa non può fermarsi alla password complessa o al cambio della porta. Il controllo deve essere multilivello: esposizione, autenticazione, autorizzazione, protezione delle credenziali, patching, segmentazione, detection e recovery.
1. Elimina l’RDP esposto direttamente a Internet
La priorità è verificare se esistono host con TCP/UDP 3389 raggiungibile direttamente da Internet. Se non strettamente necessario, chiudi l’esposizione sul firewall e rimuovi le regole NAT/port-forwarding. Una modifica della porta predefinita può ridurre il rumore generato da scanner automatici, ma non deve essere considerata una misura di sicurezza: un servizio esposto resta individuabile.
Per l’accesso remoto dall’esterno, le architetture preferibili sono:
- Remote Desktop Gateway, che pubblica l’accesso RDS tramite HTTPS/TLS e consente policy centralizzate.
- RD Gateway integrato con Microsoft Entra MFA tramite Network Policy Server (NPS) Extension.
- ZTNA/SASE quando l’obiettivo è pubblicare la sola applicazione o risorsa autorizzata senza estendere l’accesso alla rete interna.
- VPN solo quando necessaria e con MFA, patching, segmentazione e policy least-privilege; la VPN non va considerata automaticamente equivalente a Zero Trust.
2. MFA prima della sessione, non solo password
Una password robusta riduce alcuni attacchi opportunistici, ma non protegge un account le cui credenziali siano già state sottratte. Per gli accessi remoti occorre introdurre un secondo fattore prima che la sessione RDP venga autorizzata. Microsoft documenta l’integrazione di RD Gateway, NPS e Microsoft Entra MFA proprio per questo scenario.
In ambienti con accessi privilegiati, separa gli account amministrativi dagli account di produttività quotidiana. Un account usato per e-mail, navigazione o attività office non dovrebbe essere lo stesso usato per amministrare server via RDP.
3. Mantieni NLA e TLS correttamente configurati
Network Level Authentication (NLA) richiede l’autenticazione prima della creazione della sessione remota e riduce l’esposizione del server a connessioni anonime o non autenticate. Microsoft raccomanda di mantenerla attiva nella maggior parte degli ambienti moderni.
Le distribuzioni RDS devono inoltre usare certificati attendibili per i ruoli interessati. TLS protegge il canale e il certificato consente al client di verificare l’identità del server, riducendo il rischio di intercettazione e man-in-the-middle.
4. Limita chi può usare RDP e da dove
Il diritto “Allow log on through Remote Desktop Services” deve essere assegnato solo a utenti o gruppi che hanno una reale necessità operativa. Evita l’aggiunta indiscriminata di utenti a gruppi privilegiati e preferisci gruppi dedicati per ruolo, server o funzione.
Non applicare ricette generiche come “rimuovi sempre Administrators”: i valori corretti dipendono dal ruolo del sistema. Sui domain controller, ad esempio, Microsoft mantiene l’accesso RDP per gli amministratori e raccomanda un modello specifico. Qualsiasi modifica a User Rights Assignment deve essere testata in ambiente controllato e distribuita con change management.
Quando possibile, limita anche la provenienza delle connessioni: subnet amministrative, jump host, management network o policy ZTNA. Il principio è semplice: il server deve accettare RDP solo dai punti da cui l’accesso è realmente necessario.
5. Proteggi le credenziali degli amministratori
Una sessione RDP verso un server già compromesso può trasformarsi in un problema di credential theft. Per scenari amministrativi compatibili, Remote Credential Guard può ridurre questo rischio: le credenziali e i loro derivati non vengono consegnati al sistema remoto e le richieste Kerberos vengono reindirizzate al dispositivo da cui parte la connessione.
Questa protezione deve inserirsi in un modello più ampio: account amministrativi separati, privilegi minimi, workstation amministrative protette, hardening Active Directory e controllo delle deleghe.
6. Riduci brute force e password spray
Se RDP è raggiungibile da una rete non completamente fidata, il controllo delle autenticazioni fallite è essenziale. Applica account lockout e policy coerenti con il rischio, MFA sul punto di ingresso e restrizioni di rete. Evita soglie improvvisate che possano facilitare denial-of-service tramite blocco intenzionale degli account.
La pagina Nexsys “Remote Desktop e Brute Force RDP” deve rimanere l’approfondimento specifico sulla tecnica di attacco; questa pagina deve limitarsi a collegarla come rischio da mitigare.
7. Patch Windows Server, gateway e componenti di accesso
Mantieni aggiornati Windows Server, i client di amministrazione, RD Gateway, VPN appliance e qualunque componente intermedio usato per l’accesso remoto. Un’architettura corretta perde valore se il punto di ingresso espone vulnerabilità note o configurazioni obsolete.
Il patching deve essere accompagnato da vulnerability management: inventario degli asset esposti, scansioni periodiche e verifica delle configurazioni che riaprono porte o pubblicazioni non autorizzate.
8. Segmenta RDP per limitare il lateral movement
RDP non deve diventare un protocollo liberamente utilizzabile tra ogni workstation e ogni server. Definisci flussi espliciti: chi può amministrare cosa, da quali subnet e attraverso quali jump host o gateway. Blocca il traffico RDP laterale non necessario e separa le reti utenti, server, management e asset critici.
La segmentazione riduce il blast radius: anche se un endpoint viene compromesso, l’attaccante non deve poter usare RDP per attraversare indisturbato l’intera infrastruttura.
9. Centralizza logging e detection
Un controllo RDP efficace deve essere osservabile. Centralizza almeno i log di autenticazione e delle sessioni, correlandoli con EDR/XDR e SIEM. I segnali tipici includono numerosi logon falliti, accessi riusciti da origini anomale, attività fuori orario, creazione di nuovi account privilegiati e sequenze di movimento laterale.
Nel log di sicurezza Windows, Event ID 4624 e 4625 aiutano a distinguere autenticazioni riuscite e fallite; i log TerminalServices forniscono ulteriore contesto sulle sessioni. In un SOC questi eventi devono essere correlati, non semplicemente archiviati.
10. EDR/XDR anche sui server raggiungibili via RDP
L’accesso RDP legittimo può essere abusato da un account compromesso e quindi non generare necessariamente un exploit di rete. Un EDR/XDR sul server consente di rilevare ciò che avviene dopo il logon: credential dumping, esecuzione anomala di PowerShell, disattivazione delle difese, discovery, persistence e distribuzione del ransomware.
La sicurezza del protocollo e la protezione dell’endpoint sono controlli complementari: nessuno dei due sostituisce l’altro.
11. Backup e recovery: il controllo finale
Se un attaccante supera i controlli di accesso, l’organizzazione deve poter ripristinare sistemi e dati senza dipendere dall’infrastruttura compromessa. I backup devono essere protetti da credenziali amministrative separate, includere copie immutabili o isolate e soprattutto essere sottoposti a test di restore periodici.
Un ransomware che entra via RDP non deve poter raggiungere con la stessa identità anche console di backup, repository e hypervisor. La separazione amministrativa è parte integrante della resilienza.
Accesso RDP: proteggere la rete dall'esterno e dall'interno
Probabilmente non è necessario sottolineare quanto sia importante proteggere la rete aziendale dall’esterno. Nel contesto degli attacchi RDP è importante applicare alcune misure di sicurezza interne. I PC che possono essere controllati da remoto dovrebbero essere in grado di utilizzare le risorse di rete ma non di distruggerle. Utilizzare politiche restrittive per tenere a bada i possibili danni che qualsiasi utente, non solo remoto, può scatenare.
Attacco ransomware tramite RDP
In caso di attacco ransomware tramite RDP, è bene adottare alcune misure per proteggere meglio la rete e gli endpoint. Dopo aver recuperato i file da un backup, è necessario controllare i sistemi per eventuali modifiche apportate dagli aggressori che renderebbero loro una visita futura più facile, specie se si è deciso di pagare il riscatto.
Per essere sicuri che non ci siano refusi, è necessario controllare non solo il PC in cui è stato eseguito il collegamento remoto per trovare Trojan backdoor e strumenti di hacking, ma anche tutti i dispositivi in rete a cui è stato possibile accedere dal PC compromesso.
Accesso RDP: ma è davvero indispensabile?
Anche se si seguono tutte le linee guida di sicurezza, ci sono sempre possibili punti deboli in RDP che possono essere sfruttati. Nessuno desidera introdurre queste debolezze nella rete se effettivamente non ce n'è davvero bisogno. Le possibili conseguenze potrebbero essere devastanti, soprattutto senza una strategia di backup efficace.
Proteggere i tuoi dati aziendali richiede attenzione e precisione, occorre affidarsi ad aziende in grado di garantire ottime difese. Nexsys ti supporta nella definizione delle copie dei tuoi dati e nella gestione dei salvataggi per evitare perdite e danni, attraverso il servizio di backup aziendale.
Nexsys propone, inoltre, corsi con lo scopo di educare gli utenti ad un uso consapevole e responsabile dei mezzi informatici ed insegna agli amministratori di sistema le migliori strategie affinché possano mitigare ogni possibile attacco. Scopri, ad esempio, il corso di Cybersecurity Awareness che mira proprio a far comprendere agli utenti aziendali il proprio ruolo nella difesa delle informazioni sensibili.