Configurare Clientless SSL VPN su Sophos Firewall per RDP e SSH

Con Clientless SSL VPN, Sophos Firewall rende disponibili direttamente nel browser singole connessioni interne RDP, SSH, VNC o a file server. L’utente non installa alcun client VPN e non ottiene un accesso generale a una rete interna. Accede invece al VPN Portal e vede solo i bookmark pubblicati dalla propria policy Clientless.

Il nome simile può portare facilmente alla configurazione sbagliata: Clientless Users associa internamente un IP fisso a un’identità. Non pubblica bookmark e non fa parte di questa procedura di Remote Access.

L’accesso al VPN Portal e quello al sistema di destinazione sono due passaggi separati. Clientless SSL VPN non supporta il Credential Passthrough: la password del VPN Portal non viene inoltrata automaticamente come credenziale Windows o SSH. Due accessi sono quindi normali finché nel bookmark non vengono memorizzate le credenziali della destinazione.

Il processo principale è breve:

Definire il sistema di destinazione fisso, la porta e il gruppo di utenti autorizzato.
Creare un bookmark RDP o SSH in Remote access VPN > Clientless SSL VPN policy > Bookmarks.
Collegare il gruppo di utenti e il bookmark in Policies.
Proteggere VPN Portal, certificato, autenticazione, MFA e Device Access.
Testare l’accesso dall’esterno in VPN > Clientless access connections con un utente autorizzato e uno non autorizzato.

Quando Clientless SSL VPN è adatto e quando non lo è

Clientless Access è particolarmente indicato per poche destinazioni fisse, accessi occasionali o tecnici esterni quando non si vuole installare un client VPN sul dispositivo utilizzato. In questo modo RDP e SSH non devono essere pubblicati direttamente su Internet tramite DNAT. A essere raggiungibile pubblicamente è invece il VPN Portal protetto.

Tuttavia, non è una versione ridotta adatta a ogni Remote Access VPN:

Clientless SSL VPN è adatto a singole destinazioni statiche RDP, SSH, VNC o file server utilizzabili nel browser.
Sophos Connect con IPsec o SSL VPN è più adatto quando un dispositivo gestito deve raggiungere più reti, applicazioni native, DNS o protocolli diversi. La guida alla scelta del Remote Access inquadra le varianti.
ZTNA è pensato per un accesso continuativo basato sull’applicazione, con identità, stato del dispositivo e policy centrali. Le basi sono descritte in Che cos’è Zero Trust Network Access?.
È opportuno valutare RD Gateway, Jump Host o PAM quando sono determinanti l’amministrazione privilegiata, gli account di destinazione personali, la registrazione delle sessioni o i workflow di approvazione.

Per RDP è inoltre importante sapere che gli appunti non sono supportati nelle sessioni Clientless a partire da SFOS 19. Se il workflow richiede necessariamente il copia e incolla o altre funzioni RDP native, è preferibile un accesso basato su client o una soluzione specializzata.

Clientless SSL VPN non supporta indirizzi IP di destinazione dinamici. È consentito usare un hostname come destinazione, ma Sophos Firewall deve risolverlo in modo stabile verso il sistema previsto. Una destinazione che cambia spesso non dovrebbe essere pianificata come scenario Dynamic DNS aggiornato in modo affidabile.

Prerequisiti e valori di esempio

Prima della configurazione devono essere definiti destinazione, identità e accesso al portale:

Il sistema di destinazione è raggiungibile da Sophos Firewall tramite routing e DNS e il servizio richiesto è in esecuzione.
Un utente o, preferibilmente, un gruppo ristretto è presente su Sophos Firewall oppure sul server di autenticazione collegato.
Il VPN Portal dispone di un FQDN pubblico o raggiungibile internamente e di un certificato corrispondente e attendibile.
In Authentication > Services è selezionato un metodo appropriato sotto VPN portal authentication methods.
Sono predisposti MFA e un accesso di ripristino indipendente.
È stato deciso se le credenziali di destinazione possono essere memorizzate nel bookmark.

L’esempio RDP seguente utilizza:

VPN Portal: https://vpn.example.com
server di destinazione: rdp-app01.intern.example
IP di destinazione: 10.20.30.25
porta RDP: 3389
bookmark: RDP-Fibu-Test
gruppo: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
sicurezza RDP per il primo test: TLS
Automatic login: disattivato
Share session: disattivato

example.com è un dominio di esempio riservato e 10.20.30.25 è un indirizzo privato di esempio. FQDN, IP, gruppo e nomi devono essere sostituiti con valori dell’ambiente reale. La porta 3389 è corretta solo se il server Windows utilizza effettivamente la porta RDP standard.

