1 14/10/2026 8 min

Su una VPS Windows Server la porta RDP non si cambia “solo” nel Registro: se tocchi un lato e dimentichi l’altro, ti ritrovi con un host vivo ma irraggiungibile. La sequenza corretta è semplice: prima apri una porta alternativa, poi aggiorni la configurazione RDP, infine verifichi accesso e regole firewall prima di chiudere la 3389. Su VPSie il punto critico è sempre lo stesso: la console del provider è il tuo paracadute, quindi non fare il cambio da una sessione RDP unica senza un canale di accesso alternativo.

Questo è un cambio controllato, non un fix da emergenza. L’obiettivo è ridurre l’esposizione della porta standard senza perdere accesso amministrativo. Se la tua esigenza è sicurezza reale, la porta diversa aiuta solo a ridurre rumore e scansioni banali; non sostituisce MFA, account nominativi, NLA, patching e firewall restrittivo. La regola operativa è: prima osservi, poi modifichi, poi verifichi. Se qualcosa va storto, rollback immediato alla 3389 usando la console VPSie o una sessione PowerShell già aperta.

Perché la porta RDP va cambiata con metodo

RDP ascolta di default su TCP 3389. Cambiare porta significa intervenire su due punti distinti: il listener di Windows e il filtro di rete. Se aggiorni solo il listener, il firewall locale o quello del provider continueranno a bloccare il traffico. Se apri solo il firewall, il servizio continuerà ad ascoltare sulla porta vecchia. Il risultato tipico è un timeout, non un errore esplicito, quindi senza verifica rischi di attribuire il problema alla rete quando in realtà è la configurazione del server.

Su una VPS Windows Server l’approccio migliore è usare una porta alta e poco usata, ad esempio tra 40000 e 50000, evitando porte note già occupate da servizi di sistema o da software di terze parti. Non scegliere numeri “creativi” ma poco documentati: la porta deve essere facile da ricordare per te e improbabile da colpire per scansione casuale.

Verifiche prima del cambio

Prima di toccare la configurazione, verifica tre cose: accesso alternativo, stato del servizio RDP e regole firewall attive. Se hai una console web VPSie, tienila aperta fino alla fine. Se non hai una console, il cambio non è prudente.

Dal prompt amministrativo, puoi controllare che Remote Desktop sia attivo e che il servizio base sia in esecuzione:

sc query termservice

Atteso: stato RUNNING. Se non lo è, non cambiare porta finché non capisci perché il servizio è fermo. Un listener non attivo rende inutile qualsiasi modifica al firewall.

Controlla anche quale porta sta ascoltando il sistema prima del cambio:

netstat -ano | findstr :3389

Atteso: una riga in LISTENING con PID del processo associato. Se non compare nulla, la macchina potrebbe già avere una configurazione anomala o il servizio non è partito correttamente.

Se vuoi un controllo più pulito via PowerShell, puoi anche leggere il valore di registro che governa la porta RDP:

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' | Select-Object PortNumber

Atteso: PortNumber espresso in decimale. Se il valore è già diverso da 3389, non dare per scontato che il firewall sia coerente: verifica anche le regole in ingresso.

Scelta della porta e blast radius

La scelta della porta è il punto con il blast radius più ampio, perché un errore qui ti taglia fuori da remoto. Usa una porta TCP alta, per esempio 44889 o 49152, e annotala prima di applicarla. Evita porte condivise con altri servizi, porte note di applicazioni aziendali e numeri già usati dalle tue policy firewall. Se gestisci più server, standardizza: una porta per ambiente o una regola per range, ma non inventare porte diverse per ogni macchina senza una tabella di mapping.

Rollback previsto: riportare il valore di registro a 3389 e aprire di nuovo la relativa eccezione firewall. Questo deve essere possibile dalla console VPSie o da una sessione amministrativa già aperta, altrimenti il change non è reversibile in sicurezza.

Modifica della porta RDP passo per passo

Il metodo più lineare è agire con il Registro di sistema e poi allineare firewall e verifica. Puoi farlo anche da GUI, ma in amministrazione operativa la sequenza con PowerShell è più chiara e lascia traccia ripetibile.

  1. Apri PowerShell come amministratore.

  2. Decidi la nuova porta, ad esempio 44889. Prima di applicarla, verifica che non sia già in uso:

    netstat -ano | findstr :44889

    Atteso: nessun output. Se compare una riga LISTENING, scegli un’altra porta.

  3. Scrivi il nuovo valore nel registro:

    Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 44889

    Il valore viene salvato come DWORD. Se vuoi controllarlo subito:

    Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' | Select-Object PortNumber

  4. Aggiorna il firewall locale con una regola dedicata alla nuova porta. Se mantieni una policy restrittiva, crea prima la regola e solo dopo chiudi la vecchia:

    New-NetFirewallRule -DisplayName 'RDP custom 44889' -Direction Inbound -Protocol TCP -LocalPort 44889 -Action Allow

    Atteso: regola presente in Get-NetFirewallRule con porta corretta.

  5. Se hai una regola esplicita per 3389, disabilitala solo dopo avere verificato l’accesso sulla nuova porta. Non cancellarla subito se non hai ancora testato da fuori.

  6. Riavvia il servizio RDP oppure, più semplicemente, riavvia la macchina in una finestra controllata. Il riavvio del servizio può non essere sufficiente in tutti gli scenari se ci sono sessioni attive e policy locali particolari. La via più pulita è un reboot breve se il server lo consente:

    shutdown /r /t 0

    Se non puoi riavviare, almeno verifica dopo la modifica che il listener sia sulla nuova porta con netstat.

