Konfiguracja Clientless SSL VPN dla RDP i SSH na Sophos Firewall

Za pomocą Clientless SSL VPN Sophos Firewall udostępnia bezpośrednio w przeglądarce pojedyncze wewnętrzne połączenia RDP, SSH, VNC lub z serwerami plików. Użytkownik nie instaluje klienta VPN i nie otrzymuje ogólnego dostępu do sieci wewnętrznej. Zamiast tego loguje się do VPN Portal i widzi tylko bookmarki opublikowane przez przypisaną mu policy Clientless.

Podobna nazwa łatwo prowadzi do niewłaściwej konfiguracji: Clientless Users wewnętrznie przypisuje stały adres IP do tożsamości. Nie publikuje bookmarków i nie należy do tej procedury Remote Access.

Logowanie do VPN Portal i logowanie do systemu docelowego to dwa oddzielne etapy. Clientless SSL VPN nie obsługuje Credential Passthrough: hasło do VPN Portal nie jest automatycznie przekazywane jako dane logowania Windows lub SSH. Dwa logowania są więc normalne, dopóki dane logowania do celu nie zostaną zapisane w bookmarku.

Podstawowy proces jest krótki:

Określić stały system docelowy, port i uprawnioną grupę użytkowników.
W sekcji Remote access VPN > Clientless SSL VPN policy > Bookmarks utworzyć bookmark RDP lub SSH.
W sekcji Policies połączyć grupę użytkowników z bookmarkiem.
Zabezpieczyć VPN Portal, certyfikat, uwierzytelnianie, MFA i Device Access.
Przetestować dostęp z zewnątrz w sekcji VPN > Clientless access connections przy użyciu uprawnionego i nieuprawnionego użytkownika.

Kiedy Clientless SSL VPN jest odpowiedni, a kiedy nie

Clientless Access nadaje się szczególnie do kilku stałych celów, sporadycznego dostępu lub pracy zewnętrznych techników, gdy na używanym urządzeniu nie ma być instalowany klient VPN. Dzięki temu RDP i SSH nie muszą być publikowane bezpośrednio w Internecie za pomocą DNAT. Publicznie dostępny jest natomiast zabezpieczony VPN Portal.

Nie jest to jednak uproszczony zamiennik każdego Remote Access VPN:

Clientless SSL VPN pasuje do pojedynczych statycznych celów RDP, SSH, VNC lub serwerów plików, które można obsługiwać w przeglądarce.
Sophos Connect z IPsec lub SSL VPN sprawdza się lepiej, gdy zarządzane urządzenie potrzebuje dostępu do wielu sieci, aplikacji natywnych, DNS lub różnych protokołów. Warianty opisano w poradniku wyboru Remote Access.
ZTNA jest przeznaczone do stałego dostępu zorientowanego na aplikacje, opartego na tożsamości, stanie urządzenia i centralnych policies. Podstawy opisano w artykule Czym jest Zero Trust Network Access?.
Warto rozważyć RD Gateway, Jump Host lub PAM, gdy kluczowe znaczenie mają uprzywilejowana administracja, osobiste konta docelowe, rejestrowanie sesji lub procesy zatwierdzania.

W przypadku RDP należy również pamiętać, że schowek nie jest obsługiwany w sesjach Clientless od SFOS 19. Jeśli kopiowanie i wklejanie lub inne natywne funkcje RDP są niezbędne w danym procesie, lepszym wyborem będzie dostęp oparty na kliencie lub wyspecjalizowane rozwiązanie.

Clientless SSL VPN nie obsługuje dynamicznych docelowych adresów IP. Nazwa hosta jest dozwolona jako cel, ale Sophos Firewall musi rozwiązywać ją stabilnie na właściwy system. Często zmieniający się cel nie powinien być planowany jako niezawodnie aktualizowany scenariusz Dynamic DNS.

Wymagania wstępne i wartości przykładowe

Przed konfiguracją należy ustalić cel, tożsamość i dostęp do portalu:

