Zestawienie tunelu odbywa się przynajmniej między dwoma hostami, którym wydzielana jest wirtualna przestrzeń adresowa oraz interfejsy sieciowe. Wymiana danych jest szyfrowana i odbywa się poprzez sieć publiczną. Dane takie muszą być zabezpieczone w kwestii poufności, integralności i autentyczności. Na potrzeby wirtualnej sieci prywatnej tworzona jest osobna tablica routingu. Umożliwia to fakt, że VPN działa w trzeciej warstwie modelu ISO/OSI – warstwie sieciowej.

W sytuacji kiedy powstaje nowy oddział danego przedsiębiorstwa, a koszty zbudowania dedykowanej dzierżawionej linii komunikacyjnej są zbyt wysokie, istnieje możliwość połączenia oddziałów przez publiczną sieć Internet.

 

Rysunek 3.1 Przykład tunelu VPN [opracowanie własne]

 

Wyróżniamy dwa podstawowe rodzaje architektury sieci VPN :

Site-to-site – służąca do łączenia lokalizacji odległych od siebie poprzez sieć Internet; celem jest stworzenie trwałego połączenia, którego celem jest zapewnienie pracy w taki sposób, jak wyglądałaby ona jeśli komputery znajdowałyby się w jednej sieci fizycznej.

Implementacja może przebiegać na dwa sposoby – Meshed VPN oraz Hub & Spoke. W topologii pierwszego typu każde urządzenie zestawia tunel VPN między sobą; druga topologia zakłada istnienie centralnego urządzenia, które zarządza zestawianiem połączeń pomiędzy innymi elementami sieci. Używane w przypadku dużej liczby urządzeń ze względu na lepszą efektywność.

Rysunek 3.2. Przykład rozwiązania typu site-to-site [opracowanie własne na podstawie literatury[1]]

Client-to-site – rozwiązanie to służy do łączenia zdalnych hostów poprzez publiczną sieć z siecią LAN w danej organizacji. Kanał jest otwierany na żądanie klienta i po uprzedniej autoryzacji umożliwia korzystanie z zasobów lokalnych danej organizacji.

 

Rysunek 3.3. Przykład rozwiązania client-to-site [opracowanie własne na podstawie literatury[2]]

Ogólna idea działania polega na zaszyfrowaniu danych i nagłówka oryginalnego pakietu, następnie umieszczenie go w pakiecie zawierającym nowy nagłówek, a w nim adresy IP urządzeń VPN.

3.2 Rozwiązanie oparte o protokół IPSEC

Rozwiązanie VPN oparte o protokół IPSEC składa się z dwóch kanałów komunikacji – kanału wymiany kluczy, którym przekazywane są dane dotyczące uwierzytelniania i szyfrowania oraz kanału transmisji pakietów. Standardowa komunikacja w kanale obsługującym wymianę pakietów odbywa się na porcie 500 UDP, zaś dane są transmitowane przez protokół ESP[3]. Pakiety TCP są poddawane kapsułkowaniu.

Jakie są korzyści z używania protokołu ESP? Najważniejsze z nich to:

  • uwierzytelnianie źródła danych
  • integralność danych (wykorzystanie funkcji skrótu)
  • niezaprzeczalność danych (wykorzystanie funkcji skrótu)
  • zapewnia odporność na duplikowanie pakietów oraz ataku typu „replay attack (szerzej opisanego w sekcji bezpieczeństwa protokołu, rozdział 3.4.2)
  • zapewnia poufność danych

Protokół ten może działać w dwóch trybach – transportowym i tunelowym.

W trybie transportowym oryginalny nagłówek pakietu pozostaje bez zmian, natomiast tuż za nim dokładane są dane protokołu ESP. W tym trybie potencjalny atakujący nie jest w stanie podsłuchać treści komunikacji, ale może zobaczyć oryginalne adresy źródłowe i docelowe (wraz z rzeczywistą adresacją w danej sieci).

Rysunek 3.4. Protokół IPSEC – schemat nagłówka w trybie transportowym [opracowanie własne na podstawie RFC 2406[4]]

