Accedere al desktop remoto di Kali Linux da Windows via RDP

Su Kali Linux il desktop remoto via RDP non è “magia”, ma una catena precisa: un servizio ascolta sulla 3389, un desktop environment deve partire correttamente e Windows deve trovare una sessione valida. Se uno di questi pezzi manca, il sintomo cambia: connessione rifiutata, schermo nero, logout immediato o finestra che si chiude dopo l’autenticazione.

La via più lineare è usare xrdp come server RDP e un ambiente grafico compatibile, in genere XFCE su Kali. XFCE è più prevedibile di GNOME in questo scenario: meno dipendenze, meno integrazioni con sessioni Wayland, meno sorprese quando ci si collega da un client Windows.

Scelta architetturale: xrdp + XFCE

Se l’obiettivo è accedere al desktop di Kali da Windows senza passare da VNC o da soluzioni proprietarie, xrdp è la scelta pratica. Non richiede tunnel applicativi complessi, funziona bene in LAN e, se esposto su rete non fidata, si presta a essere chiuso dietro VPN o SSH tunnel. La parte da non sottovalutare è il desktop environment: con sessioni leggere e Xorg il comportamento è molto più stabile.

In questa guida parto da un sistema Kali recente con accesso amministrativo, interfaccia di rete già operativa e nessun vincolo particolare sul pannello grafico. Se stai lavorando su una macchina remota già in produzione, considera il cambiamento come change controllato: backup dei file di configurazione, finestra di manutenzione e piano di rollback.

Installazione dei pacchetti necessari

Installa xrdp, il relativo backend per Xorg e un desktop environment leggero. Su Kali, XFCE è la combinazione più semplice da mantenere.

sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies

Dopo l’installazione verifica che il servizio esista e sia abilitabile con systemd.

systemctl status xrdp --no-pager
systemctl status xrdp-sesman --no-pager

Atteso: entrambi i servizi devono risultare presenti; inizialmente possono essere inactive se non sono stati avviati. Se il pacchetto non è installato correttamente, il comando mostra “Unit xrdp.service could not be found” o uno stato analogo.

Abilitazione del servizio e ascolto sulla porta 3389

Una volta installato, abilita e avvia xrdp. Questo è il punto in cui si decide se il servizio deve partire automaticamente al boot.

sudo systemctl enable --now xrdp
sudo systemctl enable --now xrdp-sesman

Controlla che la porta sia in ascolto.

ss -ltnp | grep 3389

Atteso: una riga con LISTEN su 0.0.0.0:3389 o sull’IP della macchina. Se non compare nulla, il problema è nel servizio, non nel client Windows.

Per una verifica più immediata lato log, guarda gli ultimi eventi di xrdp.

journalctl -u xrdp -u xrdp-sesman -n 50 --no-pager

Se vedi errori di binding, permessi o mancanza di backend Xorg, non andare oltre: il client RDP non risolverà nulla finché il server non è sano.

Preparazione della sessione grafica

Il classico errore con xrdp è autenticarsi correttamente e poi ricevere una schermata nera o una sessione che termina subito. Il motivo è quasi sempre la sessione grafica predefinita che non è coerente con xrdp. Con XFCE la correzione è semplice: forzare l’avvio del desktop corretto nel file ~/.xsession.

Se l’utente con cui ti colleghi è kali, crea o modifica il file nella home dell’utente:

echo xfce4-session > ~/.xsession
chmod 644 ~/.xsession

Per un controllo più esplicito, puoi usare:

cat ~/.xsession

Atteso: una sola riga con xfce4-session. Se lasci il file vuoto o punti a un comando errato, xrdp proverà ad aprire una sessione non valida e la connessione si interromperà dopo l’autenticazione.

In alcuni casi conviene anche impostare la sessione di XDG per evitare ambiguità, soprattutto se l’utente ha più ambienti installati. Non è sempre necessario, ma aiuta quando stai diagnosticando una macchina “sporca” con più desktop presenti.

Permessi e appartenenza ai gruppi

xrdp non richiede privilegi speciali per l’utente finale, ma l’utente deve poter aprire una sessione grafica e accedere ai dispositivi base del desktop. Su Kali, l’account usato per il login deve essere regolare e non bloccato da policy locali.

Se hai creato un utente ad hoc per l’accesso remoto, verifica che sia presente e che la shell sia valida.

getent passwd nomeutente
id nomeutente