System docelowy jest osiągalny z Sophos Firewall za pomocą routingu i DNS, a wymagana usługa działa.
Na Sophos Firewall lub podłączonym serwerze uwierzytelniania istnieje użytkownik albo możliwie wąska grupa.
VPN Portal ma publicznie lub wewnętrznie osiągalny FQDN oraz odpowiedni, zaufany certyfikat.
W sekcji Authentication > Services wybrano odpowiednią metodę w polu VPN portal authentication methods.
Przygotowano MFA i niezależny dostęp awaryjny.
Ustalono, czy dane logowania do celu mogą być przechowywane w bookmarku.

Poniższy przykład RDP wykorzystuje:

VPN Portal: https://vpn.example.com
serwer docelowy: rdp-app01.intern.example
docelowy adres IP: 10.20.30.25
port RDP: 3389
bookmark: RDP-Fibu-Test
grupa: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
zabezpieczenie RDP dla pierwszego testu: TLS
Automatic login: wyłączone
Share session: wyłączone

example.com jest zarezerwowaną domeną przykładową, a 10.20.30.25 prywatnym adresem przykładowym. FQDN, adres IP, grupa i nazwy muszą zostać zastąpione wartościami z własnego środowiska. Port 3389 jest prawidłowy tylko wtedy, gdy serwer Windows rzeczywiście używa standardowego portu RDP.

Konfiguracja bookmarka RDP

Bookmark z TLS i osobistym logowaniem do celu

W sekcji Remote access VPN > Clientless SSL VPN policy > Bookmarks za pomocą Add tworzy się nowy bookmark:

W polu Name wpisać RDP-Fibu-Test.
Jako Type wybrać RDP.
W polu URL wpisać rdp-app01.intern.example lub stały adres IP 10.20.30.25.
Użyć portu usługi 3389. Inny port wpisuje się tylko wtedy, gdy został on świadomie skonfigurowany inaczej na systemie docelowym.
Na potrzeby pierwszego testu pozostawić Automatic login wyłączone.
W razie potrzeby wpisać domenę sieciową Windows, na przykład CORP lub corp.example.com.
W polu Protocol security wybrać TLS.
Pozostawić Share session wyłączone.
Zapisać przyciskiem Save.

Bez Automatic login użytkownik wpisuje swoje dane logowania w otwartym oknie RDP. Pozwala to zalogować się za pomocą osobistego konta Windows, o ile model zabezpieczeń serwera docelowego dopuszcza ten tryb TLS.

Certyfikat VPN Portal i Protocol security: TLS pełnią różne funkcje. Certyfikat portalu chroni połączenie przeglądarki z Sophos Firewall. Ustawienie RDP chroni dalsze połączenie Sophos Firewall z systemem Windows. Prawidłowy certyfikat portalu nie zastępuje więc odpowiedniego zabezpieczenia RDP.

Gdy serwer Windows wymaga NLA

Wiele systemów Windows wymaga Network Level Authentication (NLA). W takim przypadku w bookmarku wybiera się NLA. SFOS włącza przez to Automatic login, a nazwa użytkownika i hasło systemu docelowego muszą zostać zapisane w bookmarku.

Nie jest to wyłącznie opcja zwiększająca wygodę. Wszyscy uprawnieni użytkownicy tego bookmarka pracują na systemie docelowym z użyciem tej samej zapisanej tożsamości Windows. Do tego celu należy używać wyłącznie dedykowanego konta z minimalnymi uprawnieniami i możliwością rotacji. Konta Domain Admin, osobiste konta administracyjne i szeroko uprawnione konta usługowe nie powinny znajdować się w bookmarku Clientless.

NLA nie powinno być wyłączane na serwerze Windows tylko po to, aby zadziałała przykładowa ścieżka TLS. Jeśli zapisane dane logowania lub wspólna tożsamość docelowa są niedopuszczalne, Clientless RDP nie pasuje do tego serwera. Zwykły VPN, RD Gateway, PAM lub kontrolowany Jump Host lepiej zachowują osobistą rozliczalność.

Również Share session pozostaje wyłączone. Opcja jest przeznaczona do świadomie zaplanowanego przypadku współpracy. W sesji współdzielonej Stop session kończy połączenie dla wszystkich uczestników, natomiast Suspend session wstrzymuje je tylko dla bieżącego użytkownika. Sesji uprzywilejowanej administracji nie należy udostępniać.

