Cambiare la porta RDP con SCCM, PowerShell e Registro

La porta RDP non si cambia “perché sì”: si cambia quando c’è una ragione operativa precisa, ad esempio ridurre il rumore sugli scan automatici, separare ambienti, o applicare una policy di hardening coerente. Il punto critico non è il valore in sé, ma il modo in cui lo propaghi senza perdere l’accesso amministrativo. Con SCCM, PowerShell e Registro di sistema puoi farlo in modo ordinato, ma solo se tratti l’operazione come un change controllato: prima identifichi il layer, poi distribuisci la modifica, poi verifichi che il firewall, il servizio RDP e il listener siano allineati.

La regola pratica è semplice: la porta RDP vive nel Registro, ma il traffico passa davvero solo se anche il firewall e gli eventuali controlli di sicurezza la consentono. Per questo il cambio va sempre fatto in tre punti: PortNumber nel registro, regola firewall coerente, e conferma lato servizio. Se cambi solo il registro, il server ascolta sulla nuova porta ma resta di fatto irraggiungibile; se cambi solo il firewall, non succede nulla; se cambi entrambi senza verificare, rischi di tagliarti fuori dal sistema remoto.

Il punto esatto del Registro da modificare

La chiave usata da Remote Desktop Services è questa:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Il valore da cambiare è PortNumber, di tipo DWORD. Il sistema si aspetta il numero in formato decimale o esadecimale a seconda dello strumento usato, ma il dato finale è sempre lo stesso. Per esempio, la porta 3390 corrisponde a 0x00000d3e, mentre 3389 è 0x00000d3d. Non c’è magia: il listener RDP legge quel valore al riavvio del servizio o della macchina, quindi il cambio non è istantaneo in tutti i casi.

Prima di toccare il valore, conviene leggere lo stato attuale e salvarlo. Con PowerShell puoi farlo così:

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

Se vuoi esportare il ramo per rollback, puoi usare reg.exe o PowerShell. Il backup del solo ramo RDP è sufficiente nella maggior parte dei casi:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" C:\Temp\RDP-Tcp-backup.reg /y

Questo backup non sostituisce uno snapshot o un punto di ripristino, ma per un change mirato è il minimo sindacale. Se il server è critico, il rollback deve essere già scritto prima di iniziare.

Perché SCCM qui ha senso

SCCM non serve solo a “spingere un comando”. Serve a distribuire la modifica in modo tracciabile, con collection mirate, maintenance window e reporting. In un ambiente con decine o centinaia di server, il vantaggio è evitare interventi manuali incoerenti e avere una prova di esecuzione. La porta RDP è una configurazione locale, ma l’uso di SCCM ti permette di standardizzarla per gruppi di sistemi, ad esempio:

Il rischio da tenere presente è il blast radius: se la collection è troppo ampia o il comando è errato, il cambio si propaga ovunque. Per questo la distribuzione va fatta in due fasi: prima un gruppo pilota, poi il resto. Il rollback deve essere altrettanto semplice: ripristino del valore precedente nel registro e riapertura della porta vecchia nel firewall, se necessario.

Script PowerShell per cambiare porta e aggiornare il firewall

Il metodo più pulito è uno script PowerShell che legge la porta corrente, imposta la nuova, e aggiorna una regola firewall dedicata. Evita di sovrascrivere regole esistenti senza controllo: meglio creare una regola esplicita per RDP che hai generato tu, così il rollback è lineare.

$NewPort = 3390
$RegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
$OldPort = (Get-ItemProperty -Path $RegPath).PortNumber

Set-ItemProperty -Path $RegPath -Name PortNumber -Type DWord -Value $NewPort

$ruleName = 'RDP Custom Port'
if (Get-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue) {
    Set-NetFirewallRule -DisplayName $ruleName -Enabled True
    Set-NetFirewallPortFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -DisplayName $ruleName) -Protocol TCP -LocalPort $NewPort
} else {
    New-NetFirewallRule -DisplayName $ruleName -Direction Inbound -Action Allow -Protocol TCP -LocalPort $NewPort -Profile Any
}

Qui c’è un dettaglio importante: Set-NetFirewallPortFilter non è sempre la strada più comoda se la regola non esiste già o se vuoi mantenere compatibilità tra versioni. In molti casi conviene cancellare e ricreare la regola dedicata, ma solo se hai controllo pieno sul naming e sul rollback. Se vuoi ridurre il rischio, crea una regola nuova e lascia la vecchia disabilitata finché non hai verificato il login remoto sulla nuova porta.

Per applicare il cambio in modo affidabile, spesso basta riavviare il servizio o, nei casi più conservativi, la macchina. Sul piano operativo, la verifica più utile non è “il comando è andato a buon fine”, ma “il server ascolta davvero sulla nuova porta”.

Get-NetTCPConnection -LocalPort 3390 -State Listen
netstat -ano | findstr :3390

Se non vedi il listener, il cambio nel registro non è stato applicato al servizio in esecuzione. In quel caso la falsificazione più rapida è controllare se il servizio RDP è stato riavviato e se il firewall non sta già bloccando la porta.

Distribuzione con SCCM: package, application o script?

Per una modifica di questo tipo, in genere la strada più pulita è un package con script PowerShell o un baseline di compliance. Le application model di SCCM funzionano, ma non sempre sono la scelta più semplice quando il target è un set di system settings e non un software installabile. Se il tuo obiettivo è far convergere più server allo stesso stato, una baseline con remediation è spesso più robusta del “run once”.

Una sequenza ragionevole è questa:

Se usi una compliance baseline, il vantaggio è doppio: hai detection e remediation separate. La detection può leggere il valore del registro e segnalare la non conformità; la remediation può applicare il valore corretto. Questo è utile quando vuoi prima osservare l’impatto su un sottoinsieme di server, senza correggere tutto in automatico al primo giro.