Se preferisci la GUI, il percorso standard è il Registro: regedit → HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp → PortNumber. Il valore va impostato in decimale. Il vantaggio della GUI è la leggibilità; il difetto è che non documenta bene il change se non fai uno screenshot o una nota operativa.

Allineare il firewall di Windows e quello del provider

Il firewall locale non è l’unico gate. Su VPSie devi considerare anche eventuali filtri lato pannello, security group o regole anti-DDoS se presenti nel piano. Prima di dichiarare il cambio concluso, controlla che il traffico TCP in ingresso sulla nuova porta sia consentito lungo tutto il percorso.

Nel firewall di Windows puoi visualizzare le regole attive con:

Get-NetFirewallRule | Where-Object {$_.DisplayName -like '*RDP*'} | Select-Object DisplayName, Enabled, Direction, Action

Atteso: la nuova regola è Enabled e Inbound/Allow. Se hai creato una regola specifica, puoi anche verificare il porto associato:

Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq 44889}

Se VPSie offre un firewall esterno nel pannello, apri la porta TCP scelta e limita l’origine ai tuoi IP amministrativi. Se la piattaforma consente il whitelist per sorgente, usa un range ristretto; se non lo consente, valuta seriamente un accesso tramite VPN o jump host invece di esporre RDP a tutto Internet.

Verifica da client: non fidarti del solo server

La verifica corretta non è “il servizio è su”, ma “riesco a connettermi dall’esterno sulla nuova porta”. Da un client di amministrazione, prova prima la raggiungibilità TCP e poi l’accesso RDP.

Per il test di porta, da PowerShell su un host esterno:

Test-NetConnection -ComputerName tuo-host-o-ip -Port 44889

Atteso: TcpTestSucceeded : True. Se è False, il problema è prima del login: firewall, route, regola VPSie o listener non attivo.

Per il client RDP, l’accesso va esplicitato con porta custom, ad esempio in mstsc:

mstsc /v:tuo-host-o-ip:44889

Se usi un file .rdp, la riga rilevante è:

full address:s:tuo-host-o-ip:44889

Se la connessione apre ma fallisce dopo l’autenticazione, il problema non è più la porta: spostati su NLA, credenziali, policy locali o stato account. In quel caso il cambio porta è riuscito, ma il guasto è a livello di autenticazione o sessione.

Rollback rapido se perdi l’accesso

Se la nuova porta non risponde e non hai una sessione alternativa, non insistere con tentativi ripetuti. Il rollback più veloce è ripristinare la 3389 dal canale console VPSie o da PowerShell locale. La sequenza è identica al cambio, ma al contrario.

  1. Apri la console VPSie o una sessione già attiva.

  2. Ripristina il valore del registro a 3389:

    Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 3389

  3. Riattiva o ricrea la regola firewall per 3389 se l’hai rimossa:

    New-NetFirewallRule -DisplayName 'RDP 3389 rollback' -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow

  4. Verifica il listener:

    netstat -ano | findstr :3389

  5. Se necessario, riavvia il server in finestra di manutenzione.

Rollback del blast radius: basso, perché stai solo riportando il servizio allo stato standard. Il rischio vero è quando hai già chiuso 3389 senza confermare il funzionamento della nuova porta. Per questo la vecchia regola non va eliminata prima del test esterno positivo.

Controlli finali che vale la pena lasciare in checklist

Dopo il cambio, conserva una mini-checklist operativa per i server Windows su VPSie:

  • porta RDP documentata nel runbook;

  • regola firewall Windows allineata alla nuova porta;

  • eventuale firewall del provider aggiornato;

  • accesso testato da rete esterna con Test-NetConnection;

  • console VPSie verificata come accesso di emergenza;

  • eventuale eccezione 3389 rimossa solo dopo validazione completa.

Se vuoi alzare il livello di sicurezza, la porta custom è solo il primo passo. La difesa vera è limitare gli IP sorgente, tenere aggiornato Windows Server, usare account amministrativi separati, attivare NLA, disabilitare gli account inutilizzati e monitorare i tentativi di accesso. Su una VPS esposta, ridurre il rumore su RDP è utile; ridurre la superficie d’attacco è necessario.

Assunzione operativa: il server è una VPS Windows Server su VPSie con accesso amministrativo e possibilità di usare la console web del provider in caso di errore.