W trybie tunelowym nagłówek zawiera już zmodyfikowane dane (m.in. adres źródłowy i docelowy). Oryginalny nagłówek zostaje także umieszczony w sekcji danych pakietu TCP. Potencjalny atakujący nie jest w stanie poznać adresacji w sieciach, poprzez które komunikują się dwie strony kanału transmisji.

Rysunek 3.5. Protokół IPSEC – nagłówek w trybie tunelowym [opracowanie własne na podstawie RFC 2406[5]]

Do zestawienia tunelu IPSEC konieczne jest ustalenie związków bezpieczeństwa. Musi nastąpić wymiana kluczy tajnych, co odbywa się przy zastosowaniu protokołu IKE (ISAKMP). Fundamentem tego protokołu jest wcześniej opisywany przeze mnie algorytm Diffiego-Hellmana. Urządzenia wspierające budowanie VPN umożliwiają zazwyczaj na skorzystanie z jednej z trzech możliwych długości klucza DH :

  • Grupa 1 – klucz o długości 768 bitów
  • Grupa 2 – klucz o długości 1024 bity
  • Grupa 5 – klucz o długości 1536 bitów

Proces bezpiecznej wymiany kluczy IKE przebiega dwufazowo[6]:

W fazie 1 zostaje zestawiony bezpieczny kanał komunikacji służący do wymiany informacji kluczowych, aby rozpocząć fazę 2. W skład tych informacji wchodzą:

  • Algorytm szyfrowania (DES lub 3DES)
  • Algorytm integralności (MD5 lub SHA1)
  • Grupa Diffiego-Hellmana
  • Metoda uwierzytelniania (uwierzytelnianie przy użyciu protokołu Kerberos V5, certyfikatów lub klucza wstępnego)[7]

Podczas trwania fazy pierwszej urządzenia VPN generują cztery klucze tajne (SKEYID), które służą do wyznaczania następnych kluczy (m.in. do sprawdzania integralności, autentyczności, szyfrowania komunikatów protokołu).

Faza pierwsza może zostać przeprowadzona na dwa sposoby – w trybie pełnym (Main Mode) lub skróconym (Aggressive Mode).

Tryb Main Mode charakteryzuje wymiana 6-ciu komunikatów pomiędzy urządzeniami. Stosuje się go głównie w trybie Site-to-site, gdzie adresy IP urządzeń są stałe.

Przebieg tej fazy wygląda następująco:

  • Pierwsze dwie wiadomości służą do wynegocjowania informacji SA celem zestawienia kanału bezpiecznej transmisji. Przesyłane są dane Cookie, które chronią przed atakiem typu IP Spoofing i jednoznacznie identyfikują urządzenia.
  • Kolejne dwie wiadomości zawierają klucz publiczny Diffiego-Hellmana oraz losowo wygenerowaną liczbę, która posłuży w fazie 2 do wyznaczania tajnych kluczy.
  • Ostatnie dwie wiadomości służą do uwierzytelnienia autentyczności urządzeń VPN poprzez klucz typu Pre-Shared lub certyfikaty. Transmisja ta jest szyfrowana i uwierzytelniana za pomocą algorytmów ustalonych w pierwszych dwóch wiadomościach.

Rysunek 3.6. Faza 1 IKE w trybie Main Mode. [opracowanie własne na podstawie literatury[8]]

Tryb Aggressive Mode charakteryzuje wymiana trzech komunikatów i jest powszechnie stosowany w rozwiązaniu Client-to-site.

Przebieg fazy 1 w tym trybie wygląda następująco:

  • W wiadomości pierwszej urządzenie inicjujące tunel wysyła komplet wiadomości – propozycję SA, klucz Diffiego-Hellmana, liczbę losową i identyfikator IKE (np. nazwa domenowa urządzenia).
  • Wiadomość drugą przesyła urządzenie odpowiadające. Zawiera się w niej informacja o akceptacji połączenia, kod Hash wygenerowany z wykorzystaniem Pre-Shared Secret. Urządzenie odpowiadające umieszcza w niej również swój klucz DH, liczbę losową i IKE ID.
  • Wiadomość trzecia kończy proces wymiany informacji poprzez uwierzytelnianie przesłanych do urządzenia inicjującego informacji.

 