Konfiguracja policy Clientless i VPN Portal

Łączenie użytkowników i bookmarka w policy

Sam istniejący bookmark nie udostępnia jeszcze celu użytkownikowi. Dopiero policy łączy tożsamość z zasobem:

Otworzyć Remote access VPN > Clientless SSL VPN policy.
W sekcji Policies kliknąć Add.
Jako Name wpisać Clientless-RDP-Fibu.
W polu Policy members wybrać tylko grupę Clientless-RDP-Fibu.
W polu Published bookmarks wybrać RDP-Fibu-Test.
Zapisać przyciskiem Apply.

Bookmark Group ma sens dopiero wtedy, gdy ci sami użytkownicy potrzebują kilku celów. Dla pojedynczego celu RDP tworzy tylko dodatkowy poziom zarządzania.

Zabezpieczanie VPN Portal

Użytkownik otwiera połączenia Clientless za pośrednictwem VPN Portal. Domyślny port to 443; port i certyfikat znajdują się w sekcji Administration > Admin and user settings > Admin console and end-user interaction. W przykładzie certyfikat musi zawierać vpn.example.com jako SAN i być akceptowany przez przeglądarkę bez ostrzeżenia. Ogólne przypisywanie certyfikatów opisano w artykule Importowanie i przypisywanie certyfikatów na Sophos Firewall.

W sekcji Administration > Device access usługa VPN portal musi być dozwolona dla rzeczywiście potrzebnego dostępu. Jeśli portal ma być osiągalny ze wszystkich źródeł WAN, w macierzy włącza się WAN. W przypadku znanych sieci źródłowych lepszy jest bardziej restrykcyjny wariant: pozostawić WAN wyłączone w macierzy i w sekcji Local service ACL exception rule utworzyć regułę Accept z Source zone: WAN, konkretnym Source Network / Host, wymaganym adresem Sophos Firewall jako Destination host oraz Services: VPN portal. Dodatkowy wyjątek Accept nie ogranicza już ogólnie włączonego dostępu WAN w macierzy. WebAdmin, User Portal, SSH ani SSL VPN nie są przez to automatycznie udostępniane. Bezpieczne planowanie opisano w artykule Device Access i Local Service ACL.

⚠️ VPN Portal osiągalny ze strefy WAN jest publiczną powierzchnią logowania. Nie powinien działać bez MFA, zaufanego certyfikatu, wąskiego członkostwa w policy i monitorowania logowań. Jeśli VPN Portal i SSL VPN współdzielą ten sam port i protokół, ich osiągalne strefy mogą na siebie wpływać; ten efekt Port Sharing trzeba sprawdzić oddzielnie.

Dla lokalnego Sophos OTP w sekcji Authentication > Multi-factor authentication najpierw wybiera się Specific users and groups. Aby umożliwić samodzielną rejestrację za pomocą aplikacji uwierzytelniającej, należy włączyć Generate OTP token with next sign-in, w sekcji Require MFA for wybrać VPN portal i zapisać przyciskiem Apply. Pilotaż i ścieżkę odzyskiwania opisano w artykule Aktywacja MFA dla Sophos Firewall. VPN Portal nie obsługuje MFA RADIUS opartego na challenge; istniejącą metodę RADIUS trzeba więc przetestować dokładnie dla tego logowania do portalu. Jeśli portal ma zamiast tego używać Microsoft Entra ID SSO i Conditional Access, pełny łańcuch tożsamości opisano w artykule Entra ID SSO dla Sophos Connect i VPN Portal.

Testowanie dostępu z zewnątrz

Test należy przeprowadzić z rzeczywistej sieci zewnętrznej, na przykład przez hotspot komórkowy. Test z sieci LAN nie dowodzi, że DNS, certyfikat, Device Access i router poprzedzający Sophos Firewall współdziałają prawidłowo od strony Internetu.

