Zasady działania i praktyczne implementacje sieci VPN

Zasady działania i praktyczne implementacje sieci VPN na bazie protokołów IPSec/IKE

1. Techniczne zasady funkcjonowania sieci IPSec

Protokół IPSec (IP Security) jest powszechnie stosowany do zabezpieczenia danych przesyłanych w sieciach IP. Został opracowany przez IETF (Internet Engineering Task Force) jako standard ochrony danych przesyłanych w sieciach IPv6 i dopiero w późniejszym czasie został przystosowany do wykorzystania w sieciach IPv4. Pierwsza specyfikacja IPSec pojawiła się w RFC 1825-1829. Aktualna specyfikacja to RFC 2401-2412 i 2451. IPSec ustala, w jaki sposób dane przesyłane w sieci powinny zostać zabezpieczone przed podsłuchem i nieupoważnioną modyfikacją za pomocą odpowiednich technik kryptograficznych (m.in. szyfrów, funkcji haszujących). Stosowane mogą być w tym zakresie m.in. algorytmy szyfrowania AES, 3DES, DES i CAST oraz algorytmy uwierzytelniania MD5 i SHA-1.

Ochrona danych w IPSec realizowana jest na poziomie warstwy 3 modelu OSI, czyli na poziomie datagramów IP. IPSec zawiera dwa stosowane w zależności od potrzeb protokoły ochrony danych:

– ESP (Encapsulating Security Payload) - stosowany do szyfrowania oraz częściowego uwierzytelniania danych,

– AH (Authentication Header) - służy do uwierzytelniania danych bez ich szyfrowania. Technicznie, funkcjonowanie IPSec polega na zabezpieczeniu datagramu IP i dodaniu do niego nagłówków ESP lub AH tak, aby odbiorca datagramu mógł go odczytać i zweryfikować jego integralność i autentyczność. Nagłówki ESP i AH dodawane są w zależności od protokołu ochrony, jaki został wybrany. W praktycznych implementacjach VPN zwykle stosuje się tylko protokół ESP. Rysunek przedstawia pakiet zabezpieczony protokołem IPSec ESP.

Datagram IP zabezpieczony protokołem IPSec ESP

Zasady działania i implementacje sieci VPN

© 2003 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 2

Oprócz protokołu ochrony (ESP, AH) można wybrać tryb funkcjonowania IPSec. Występują dwa tryby IPSec (patrz rysunek):

– Transport Mode - tryb IPSec bez tunelowania pakietów (tzn. pozostają oryginalne nagłówki datagramów IP),

– Tunnel Mode - tryb IPSec z tunelowaniem pakietów.

Tryby implementacji IPSec Tryb IPSec bez tunelowania pakietów (Transport Mode) stosuje się zwykle przy tworzeniu sieci VPN bezpośrednio pomiędzy komputerami. W sieciach VPN zestawianych pomiędzy urządzeniami typu Gateway/Router stosuje się tryb IPSec z tunelowaniem pakietów (Tunnel Mode).



Przed rozpoczęciem sesji IPSec wymagane jest, aby strony uczestniczące w transmisji wiedziały, w jaki sposób będą zabezpieczać dane. Zestaw informacji, które należy ustalić to m.in. protokół ESP czy AH, algorytmy i klucze kryptograficzne (patrz rysunek). Zestaw tych informacji określany jest jako Security Association (SA). Każdy tunel VPN powinien posiadać unikalne SA do ochrony wysyłanych i odbieranych informacji (tzn. dla jednego tunelu VPN wymagane są dwa SA). Urządzenie VPN posiada do tego celu bazę SA ponumerowaną za pomocą unikalnych identyfikatorów o nazwie Security Parameters Index (SPI). Numery SPI przekazywane są w nagłówkach ESP i AH tak, aby urządzenie odbierające pakiety IPSec widziało, w jaki sposób zostały zabezpieczone.

Elementy konfiguracji tunelu IPSec ESP

Bazy SA w urządzeniach VPN mogą być wpisywane ręcznie przez administratorów lub ustalane automatycznie z użyciem protokołu Internet Key Exchange (IKE). Protokół IKE został przedstawiony w dalszej części.



2. Negocjowanie sesji VPN za pomocą protokołu IKE

Przed zestawieniem tunelu IPSec wymagane jest, aby na urządzeniach VPN zostały ustalone związki bezpieczeństwa SA (m.in. zastosowany protokół ESP-AH, algorytmy i klucze kryptograficzne). Może odbywać się to ręcznie, bądź automatycznie za pomocą protokołu Internet Key Exchange (IKE). Protokół IKE (dawniej ISAKMP/Oakley) został opracowany przez IETF jako uzupełnienie IPSec o mechanizmy zarządzania kluczy.

Protokół IKE bazuje na algorytmie Diffiego-Hellmana, który umożliwia wyznaczenie tajnego klucza sesji bez konieczności wymiany tajnych informacji pomiędzy urządzeniami VPN. Bezpieczeństwo IKE jest w głównej mierze uzależnione od długości kluczy zastosowanych w algorytmie Diffiego-Hellmana (dokładnie chodzi o długość wykorzystywanej w algorytmie liczby pierwszej). Urządzenia VPN zwykle wspierają trzy opcje:

– Diffie-Hellman Group 1 (klucz 768 bitów), – Diffie-Hellman Group 2 (klucz 1024 bity), – Diffie-Hellman Group 3 (klucz 1536 bitów).

Proces ustalania SA pomiędzy urządzeniami VPN za pomocą protokołu IKE przebiega w

następujący sposób: – faza 1 (negocjacja IKE SA) � zestawienie bezpiecznego kanału komunikacji do

prowadzenia dalszych negocjacji (tzn. dla fazy 2), – faza 2 (negocjacja IPSec SA) � uzgodnienie SA do zabezpieczania transmisji

danych.

Faza 1 może przebiegać w normalnym trybie Main Mode lub trybie przyspieszonym Aggressive Mode. W trybie Aggressive Mode w czasie negocjowania IKE SA przesyłana jest mniejsza liczba pakietów. Faza 2 nosi nazwę Quick Mode. W domyślnej konfiguracji IKE, poprzez jeden zestawiony w fazie 1 kanał może odbywać się potem wiele negocjacji fazy 2. Zwykle więc faza 2 jest wykonywana znacznie częściej od fazy 1. Zachowanie to można zmienić włączając opcję Perfect Forward Secrecy (PFS). Opcja ta została omówiona w dalszej części.

W fazie 1 IKE urządzenia VPN generują także cztery tajne klucze - SKEYID do wyznaczania kolejnych kluczy, SKEYID_d do wyznaczania materiału krypto dla IPSec i innych SA, SKEYID_a do sprawdzania integralności i autentyczności źródła komunikatów IKE, a także SKEYID_e do szyfrowania komunikatów IKE.



Faza 1 IKE (Main Mode)

Faza 1 protokołu IKE wykonywana w trybie Main Mode polega na wymianie sześciu wiadomości (patrz rysunek). W trybie Aggressive Mode wymieniane są tylko trzy wiadomości. Tryb Main Mode stosowany jest zwykle w konfiguracjach VPN Site-Site ze stałymi adresami IP urządzeń VPN, zaś tryb Aggressive Mode w konfiguracjach VPN Client-Site z adresami IP przydzielanymi dynamicznie (np. Dial-up).

Zasada działania fazy 1 IKE

Faza 1 negocjacji IKE w trybie Main Mode przebiega w następującej kolejności: – Wiadomości 1 i 2 - mają za zadanie wynegocjowanie SA umożliwiających