Rysunek 3.7. Faza 1 IKE w trybie Aggressive Mode [opracowanie własne na podstawie literatury[9]]

 

W fazie 2 IKE uzgadniane są związki bezpieczeństwa dotyczące konkretnej transmisji danych celem szyfrowania i uwierzytelniania danych przesyłanych w tunelu IPSec.

W tej fazie urządzenia wymieniają między sobą trzy wiadomości:

  • Wiadomość 1 (urządzenie A – inicjujące) – hash wyznaczony z danych fazy #1, identyfikator wiadomości, propozycje SA, liczba losowa A, proxy ID, klucz publiczny DH urządzenia wysyłającego
  • Wiadomość 2 (urządzenie B – odpowiadające) – hash wyznaczony z danych fazy #1, identyfikator wiadomości, akceptacja propozycji SA, liczba losowa B, proxy ID, klucz publiczny DH urządzenia B
  • Wiadomość 3 (urządzenie A – inicjujące) – hash wyznaczony z danych fazy #1, identyfikator wiadomości, liczba losowa A, liczba losowa B.

Analogicznie do fazy #1 , w fazie drugiej urządzenie inicjujące sesję może podać kilka propozycji SA, które jest w stanie obsłużyć. W polu Proxy ID znajdują się informację o regułach polityki bezpieczeństwa w zestawianej sesji VPN.

W tej fazie może nastąpić kolejna wymiana kluczy DH. Standardowo jest to opcja i następuje tylko przy wykorzystaniu właściwości Perfect Forward Secrecy).

Podczas działania fazy drugiej następuje odnawianie SA w określonym interwale czasowym. Czas określa się podczas konfiguracji urządzeń VPN.

3.3 Wzbogacenie rozwiązania opartego na IPSEC o infrastrukturę PKI

Zwiększenie bezpieczeństwa w sieci VPN opartej o IPSEC można osiągnąć poprzez wykorzystanie infrastruktury klucza publicznego. Cyfrowe certyfikaty minimalizują niebezpieczeństwo podszywania się pod zaufane urządzenia sieci VPN.

Celem wykorzystania certyfikatów, należy zarejestrować urządzenia w urzędzie certyfikacji dołączając część publiczną kluczy krypto danego urządzenia. Tworząc sieć VPN dla biznesu SOHO zazwyczaj stosuje się generowanie certyfikatów przez własny, wewnętrzny urząd certyfikacji CA[10].

Proces wymiany wiadomości w fazie #1 IKE z wykorzystaniem certyfikatów różni się od procesu z wymianą klucza tajnego ostatnimi dwiema wiadomościami. Zawierają one bowiem zamiast tajnego klucza, identyfikatory i podpisy cyfrowe odpowiednich urządzeń końcowych danego kanału komunikacji.

Rysunek 3.8  Faza 1 IKE z wykorzystaniem PKI [opracowanie własne na podstawie literatury[11]]

Cyfrowy certyfikat zawiera szereg istotnych informacji. Możemy dowiedzieć się m.in. jaka wersja X509 została użyta do jego utworzenia, kiedy został wydany i przez kogo oraz jaka jest jego ważność. Wydany raz certyfikat można unieważnić np. w sytuacji, gdy dostał się w niepowołane ręce.

Rysunek 3.9 budowa certyfikatu x509 v1,2,3  [opracowanie własne na podstawie dokumentu RFC 3280[12]]

Jeżeli certyfikat został unieważniony, trafia na listę CRL. Lista taka jest publikowana przez dostawcę certyfikatu w formie pliku i zawiera najważniejsze informacje tj. unikalny numer seryjny certyfikatu oraz datę unieważnienia. Listy CRL są na bieżąco aktualizowane przez dostawców.

Aby urządzenie w sieci VPN mogło wykorzystać certyfikaty cyfrowe, musi spełniać następujące założenia[13]:

  • posiadać mechanizm generowania kluczy prywatnych, publicznych RSA
  • generować wniosek o wydanie certyfikatu zgodnie ze standardem PKCS#10
  • odczytywać certyfikaty w standardzie X.509 zgodnie ze standardem PKCS#7 i sprawdzać ich ważność na liście CRL
  • pobierać aktualnie listy CRL

