Coraz częściej mamy do czynienia z sytuacją, kiedy pracownicy firmy czy organizacji tylko niewielką część czasu spędzają wewnątrz firmy natomiast stosunkowo często znajdują się poza firmą – odwiedzając klientów, podróżując służbowo czy też po prostu wykonując część pracy z domu. W takich przypadkach zachodzi potrzeba zapewnienia użytkownikom zdalnym bezpiecznego dostępu do zasobów sieci – nie tylko poczty e-mail, ale również często usług zdalnego pulpitu, udostępnionych folderów i drukarek czy innych aplikacji i zasobów biznesowych.

Jedną z możliwości zapewnienia dostępu zdalnego jest skonfigurowanie tzw. węzła dostępowego, wyposażonego w odpowiednią ilość portów, do których są dołączone np. modemy analogowe lub ISDN. Każdy użytkownik zestawia bezpośrednie połączenie do takiego serwera dostępowego i przez niego uzyskuje dostęp do innych zasobów sieci LAN. Dane są w takim przypadku przesyłane jedynie przez wewnętrzną infrastrukturę operatora PSTN czy ISDN, więc zagrożenia związane z podsłuchaniem przesyłanych danych, czy podszyciem się pod konkretny numer telefonu są stosunkowo niewielkie. Problemem staje się natomiast ilość dostępnych portów – ograniczenia może tu narzucać wykorzystywany sprzęt (serwer czy tzw. access builder) lub dostawca (ilość dostępnych linii telefonicznych czy kanałów ISDN). W przypadku połączeń międzymiastowych lub międzynarodowych znacząco rosną koszty związane z zapewnieniem zdalnego dostępu.

Innym, coraz powszechniej stosowanym rozwiązaniem jest wykorzystanie wspólnej sieci o charakterze publicznym, do której mają dostęp: użytkownik pracujący zdalnie i przynajmniej jeden serwer z sieci, do której chcemy się podłączyć. Aby wyeliminować zagrożenia związane z przesyłaniem danych w sieci takiej jak np. Internet klient zdalny oraz serwer dostępowy tworzą bezpieczny tunel. Dane wysyłane przez klienta są kodowane oraz podpisywane cyfrowo a następnie w postaci tzw. protokołu tunelującego przesyłane przez sieć publiczną do serwera, który je rozkodowuje, weryfikuje podpis oraz przekierowuje do odpowiedniego serwera w sieci LAN.

W przypadku, kiedy serwerem tworzącym tunel (VPN) jest Small Business Server 2003 do dyspozycji mamy dwa protokoły tunelujące – PPTP oraz L2TP. Podstawowe różnice pomiędzy tymi protokołami zestawia poniższa tabela:

W jaki sposób skonfigurować system po stronie serwera i klienta aby było możliwe zestawianie bezpiecznych tuneli VPN ? W poniższym opisie zakładam, że firma dysponuje systemem SBS 2003 Premium po stronie serwera oraz Windows XP Professional po stronie klienta, choć tunele można zestawiać w przypadku dowolnej wersji SBS oraz dla systemów od Windows 95 wzwyż.

Procedurę rozpoczynamy od skonfigurowania serwera ISA, tak aby zapora akceptowała połączenia od klientów VPN. W tym celu w konsoli „ISA Management” odnajdujemy obiekt „Network configuration” i po jego podświetleniu w oknie detali uruchamiamy kreatora „Configure a client VPN”. Kreator nie zadaje żadnych pytań – informuje jedynie, że została uruchomiona i skonfigurowana usługa „Routing and Remote Access”, oraz że zostały dodane odpowiednie filtry pakietowe, konieczne dla akceptowania ramek protokołów tunelujących PPTP oraz L2TP.

W tym momencie możemy już przetestować działanie tunelu VPN po stronie klienta. Zakładamy, że stacja robocza jest podłączona do sieci Internet (np. przez modem) i posiada zarejestrowany, poprawny adres IP. W oknie „Połączenia sieciowe” uruchamiamy kreatora tworzenia nowego połączenia i jako typ połączenia wybieramy „Połącz z siecią w miejscu pracy” a później „Połączenie wirtualnej sieci prywatnej”.

Jedyną informacją, jaką musimy dysponować jest zewnętrzny adres IP naszego serwera VPN i taki adres wprowadzamy w polu „Wybór serwera sieci VPN”. Przy zestawianiu połączenia potrzebna nam będzie również nazwa i hasło użytkownika, któremu administrator nadał uprawnienie do zestawiania połączeń zdalnych (Dial-in permissions). W przypadku braku takiego uprawnienia zobaczymy komunikat jak poniżej:

Jeśli natomiast udało nam się pomyślnie nawiązać połączenie to jego parametry możemy sprawdzić klikając prawym klawiszem myszki na ikonie połączenia i wybierając opcję „STAN”.

Zauważmy, że automatycznie został wybrany protokół tunelujący PPTP a więc połączenie charakteryzuje się stosunkowo niskim poziomem zabezpieczeń. Podstawowym problemem jest fakt, że uwierzytelnienie użytkownika i połączenia zdalnego nastąpiło wyłącznie na podstawie jego nazwy i hasła a więc każdy, kto poznałby to hasło – może zestawić tunel VPN i tym samym uzyskać dostęp do zasobów sieci lokalnej.

