Konfigurera Sophos Firewall Clientless SSL VPN för RDP och SSH

Med Clientless SSL VPN gör en Sophos Firewall enskilda interna RDP-, SSH-, VNC- eller filserveranslutningar tillgängliga direkt i webbläsaren. Användaren installerar ingen VPN-klient och får ingen allmän åtkomst till ett internt nätverk. I stället loggar användaren in på VPN Portal och ser endast de bookmarks som publiceras av användarens Clientless Policy.

Det liknande namnet kan lätt leda till fel konfiguration: Clientless Users kopplar internt en fast IP-adress till en identitet. Det publicerar inga bookmarks och ingår inte i denna Remote Access-procedur.

Inloggningen på VPN Portal och inloggningen på målsystemet är två separata steg. Clientless SSL VPN stöder inte Credential Passthrough: lösenordet till VPN Portal vidarebefordras inte automatiskt till Windows- eller SSH-inloggningen. Två inloggningar är därför normalt så länge inga inloggningsuppgifter för målsystemet är lagrade i bookmarken.

Huvudförloppet är kort:

Ange ett fast målsystem, port och behörig användargrupp.
Skapa en RDP- eller SSH-bookmark under Remote access VPN > Clientless SSL VPN policy > Bookmarks.
Koppla samman användargruppen och bookmarken under Policies.
Säkra VPN Portal, certifikat, autentisering, MFA och Device Access.
Testa åtkomsten externt under VPN > Clientless access connections med en behörig och en obehörig användare.

När Clientless SSL VPN passar – och när det inte gör det

Clientless Access passar särskilt bra för ett fåtal fasta mål, tillfällig åtkomst eller externa tekniker när ingen VPN-klient ska installeras på den använda enheten. RDP och SSH behöver då inte publiceras direkt på internet via DNAT. I stället är den säkrade VPN Portal offentligt tillgänglig.

Det ersätter däremot inte alla Remote Access VPN-scenarier:

Clientless SSL VPN passar för enskilda statiska RDP-, SSH-, VNC- eller filservermål som kan användas i webbläsaren.
Sophos Connect med IPsec eller SSL VPN passar bättre när en hanterad enhet behöver flera nätverk, inbyggda program, DNS eller olika protokoll. Beslutsguiden för Remote Access förklarar alternativen.
ZTNA är avsett för permanent programorienterad åtkomst med identitet, enhetsstatus och centrala policies. Grunderna finns i Vad är Zero Trust Network Access?.
RD Gateway, Jump Host eller PAM bör övervägas när privilegierad administration, personliga målkonton, sessionsinspelning eller godkännandeflöden är avgörande.

För RDP är det också viktigt att urklipp inte stöds i Clientless-sessioner sedan SFOS 19. Om copy-and-paste eller andra inbyggda RDP-funktioner är obligatoriska för arbetsflödet är en klientbaserad eller specialiserad åtkomstväg ett bättre val.

Clientless SSL VPN stöder inte dynamiska mål-IP-adresser. Ett värdnamn får användas som mål, men brandväggen måste kunna slå upp det stabilt och det måste peka på det avsedda systemet. Ett mål som ändras ofta bör inte planeras som ett Dynamic DNS-scenario som förväntas uppdateras tillförlitligt.

Krav och exempelvärden

Före konfigurationen bör mål, identitet och portalåtkomst vara fastställda:

Målsystemet kan nås från brandväggen via routing och DNS, och den tjänst som behövs körs.
En användare eller helst en snävt avgränsad grupp finns på brandväggen eller den anslutna autentiseringsservern.
VPN Portal har ett offentligt eller internt åtkomligt FQDN och ett matchande betrott certifikat.
Under Authentication > Services har en lämplig metod valts under VPN portal authentication methods.
MFA och en oberoende återställningsåtkomst har förberetts.
Det har beslutats om inloggningsuppgifter för målsystemet får lagras i bookmarken.

Följande RDP-exempel använder:

VPN Portal: https://vpn.example.com
målserver: rdp-app01.intern.example
mål-IP: 10.20.30.25
RDP-port: 3389
bookmark: RDP-Fibu-Test
grupp: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
RDP-säkerhet för det första testet: TLS
Automatic login: inaktiverat
Share session: inaktiverat

example.com är en reserverad exempeldomän och 10.20.30.25 är en privat exempeladress. FQDN, IP, grupp och namn måste ersättas med värden från den egna miljön. Port 3389 är endast korrekt om Windows-servern faktiskt använder RDP-standardporten.

