Usare Remote Desktop da Kali per accedere a Windows 10 e 11

Remote Desktop da Kali verso Windows 10 e 11

Se devi amministrare o affiancare una macchina Windows da Kali Linux, il percorso più lineare è usare RDP con un client compatibile come Remmina o FreeRDP. La parte importante non è “far partire la connessione”, ma farlo in modo pulito: porte corrette, account abilitato, cifratura accettabile e una verifica rapida dei problemi più probabili quando la sessione non si apre.

Qui sotto trovi una procedura pratica per Windows 10 e 11, con controlli lato client e lato server. L’obiettivo è distinguere subito tra errore di rete, blocco sul firewall, servizio disabilitato, credenziali errate o incompatibilità di sicurezza.

Prerequisiti minimi su Windows

Prima di tutto, il computer Windows deve supportare la connessione in ingresso tramite Remote Desktop. Su Windows 10 e 11 questo vale per molte edizioni Pro, Enterprise ed Education; le edizioni Home, in generale, non accettano connessioni RDP in ingresso. Se non hai certezza dell’edizione, verifica in Impostazioni > Sistema > Informazioni oppure con la schermata winver.

Il requisito operativo è semplice: la macchina deve essere accesa, raggiungibile in rete, con RDP abilitato e con un account autorizzato. Se stai lavorando su una LAN, ti basta l’indirizzo IP o il nome host risolvibile via DNS. Se sei fuori sede, non esporre RDP direttamente su Internet senza una VPN o un accesso mediato: è una scelta fragile e troppo visibile agli scanner automatici.

Abilitare Remote Desktop su Windows 10 e 11

Su Windows 11 il percorso tipico è Impostazioni > Sistema > Desktop remoto. Su Windows 10 trovi la funzione nella stessa area, con una struttura molto simile. Attiva l’opzione Desktop remoto e conferma l’avviso di sicurezza. In molti casi Windows aggiunge in automatico una regola al firewall per consentire il traffico in ingresso sulla porta 3389.

Se vuoi verificare da riga di comando sul lato Windows, una risposta rapida è controllare se il servizio è attivo e se il sistema ascolta sulla porta giusta. Su una sessione amministrativa locale o remota puoi usare:

sc query TermService
netstat -an | findstr :3389

Nel primo caso lo stato atteso è RUNNING o comunque un servizio configurato per l’avvio automatico. Nel secondo, quando RDP è abilitato e in ascolto, dovresti vedere una riga in LISTENING sulla 3389. Se non compare, il problema non è ancora il client Kali: è lato Windows o firewall.

Installare il client su Kali

Su Kali hai due strade solide: un client grafico come Remmina oppure il client testuale xfreerdp del pacchetto FreeRDP. Per un uso quotidiano Remmina è più comodo; per test rapidi, scripting o troubleshooting, xfreerdp è spesso più chiaro perché ti restituisce errori immediati e dettagliati.

Installazione tipica:

sudo apt update
sudo apt install remmina freerdp2-x11

Se vuoi verificare la presenza del client e la versione installata:

remmina --version
xfreerdp /version

Non è raro che su Kali manchi il plugin RDP per Remmina o che il pacchetto non sia installato di default. In quel caso la GUI può aprirsi ma non mostrarti il profilo RDP completo. Se succede, il controllo più semplice è installare il supporto RDP e riavviare l’applicazione.

Connessione con Remmina: impostazioni che contano davvero

In Remmina crea un nuovo profilo e seleziona RDP - Remote Desktop Protocol come protocollo. I campi essenziali sono pochi: Server, Nome utente, Password e, se serve, Dominio. Per un PC in rete locale, nel campo server puoi inserire l’IP privato o il nome host. Se il nome non si risolve, passa all’IP per escludere subito un problema DNS.

Le impostazioni più sensate da curare sono queste:

• Risoluzione: usa quella del monitor o una finestra ridimensionabile se devi lavorare in multitasking.
• Color depth: 24 bit è un buon compromesso tra qualità e banda.
• Security protocol: lascia in automatico se possibile; forza NLA solo se il server lo richiede davvero.
• Keyboard layout: allinea la tastiera se usi layout non standard o se i tasti speciali risultano invertiti.

