Port Forwarding - SSL VPN

Polega na tym, że w pierwszej kolejności stacja kliencka pobiera z koncentratora i uruchamia kontrolkę ActiveX lub aplet Javy. Następnie ta miniaplikacja nasłuchuje na konkretnym porcie i wszystko to, co do niego napływa, tuneluje SSL-em do koncentratora. Ten odszyfrowuje zawartość i przekazuje ją do docelowego serwera aplikacji. Technika ta sprawdza się znakomicie w przypadku aplikacji, których zachowanie i sposoby komunikacji są łatwo przewidywalne i stałe, np. zdalny pulpit, VNC, telnet.

Inną techniką jest translacja aplikacji. Daje ona użytkownikowi możliwość interakcji z aplikacją przy udziale interfejsu ActiveX lub Javy, który naśladuje oryginalne GUI aplikacji, ale przesyła zapytania w formacie http. Koncentrator SSL VPN musi wówczas tłumaczyć http na "język ojczysty" aplikacji przed przekazaniem zapytania do serwera. Kolejna metoda to wykorzystanie właściwości systemu operacyjnego stacji klienckiej, a konkretnie jego komponentów pozwalających na przekierowanie ruchu do tunelu SSL-owego. W środowisku Windows mogą do tego celu posłużyć NSP (Name Space Provider) i LSP (Layered Service Provider). Do prawidłowego funkcjonowania technika ta wymaga jednak od producenta rozwiązania sporego nakładu pracy.

A co jeżeli mamy do czynienia z wredną aplikacją, której sposób komunikacji wymusza uruchomienie łączności na poziomie sieciowym? Wówczas jedynym sposobem jest "przedłużenie" sieci LAN i udostępnienie jej za pośrednictwem tunelu SSL. W tym celu znowu zaprzęgnięta do pracy zostaje miniaplikacja, np. aplet Javy, która po ściągnięciu na stację tworzy wirtualny interfejs sieciowy. To z kolei daje możliwość nadania stacji adresu IP z puli prywatnej, co w rezultacie pozwala traktować klienta jako element sieci lokalnej. Wtedy nic nie stoi na przeszkodzie, aby po tunelu "biegał" wszelki ruch TCP, UDP czy ICMP. Zastosowanie tej techniki w uzyskiwanym efekcie bardzo zbliża SSL VPN do IPSec. Nadal jednak SSL VPN utrzymuje przewagę polegającą na tym, że użytkownik zwolniony jest z obowiązku ręcznej konfiguracji agenta.

Nie wszystko jednak wygląda tak różowo. Tworzenie wirtualnego interfejsu sieciowego wymaga posiadania uprawnień administratora na maszynie lokalnej, a zatem zasięg skorzystania z tej metody jest ograniczony. Funkcja nawiązania łączności na poziomie sieci nazywa się różnie u różnych producentów (np. Aventail - Avantail OnDemand, CheckPoint - SSL Network Extender, Juniper - SAM/NC), ale mechanizm działania jest podobny. Tutaj też producenci oferują dwa warianty użycia "rozszerzacza sieci". Pierwszy polega na tym, że w momencie zestawienia tunelu i uruchomienia wirtualnego interfejsu całość ruchu generowanego przez stację "wpada do rury" i przekazywana jest do koncentratora SSL. Ten decyduje o dalszej dystrybucji pakietów. Te z nich, które kierowane są do zasobów w sieci LAN, dostarczane są bezpośrednio do celu; inne (np. odwołania do Google.pl) trafiają na adres bramy domyślnej dla sieci lokalnej. Funkcja ta często określana jest nazwą route all traffic lub full tunneling. Drugi z wariantów obciąża pracą stację kliencką. Do tunelu trafia tylko taki ruch, który odnosi się do zasobów w sieci lokalnej; pozostały dystrybuowany jest za pośrednictwem bramy domyślnej stacji.

Sposoby na uwierzytelnienie