Configurare il bookmark RDP

Bookmark con TLS e accesso personale alla destinazione

In Remote access VPN > Clientless SSL VPN policy > Bookmarks, creare un nuovo bookmark con Add:

Inserire RDP-Fibu-Test in Name.
Selezionare RDP come Type.
Inserire rdp-app01.intern.example oppure l’IP fisso 10.20.30.25 in URL.
Utilizzare la porta di servizio 3389. Inserire una porta diversa solo se è stata configurata consapevolmente in modo diverso sul sistema di destinazione.
Lasciare Automatic login disattivato per il primo test.
Se necessario, inserire il dominio di rete Windows, ad esempio CORP o corp.example.com.
Selezionare TLS in Protocol security.
Lasciare Share session disattivato.
Salvare con Save.

Senza Automatic login, l’utente inserisce le proprie credenziali nella finestra RDP aperta. In questo modo è possibile accedere con un account Windows personale, purché il modello di sicurezza del server di destinazione consenta questa modalità TLS.

Il certificato del VPN Portal e Protocol security: TLS svolgono funzioni diverse. Il certificato del portale protegge la tratta dal browser a Sophos Firewall. L’impostazione RDP protegge la connessione successiva da Sophos Firewall al sistema Windows. Un certificato valido del portale non sostituisce quindi una sicurezza RDP adeguata.

Quando il server Windows richiede NLA

Molti sistemi Windows richiedono Network Level Authentication (NLA). In questo caso, nel bookmark si seleziona NLA. SFOS attiva così Automatic login e nel bookmark devono essere memorizzati il nome utente e la password del sistema di destinazione.

Non si tratta di una semplice opzione di comodità. Tutti gli utenti autorizzati per questo bookmark utilizzano sul sistema di destinazione la stessa identità Windows memorizzata. A tale scopo si dovrebbe usare esclusivamente un account dedicato, con privilegi minimi e soggetto a rotazione. Account Domain Admin, account amministrativi personali e account di servizio con ampi privilegi non devono essere inseriti in un bookmark Clientless.

NLA non dovrebbe essere disattivato sul server Windows soltanto per far funzionare il percorso di esempio con TLS. Se le credenziali memorizzate o un’identità di destinazione condivisa non sono accettabili, Clientless RDP non è adatto a questo server. Una VPN normale, RD Gateway, PAM o un Jump Host controllato preservano meglio la tracciabilità personale.

Anche Share session rimane disattivato. L’opzione è destinata a un caso di collaborazione pianificato consapevolmente. In una sessione condivisa, Stop session termina la connessione per tutti i partecipanti, mentre Suspend session mette in pausa soltanto l’utente corrente. Una sessione di amministrazione privilegiata non dovrebbe essere condivisa.

Configurare la policy Clientless e il VPN Portal

Collegare utenti e bookmark in una policy

Un bookmark esistente da solo non rende ancora visibile la destinazione a un utente. Soltanto la policy collega identità e risorsa:

Aprire Remote access VPN > Clientless SSL VPN policy.
In Policies, fare clic su Add.
Inserire Clientless-RDP-Fibu come Name.
In Policy members, selezionare soltanto il gruppo Clientless-RDP-Fibu.
In Published bookmarks, selezionare RDP-Fibu-Test.
Salvare con Apply.

Una Bookmark Group è utile solo quando gli stessi utenti necessitano di più destinazioni. Per una singola destinazione RDP introduce soltanto un ulteriore livello di gestione.

Proteggere il VPN Portal

L’utente apre le connessioni Clientless tramite il VPN Portal. La porta standard è 443; porta e certificato si trovano in Administration > Admin and user settings > Admin console and end-user interaction. Per l’esempio, il certificato deve contenere vpn.example.com come SAN ed essere accettato dal browser senza avvisi. L’assegnazione generale dei certificati è descritta in Importare e assegnare certificati su Sophos Firewall.

In Administration > Device access, VPN portal deve essere consentito per l’accesso effettivamente necessario. Se il portale deve essere raggiungibile da tutte le origini WAN, si attiva WAN nella matrice. In presenza di reti di origine note, è preferibile la variante più restrittiva: lasciare WAN disattivato nella matrice e creare sotto Local service ACL exception rule una regola Accept con Source zone: WAN, lo specifico Source Network / Host, l’indirizzo di Sophos Firewall necessario come Destination host e Services: VPN portal. Un’ulteriore eccezione Accept non restringe un’autorizzazione WAN già attivata in modo generale nella matrice. WebAdmin, User Portal, SSH o SSL VPN non vengono automaticamente abilitati insieme. La pianificazione sicura è descritta in Device Access e Local Service ACL.