Standardowy proces pobierania cyfrowego certyfikatu dla urządzenia przebiega w następujących etapach:

  1. Generacja pary kluczy RSA prywatny <> publiczny
  2. Generacja pliku zgodnego z PKCS#10, zawierającego dane identyfikacyjne oraz klucz RSA.
  3. Przesłanie pliku utworzonego w poprzednim kroku do urzędu certyfikacji CA
  4. Weryfikacja pliku przez CA i wystawienie certyfikatu cyfrowego dla urządzenia
  5. Pobranie przez urządzenie certyfikatu dla urządzenia, certyfikatu urzędu CA oraz aktualnej listy CRL.

Administrator danej sieci jest odpowiedzialny za utrzymanie ważności certyfikatów, a w razie zbliżającego terminu wygaśnięcia musi podjąć stosowne kroki, aby dany certyfikat odnowić w urzędzie certyfikacji.

Protokół SCEP pozwala na zautomatyzowanie procesu certyfikowania. Sprzęt wspierający ten protokół posiada zdolność kontrolowania i automatycznego odnawiania certyfikatów w urzędzie certyfikacji.

3.4 Rozwiązanie oparte o protokół SSL

Podstawową zaletą takiego rozwiązania jest wysoka dostępność. Stosuje się je często przy połączeniach client-to-site z wykorzystaniem przeglądarek internetowych oraz dodatkowych zabezpieczeń np. w postaci tokena RSA.

Rysunek 3.10. Scenariusz wykorzystania techniki VPN SSL [opracowanie własne na podstawie Cisco Systems[14]]

 

Planując budowę rozwiązania opartego o SSL musimy mieć świadomość, że nie jest to tak uniwersalne rozwiązanie jak wspomniany wcześniej tunel IPSEC i wymaga dodatkowych form zabezpieczeń.

Wymogiem do połączenia z firmową siecią jest posiadanie najnowszych aktualizacji systemu operacyjnego i oprogramowania. Weryfikację realizują odpowiednie aplety JAVA lub programy klienckie. Aby skorzystać z tego rodzaju połączenia, dla przykładowego routera VPN CISCO z systemem IOS 12.4 należy spełniać następujące wymagania[15]:

  • Posiadanie konta użytkownika w sieci firmowej (login, hasło)
  • Przeglądarkę internetową z obsługą SSL (np. Internet Explorer, Firefox, Netscape)
  • System operacyjny Microsoft Windows 2000, XP, Vista lub MacOS X 10.4.6 lub z rodziny Unix Fedora 5 i powyżej.
  • Uprawnienia administracyjne na lokalnym koncie w systemie operacyjnym

Niestety nie każda usługa, za wyjątkiem protokołu HTTP może w sposób tradycyjny funkcjonować korzystając z tunelu VPN SSL. Stosunkowo łatwo jest wymusić zabezpieczanie transmisji poczty e-mail używając SSL. Inaczej ma się sprawa z innymi aplikacjami, kiedy trzeba wspierać się programami klienckimi czy apletami Java aby wymusić przekierowanie ruchu do bezpiecznego tunelu.

Istotną rolę w tym rozwiązaniu odgrywa usługa DNS, której odpowiednia konfiguracja umożliwia przesyłanie transmisji bezpiecznym tunelem. Zazwyczaj odbywa się to w sposób niewidoczny dla użytkownika. Pracujący klient sieci VPN SSL przekierowuje żądania DNS na siebie samego, następnie bezpiecznym kanałem przesyła żądanie do serwera w lokalizacji docelowej.

Podsumowując – rozwiązanie to ze względu na swoją wysoką dostępność wymaga szczególnej uwagi w kwestiach bezpieczeństwa. Bezpieczeństwo zdalnego systemu, który właśnie dokonuje połączenia do naszego oddziału, stanowi o bezpieczeństwie całej sieci. Dlatego tak istotną wagę przywiązuje się do:

  • Bezpiecznego uwierzytelniania użytkowników (dynamiczne hasła, tokeny sprzętowe, kody jednorazowe / sms )
  • Prawidłowej konfiguracji uprawnień, które mogą zminimalizować ewentualne szkody a zarazem zapewnić właściwą dostępność do usług
  • Sprawdzenia jakości bezpieczeństwa zdalnego systemu (kontrola aktualności oprogramowania, baz antywirusowych )
  • Rejestrowania wszelkich zdarzeń nietypowych podczas połączenia (nieoczekiwane transfery plików lub inne operacje nietypowe dla tego połączenia)
  • Czyszczenie sesji, plików tymczasowych po zamknięciu połączenia