Un esempio di logica di detection in PowerShell è questo:

$Expected = 3390
$Path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
$Current = (Get-ItemProperty -Path $Path).PortNumber
if ($Current -eq $Expected) { exit 0 } else { exit 1 }

In SCCM, l’uscita 0 indica compliance, 1 non compliance. La remediation può usare lo stesso path, ma con Set-ItemProperty e un controllo successivo sul listener.

Verifica dell’accesso remoto senza farsi male

Il test giusto non è dal server stesso, ma da un host che simuli il percorso reale dell’utente o dell’amministratore. Se il server è dietro firewall o segmentazione, testare in locale ti dice solo che il listener è vivo. Serve invece verificare il salto di rete completo. Con PowerShell puoi fare un controllo rapido della raggiungibilità della porta:

Test-NetConnection -ComputerName server01.example.local -Port 3390

L’output utile è TcpTestSucceeded : True. Se è False, le cause più probabili sono tre: firewall locale, firewall di rete, o listener non attivo. Se il test TCP va a buon fine ma RDP non si apre, allora il problema sale di livello: NLA, policy di accesso, credenziali o configurazione del servizio.

Per la validazione finale, controlla anche il log eventi. Su Windows, gli eventi di Remote Desktop Services aiutano a capire se il listener si è inizializzato e se ci sono errori di autenticazione o canale. Non serve memorizzare numeri a memoria: basta sapere dove guardare quando il test di rete è ambiguo.

Rollback: la parte che salva il change

Il rollback deve essere simmetrico rispetto al change. Se hai cambiato la porta da 3389 a 3390, il ritorno deve riportare il valore originale nel registro e ripristinare la regola firewall precedente. Non affidarti alla memoria: conserva sempre il valore iniziale in una variabile, in un file di log o nel ticket di change.

$RegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
$OriginalPort = 3389
Set-ItemProperty -Path $RegPath -Name PortNumber -Type DWord -Value $OriginalPort

Disable-NetFirewallRule -DisplayName 'RDP Custom Port'

Se la tua regola firewall vecchia è stata rimossa, ricreala invece di improvvisare. Il rollback non deve dipendere da un’operazione manuale sotto pressione. Idealmente, il tuo script iniziale dovrebbe scrivere un file di stato locale con porta vecchia e nuova, così il ripristino è eseguibile anche da un operatore diverso da chi ha fatto il deploy.

Un dettaglio pratico spesso trascurato: se la nuova porta è stata scelta per ridurre gli scan automatici, non basta spostare RDP. Devi anche verificare che il resto della superficie di attacco non sia peggiorato: account admin esposti, NLA disabilitato, gruppi troppo larghi, o jump host assente. Cambiare porta non è hardening completo, è solo una misura di riduzione del rumore.

Distribuzione con SCCM: controllo del blast radius

Con SCCM il rischio principale è applicare il change a sistemi non omogenei. Alcuni server potrebbero avere policy locali, GPO sovrapposte o firewall gestiti altrove. Prima di aprire il deployment a tutta la collection, fai una verifica su un campione ridotto e controlla tre cose: il valore nel registro, il listener TCP, e la porta effettivamente raggiungibile dall’esterno.

Se usi GPO per il firewall, chiarisci chi è la fonte di verità. Se SCCM cambia la regola locale ma una GPO la sovrascrive, il risultato finale non sarà quello atteso. In quel caso la remediation deve agire sul layer giusto, non sul primo che sembra disponibile. La differenza tra un change riuscito e uno che crea ticket inutili sta quasi sempre qui: capire chi governa davvero la configurazione finale.

In un ambiente ben gestito, il flusso ideale è:

Errore tipico: porta cambiata ma RDP non risponde

Questo è il classico caso in cui il sintomo inganna. Hai cambiato il registro, ma la porta non risponde. Le cause più comuni sono:

La falsificazione più veloce è semplice: leggi il registro, verifica il listener, poi testa la porta da fuori. Se uno dei tre punti non torna, hai già il layer colpevole. Non serve andare subito a toccare SCCM o il registro a caso.

Un controllo utile è confrontare il valore presente con quello atteso e annotare il timestamp della modifica. Se il sistema torna alla porta precedente dopo pochi minuti, la causa è quasi sempre una policy o un task di compliance che fa drift correction. In quel caso il problema non è RDP: è il controllo configurativo che va aggiornato.

Quando conviene non cambiare la porta

Ci sono casi in cui cambiare porta è una pessima idea. Se hai già un accesso tramite VPN, bastion host o RD Gateway, spostare RDP può complicare troubleshooting e supporto senza aggiungere vera sicurezza. Lo stesso vale se il tuo ambiente ha monitoraggi, playbook e regole firewall già standardizzati sulla 3389. In questi casi il beneficio marginale è basso, mentre il costo operativo cresce subito.

La scelta sensata è valutare il contesto: se la porta standard è esposta su segmenti non protetti, la modifica ha senso; se l’accesso è già ristretto e autenticato a monte, la priorità dovrebbe essere NLA, MFA, segmentazione e auditing. La porta diversa può aiutare a ridurre il rumore, ma non sostituisce i controlli veri.

La porta RDP diversa è una misura di igiene operativa, non una barriera di sicurezza completa. Se la usi, fallo come parte di una catena di controlli, non come scorciatoia.

In sintesi, il cambio di porta con SCCM e PowerShell funziona bene quando tratti il registro come una sorgente di stato, il firewall come un requisito parallelo, e SCCM come il mezzo di distribuzione con controllo del rischio. Il resto è disciplina operativa: backup del valore precedente, pilota ristretto, verifica esterna, e rollback pronto prima del deploy.