Rzućmy teraz okiem na sprawy związane z bezpieczeństwem. Podstawowa rzecz to uwierzytelnienie użytkownika. Na szczęście temat ten znany jest na tyle dobrze, że w ciemno można powiedzieć, że na poziomie logowania do portalu koncentratora niemal każde z rozwiązań będzie obsługiwało integrację z istniejącą bazą LDAP, serwerem RADIUS, wykorzystywało podwójne uwierzytelnianie (np. RSA SecurID i tokenów). Stosowane są również certyfikaty, ale ich użyteczność z uwagi na konieczność wcześniejszego "nakarmienia" nimi stacji klienckiej ogranicza krąg urządzeń, z których można się logować. Część rozwiązań zapewnia też powiązanie mechanizmu uwierzytelniania z pozostałymi aplikacjami dostępnymi z koncentratora realizując funkcję SSO (Single-Sign-On). Nie jest to jednak reguła.

Kolejna sprawa to autoryzacja, a więc przydzielenie odpowiednich uprawnień uwierzytelnionemu użytkownikowi. Kryteriów może być wiele. W przypadku uwierzytelniania podstawowym powinien być sposób uwierzytelnienia (np. szerszy dostęp - jeżeli użyto tokenu, a węższy - jeżeli hasła). Tutaj możliwości konfiguracyjne bardzo różnią między sobą dostępne bramy SSL VPN. Od autoryzacji opartej na profilach uwzględniających także specyfikę środowiska, z którego łączy się użytkownik, przez integrację z zewnętrznymi bazami danych, do totalnej ascezy polegającej na uznaniu, że jeżeli użytkownik został dowolną metodą uwierzytelniony na koncentratorze, to ma dostęp do takiej a takiej aplikacji.

Nie pozostawiać śladów

Dużym problemem w przypadku VPN z przeglądarki jest zapewnienie bezpieczeństwa poufnym danym, które trafiają do stacji użytkownika. Część z danych pobieranych jest celowo (np. arkusze kalkulacyjne), część nieświadomie (np. pliki tymczasowe zapisywane podczas otwierania załączników wiadomości pocztowych) lub niejako przy okazji (np. pamięć podręczna przeglądarki). Pozostają też inne informacje, np. zawartość pól formularzy (funkcja autouzupełniania), ciasteczka, historia odwiedzonych witryn, często również zapamiętane dane logowania do portalu. Uniknięcie tego typu niebezpieczeństw możliwe jest na kilka sposobów. Część najprostszych produktów w momencie wylogowywania użytkownika ostrzega go o konieczności usunięcia danych, a to wymaga od niego posiadania odpowiedniej wiedzy, a nawet wówczas nie gwarantując sukcesu (np. brak możliwości uruchomienia oprogramowania do bezpiecznego usuwania plików, nietypowe lokalizacje danych podręcznych itd.). Inne produkty wykorzystują "rozumienie" przez nowsze przeglądarki komendy NOCACHE, która powoduje, że żadne z przechodzących przez portal danych nie będą zapisywane lokalnie. Zabezpieczenie to, choć zawsze lepsze niż żadne, jest często nieskuteczne i bywa, że uniemożliwia przy okazji prawidłowe funkcjonowanie niektórych aplikacji. Chyba najbardziej wyszukaną z obecnie wykorzystywanych technik jest tworzenie podczas nawiązywania sesji SSL wirtualnych pulpitów oraz przestrzeni dyskowych, których cała zawartość poddana zostaje szyfrowaniu i wszelkie uruchamiane przez użytkownika aplikacje zmuszane są do operowania w tym właśnie obszarze. CheckPoint na przykład (produkt Connectra) nazywa to rozwiązanie Secure Workspace, Juniper (seria SA) - Secure Virtual Workspace. Użycie obszaru szyfrowanego sprawia, że usterka komputera czy nieuwaga użytkownika i nieprawidłowe zakończenie sesji, a co za tym idzie pozostawienie zaszyfrowanego pliku na stacji klienckiej, nie będą stanowiły zagrożenia.