zestawienie bezpiecznego kanału, poprzez który będą prowadzone dalsze negocjacje. Dodatkowo, przesyłane są Cookie zawierające adresy IP urządzeń VPN w celu przeciwdziałania możliwościom fałszowania adresów (tzw. IP Spoofing). Urządzenie VPN jako propozycje SA może przesłać wiele zestawów np. <D-H Group 2, 3DES, MD5> i <D-H Group 2, DES, SHA>. Urządzenie odpowiadające na IKE wybiera najmocniejszy z zaproponowanych zestawów SA, który jest w stanie ze swojej strony użyć.

– Wiadomości 3 i 4 - zawierają klucze publiczne Diffiego-Hellmana. Urządzenia VPN po wymienieniu pomiędzy sobą kluczy publicznych obliczają za pomocą algorytmu Diffiego-Hellmana tajny klucz sesji, który jest używany do szyfrowania dalszej komunikacji IKE. Dodatkowo, wiadomości 3 i 4 służą do wymiany wygenerowanych losowo liczb Nonce, które w fazie 2 zostaną użyte do wyznaczenia kluczy.

– Wiadomości 5 i 6 � mają za zadanie uwierzytelnienie autentyczności urządzeń zestawiających tunel VPN. Identyfikacja urządzeń VPN odbywa się za pomocą tajnych kluczy Pre-Shared Secret (ustalanych ręcznie w konfiguracji IKE urządzeń) lub certyfikatów cyfrowych. Wymiana komunikatów 5 i 6 jest szyfrowana i uwierzytelniania za pomocą algorytmów wynegocjowanych w wiadomościach 1 i 2.



Faza 1 IKE (Aggressive Mode)

Faza 1 wykonywana w trybie Aggressive Mode umożliwia zestawienie bezpiecznego kanału komunikacji IKE jednak odbywa się to tylko za pomocą trzech wiadomości. Negocjacja IKE w trybie Aggressive Mode przebiega w następującej kolejności:

– Wiadomość 1 - urządzenie inicjujące tunel VPN wysyła propozycję SA, swój klucz publiczny Diffiego-Hellmana, Nonce (liczbę losową) oraz identyfikator IKE. Jako identyfikator IKE może zostać użyty np. adres e-mail, nazwa urządzenia Fully Qualified Domain Name (FQDN), a także adres IP, ale tylko wtedy gdy nie jest dynamiczny (tzn. urządzenie VPN posiada na stałe przypisany adres IP).

– Wiadomość 2 - urządzenie odpowiadające na próbę zestawienia tunelu VPN akceptuje otrzymaną propozycję SA, uwierzytelnia wymianę informacji (tzn. przesyła kod Hash obliczony za pomocą Pre-Shared Secret), wysyła swój klucz publiczny Diffiego- Hellmana, Nonce (liczbę losową) oraz swój identyfikator IKE.

– Wiadomość 3 - urządzenie inicjujące tunel VPN uwierzytelnia wymianę informacji (tzn. przesyła kod Hash obliczony za pomocą Pre-Shared Secret) i potwierdza otrzymane dane.

Tryb Aggressive Mode w odróżnieniu od Main Mode nie zapewnia ochrony poufności