⚠️ Un VPN Portal raggiungibile dalla WAN è una superficie di login pubblica. Non dovrebbe essere utilizzato senza MFA, un certificato attendibile, una membership della policy ristretta e il monitoraggio degli accessi. Se VPN Portal e SSL VPN condividono la stessa porta e lo stesso protocollo, le rispettive zone raggiungibili possono influenzarsi reciprocamente; questo effetto del Port Sharing deve essere controllato separatamente.

Per l’OTP locale di Sophos, in Authentication > Multi-factor authentication si utilizza innanzitutto Specific users and groups. Per l’autoregistrazione tramite app di autenticazione, attivare Generate OTP token with next sign-in, selezionare VPN portal in Require MFA for e salvare con Apply. La fase pilota e il percorso di ripristino sono descritti in Attivare MFA per Sophos Firewall. Il VPN Portal non supporta MFA RADIUS basata su challenge; una procedura RADIUS esistente deve quindi essere testata specificamente per questo accesso al portale. Se invece il portale deve utilizzare Microsoft Entra ID SSO e Conditional Access, Entra ID SSO per Sophos Connect e VPN Portal descrive l’intera catena di identità.

Testare l’accesso dall’esterno

Il test dovrebbe essere eseguito da una rete realmente esterna, ad esempio tramite un hotspot mobile. Un test dalla LAN non dimostra che DNS, certificato, Device Access e un router a monte funzionino correttamente da Internet.

Aprire https://vpn.example.com in una finestra privata del browser.
Controllare nome del certificato, catena dei certificati e stato nel browser.
Accedere con un membro di Clientless-RDP-Fibu e completare l’MFA.
In VPN > Clientless access connections, verificare che appaia RDP-Fibu-Test.
Fare clic su Connect. La sessione deve aprirsi in una nuova finestra del browser.
Con Automatic login disattivato, inserire le credenziali Windows personali e verificare l’accesso RDP.
Disconnettere correttamente la sessione sul sistema Windows e poi uscire dal VPN Portal.
Eseguire il test con un utente esterno al gruppo. Il bookmark non deve apparire.
Rimuovere temporaneamente l’utente di test dal gruppo della policy e verificare che l’accesso scompaia dopo un nuovo login.

Il successo non consiste soltanto nella visualizzazione di un desktop. L’utente positivo vede esattamente i bookmark previsti, l’utente negativo non ne vede alcuno, l’MFA interviene, il certificato è attendibile, l’accesso alla destinazione funziona e la sessione termina in modo verificabile sia sul portale sia sul sistema di destinazione.

Opzioni per SSH, VNC e file server

Bookmark SSH con Host Key verificato

Per SSH, in Bookmarks > Add si seleziona SSH come Type. Un esempio utilizza srv-linux01.intern.example, la porta 22 e l’utente clientless-test.

Il Public host key deve appartenere al server previsto. Per una destinazione Linux, è possibile visualizzare il Public Host Key direttamente dalla console attendibile del server e documentarne il fingerprint:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Questi comandi vengono eseguiti sul server Linux di destinazione, non su Sophos Firewall. Se il server utilizza un altro tipo di Host Key, il nome del file deve essere adattato di conseguenza. Non si deve accettare alla cieca una chiave proveniente da un avviso del browser non verificato o da una scansione di rete qualsiasi.

Il primo comando restituisce il Public Host Key ED25519 da inserire nel bookmark sotto Public host key. Il secondo comando mostra soltanto il fingerprint per il confronto documentato; il fingerprint non viene copiato nel campo al posto della chiave.

Successivamente, creare completamente il bookmark SSH:

In Name, inserire ad esempio SSH-Linux-Test.
Selezionare SSH come Type.
In URL, inserire srv-linux01.intern.example e la porta 22.
In Username, impostare clientless-test o l’utente di destinazione previsto.
Lasciare Automatic login disattivato se l’utente deve inserire personalmente la password della destinazione.
Inserire in Public host key la chiave pubblica verificata direttamente sul sistema di destinazione.
Lasciare Share session disattivato e salvare con Save.
Aggiungere il bookmark alla policy Clientless in Published bookmarks e salvare con Apply.
Nel VPN Portal, fare clic su Connect in VPN > Clientless access connections, inserire la password della destinazione e verificare che appaia il prompt del terminale previsto. Terminare quindi correttamente la sessione SSH.