Konfigurera RDP-bookmarken

Bookmark med TLS och personlig målinloggning

Under Remote access VPN > Clientless SSL VPN policy > Bookmarks skapas en ny bookmark med Add:

Ange RDP-Fibu-Test under Name.
Välj RDP som Type.
Ange rdp-app01.intern.example eller den fasta IP-adressen 10.20.30.25 under URL.
Använd tjänsteporten 3389. En annan port anges endast om den avsiktligt har konfigurerats annorlunda på målsystemet.
Låt Automatic login vara inaktiverat för det första testet.
Ange Windows-nätverksdomänen vid behov, till exempel CORP eller corp.example.com.
Välj TLS under Protocol security.
Låt Share session vara inaktiverat.
Spara med Save.

Utan Automatic login anger användaren sina inloggningsuppgifter i det öppnade RDP-fönstret. Inloggningen kan då göras med ett personligt Windows-konto, förutsatt att målsystemets säkerhetsmodell tillåter detta TLS-läge.

Certifikatet för VPN Portal och Protocol security: TLS har olika uppgifter. Portalcertifikatet skyddar webbläsarvägen till brandväggen. RDP-inställningen skyddar den efterföljande anslutningen från brandväggen till Windows-systemet. Ett giltigt portalcertifikat ersätter därför inte lämplig RDP-säkerhet.

När Windows-servern kräver NLA

Många Windows-system kräver Network Level Authentication (NLA). I så fall väljs NLA i bookmarken. SFOS aktiverar då Automatic login, och användarnamn och lösenord för målsystemet måste lagras i bookmarken.

Det är inte en ren bekvämlighetsfunktion. Alla behöriga användare av denna bookmark arbetar då på målsystemet med samma lagrade Windows-identitet. Endast ett dedikerat konto med minimala behörigheter som går att rotera bör användas för detta. Domain Admin-konton, personliga administratörskonton och brett behöriga tjänstekonton hör inte hemma i en Clientless Bookmark.

NLA bör inte inaktiveras på Windows-servern enbart för att TLS-exemplet ska fungera. Om lagrade inloggningsuppgifter eller en gemensam målidentitet inte är acceptabla passar Clientless RDP inte för den här servern. En vanlig VPN, RD Gateway, PAM eller en kontrollerad Jump Host bevarar den personliga spårbarheten bättre.

Share session förblir också inaktiverat. Alternativet är avsett för ett medvetet planerat samarbetsfall. I en delad session avslutar Stop session anslutningen för alla deltagare, medan Suspend session endast pausar den aktuella användaren. En session för privilegierad administration bör inte delas.

Konfigurera Clientless Policy och VPN Portal

Koppla användare och bookmark i en policy

En befintlig bookmark gör inte i sig målet synligt för någon användare. Det är först policyn som kopplar samman identitet och resurs:

Öppna Remote access VPN > Clientless SSL VPN policy.
Klicka på Add under Policies.
Ange Clientless-RDP-Fibu som Name.
Välj endast gruppen Clientless-RDP-Fibu under Policy members.
Välj RDP-Fibu-Test under Published bookmarks.
Spara med Apply.

En Bookmark Group är först motiverad när samma användare behöver flera mål. För ett enskilt RDP-mål skapar den bara ett extra administrationslager.

Säkra VPN Portal

Användaren öppnar Clientless-anslutningar via VPN Portal. Standardporten är 443; port och certifikat finns under Administration > Admin and user settings > Admin console and end-user interaction. I exemplet måste certifikatet innehålla vpn.example.com som SAN och godtas av webbläsaren utan varning. Importera och tilldela certifikat på Sophos Firewall förklarar den allmänna certifikattilldelningen.

Under Administration > Device access måste VPN portal tillåtas för den åtkomst som faktiskt behövs. Om portalen ska vara åtkomlig från alla WAN-källor aktiveras WAN i matrisen. Vid kända källnätverk är den snävare varianten bättre: låt WAN vara inaktiverat i matrisen och skapa under Local service ACL exception rule en Accept-regel med Source zone: WAN, det konkreta Source Network / Host, den brandväggsadress som behövs som Destination host och Services: VPN portal. Ett ytterligare Accept-undantag begränsar inte en WAN-matrisbehörighet som redan har aktiverats generellt. WebAdmin, User Portal, SSH eller SSL VPN aktiveras inte automatiskt samtidigt. Den säkra planeringen finns i Device Access och Local Service ACL.