Otworzyć https://vpn.example.com w prywatnym oknie przeglądarki.
Sprawdzić nazwę certyfikatu, łańcuch certyfikatów i stan w przeglądarce.
Zalogować się jako członek Clientless-RDP-Fibu i ukończyć MFA.
W sekcji VPN > Clientless access connections sprawdzić, czy pojawia się RDP-Fibu-Test.
Kliknąć Connect. Sesja musi otworzyć się w nowym oknie przeglądarki.
Przy wyłączonym Automatic login wpisać osobiste dane logowania Windows i sprawdzić logowanie RDP.
Prawidłowo wylogować sesję w systemie Windows, a następnie opuścić VPN Portal.
Przeprowadzić test z użytkownikiem spoza grupy. Bookmark nie może się tam pojawić.
Tymczasowo usunąć użytkownika testowego z grupy policy i sprawdzić, czy dostęp znika po ponownym zalogowaniu.

Sukces oznacza nie tylko widoczny pulpit. Użytkownik pozytywnego testu widzi dokładnie przewidziane bookmarki, użytkownik negatywnego testu nie widzi żadnego, MFA działa, certyfikat jest zaufany, logowanie do celu przebiega prawidłowo, a sesja kończy się w sposób możliwy do prześledzenia zarówno w portalu, jak i na systemie docelowym.

SSH, VNC i serwery plików

Bookmark SSH ze sprawdzonym Host Key

Dla SSH w sekcji Bookmarks > Add jako Type wybiera się SSH. Przykład wykorzystuje srv-linux01.intern.example, port 22 i użytkownika clientless-test.

Public host key musi należeć do oczekiwanego serwera. W przypadku systemu docelowego Linux można wyświetlić publiczny Host Key bezpośrednio na zaufanej konsoli serwera i udokumentować jego fingerprint:

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

Polecenia te wykonuje się na docelowym serwerze Linux, a nie na Sophos Firewall. Jeśli serwer używa innego typu Host Key, nazwę pliku trzeba odpowiednio zmienić. Klucza z niezweryfikowanego ostrzeżenia przeglądarki lub dowolnego skanu sieciowego nie należy przejmować bez sprawdzenia.

Pierwsze polecenie wyświetla publiczny ED25519 Host Key, który wstawia się w bookmarku w polu Public host key. Drugie polecenie pokazuje tylko fingerprint do udokumentowanego porównania; fingerprintu nie kopiuje się do pola zamiast klucza.

Następnie należy utworzyć kompletny bookmark SSH:

W polu Name wpisać na przykład SSH-Linux-Test.
Jako Type wybrać SSH.
W polu URL wpisać srv-linux01.intern.example, a jako port 22.
W polu Username ustawić clientless-test lub przewidzianego użytkownika docelowego.
Pozostawić Automatic login wyłączone, jeśli użytkownik ma samodzielnie wpisywać hasło do celu.
W polu Public host key wkleić klucz publiczny sprawdzony bezpośrednio na systemie docelowym.
Pozostawić Share session wyłączone i zapisać przyciskiem Save.
Dodać bookmark do policy Clientless w polu Published bookmarks i zapisać przyciskiem Apply.
W VPN Portal w sekcji VPN > Clientless access connections kliknąć Connect, wpisać hasło do celu i sprawdzić, czy pojawia się oczekiwany prompt terminala. Następnie prawidłowo zakończyć sesję SSH.

Bez Automatic login użytkownik wpisuje hasło do celu podczas nawiązywania połączenia; nazwa użytkownika pozostaje częścią bookmarka. Dla różnych osobistych nazw użytkowników SSH potrzebne są więc oddzielne bookmarki lub inna ścieżka dostępu. Z Automatic login SFOS może używać hasła lub Private Key. Uprzywilejowane lub szeroko wykorzystywane Private Keys nie powinny być zapisywane we wspólnie publikowanym bookmarku.

Inne typy bookmarków

SFOS 22 dokumentuje ponadto:

VNC do graficznego dostępu do odpowiednio skonfigurowanych systemów Linux lub UNIX.
FTP, FTPS, SFTP i SMB do dostępu do serwerów plików w przeglądarce. Nie powstaje przy tym zwykły zamontowany dysk sieciowy. W przypadku danych poufnych należy preferować SFTP lub FTPS zamiast nieszyfrowanego FTP.
Telnet jako typ terminala. Ponieważ Telnet nie szyfruje transportu, nie powinien być używany do nowych dostępów.