Przed przystąpieniem do bezpiecznej komunikacji z wykorzystaniem SSL, musi zostać nawiązana sesja (ang. handshake). Proces ten składa się z następujących etapów[16]:

  1. Klient wysyła pakiet do serwera (tzw. Hello) zawierający: numer obsługiwanej wersji protokołu SSL, rodzaje obsługiwanych algorytmów szyfrowania i kompresji oraz liczbę losową.
  2. W odpowiedzi serwer również wysyła informacje o obsłudze wspomnianych zagadnień oraz klucz publiczny (certyfikat).
  3. Następuje sprawdzenie przez klienta czy otrzymany certyfikat nie stracił ważności oraz czy został wystawiony przez zaufaną jednostkę CA.
  4. Jeśli wszystko zostanie zaakceptowane klient przystępuje do wygenerowania losowej liczby o nazwie „pre-master secret”. Liczba ta zostaje zaszyfrowana z użyciem klucza publicznego serwera.
  5. Serwer przystępuje do odszyfrowania liczby „pre-master” korzystając ze swojego klucza prywatnego. Liczba zostaje porównana do tej wysłanej w kroku pierwszym.
  6. W przypadku gdy serwer wymaga uwierzytelnienia, w tym kroku klient przesyła swój certyfikat.
  7. Bazując na poznanych wcześniej danych, klient i serwer generują tajny klucz główny (ang. master key)
  8. Serwer oraz klient generują symetryczne klucze sesji na podstawie klucza „master key”. Są one wykorzystywane do szyfrowania i weryfikacji integralności.
  9. Przy zamykaniu etapu handshake, serwer otrzymuje od klienta poufną wiadomość zaszyfrowaną kluczem sesji. Nazywamy ją finished handshake.
  10. Serwer odpowiada poufną wiadomością zaszyfrowaną za pomocą tajnego klucza master. Sesja SSL zostaje nawiązana.

 


[1] M. Stawowski Projektowanie i praktyczne implementacje sieci VPN, Warszawa 2004, ArsKom, s. 24

[2] tamże, s. 25

[3] Dokument RFC 2406 (odnośnik: http://www.ietf.org/rfc/rfc2406.txt ) listopad 1998 r., s.7

[4] Dokument RFC 2406 , http://www.ietf.org/rfc/rfc2406.txt  , s.7

[5] tamże, s. 8

[6] Dokument RF2408, fazy negocjacji (odnośnik: http://www.ietf.org/rfc/rfc2408.txt) s. 15

[7] Baza wiedzy MS Tech-net,  (odnośnik: http://technet.microsoft.com/pl-pl/library/cc784994%28v=ws.10%29.aspx )

[8] M. Stawowski Projektowanie i praktyczne implementacje sieci VPN, Warszawa 2004, ArsKom, s. 35

[9] M. Stawowski Projektowanie i praktyczne implementacje sieci VPN, Warszawa 2004, ArsKom, s. 36

[10] M.Serafin, Sieci VPN – Zdalna praca i bezpieczeństwo danych str.15, Helion 2008, Warszawa

[11] M. Stawowski Projektowanie i praktyczne implementacje sieci VPN, Warszawa 2004, ArsKom, s. 41

[12] Dokument RFC 3280 , http://tools.ietf.org/html/rfc3280  , str. 14

[13] M. Stawowski Projektowanie i praktyczne implementacje sieci VPN, Warszawa 2004, ArsKom, s. 21

[14] Źródło internetowe: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html

[15] Prerequisites for SSL VPN, Źródło internetowe: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html

[16] M. Serafin Sieci VPN – Zdalna praca i bezpieczeństwo danych, Warszawa 2008, Helion, s.14