⚠️ En VPN Portal som kan nås från WAN är en offentlig inloggningsyta. Den bör inte användas utan MFA, ett betrott certifikat, snäv policymedlemskap och övervakning av inloggningar. Om VPN Portal och SSL VPN delar samma port och protokoll kan de nåbara zonerna påverka varandra. Denna Port Sharing-effekt måste kontrolleras separat.

För lokal Sophos OTP används först Specific users and groups under Authentication > Multi-factor authentication. För självregistrering via en autentiseringsapp aktiveras Generate OTP token with next sign-in, VPN portal väljs under Require MFA for och inställningen sparas med Apply. Pilotfasen och återställningsvägen finns i Aktivera MFA för Sophos Firewall. VPN Portal stöder inte challenge-baserad RADIUS-MFA. En befintlig RADIUS-metod måste därför testas specifikt för denna portalinloggning. Om portalen i stället ska använda Microsoft Entra ID SSO och Conditional Access beskriver Entra ID SSO för Sophos Connect och VPN Portal hela identitetskedjan.

Testa åtkomst utifrån

Testet bör utföras från ett verkligt externt nätverk, till exempel via en mobil hotspot. Ett test från LAN bevisar inte att DNS, certifikat, Device Access och en framförliggande router fungerar korrekt från internet.

Öppna https://vpn.example.com i ett privat webbläsarfönster.
Kontrollera certifikatnamn, certifikatkedja och webbläsarstatus.
Logga in som medlem i Clientless-RDP-Fibu och slutför MFA.
Kontrollera under VPN > Clientless access connections att RDP-Fibu-Test visas.
Klicka på Connect. Sessionen måste öppnas i ett nytt webbläsarfönster.
När Automatic login är inaktiverat anger man de personliga Windows-inloggningsuppgifterna och testar RDP-inloggningen.
Logga ut korrekt från sessionen på Windows-systemet och lämna sedan VPN Portal.
Testa med en användare utanför gruppen. Bookmarken får inte visas där.
Ta tillfälligt bort testanvändaren från policygruppen och kontrollera att åtkomsten försvinner efter en ny inloggning.

Ett lyckat resultat innebär inte bara att ett skrivbord visas. Den behöriga användaren ser exakt de avsedda bookmarks, den obehöriga användaren ser inga, MFA tillämpas, certifikatet är betrott, målinloggningen fungerar och sessionen avslutas spårbart på både portalen och målsystemet.

Alternativ för SSH, VNC och filservrar

SSH-bookmark med verifierad Host Key

För SSH väljs SSH som Type under Bookmarks > Add. Ett exempel använder srv-linux01.intern.example, port 22 och användaren clientless-test.

Public host key måste tillhöra den förväntade servern. På ett Linux-mål kan den offentliga Host Key visas direkt i den betrodda serverkonsolen och dess fingerprint dokumenteras:

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

Dessa kommandon körs på Linux-målservern, inte på Sophos Firewall. Om servern använder en annan Host Key-typ måste filnamnet anpassas. En nyckel från en overifierad webbläsarvarning eller en godtycklig nätverksskanning får inte användas utan kontroll.

Det första kommandot visar den offentliga ED25519 Host Key som ska infogas under Public host key i bookmarken. Det andra kommandot visar endast fingerprint för den dokumenterade jämförelsen. Fingerprint ska inte kopieras till fältet i stället för nyckeln.

Därefter skapas hela SSH-bookmarken:

Ange exempelvis SSH-Linux-Test under Name.
Välj SSH som Type.
Ange srv-linux01.intern.example under URL och port 22.
Ange clientless-test eller den avsedda målanvändaren under Username.
Låt Automatic login vara inaktiverat om användaren ska ange mållösenordet själv.
Infoga den offentliga Host Key som har verifierats direkt på målsystemet under Public host key.
Låt Share session vara inaktiverat och spara med Save.
Lägg till bookmarken i Clientless Policy under Published bookmarks och spara med Apply.
Klicka på Connect under VPN > Clientless access connections i VPN Portal, ange mållösenordet och kontrollera att förväntad Terminal Prompt visas. Avsluta sedan SSH-sessionen korrekt.