Per salvare una configurazione ordinata, conviene creare un profilo per ogni host Windows. Su chi amministra più macchine evita di riutilizzare lo stesso profilo con credenziali diverse: è la strada più breve verso errori di login e sessioni che si aprono sul server sbagliato.

Connessione rapida da terminale con xfreerdp

Quando vuoi capire subito se il problema è il client grafico o il server, xfreerdp è il test più utile. Un comando base è questo:

xfreerdp /v:192.168.1.50 /u:utente /p:'PasswordForte' /cert:ignore

Il parametro /cert:ignore è utile nei test interni quando il certificato presentato dal server è autofirmato o non ancora fidato dal client. Non è una soluzione da tenere come abitudine su reti esposte. In ambienti controllati, meglio installare o distribuire un certificato corretto sul server RDP e non ignorare la verifica in modo permanente.

Se vuoi una verifica più verbosa, aggiungi il logging dettagliato:

xfreerdp /v:192.168.1.50 /u:utente /p:'PasswordForte' /cert:ignore /log-level:TRACE

Con questo livello di log puoi distinguere meglio tra errore di trasporto, rifiuto di autenticazione, problema TLS o incompatibilità di negoziazione.

Verifiche lato rete: porta 3389, DNS e reachability

Se la connessione fallisce, il primo controllo non deve essere la password. Verifica prima che il target sia raggiungibile e che la porta RDP risponda. Dal client Kali puoi fare un test semplice con nc o con un controllo TCP equivalente:

nc -vz 192.168.1.50 3389

Lo stato atteso è un messaggio di connessione riuscita o almeno un handshake TCP completato. Se ottieni refused, il servizio non ascolta o il firewall del server sta respingendo. Se ottieni timed out, il blocco è più a monte: routing, ACL, VPN, firewall intermedio o host spento.

Se usi un nome host invece dell’IP, controlla la risoluzione:

getent hosts pc-ufficio.local

Se il nome non restituisce nulla, il problema non è RDP ma DNS o mDNS. In una LAN piccola l’IP diretto è la via più rapida per separare il guasto di risoluzione da quello del servizio.

Autenticazione: account locale, dominio e UAC

Su Windows puoi autenticarti con un account locale o di dominio. Con account locale, spesso è più affidabile specificare il nome macchina insieme all’utente, ad esempio NOMEPC\utente. Con account di dominio, il formato dipende dall’infrastruttura: DOMINIO\utente oppure l’UPN completo, se abilitato.

Un errore frequente è confondere il login locale con quello Microsoft account, soprattutto su Windows 11. Se l’account usato sul desktop è legato a un indirizzo email, non sempre il nome visualizzato corrisponde al formato da digitare in RDP. In questi casi conviene aprire Gestione computer > Utenti e gruppi locali o controllare la sezione account nelle impostazioni per identificare il nome effettivo.

Se un utente amministratore non riesce a connettersi ma un account standard sì, controlla i criteri di accesso remoto e i gruppi autorizzati. L’utente deve essere incluso nel gruppo Remote Desktop Users o avere privilegi equivalenti. L’appartenenza può essere verificata da Computer Management > Local Users and Groups > Groups.

Sicurezza: NLA, certificati e superficie esposta

Per un uso serio, RDP non va trattato come un servizio “comodo ma innocuo”. La configurazione minima consigliabile è Network Level Authentication attiva, password robuste, account limitati e accesso consentito solo dalla rete necessaria. Se il server è raggiungibile da più segmenti, restringi il firewall del sistema e dell’infrastruttura per permettere la 3389 solo da IP o subnet autorizzati.

Su Windows puoi controllare il firewall con l’interfaccia Windows Defender Firewall con sicurezza avanzata e verificare che la regola del Desktop remoto sia attiva solo nei profili corretti. Se il PC è in rete pubblica, non lasciare regole troppo larghe. In ambienti sensibili, l’accesso dovrebbe passare da VPN o da un jump host, non da esposizione diretta della porta RDP verso Internet.