Senza Automatic login, l’utente inserisce la password della destinazione quando stabilisce la connessione; il nome utente rimane parte del bookmark. Per nomi utente SSH personali diversi sono quindi necessari bookmark distinti o un altro percorso di accesso. Con Automatic login, SFOS può utilizzare una password o una Private Key. Private Key privilegiate o ampiamente utilizzate non dovrebbero essere memorizzate in un bookmark pubblicato per più utenti.

Altri tipi di bookmark

SFOS 22 documenta inoltre:

VNC per l’accesso grafico a sistemi Linux o UNIX configurati di conseguenza.
FTP, FTPS, SFTP e SMB per l’accesso a file server nel browser. Non viene montata una normale unità di rete. Per dati riservati, SFTP o FTPS sono preferibili a FTP non cifrato.
Telnet come tipo di terminale. Poiché Telnet non cifra il trasporto, non dovrebbe essere utilizzato per nuovi accessi.

I bookmark HTTP e HTTPS non rientrano tra i tipi Clientless attualmente documentati per SFOS 22. Per le applicazioni web interne, a seconda delle esigenze di protezione, Web Application Firewall o ZTNA rappresentano un’architettura più adatta.

Risolvere i problemi più comuni

Il VPN Portal non è raggiungibile: Controllare record DNS pubblico, porta, NAT a monte, Administration > Device access e un possibile effetto del Port Sharing.
L’accesso al portale non riesce: In Authentication > Services, controllare l’autenticazione del VPN Portal, lo stato dell’utente, MFA e access_server.log.
Manca Clientless access connections: L’utente non è assegnato a una policy Clientless oppure la policy non pubblica alcun bookmark.
Il bookmark è visibile all’utente sbagliato: Controllare Policy members, appartenenza ai gruppi e Published bookmarks. Con più gruppi corrispondenti, Clientless SSL VPN può combinare le autorizzazioni delle policy associate. I bookmark effettivamente visibili a un utente reale devono essere inclusi nei test positivo e negativo.
Il bookmark si apre, ma la destinazione non è raggiungibile: Controllare risoluzione DNS dalla prospettiva di Sophos Firewall, indirizzo di destinazione statico, routing, porta di destinazione, stato del servizio e firewall dell’host.
L’accesso al VPN Portal funziona, ma quello Windows no: L’accesso al portale e quello alla destinazione sono separati. Controllare dominio, account di destinazione, password e TLS o NLA.
NLA attiva Automatic login: È il comportamento documentato. Non disattivare NLA senza pianificazione, ma rivalutare il modello di account e accesso.
SSH segnala un Host Key diverso: Interrompere la connessione e verificare la modifica direttamente sul sistema di destinazione o con il responsabile. Una chiave inattesa può indicare una reinstallazione, una destinazione errata o un attacco.

In Diagnostics > Tools > Troubleshooting logs, file diversi aiutano nelle varie fasi:

vpnportal.log per il VPN Portal;
access_server.log per autenticazione e autorizzazione;
clientless_access.log per le connessioni Clientless e la connessione alla destinazione;
oauth_sso_vpn.log per gli accessi al VPN Portal con SSO.

Documentare insieme ora del test, utente, bookmark e destinazione. In questo modo è possibile distinguere nei log i problemi del portale, dell’identità e della destinazione. L’assegnazione generale dei log e l’accesso tramite Advanced Shell sono descritti in Log dei servizi di Sophos Firewall.

Gestione operativa e limiti RDP noti

Le policy Clientless devono essere controllate regolarmente come le altre autorizzazioni di Remote Access. Rimuovere utenti, bookmark e account di destinazione non più necessari. Le password o le Private Key memorizzate devono avere un Owner, una data di scadenza e un processo di rotazione. Automatic login e Share session devono far parte di ogni revisione delle autorizzazioni.

Per RDP esistono due limitazioni attuali che non devono essere trattate come errori di configurazione:

Gli appunti non sono supportati nei bookmark RDP Clientless a partire da SFOS 19. Il copia e incolla tra dispositivo locale e sessione RDP non costituisce quindi un workflow affidabile.
Il puntatore del mouse può apparire nella sessione RDP HTML5 come una croce o una X invece della normale freccia. Sophos attualmente non indica alcuna soluzione alternativa.

Se sono indispensabili gli appunti, funzioni RDP native, un accesso di rete più ampio oppure account di destinazione personali su un server che richiede NLA senza credenziali memorizzate, Clientless SSL VPN non è la scorciatoia adatta. L’accesso dovrebbe allora essere spostato consapevolmente su Sophos Connect, RD Gateway, PAM, un Jump Host o ZTNA.