Utan Automatic login anger användaren mållösenordet när anslutningen upprättas. Användarnamnet förblir en del av bookmarken. Olika personliga SSH-användarnamn kräver därför separata bookmarks eller en annan åtkomstväg. Med Automatic login kan SFOS använda lösenord eller Private Key. Privilegierade eller brett använda Private Keys bör inte lagras i en gemensamt publicerad bookmark.

Andra bookmarktyper

SFOS 22 dokumenterar även:

VNC för grafisk åtkomst till Linux- eller UNIX-system som har konfigurerats för detta.
FTP, FTPS, SFTP och SMB för åtkomst till filservrar i webbläsaren. Ingen vanlig monterad nätverksenhet skapas. För konfidentiella data är SFTP eller FTPS att föredra framför okrypterad FTP.
Telnet som terminaltyp. Eftersom Telnet inte krypterar transporten bör det inte användas för nya åtkomster.

HTTP- och HTTPS-bookmarks ingår inte i de Clientless-typer som för närvarande dokumenteras för SFOS 22. För interna webbapplikationer är Web Application Firewall eller ZTNA en lämpligare arkitektur, beroende på skyddsbehovet.

Felsöka vanliga problem

VPN Portal kan inte nås: Kontrollera den offentliga DNS-posten, porten, framförliggande NAT, Administration > Device access och en möjlig Port Sharing-effekt.
Portalens inloggning misslyckas: Kontrollera VPN Portal-autentisering under Authentication > Services samt användarstatus, MFA och access_server.log.
Clientless access connections saknas: Användaren har inte tilldelats någon Clientless Policy eller så publicerar policyn ingen bookmark.
Bookmarken visas för fel användare: Kontrollera Policy members, gruppmedlemskap och Published bookmarks. Vid flera matchande grupper kan Clientless SSL VPN kombinera behörigheterna från de tillhörande policies. Vilka bookmarks en verklig användare därmed ser ska ingå i det positiva och negativa testet.
Bookmarken öppnas men målet kan inte nås: Kontrollera DNS-upplösningen ur brandväggens perspektiv, den statiska måladressen, routing, målporten, tjänstens status och värdbrandväggen.
Inloggningen på VPN Portal fungerar men inte Windows-inloggningen: Portal- och målinloggning är separata. Kontrollera domän, målkonto, lösenord samt TLS eller NLA.
NLA aktiverar Automatic login: Detta är det dokumenterade beteendet. Inaktivera inte NLA oplanerat, utan ompröva konto- och åtkomstmodellen.
SSH visar en annan Host Key: Stoppa anslutningen och kontrollera ändringen direkt på målsystemet eller med den ansvariga operatören. En oväntad nyckel kan tyda på en ominstallation, ett felaktigt mål eller en attack.

Under Diagnostics > Tools > Troubleshooting logs hjälper olika filer i olika faser:

vpnportal.log för VPN Portal;
access_server.log för autentisering och auktorisering;
clientless_access.log för Clientless-anslutningar och anslutningen till målet;
oauth_sso_vpn.log för inloggningar på VPN Portal med SSO.

Testtidpunkt, användare, bookmark och mål bör dokumenteras tillsammans. Då kan portal-, identitets- och målproblem skiljas åt i loggarna. Den allmänna loggtilldelningen och åtkomst via Advanced Shell finns i Sophos Firewall-tjänsteloggar.

Drift och kända RDP-begränsningar

Clientless Policies bör granskas regelbundet på samma sätt som andra Remote Access-behörigheter. Användare, bookmarks och målkonton som inte längre behövs tas bort. Lagrade lösenord eller Private Keys ska ha en owner, ett utgångsdatum och en rotationsprocess. Automatic login och Share session ska ingå i varje behörighetsgranskning.

RDP har två aktuella begränsningar som inte bör behandlas som konfigurationsfel:

Urklipp stöds inte i Clientless RDP-bookmarks sedan SFOS 19. Copy-and-paste mellan den lokala enheten och RDP-sessionen är därför inte en tillförlitlig arbetsmetod.
Muspekaren kan visas som ett kryss eller X i HTML5-RDP-sessionen i stället för som en normal pil. Sophos anger för närvarande ingen lösning.

Om urklipp, inbyggda RDP-funktioner, bredare nätverksåtkomst eller personliga målkonton på en server som kräver NLA utan lagrade Credentials är obligatoriska är Clientless SSL VPN inte rätt genväg. Då bör åtkomsten avsiktligt flyttas till Sophos Connect, RD Gateway, PAM, en Jump Host eller ZTNA.