Dal lato client, evitare di salvare credenziali condivise in profili usati da più operatori è una buona pratica basilare. Se devi distribuire accessi, usa account nominali e revoca puntuale. Se c’è il dubbio di compromissione, cambia la password dell’account interessato e verifica i log di accesso remoto prima di riaprire la sessione operativa.

Troubleshooting dei problemi più comuni

Quando RDP non funziona, la diagnosi migliore è procedere per layer. Se il client non apre proprio la sessione, controlla prima connettività e porta. Se la sessione si apre ma poi cade, guarda il lato sicurezza o il profilo utente. Se compare una schermata nera o una finestra che resta vuota, il problema può essere grafico, di sessione o di policy.

1. Errore di rete: nc -vz host 3389 fallisce o va in timeout. Verifica IP, routing, VPN e firewall.
2. Errore di autenticazione: il servizio risponde ma le credenziali vengono rifiutate. Controlla formato utente, password, permessi nel gruppo RDP e lock dell’account.
3. Errore di sicurezza/TLS: il client segnala certificato o negoziazione fallita. Prova temporaneamente con un certificato ignorato solo in test interni e poi sostituisci il certificato lato server.

Se vuoi leggere gli eventi lato Windows, il registro più utile è Visualizzatore eventi > Registri applicazioni e servizi > Microsoft > Windows > TerminalServices-*. Lì trovi indizi su login riusciti, falliti, disconnessioni e problemi di sessione. Non serve scavare subito nel kernel o nei log di sistema generici: per RDP, i log dedicati sono molto più utili.

Sessione nera, lag e disconnessioni improvvise

Una finestra nera con connessione apparentemente stabilita spesso indica un problema di caricamento della sessione o di profilo utente. In altri casi è il desktop remoto che parte ma l’esplorazione del profilo fallisce per rallentamenti del disco, policy di login o software di sicurezza che blocca il caricamento. Se il comportamento è intermittente, osserva l’ora, l’utente coinvolto e l’eventuale carico del sistema Windows.

Se invece la sessione è lenta, la causa non è sempre RDP. Controlla la qualità della rete, la latenza, eventuali VPN e il carico della macchina Windows. In ambienti con banda stretta, abbassa la profondità colore e disattiva effetti grafici superflui dal client. Su Remmina può bastare un profilo più leggero; su xfreerdp puoi lavorare con parametri più aggressivi per ridurre il traffico visivo.

Esempio operativo completo

Scenario tipico: hai un PC Windows 11 in ufficio con IP 192.168.1.50 e vuoi collegarti da Kali sulla stessa rete. Prima verifichi che la porta sia aperta, poi apri il client e solo dopo inserisci le credenziali.

nc -vz 192.168.1.50 3389
xfreerdp /v:192.168.1.50 /u:utente /p:'PasswordForte' /cert:ignore

Se il primo comando fallisce, non ha senso insistere sul secondo. Se il primo riesce ma il secondo no, allora il focus si sposta su credenziali, permessi o certificato. Questo ordine ti fa risparmiare tempo e evita di cambiare tre cose insieme senza sapere quale abbia davvero risolto il guasto.

Buone pratiche per l’uso quotidiano

Per un utilizzo stabile, conviene seguire alcune regole semplici. Tieni un profilo separato per ogni host, usa nomi chiari per i server, conserva solo credenziali strettamente necessarie e preferisci account nominali a credenziali condivise. Se lavori su più reti, annota anche il contesto: LAN aziendale, VPN, rete domestica o laboratorio. Molti problemi “misteriosi” sono solo profili creati per l’ambiente sbagliato.

Se il tuo obiettivo è amministrare Windows da Kali in modo affidabile, l’approccio corretto è questo: prima conferma che il server ascolta, poi che il client raggiunge la porta, poi che l’utente ha permessi, infine che la sicurezza non stia bloccando la negoziazione. Quando segui questa sequenza, RDP smette di essere una prova casuale e diventa uno strumento operativo prevedibile.