Pierwszą czynnością, jaką wykonamy, aby lepiej zabezpieczyć nasz tunel będzie przełączenie na protokół L2TP, co zapewni nam lepszy poziom szyfrowania danych oraz przede wszystkim autoryzację komputerów biorących udział w zestawieniu tunelu VPN.

Rozpoczynamy od wystawienia certyfikatów dla obu komputerów tj. serwera VPN oraz stacji roboczej – procedura ta została opisana w artykule: Efektywne zabezpieczenie transmisji danych w sieci z wykorzystaniem protokołu IPsec i certyfikatów (PKI) na platformie SBS 2003. Ponieważ protokół L2TP wykorzystuje do zabezpieczenia transmisji mechanizm IPSEC to obie strony muszą dysponować certyfikatami wystawionymi przez ten sam lub wzajemnie zaufane urzędy CA i przypisanymi do konta komputera. Certyfikaty mogą być wystawione w oparciu o dedykowany szablon IPSEC lub też o standardowe szablony „Computer” lub „Domain Controller”.

Następnym krokiem jest wymuszenie tunelowania przy użyciu protokołu L2TP. Możemy to wykonać po stronie klienta konfigurując właściwości połączenia VPN według rysunku poniżej:

W takim przypadku jednak ustawienie to będzie dotyczyło tylko tego jednego klienta a inne stacje nadal będą mogły realizować połączenia z wykorzystaniem protokołu PPTP. Znacznie lepszym rozwiązaniem jest wyłączenie protokołu PPTP na serwerze VPN i pozostawienie wyłącznie możliwości użycia L2TP. Taki efekt uzyskujemy wybierając w konsoli „Routing and Remote Access” właściwości obiektu „Ports” i ustawiając opcje portów tak jak na poniższym ekranie.

Jeśli po wykonaniu tych zmian ponownie zestawimy tunel VPN to stan połączenia powinien wskazywać, że został wykorzystany protokół L2TP. Czynności, które wykonaliśmy dają nam pewność, że tunel mogą zestawić tylko i wyłącznie te komputery, dla których wystawiliśmy i zainstalowaliśmy odpowiedni certyfikat.

Jak widać powyżej – pierwszy krok zabezpieczenia tunelu został pomyślnie wykonany i zweryfikowany. W tej chwili najsłabszym elementem zabezpieczeń tunelu VPN jest hasło użytkownika. Jeśli potencjalny intruz wejdzie w posiadanie notebooka z zainstalowanym certyfikatem i pozna hasło użytkownika – będzie mógł zestawiać tunele i uzyskiwać dostęp do zasobów sieci. Możemy zatem wystawić certyfikat dla każdego użytkownika autoryzowanego do zestawiania tuneli VPN i taki certyfikat zabezpieczyć na stacji, np. kodem PIN lub umieścić na karcie inteligentnej, która będzie musiała być umieszczona w czytniku przed każdym nawiązaniem połączenia. W tym celu musimy tak skonfigurować serwer dostępu zdalnego, aby akceptował uwierzytelnianie użytkownika przy wykorzystaniu protokołu EAP i certyfikatów. Kolejne kroki wyglądają następująco:

1. W konsoli „Routing and Remote Access” wybieramy właściwości obiektu serwera i konfigurujemy ustawienia uwierzytelniania jak poniżej.
   
2. Tworzymy nową politykę zdalnego dostępu dla klientów VPN (Remote Access Policies) i w jej właściwościach zaznaczamy typ połączenia jako VPN oraz EAP jako metodę uwierzytelniania. Po wykonaniu tych zmian niezbędny jest restart usługi RRAS.
   
3. Ostatnim etapem jest wystawienie certyfikatu i modyfikacja ustawień klienta – we właściwościach połączenia VPN dodajemy typ uwierzytelniania EAP.
   

Po wprowadzeniu powyższych zmian tunel VPN może być zestawiony jedynie po spełnieniu trzech warunków:

1. Komputer, z którego jest zestawiane połączenie musi być autoryzowany poprzez wystawienie dla niego i zainstalowanie odpowiedniego certyfikatu (IPSEC).
2. Użytkownik zestawiający tunel musi mieć wystawiony certyfikat weryfikujący jego tożsamość (Client Authentication Certificate) – nie jest w tym przypadku konieczne wpisywanie jakiejkolwiek nazwy logowania ani hasła.
3. Serwer VPN musi dysponować co najmniej dwoma certyfikatami: „IPSEC” oraz „Server Authentication” oraz mieć skonfigurowaną politykę dopuszczającą uwierzytelnianie zdalnych użytkowników za pomocą protokołu EAP.

Tak skonfigurowany i zabezpieczony tunel jest najlepszym sposobem na dostęp do zasobów serwera SBS oraz sieci lokalnej z zewnątrz tej sieci. Zabezpieczenia tunelu nie zwalniają jednak administratora z konieczności śledzenia połączeń i wykrywania oraz blokowania potencjalnych ataków pochodzących z sieci Internet.

Opracowanie własne dla portalu SBS-Forum.pl

Autor: Paweł Ratajczak