Atteso: un record in passwd con home directory corretta e una shell non nera/listata come /usr/sbin/nologin. Se l’utente non esiste o è disabilitato, il login RDP fallirà anche se il servizio è perfetto.

Firewall: aprire solo ciò che serve

La porta RDP standard è 3389/TCP. Aprirla su una macchina esposta direttamente a Internet non è una buona idea; se devi farlo, il minimo sindacale è limitare l’accesso per IP o passare da VPN. In rete interna, invece, l’apertura controllata è sufficiente.

Se usi ufw, la regola minimale è questa:

sudo ufw allow from 192.0.2.0/24 to any port 3389 proto tcp
sudo ufw status verbose

Atteso: una regola che limiti il traffico RDP alla tua subnet di amministrazione. Se non usi UFW, verifica il firewall in uso con nft list ruleset o con la GUI del pannello, se presente.

Se la macchina è dietro un router o un firewall perimetrale, la regola va replicata anche lì. Il sintomo tipico in questo caso è il timeout dal client Windows, non un errore di autenticazione.

Connessione da Windows

Su Windows il client integrato è Connessione Desktop remoto (mstsc). Inserisci l’IP o il nome host della macchina Kali e avvia la sessione. Se stai lavorando in LAN, preferisci l’IP per evitare problemi DNS durante il test iniziale.

mstsc

Nel campo computer inserisci l’indirizzo di Kali, poi usa le credenziali dell’utente Linux. Non usare account root per comodità: su una macchina remota è una pessima abitudine operativa e complica anche la diagnosi di errori di sessione.

Se il server presenta il classico warning sul certificato, è normale quando non hai ancora installato un certificato firmato da una CA attendibile. Il controllo da fare è banale: verifica che l’host e l’IP corrispondano alla macchina giusta prima di accettare l’avviso. Se la connessione è in una rete amministrativa, puoi accettare il certificato e poi pianificare la sostituzione con un certificato corretto.

Errori tipici e lettura rapida dei sintomi

La parte utile non è “installare xrdp”, ma riconoscere dove si rompe la catena. Con RDP i sintomi sono abbastanza distinti.

Per una diagnosi veloce, questi file e comandi bastano nella maggior parte dei casi:

journalctl -u xrdp -u xrdp-sesman -n 100 --no-pager
cat ~/.xsession
ss -ltnp | grep 3389

Se vuoi il dettaglio di una sessione, spesso i log più utili sono sotto la home dell’utente o nei log di sistema. Su alcune installazioni li trovi in /var/log/xrdp.log e /var/log/xrdp-sesman.log; su altre la telemetria passa soprattutto da journalctl. Non assumere il path a memoria: verifica dove il pacchetto sta realmente scrivendo.

Hardening minimo prima di esporre RDP

RDP è comodo, ma non va trattato come un servizio da lasciare aperto a caso. La superficie d’attacco è chiara: autenticazione, porta standard facilmente scansionabile e potenziale esposizione del desktop completo. Se la macchina non è solo di laboratorio, applica almeno queste misure.

Se la macchina è accessibile da Internet, la scelta più prudente è non pubblicare 3389 direttamente. Il rischio non è teorico: il servizio diventa un bersaglio ovvio per brute force e scansioni automatiche. La riduzione dell’esposizione vale più di qualsiasi tweak cosmetico della GUI.

Procedura completa sintetica

Se vuoi una sequenza operativa lineare, questa è quella che uso per un setup pulito e ripetibile:

Questa sequenza riduce i falsi positivi. In pratica separa il problema di rete dal problema di sessione grafica: se non arrivi alla porta, non ha senso toccare XFCE; se arrivi ma la sessione cade, non ha senso inseguire il firewall.

Rollback rapido se il change crea problemi

Se stai facendo il change su una macchina remota e perdi stabilità, il rollback deve essere immediato e semplice. Prima di cambiare, conserva una copia dei file toccati; dopo, torna alla condizione precedente senza inseguire una configurazione più complessa del necessario.

cp ~/.xsession ~/.xsession.bak
sudo systemctl disable --now xrdp xrdp-sesman

Se hai aperto una regola firewall dedicata, rimuovila o disabilitala dal pannello o dal tool usato. Il rollback corretto non è “spegnere tutto a caso”, ma riportare il sistema allo stato precedente in modo verificabile.

Assunzione operativa: la macchina è un Kali recente con Xorg disponibile e un utente locale già creato; se stai usando GNOME puro, Wayland o un setup minimale senza desktop, va adattata la parte di sessione grafica.