Bookmarki HTTP i HTTPS nie należą do obecnie udokumentowanych typów Clientless dla SFOS 22. Dla wewnętrznych aplikacji webowych, zależnie od wymagań ochrony, lepszą architekturą jest Web Application Firewall lub ZTNA.

Rozwiązywanie typowych problemów

VPN Portal jest nieosiągalny: Sprawdzić publiczny rekord DNS, port, poprzedzający NAT, Administration > Device access i możliwy efekt Port Sharing.
Logowanie do portalu nie działa: W sekcji Authentication > Services sprawdzić uwierzytelnianie VPN Portal, stan użytkownika, MFA i access_server.log.
Brakuje Clientless access connections: Użytkownik nie jest przypisany do policy Clientless albo policy nie publikuje żadnego bookmarka.
Bookmark jest widoczny dla niewłaściwego użytkownika: Sprawdzić Policy members, członkostwo w grupach i Published bookmarks. W przypadku kilku pasujących grup Clientless SSL VPN może łączyć uprawnienia powiązanych policies. To, które bookmarki widzi przez to rzeczywisty użytkownik, należy sprawdzić w teście pozytywnym i negatywnym.
Bookmark otwiera się, ale cel jest nieosiągalny: Sprawdzić rozwiązywanie DNS z perspektywy Sophos Firewall, statyczny adres docelowy, routing, port docelowy, stan usługi i firewall hosta.
Logowanie do VPN Portal działa, ale logowanie Windows nie: Logowanie do portalu i do celu to oddzielne procesy. Sprawdzić domenę, konto docelowe, hasło oraz TLS lub NLA.
NLA włącza Automatic login: Jest to udokumentowane zachowanie. Nie wyłączać NLA bez planu, lecz ponownie ocenić model kont i dostępu.
SSH zgłasza inny Host Key: Zatrzymać połączenie i sprawdzić zmianę bezpośrednio na systemie docelowym lub u odpowiedzialnego administratora. Nieoczekiwany klucz może wskazywać na ponowną instalację, błędny cel lub atak.

W sekcji Diagnostics > Tools > Troubleshooting logs w poszczególnych etapach pomagają różne pliki:

vpnportal.log dla VPN Portal;
access_server.log dla uwierzytelniania i autoryzacji;
clientless_access.log dla połączeń Clientless i nawiązywania połączenia z celem;
oauth_sso_vpn.log dla logowań do VPN Portal z SSO.

Należy wspólnie udokumentować czas testu, użytkownika, bookmark i cel. Pozwala to rozdzielić w logach problemy portalu, tożsamości i celu. Ogólne przypisanie logów oraz dostęp przez Advanced Shell opisano w artykule Logi usług Sophos Firewall.

Eksploatacja i znane ograniczenia RDP

Policies Clientless należy regularnie sprawdzać tak jak inne uprawnienia Remote Access. Usuwa się niepotrzebnych użytkowników, bookmarki i konta docelowe. Zapisane hasła lub Private Keys otrzymują Ownera, datę wygaśnięcia i proces rotacji. Automatic login i Share session powinny być elementem każdej kontroli uprawnień.

RDP ma dwa aktualne ograniczenia, których nie należy traktować jako błędów konfiguracji:

Schowek nie jest obsługiwany w bookmarkach Clientless RDP od SFOS 19. Kopiowanie i wklejanie między urządzeniem lokalnym a sesją RDP nie jest więc niezawodnym sposobem pracy.
W sesji HTML5 RDP wskaźnik myszy może być wyświetlany jako krzyżyk lub X zamiast zwykłej strzałki. Sophos nie podaje obecnie żadnego obejścia.

Jeśli niezbędne są schowek, natywne funkcje RDP, szerszy dostęp do sieci albo osobiste konta docelowe na serwerze wymagającym NLA bez zapisanych danych logowania, Clientless SSL VPN nie jest odpowiednim skrótem. Należy wtedy świadomie przejść na Sophos Connect, RD Gateway, PAM, Jump Host lub ZTNA.