danych identyfikacyjnych urządzeń VPN (tzn. dane te są przesyłane w wiadomościach 1 i 2 w formie niezaszyfrowanej). Stwarza to zagrożenie, że intruz, który zarejestruje przebieg negocjacji IKE stosując odpowiednie operacje może wyznaczyć tajny klucz Pre-Shared Secret. W trybie Aggressive Mode do uwierzytelnienia komunikacji IKE stosowane są kody Hash obliczone za pomocą tajnego klucza Pre-Shared Secret. Kody Hash są przesyłane w formie jawnej. Istnieje realne niebezpieczeństwo (potwierdzone przez praktyczne testy), że intruz będący na drodze transmisji danych odczyta kod Hash i poddając go atakowi brutalnemu lub słownikowemu jest w stanie wyznaczyć tajny klucz Pre-Shared Secret. Gotowe narzędzia do tego celu są dostępne w Internecie (np. IKECrack, http://ikecrack.sourceforge.net). Intruz posiadając klucz Pre-Shared Secret może zestawić tunel VPN w imieniu legalnego użytkownika i uzyskać nieupoważniony dostęp do sieci wewnętrznej firmy.

Zalecane jest, aby dla konfiguracji VPN Site-Site nie stosować trybu Aggressive Mode z uwierzytelnianiem Pre-Shared Secret, a dla klientów VPN wykonywać uwierzytelnianie za pomocą certyfikatów cyfrowych lub haseł dynamicznych.



Faza 2 IKE (Quick Mode)

Faza 2 IKE ma za zadanie wyznaczyć SA do szyfrowania i uwierzytelniania danych przesyłanych w tunelu IPSec. Odbywa się to poprzez wymianę trzech wiadomości (patrz rysunek). Komunikacja jest zabezpieczona za pomocą SA wyznaczonego w fazie 1 IKE. W wiadomościach 1 i 2 urządzenia VPN ustalają odpowiednie dla siebie SA. Podobnie jak w fazie 1 urządzenie inicjujące IKE może podać wiele propozycji SA. Pole Proxy ID zawiera informacje nt. reguły polityki bezpieczeństwa odnoszącej się do zestawianego tunelu IPSec. Ustawienie Proxy ID zależy od implementacji VPN. W fazie 2 IKE może zostać wykonana druga wymiana kluczy Diffiego-Hellmana (pierwsza odbywa się w fazie 1) i obliczenie za ich pomocą nowego klucza sesji. Jest to jednak opcjonalne i zależy to od włączenia własności Perfect Forward Secrecy (PFS). Własność PFS została omówiona w dalszej części. Wiadomość 3 służy do potwierdzenia informacji otrzymanych w wiadomości 2.

Zasada działania fazy 2 IKE

W trakcie działania sieci VPN następuje odnawianie SA. Renegocjacja IKE może nastąpić po określonym czasie lub po przesłaniu poprzez tunel VPN odpowiedniej ilości danych. Czasy renegocjacji IPSec SA i IKE SA ustala się w konfiguracji urządzeń VPN. Zwykle jednak renegocjacja IPSec SA (faza 2 IKE) odbywa się dużo częściej od renegocjacji IKE SA (faza 1 IKE). Dla przykładu, faza 2 IKE może odbywać się co godzinę, zaś faza 1 raz na dobę.



3. Bezpieczeństwo sieci IPSec/IKE Uwierzytelnianie w sieci VPN

Jednym z podstawowych wymagań bezpieczeństwa sieci VPN jest zapewnienie autentyczności stron zestawiających tunele VPN. Ma to na celu niedopuszczenie do sytuacji podszycia się intruza pod legalne urządzenie lub klienta VPN. Uwierzytelnianie w sieci VPN opartej na protokołach IPSec/IKE jest realizowane w fazie 1 IKE i może odbywać się za pomocą:

– tajnych kluczy Pre-Shared Secret ustalanych (ręcznie) przez administratorów; klucze Pre-Shared Secret są formą haseł statycznych,

– certyfikatów cyfrowych X.509 użytkowników i urządzeń VPN, wydawanych przez odpowiedni (zaufany) urząd certyfikacji; zagadnienia uwierzytelniania za pomocą certyfikatów cyfrowych oraz związane z tym przedsięwzięcia (m.in. wystawianie/unieważnianie certyfikatów, listy certyfikatów unieważnionych) zostały przedstawione w dalszej części.

Oprócz w/w metod istnieje także możliwość zastosowania dla klientów VPN metody

Extended Authentication (XAUTH). Po zakończeniu fazy 1 IKE odbywa się uwierzytelnienie użytkownika za pomocą identyfikatora i hasła. Hasła dostępu mogą być w tym przypadku statyczne lub dynamiczne. Do uwierzytelniania XAUTH wykorzystane są często zewnętrzne systemy (np. RADIUS, LDAP). Perfect Forward Secrecy

Własność Perfect Forward Secrecy (PFS) polega na tym, że klucze krypto wyznaczone w fazie 2 IKE w określonym czasie są niezależne od kluczy wyznaczonych wcześniej. Bez PFS klucze fazy 2 są wyznaczane z klucza SKEYID_d, który z kolei ustalany jest w fazie 1 IKE. Tak więc z tego samego klucza SKEYID_d wyznaczanych jest wiele kluczy w czasie kolejnych negocjacji fazy 2 IKE (faza 2 IKE jest wykonywana częściej od fazy 1). Takie działanie IKE jest dobre z punktu widzenia wydajności, jednak w razie uzyskania przez intruza dostępu do klucza SKEYID_d wszystkie klucze szyfrowania IPSec zostaną ujawnione. PFS wymusza wykonywanie w czasie fazy 2 IKE wymiany kluczy Diffiego-Hellmana i obliczanie za każdym razem nowego klucza sesji. Włączenie PFS podnosi poziom bezpieczeństwa VPN jednak powoduje przedłużenie czasu negocjacji IKE. Replay Protection

Atak powtórzeniowy (ang. replay attack) polega na rejestrowaniu pakietów IPSec/IKE i wykorzystywaniu ich potem do "zalewania" urządzeń VPN w celu zablokowania lub zakłócenia ich pracy (DoS), bądź wysyłania pakietów VPN w celu uzyskania nieupoważnionego dostępu do sieci prywatnej. Ochrona Replay Protection polega na tym, że urządzenie VPN sprawdza każdy pakiet IPSec, czy został odebrany w przeszłości. Pakiet zostaje odrzucony, jeżeli wybiega poza określony zakres numerów. Kontroli podlegają przy tym numery sekwencyjne nagłówków ESP.



4. Implementacja sieci VPN Site-Site Zasady implementacji VPN Site-Site zostały przedstawione na przykładowej sieci lab

(patrz rysunek), gdzie do budowy tunelu VPN zastosowane zostały systemy zabezpieczeń Check Point VPN-1 NG oraz NetScreen . Systemy zabezpieczeń Check Point i NetScreen są obecnie jednymi z najczęściej stosowanych rozwiązań VPN. Check Point to rozwiązanie programowe, w którym dla operacji VPN możliwe jest zastosowanie wspomagania sprzętowego. NetScreen dostarczany jest jako urządzenia typu Appliance, w których funkcjonowanie zabezpieczeń VPN jest realizowane sprzętowo za pomocą układów ASIC. Dzięki temu osiągają bardzo wysoką wydajności (np. model 5400 posiada przepływność VPN z algorytmem 3DES rzędu 6 Gb/s). W niniejszym dokumencie znajdują się dwie procedury konfiguracji NetScreen. Urządzenia te posiadają bowiem możliwości konfiguracji VPN na dwa sposoby:

– Policy-based VPN � tunele VPN są obiektami w polityce bezpieczeństwa (tzn. dla określonej komunikacji ustawiona zostaje akcja Tunnel),

– Routing-based VPN � tunele VPN są traktowane jak elementy sieci służące do przesyłania danych w sposób bezpieczny (tzn. ustawienia rutingu kierują określony ruch sieciowy na interfejsy typu Tunnel).

Konfiguracja w trybie �Policy-based VPN�

Przyjęto następujące założenia do konfiguracji zabezpieczeń NetScreen i Check Point: 1. Komunikacja pomiędzy sieciami odbywa się bez translacji NAT. 2. Interfejsy urządzenia NetScreen są skonfigurowane w trybie rutingu. 3. Parametry tunelu VPN: Pre-Shared Secret, Main Mode IKE, DES/SHA-1 (faza 1

IKE), DES/MD5 (faza 2 IKE), grupa 2 D-H, brak PFS, ochrona Replay Protection, brak NAT Traversal, brak podtrzymywania aktywności tunelu, 28000 sekund (renegocjacja IKE SA) oraz 3600 sekund (renegocjacja IPSec SA).

Proces konfiguracji "Policy-based VPN" odbywa się w następującej kolejności:

– Definiujemy i konfigurujemy zdalne urządzenie VPN. – Definiujemy parametry fazy 1 IKE. – Definiujemy parametry fazy 2 IKE. – Tworzymy politykę VPN.



Konfiguracja urządzenia NetScreen może odbywać się z linii komend (CLI), konsoli WebGUI oraz centralnego systemu zarządzania NetScreen-Global PRO. W dalszej części opracowania wykorzystana została konsola WebGUI. 1. Definiujemy i konfigurujemy zdalne urządzenie VPN (VPNs > AutoKey IKE > New)

2. W ustawieniach Advanced wybieramy propozycje IPSec SA (faza 2 IKE)



3. W ustawieniach Advanced włączamy monitorowanie sesji VPN (może być przydatne przy diagnozowaniu ewentualnych problemów)

4. Ustalamy propozycje IKE SA oraz tryb IKE (VPNs > AutoKey Advanced > Gateway > Edit > Advanced)



5. Tworzymy politykę VPN (Policies > From Trust To Untrust > New)

6. W ustawieniach Advanced włączamy logowanie ruchu VPN



7. Dodajemy polityki blokujące ruch za wyjątkiem VPN z rejestrowaniem zablokowanych połączeń



Konfiguracja VPN w Check Point NG przebiega w następującej kolejności: 1. Definiujemy lokalne urządzenie VPN (Manage > Network Objects > New > Check Point > Gateway) - ustalamy adres IP i moduły zabezpieczeń

- konfigurujemy interfejsy sieciowe i domenę VPN



2. Definiujemy zdalną domenę VPN (Manage > Network Objects >New > Network)

3. Definiujemy zdalne urządzenie VPN (Manage > Network Objects >New > Interoperable Device) - ustalamy adres IP

- domenę VPN



4. Definiujemy kanał VPN (VPN Manager > MyIntranet > Edit) - ustalamy urządzenia VPN zestawiające tunel

- ustalamy algorytmy krypto dla fazy 1 i 2 IKE



- dopasowujemy pozostałe parametry IPSec/IKE do ustawień zdalnego urządzenia VPN



- wprowadzamy klucz Pre-Shared Secret (klucz ma taką samą wartość jak na zdalnym urządzeniu VPN)

5. Definiujemy reguły polityki bezpieczeństwa dla VPN.



Konfiguracja w trybie �Route-based VPN� (urządzenia NetScreen)

�Route-based VPN� można traktować jak �rurę� pomiędzy dwoma odległymi urządzeniami w sieci. Jej początkiem jest wirtualny interfejs tunelowy (ang. tunnel interface). VPN jest wykonywany w momencie skierowania rutingu do odległej sieci poprzez interfejs tunelowy. Nie jest wymagane definiowanie polityki dla VPN, jeżeli interfejs tunelowy i komputery uczestniczące w transmisji danych należą do tej samej strefy bezpieczeństwa (np. stacje użytkowników i interfejs tunelowy należą do strefy Trust).

Proces konfiguracji �Route-based VPN� odbywa się w następującej kolejności: – Tworzymy interfejs wirtualny typu �Tunnel� i przypisujemy go do wybranej strefy

bezpieczeństwa. – Definiujemy parametry fazy 1 IKE. – Definiujemy parametry fazy 2 IKE. – Definiujemy ruting IP do odległej sieci poprzez interfejs tunelowy.

1. Tworzymy interfejs wirtualny typu �Tunnel� i przypisujemy go do wybranej strefy bezpieczeństwa (Network > Interfaces > New (Tunnel IF)). Interfejsy tunelowe zwykle należą do stref wewnętrznych np. Trust. Zwykle też interfejs tunelowy nie posiada adresu IP.



2. Definiujemy parametry fazy 1 IKE (VPNs > AutoKey Advanced > Gateway)



3. Definiujemy parametry fazy 2 IKE (VPNs > AutoKey IKE > Edit)

Jeżeli urządzenie po drugiej stronie tunelu VPN jest skonfigurowane w trybie �Policy_based VPN� należy dodatkowo skonfigurować Proxy-ID.



4. Definiujemy ruting IP do odległej sieci poprzez interfejs tunelowy (Network > Routing > Routing Table)



4. Wykorzystanie certyfikatów cyfrowych do uwierzytelniania sieci VPN

Wysokie bezpieczeństwo sieci VPN w zakresie autentyczności urządzeń zestawiających tunele IPSec można osiągnąć za pomocą certyfikatów cyfrowych. Praktycznie eliminują one zagrożenie podszywania się pod elementy sieci VPN, co jest możliwe przy stosowaniu kluczy Pre-Shared Secret. Urządzenia VPN (oraz klienci VPN na stacjach użytkowników), którzy zamierzają wykorzystywać certyfikaty najpierw muszą zostać zarejestrowani w urzędzie certyfikacji. Następnie urządzenie występuje do urzędu o certyfikat. Zwykle wcześniej urządzenie VPN generuje swoje klucze krypto, a następnie przekazuje ich część publiczną razem z wnioskiem o certyfikat. Klucz publiczny jest, bowiem integralnym elementem certyfikatu. Proces uwierzytelniania urządzeń VPN za pomocą certyfikatów cyfrowych w trakcie fazy 1 IKE w trybie Main Mode pokazuje rysunek. Wykorzystanie certyfikatów w trybie Aggressive Mode jest analogiczne.

Uwierzytelnianie urządzeń VPN za pomocą certyfikatów cyfrowych Certyfikaty cyfrowe nie są wydawane bezterminowo. W każdym certyfikacie X.509

znajduje się informacja kiedy został wydany i do kiedy jest ważny. Certyfikat, który utracił swoją ważność nie może być wykorzystywany. Także urząd certyfikacji może unieważnić wydany już certyfikat. Informacje na temat unieważnionych certyfikatów są publikowane przez urząd certyfikacji na listach CRL. CRL dostarczany jest w formie pliku zawierającego listę unieważnionych certyfikatów, ich numery seryjne oraz daty unieważnienia. Plik CRL zwykle zawiera także nazwę urzędu certyfikacji wydającego CRL, datę wydania listy oraz datę następnej aktualizacji.



Urządzenia IPSec, które będą wykorzystywać certyfikaty cyfrowe do potwierdzania swojej autentyczności w trakcie zestawiania tuneli VPN (faza 1 IKE) powinny posiadać zaimplementowane odpowiednie mechanizmy PKI:

– Generowanie pary kluczy prywatny-publiczny RSA oraz tworzenie wniosku o certyfikat zgodnie ze standardem PKCS#10. Wniosek o certyfikat zawierający dane identyfikacyjne urządzenia VPN oraz klucz publiczny RSA w formie pliku jest przekazywany do urzędu certyfikacji i stanowi podstawę do wystawienia certyfikatu.

– Odczytywanie certyfikatu X.509 oraz listy unieważnionych certyfikatów CRL z otrzymanego z urzędu certyfikacji pakietu (pliku) zgodnie ze standardem PKCS#7. Urządzenie VPN może także wystąpić o wydanie i otrzymać certyfikat za pomocą dedykowanego protokołu Simple Certificate Enrollment Protocol (SCEP).

– Pobieranie aktualnych list CRL (np. poprzez LDAP, HTTP). Urządzenie VPN może także sprawdzać ważność certyfikatów za pomocą dedykowanego protokołu Online Certificate Status Protocol (OCSP).

Zasady współdziałania zabezpieczeń VPN i PKI Typowy proces pozyskiwania certyfikatu przez urządzenie VPN przebiega w

następującej kolejności (patrz rysunek): 1. Urządzenie VPN generuje parę kluczy prywatny-publiczny RSA. 2. Urządzenie VPN tworzy plik PKCS10 zawierający jego dane identyfikacyjne oraz

klucz publiczny RSA, a następnie przekazuje go do urzędu certyfikacji. 3. Urząd certyfikacji weryfikuje plik PKCS10 i wystawia certyfikat cyfrowy (tzn. podpisuje

plik swoim kluczem prywatnym RSA). 4. Urządzenie VPN pobiera z urzędu certyfikacji wystawiony dla siebie certyfikat

cyfrowy, a także certyfikat urzędu certyfikacji i aktualną listę CRL.



Proces tworzenia wniosku, wydawania i instalowania certyfikatów cyfrowych zostanie przedstawiony na przykładzie konfiguracji urządzenia NetScreen. W przykładzie wykorzystano urząd certyfikacji Microsoft CA . W pierwszej kolejności należy zweryfikować poprawność ustawiona daty i czasu systemowego oraz sprawdzić nazwę urządzenia i ustawienie domeny DNS. Następnie należy wypełnić wniosek o wydanie certyfikatu i wygenerować klucze RSA.

Wniosek o wydanie certyfikatu zapisujemy do pliku (dokument PKCS#10) lub przesłamy na wybrane konto e-mail. Wniosek może zostać także przekazany bezpośrednio do urzędu certyfikacji za pomocą protokołu SCEP.



Z urzędu certyfikacji należy pobrać jego certyfikat cyfrowy oraz aktualną listę CRL. Certyfikat cyfrowy zawiera klucz publiczny urzędu certyfikacji, który będzie wykorzystywany przez urządzenie VPN do weryfikacji autentyczności certyfikatów innych urządzeń i klientów VPN. Zaufanie do urzędu certyfikacji i potwierdzona autentyczność wydawanych przez niego certyfikatów cyfrowych będzie stanowić podstawę bezpieczeństwa sieci VPN.

Utworzony wcześniej na urządzeniu VPN wniosek o wydanie certyfikatu (dokument PKCS#10) należy przesłać do urzędu certyfikacji. Na jego podstawie administrator urzędu certyfikacji dokona wygenerowania certyfikatu.



Po otrzymaniu potwierdzenia od administratora urzędu certyfikacji można skopiować certyfikat cyfrowy wystawiony dla urządzenia VPN.

Na urządzeniu VPN instalujemy certyfikat urzędu certyfikacji, listę CRL oraz certyfikat

wydany dla tego urządzenia.

Ostatnią czynnością w konfiguracji jest ustawienie parametrów fazy 1 IKE tak, aby uwierzytelnianie odbywało się nie za pomocą klucza Pre-Shared Secret lecz z użyciem certyfikatów cyfrowych (RSA).



6. Implementacja sieci VPN Client-Site

Ochrona informacji przesyłanych pomiędzy siecią korporacyjną i odległymi komputerami użytkowników (mobilnych, tele-pracowników) odbywa się za pomocą sieci VPN typu Client-Site (patrz rysunek). Po stronie komputera użytkownika wymagane jest wtedy uruchomienie oraz odpowiednie skonfigurowanie klienta VPN tak, aby połączenia do/z sieci firmowej były zabezpieczone kryptograficznie (m.in. szyfrowanie, uwierzytelnianie danych). W zakresie konfiguracji klientów VPN występują dwa podejścia � konfiguracja lokalna oraz konfiguracja scentralizowana, gdzie klient VPN pobiera swoje ustawienia z centralnego systemu zarządzania. Konfiguracja lokalna zwykle umożliwia wykonanie eksportu wprowadzonych ustawień i ich użycie na komputerach innych użytkowników VPN.

Koncepcja sieci VPN typu Client-Site

Z punktu widzenia bezpieczeństwa systemu informatycznego firmy zastosowanie na odległej stacji użytkownika tylko klienta VPN nie jest wystarczające. Komputer użytkownika zlokalizowany poza siecią firmy narażony jest bowiem na liczne niebezpieczeństwa (m.in. wirusy/robaki, hakerzy), które poprzez tunele VPN mogą zagrażać zasobom sieci wewnętrznej. Wymagane jest w tym przypadku zastosowanie kompletnego zastawu zabezpieczeń zapewniających następujące środki bezpieczeństwa:

– ochrona kryptograficzna komunikacji sieciowej (klient VPN), – kontrola komunikacji sieciowej do/z komputera (Personal Firewall/IDS), – wiarygodne uwierzytelnianie użytkowników (hasła dynamiczne i tokeny, certyfikaty

i karty Smart Card), – kontrola zawartości (wykrywanie i eliminowanie wirusów, robaków, koni trojańskich

i innych groźnych aplikacji), – ochrona dostępu do komputera i zasobów dyskowych (szyfrowanie plików,

zabezpieczenia zasobów dyskowych na wypadek kradzieży komputera).



Konfiguracja klientów i koncentratora VPN

Obecna wersja standardu IKE (IKEv1) posiada wiele brakujących funkcji i własności, które uzupełniane są przez twórców technologii VPN we własnym zakresie (m.in. wiarygodne uwierzytelnianie użytkowników VPN, scentralizowane instalowanie konfiguracji zdalnych klientów VPN i nadawanie im adresów IP, wykrywanie nieaktywności tuneli VPN i odnawianie kluczy, uniezależnienie funkcjonowania VPN od wpływu translacji adresów NAT). Tworzenie własnych, niestandardowych uzupełnień VPN powoduje problemy niekompatybilności rozwiązań pochodzących od różnych dostawców. Dlatego też do implementacji sieci VPN typu Client-Site uzasadnione jest zastosowanie urządzeń i klientów VPN jednego producenta. Konfiguracja klienta VPN odbywa się w sposób analogiczny jak urządzenia VPN (m.in. ustawienie parametrów IPSec i IKE). Zwykle jest ona jednak uzupełniona o mechanizmy wiarygodnego uwierzytelniania tożsamości zdalnych użytkowników oraz zabezpieczenia Personal Firewall.

Procedura konfiguracji sieci VPN typu Client-Site zostanie przedstawiona na

praktycznym przykładzie rozwiązania Check Point VPN-1. W systemie zabezpieczeń Check Point VPN-1 całość konfiguracji klienta VPN i Personal Firewall odbywa się na centralnej stacji zarządzającej zabezpieczeń. W pierwszej kolejności należy zdefiniować użytkowników VPN i ustalić dla nich metody uwierzytelniania oraz algorytmy kryptograficzne dla IPSec SA (faza 2 IKE). Parametry fazy 1 IKE ustalane są na drodze negocjacji (tzn. wybierane są najmocniejsze algorytmy wspierane przez klienta i koncentrator VPN). Baza użytkowników może znajdować się lokalnie na urządzeniu VPN, bądź też na zewnętrznym serwerze (m.in. LDAP, RADIUS). Użytkowników VPN należy dodać do określonej grupy, której zostaną później przyznane uprawnienia i ustalona polityka ochrony Personal Firewall.



Grupę użytkowników VPN oraz urządzenie Check Point VPN-1 pełniące rolę koncentratora VPN należy wprowadzić w konfiguracji Remote Access Community.

Uprawnienia użytkowników uzyskujących zdalny dostęp do sieci firmy poprzez tunele

VPN ustalane są w polityce bezpieczeństwa koncentratora VPN. W większości systemów zabezpieczeń, w tym także w Check Point VPN-1 moduł VPN jest dostępny razem z modułem Firewall.

Komputery zdalnych użytkowników VPN stanowią istotne źródło zagrożenia dla sieci firmy. Znajdują się one bowiem w niechronionej strefie zewnętrznej, gdzie potencjalnie mogą zostać przejęte przez osoby nieupoważnione (np. hakerów). Posiadając dostęp do komputera z klientem VPN intruz może w prosty sposób przedostać się do sieci wewnętrznej firmy. Zwykle ze strony operatora Internetu nie są zapewniane w tym zakresie żadne środki bezpieczeństwa. Zalecane jest uruchomienie na komputerach zdalnych użytkowników osobistej zapory (Personal Firewall). W typowej konfiguracji odpowiada ona za blokowanie wszystkich połączeń do komputera inicjowanych z sieci zewnętrznych.



W praktyce funkcjonowanie sieci VPN typu Client-Site narażone jest na liczne zakłócenia, wynikające głównie ze zmiennego i nieprzewidywalnego środowiska pracy zdalnych użytkowników. W typowej implementacji zdalnego dostępu klient VPN nawiązuje połączenie z siecią firmy używając adresu IP, który został nadany mu przez operatora Internetu. Często zdarza się, że adres ten jest adresem prywatnym i dopiero urządzenie brzegowe operatora Internetu wykonuje dynamiczną translację adresów NAT. W takiej sytuacji, kiedy adresy IP klientów VPN są nadawane dynamicznie przez operatorów Internetu istnieją bardzo ograniczone możliwości wprowadzenia wewnątrz sieci firmy kontroli dostępu do zasobów. Jeszcze większy problem z punktu widzenia bezpieczeństwa stanowi zabezpieczenie i odpowiednie kontrolowanie użytkowników VPN zlokalizowanych poza siecią firmy. Występują także liczne problemy z działaniem VPN. Podstawowy z nich wynika z faktu, że sieć VPN oparta na standardzie IPSec nie działa poprawnie, jeżeli na jej drodze wykonywana jest dynamiczna translacja adresów NAT. Następny, często występujący problem to możliwość uzyskania przez klienta VPN adresu IP z takiej samej klasy jak adresy wykorzystywane w sieci firmy. Połączenie VPN nie będzie wtedy funkcjonować poprawnie.

Producenci technologii VPN oferują zwykle własne rozwiązania w/w problemów. Dla przykładu, klient VPN dostarczany przez Check Point oprócz zwykłego trybu pracy może funkcjonować w sposób odpowiadający specyficznym wymaganiom, m.in.:

– Office Mode - koncentrator VPN przydzielna adresy IP dla zdalnych klientów VPN. Tryb Office Mode ułatwia klientom VPN dostęp do usług sieci wewnętrznych i umożliwia szczegółowe kontrolowanie wykorzystywania przez nich zasobów sieci. Przydział adresów odbywa się w czasie nawiązywania połączenia VPN. Adresy są nadawane z ustalonej puli lub wewnętrznego serwera DHCP. Wraz z adresem IP zdalny komputer użytkownika VPN może otrzymać informacje nt. wewnętrznych serwerów DNS i WINS. Technicznie jest to realizowane poprzez wirtulany interfejs utworzony na komputerze użytkownika VPN. Pakiety IPSec wysyłane są przez klienta VPN z rzeczywistym adresem IP, aby mogły zostać poprawnie przesłane poprzez Internet. Wewnątrz pakietów IPSec znajdują się adresy nadawane przez koncentrator VPN, które po odszyfrowaniu pakietów są używane w sieci firmy.

– Hub Mode - wszystkie połączenia sieciowe z komputera użytkownika VPN przechodzą przez centralny koncentrator VPN. Tryb Hub Mode zapewnia szczegółową inspekcję komunikacji sieciowej prowadzonej przez zdalnych użytkowników z Internetem (m.in. filtracja URL, kontrola antywirusowa). Tryb ten umożliwia dokładne rozliczanie użytkowników VPN z wykorzystywania usług Internetu i zabezpieczenie ich przed zagrożeniami z tym związanymi. Użytkownicy pracujacy w trybie VPN Hub Mode mogą pomiędzy sobą nawiązywać bezpośrednią komunikację (np. VoIP, Microsoft Netmeeting).

– Visitor Mode - komunikacja VPN jest w całości tunelowana w wybranym protokole TCP. Tryb Visitor Mode umożliwia poprawne funkcjonowanie zabezpieczeń VPN w sieciach, gdzie dozwolone są tylko standardowe protokoły (np. HTTP, HTTPS), a na drodze VPN występują urządzania wykonujące dynamiczną translację adresów NAT. Z taką sytuacją można spotkać się często w hotelach lub kawiarenkach internetowych. W trybie Visitor Mode pakiety IKE i IPSec ESP, które domyślnie wykorzystują porty UDP-500 i IP-50 zostają przez klienta VPN wysłane z użyciem standardowych portów (np. TCP-80 lub TCP-443).



Uwierzytelnianie użytkowników VPN

Uwierzytelnianie użytkowników VPN może być realizowane za pomocą różnych metod. Najczęściej odbywa się to z wykorzystaniem kluczy Pre-Shared Secret, certyfikatów cyfrowych X.509 oraz haseł dynamicznych. Certyfikaty cyfrowe oferują w tym zakresie wysoki poziom bezpieczeństwa jednak tylko wtedy, gdy są składowane na kartach inteligentnych Smart Card. Klucze kryptograficzne i certyfikaty nie powinny być składowane w plikach na dyskach komputerów, ponieważ istnieje realne zagrożenie, że odpowiednio spreparowany wirus, czy robak może odczytać profil kryptograficzny użytkownika razem z hasłem dostępu i przesłać całość do dalszego, nieupoważnionego wykorzystania.

Klucze prywatne użytkowników VPN nie powinny opuszczać kart Smart Card (tzn. nie powinno być możliwości ich nieupoważnionego odczytania przez oprogramowanie komputera). Karta Smart Card oprócz bezpiecznego składowania materiału kryptograficznego VPN powinna realizować także inne, newralgiczne operacje (wykonywane wewnątrz karty):

– generowanie kluczy kryptograficznych, – wykonywanie podpisów cyfrowych, – szyfrowanie kluczy sesji (tzn. kluczy używanych do szyfrowania danych).

Tokeny i karty Smart Card (rozwiązania ActivCard)

Karta inteligentna Smart Card jest urządzeniem elektronicznym zbudowanym na wzór komputera (m.in. posiada procesor, pamięć i system operacyjny). Wyposażona w odpowiednie oprogramowanie może użytkownikowi służyć do wielu zastosowań (np. w systemie kontroli dostępu do pomieszczeń i stref bezpieczeństwa). Karty Smart Card produkowane są zwykle w formie kart chip-owych lub tokenów USB. Rysunek przedstawia przykładowe rozwiązania tokenów i kart Smart Card oferowanych przez ActivCard.

Koncepcja haseł dynamicznych polega na tym, że hasło użytkownika VPN jest za każdym razem inne. Eliminuje się w ten sposób zagrożenie, że nieupoważniona osoba podszyje się pod legalnego użytkownika (np. w razie odgadnięcia hasła). Hasła dynamiczne dla użytkowników generowane są w specjalnych urządzeniach lub aplikacjach (tzn. tokenach sprzętowych lub programowych). Tokeny sprzętowe to najczęściej urządzenia o wielkości karty kredytowej wyposażone w klawiaturę i wyświetlacz. Użycie tokenu zwykle wymaga wprowadzenia do urządzenia kodu dostępu PIN (Personal Identification Number).



Token, aby mógł generować dla użytkownika unikalne hasła posiada zaprogramowany tajny klucz (tzw. seed). Klucz ten może być zaprogramowany przez producenta, bądź przez właściciela urządzeń (np. oficera bezpieczeństwa). Metoda uwierzytelniania użytkowników oparta na sprzętowych tokenach określana jest jako Two-Factor Authentication, ponieważ bezpieczeństwo i wiarygodność procesu identyfikacji użytkownika opiera się na dwóch składnikach: urządzeniu generującym hasła (tokenie) oraz tajnym kodzie dostępu do urządzania (PIN). Tokeny umożliwiają generowanie haseł w dwóch trybach:

– synchronicznym - token użytkownika i serwer uwierzytelniania są zsynchronizowane ze sobą i dzięki temu serwer wie jakie hasło powinien wygenerować token,

– wyzwanie-odpowiedź (ang. challenge-response) - serwer przesyła do tokenu kod wejściowy (tzn. wyzwanie), na podstawie którego token oblicza hasło (tzn. odpowiedź).

Zasady uwierzytelniania użytkowników VPN w obu trybach zostaną przedstawione na

przykładzie systemu uwierzytelniania ActivCard ActivPack. Generowanie haseł w systemie ActivCard może być realizowane za pomocą tokenów sprzętowych (�kalkulatorek� lub �breloczek�), kart Smart Card, tokenów USB oraz tokenów programowych. Urządzenia VPN korzystają z usług serwera ActivPack za pomocą protokołów RADIUS lub TACACS+. Komunikacja sieciowa z serwerem jest zabezpieczona kryptograficznie.

Uwierzytelnianie użytkowników w trybie synchronicznym

Hasło w tokenie ActivCard w trybie synchronicznym generowanie jest na podstawie

tajnego klucza (seed), licznika zdarzeń oraz czasu systemowego. Warunkiem koniecznym do przeprowadzenia kontroli użytkownika na serwerze ActivPack jest synchronizacja tokenu użytkownika z serwerem. Serwer powinien wygenerować dokładnie takie samo hasło jak token użytkownika. Aby tego dokonać serwer ActivPack musi posiadać zapisany w swojej bazie klucz tokenu oraz znać jego aktualny stan licznika zdarzeń i czasu systemowego.



Technicznie, uwierzytelnianie użytkownika VPN w trybie synchronicznym w systemie uwierzytelniania ActivCard przebiega w następującej kolejności (patrz rysunek):

1. Użytkownik poprzez koncentrator VPN zamierza uzyskać dostęp do zasobów systemu informatycznego.

2. Urządzenie VPN wysyła do użytkownika zapytanie o uwierzytelnienie (tzn. podanie swojego identyfikatora i hasła).

3. Użytkownik generuje za pomocą tokenu hasło. Hasło generowane jest na podstawie zaprogramowanego w tokenie unikalnego klucza oraz aktualnego stanu tokenu (czasu systemowego i licznika zdarzeń).

4. Użytkownik w komunikacji z urządzeniem VPN podaje swój identyfikator oraz odczytane z tokenu hasło.

5. Urządzenie VPN przekazuje dane od użytkownika (identyfikator i hasło) do serwera ActivPack.

6. Serwer ActivPack na podstawie klucza (seed), czasu systemowego oraz licznika zdarzeń tokenu (zapisanych w bazie serwera) generuje hasło i porównuje je z kodem otrzymanym od użytkownika.

7. Serwer ActivPack informuje urządzenie VPN o wyniku uwierzytelnienia użytkownika. 8. Urządzenie VPN sprawdza, czy użytkownik ma prawo dostępu do żądanego zasobu

systemu informatycznego (tzn. dokonuje autoryzacji użytkownika). 9. Po pozytywnej autoryzacji użytkownik VPN uzyskuje dostęp do zasobów systemu

informatycznego.

Uwierzytelnianie użytkowników w trybie wyzwanie-odpowiedź

W systemie uwierzytelniania ActivPack proces generowania haseł w trybie wyzwanie-odpowiedź odbywa się zgodnie ze standardem ANSI X9.9. Proces ten jest nieznacznie bardziej złożony od trybu synchronicznego, ponieważ wymaga wpisania kodu do tokenu. Zapewnia on jednak, że nawet w razie niewłaściwej obsługi token nie zostanie rozsynchronizowany.



Technicznie, uwierzytelnianie użytkownika w trybie wyzwanie-odpowiedź przebiega w następującej kolejności (patrz rysunek):

1. Użytkownik poprzez koncentrator VPN zamierza uzyskać dostęp do zasobów systemu informatycznego.

2. Urządzenie VPN wysyła do użytkownika zapytanie o uwierzytelnienie (tzn. podanie swojego identyfikatora i hasła).

3. Użytkownik w komunikacji z urządzeniem VPN podaje swój identyfikator oraz ustala tryb uwierzytelniania na wyzwanie-odpowiedz (tzn. zamiast hasła wpisuje umowny znak np. literę �w�).

4. Urządzenie VPN informuje serwer ActivPack o wyborze przez użytkownika trybu wyzwanie-odpowiedź.

5. Serwer ActivPack generuje dla użytkownika kod wejściowy (wyzwanie). 6. Serwer ActivPack przekazuje wygenerowany kod do urządzenia VPN. 7. Urządzenie VPN wysyła do użytkownika kod otrzymany od serwera ActivPack. 8. Użytkownik wpisuje kod do tokenu. 9. Token na podstawie kodu (wyzwanie) i tajnego klucza (zaprogramowanego w

tokenie) generuje hasło dynamiczne (odpowiedź). 10. Użytkownik przekazuje odczytany z tokenu kod (hasło) do urządzenia VPN. 11. Urządzenie VPN przekazuje dane od użytkownika (hasło) do serwera ActivPack. 12. Serwer na podstawie tego samego kodu (wyzwanie) i klucza tokenu (zapisanego w

bazie serwera) oblicza kod odpowiedzi i porównuje go z kodem otrzymanym od użytkownika.

13. Serwer ActivPack informuje urządzenie VPN o wyniku uwierzytelnienia użytkownika. 14. Urządzenie VPN sprawdza, czy użytkownik ma prawo dostępu do żądanego zasobu

systemu informatycznego (tzn. dokonuje autoryzacji użytkownika) 15. Po pozytywnej autoryzacji użytkownik VPN uzyskuje dostęp do zasobów systemu

informatycznego.

Wiarygodna kontrola autentyczności użytkowników VPN oprócz certyfikatów cyfrowych i haseł dynamicznych może odbywać się także za pomocą technik biometrycznych. Przykładem takiego rozwiązanie może być skaner odcisku palca, wykonujący analizę linii papilarnych. W sieciach VPN tego typu systemy uwierzytelniania są jednak rzadko stosowane z uwagi na konieczność posiadania przez użytkowników dodatkowych urządzeń oraz trudności w integracji z urządzeniami VPN.

Oprócz metod wiarygodnego uwierzytelniania użytkowników, producenci technologii VPN

dostarczają szereg innych rozszerzeń klientów VPN, mających na celu podniesienie ich funkcjonalności i bezpieczeństwa. Dla przykładu, Check Point zaimplementował mechanizm Security Configuration Verification (SCV). Umożliwia on dokonanie szczegółowej oceny stanu bezpieczeństwa zdalnego komputera przed dopuszczeniem go do sieci firmy poprzez VPN. Sprawdzeniu SCV podlega zwykle zainstalowana polityka Personal Firewall oraz oprogramowanie antywirusowe i aktualność jego bazy wirusów.



7. Weryfikacja poprawności funkcjonowania VPN

W sieciach VPN funkcjonujących na bazie sieci rozległych i Internetu może potencjalnie wystąpić wiele problemów, szczególnie jeżeli urządzenia VPN zarządzanie są przez różne ośrodki. Do typowych problemów funkcjonowania sieci VPN opartych na protokołach IPSec i IKE należą:

– niepoprawna konfiguracja urządzeń VPN (np. niezgodność algorytmów kryptograficznych),

– blokowanie na urządzeniach sieciowych na drodze VPN protokołów IPSec lub IKE, – translacja adresów NAT na drodze VPN, – fragmentacja datagramów IP, – niewłaściwe ustawienia rutingu, – pokrywające się adresacje IP sieci i dynamiczne adresy IP urządzeń VPN, – niska przepustowość łączy i przeciążenia sieci, – niska wydajność urządzeń VPN, – nieprawidłowe działanie protokołów IPSec i IKE w klastrach urządzeń VPN, – nieprawidłowe współdziałanie urządzeń VPN ze środowiskiem PKI, – nieprawidłowe współdziałanie urządzeń VPN z systemem uwierzytelniania

użytkowników (np. niedostępność serwera RADIUS, rozsynchronizowanie tokenów), – błędy urządzeń VPN. W razie wystąpienia problemów z funkcjonowaniem sieci VPN w pierwszej kolejności

należy ustalić co jest ich rzeczywistym źródłem. Nie zawsze bowiem problem wynika z zabezpieczeń. Sposób postępowania zależy także od tego, czy sieć VPN funkcjonowania poprawnie i w pewnym momencie pojawiły się problemy, czy też jest to problem w nowej instalacji. W pierwszym przypadku dobrą praktyką jest ustalenie jakie zmiany zostały wprowadzone w ostatnim czasie. Dla nowej instalacji VPN należy dokładnie zweryfikować konfigurację oraz przeanalizować informacje o znanych problemach/błędach wybranej do wdrożenia technologii VPN. Do ustalenia przyczyny niepoprawnego działania zabezpieczeń przydatne są także narzędzia diagnostyczne dostarczane przez producentów technologii VPN.

Problem funkcjonowania VPN zauważany jest zwykle poprzez niewłaściwe działanie aplikacji dostępnej poprzez VPN. W praktyce często okazuje się, że źródłem problemu nie są zabezpieczenia VPN. Typowa procedura ustalania źródła problemu VPN przebiega w następującej kolejności:

– analiza stanu aplikacji (klient, serwer), – weryfikacja komunikacji sieciowej (np. ICMP Ping do określonego urządzenia w sieci,

Telnet na otwarty port TCP innego urządzenia w sieci) – przegląd i analiza logów urządzeń VPN i aplikacji, – restart urządzeń VPN, – weryfikacja działania aplikacji z pominięciem zabezpieczeń (w razie takiej

możliwości), – analiza komunikacji sieciowej (sniffing).



Weryfikację poprawności funkcjonowania VPN wykonujemy w pierwszej kolejności na urządzeniu, które odpowiada na sesję IKE. Diagnostyka VPN na urządzeniu inicjującym sesje IKE dostarcza zwykle mniej informacji. Poniżej przedstawiono proces weryfikacji VPN na urządzeniu NetScreen z przykładowej konfiguracji (patrz rozdział 4). 1. Sprawdzamy poprawność wykonania fazy 1 IKE get ike cookie

Active: 1, Dead: 0, Total 1

102f/3, 192.168.10.156->192.168.10.71: PRESHR/grp2/DES/SHA, xchg(2) usr(d-1/u-1)

resent-tmr 0 lifetime 28800 lt-recv 28800 nxt_rekey 27273 cert-expire 0

initiator 0, in-out 0, err cnt 0, send dir 1, cond 0

nat-traversal map not available

ike heartbeat: disabled

ike heartbeat last rcv time: 0

ike heartbeat last snd time: 0

XAUTH status: 0 W przypadku gdy IKE Cookie nie zostanie wyświetlone otrzymujemy informację, że faza

1 IKE nie została zakończona pomyślnie. Z wyświetlonego IKE Cookie dowiadujemy się zaś jakie algorytmy krypto i parametry VPN zostały wynegocjowane w fazie 1 IKE oraz kiedy nastąpi jej renegocjacja. 2. Sprawdzamy poprawność wykonania fazy 2 IKE get sa active

Total active sa: 1

total configured sa: 2

HEX ID S/D Gateway Port Algorithm SPI Life:sec kb Sta PID vs

00000002 0< 192.168.10.156 500 esp: des/md5 71179ba7 1388 unlim A/U 2 0

00000002 0> 192.168.10.156 500 esp: des/md5 04bc2182 1388 unlim A/U 1 0 W przypadku gdy SA nie zostanie wyświetlone otrzymujemy informację, że faza 2 IKE

nie została zakończona pomyślnie. Z wyświetlonego SA dowiadujemy się zaś, jakie algorytmy krypto i parametry VPN zostały wynegocjowane w fazie 2 IKE oraz kiedy nastąpi jej renegocjacja. get session tunnel

alloc 5/max 2048, alloc failed 0

id 30/s**,vsys 0,flag 00010000/00/00,policy -1,time 180

1(00):192.168.10.156/0->192.168.10.71/0,50,000000000000,vlan 0,tun 0,vsd 0

id 52/s**,vsys 0,flag 00010000/00/00,policy -1,time 180

1(00):192.168.10.156/28951->192.168.10.71/39847,50,000000000000,vlan 0,tun 0,vs

d 0

Total 2 sessions shown Brak tuneli VPN oznacza niepowodzenie fazy 2 IKE.



W dużych instalacjach sieci VPN monitorowanie stanu tuneli IPSec/IKE dokonuje się za pomocą dedykowanych narzędzi dostępnych w konsoli NetScreen-Global PRO.



8. Ustalenie przyczyny problemów funkcjonowania VPN

Ustalenie przyczyny problemu funkcjonowania sieci VPN w większości przypadków można dokonać na podstawie analizy logów. Poniżej przedstawiony został przebieg poprawnie zestawionej sesji IPSec/IKE. get log event

IKE<192.168.10.156> Phase 1: Responder starts MAIN mode negotiations.

IKE<192.168.10.156> Phase 1: Completed Main mode negotiations with a <28800>-secondlifetime.

IKE<192.168.10.156> Phase 2 msg-id <2004b8b8>: Responded to the first peer message.

IKE<192.168.10.156> Phase 2 msg-id <2004b8b8>: Completed negotiations with SPI<5eb6f0a5>, tunnel ID <2>, and lifetime <3600> seconds/<0> KB.

vpn 'TUNEL_VPN' (from 192.168.10.156) is up. Typowe problemy sesji IPSec/IKE 1. Niezgodność propozycji IKE SA (np. urządzenie inicjujące IKE proponuje 3DES/SHA-1, a urządzenie odbierające zapytanie posiada skonfigurowane algorytmy DES/SHA-1). Logi na urządzeniu odpowiadającym na IKE: IKE<192.168.10.71> >> <192.168.10.156> Phase 1: Initiated negotiations in main mode.

Logi na urządzeniu inicjującym IKE: IKE: Main Mode Failed to match proposal: DES, SHA1, Pre-shared secret, Group 2

IKE: Main Mode Sent Notification: no proposal chosen 2. Niezgodność propozycji IPSec SA (np. urządzenie inicjujące IKE proponuje AES/SHA-1, a urządzenie odbierające zapytanie posiada skonfigurowane algorytmy DES/MD5). Logi na urządzeniu odpowiadającym na IKE: IKE<192.168.10.156> Phase 1: Responder starts MAIN mode negotiations.


IKE<192.168.10.156> Phase 2 msg-id <4fd34548>: Responded to the first peer message.

IKE<192.168.10.156> Phase 2: Rejected proposals from peer. Negotiations failed.

IKE<192.168.10.156> Phase 2 msg-id <4fd34548>: Negotiations have failed. Logi na urządzeniu inicjującym IKE: Encryption failure: no response from peer.

Encryption failure reason: Packet is dropped because there is no valid SA.



3. Niezgodność ustawień klucza Pre-Shared Secret. Logi na urządzeniu odpowiadającym na IKE: IKE<192.168.10.71> >> <192.168.10.156> Phase 1: Initiated negotiations in main mode.

Logi na urządzeniu inicjującym IKE: IKE: Main Mode Sent Notification: payload malformed – possibly a mismatch in pre-sharedkeys

4. Niezgodne ustawienia adresacji VPN (np. urządzenie inicjujące VPN posiada domenę VPN ustawioną na IP:10.0.0.0/8, a drugie urządzenie posiada skonfigurowany kanał VPN na IP:10.1.2.0/24). Logi na urządzeniu odpowiadającym na IKE: IKE<192.168.10.156> Phase 1: Responder starts MAIN mode negotiations.


IKE<192.168.10.156> Phase 2 msg-id <318ea7e1>: Responded to the first peer message.

IKE<192.168.10.156> Phase 2: No policy exists for the proxy ID received: local ID(<172.16.10.0>/<255.255.255.0>,<0>,<0>) remote ID (<10.0.0.0>/<255.0.0.0>,<0>,<0>)

IKE<192.168.10.156> Phase 2 msg-id <318ea7e1>: Negotiations have failed. Logi na urządzeniu inicjującym IKE: IKE: Main Mode completion.

Encryption failure: no response from peer.

Encryption failure reason: Packet is dropped because there is no valid SA. 5. Do innych typowych problemów funkcjonowania IPSec/IKE należy blokowanie na urządzeniach sieciowych na drodze VPN protokołów IPSec (IP 50) lub IKE (UDP 500). Problemy VPN mogą być także związane z infrastrukturą sieciową (np. translacja adresów NAT, fragmentacja pakietów). W zależności od zastosowanej technologii VPN dostępne są różne mechanizmy eliminacji zakłóceń VPN (m.in. NAT Traversal, TCP MSS). UWAGA: Może zdarzyć się, że wprowadzając zmiany parametrów VPN nawet jeżeli konfiguracja będzie poprawna nie uda się zestawić tunelu. Problem wynika z tego, że urządzenia VPN zachowują w pamięci wynegocjowane parametry IKE, a zmiana konfiguracji VPN zwykle ich nie kasuje. Należy wtedy przeładować urządzenia VPN, bądź za pomocą odpowiednich poleceń usunąć wynegocjowane parametry IKE z urządzeń.

! Mariusz Stawowski

Zasady działania i praktyczne implementacje sieci VPN

Documents

Transcript of Zasady działania i praktyczne implementacje sieci VPN