IPsec

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacji, wyszukiwania

IPsec (ang. Internet Protocol Security, IP Security) – zbiór protokołów służących implementacji bezpiecznych połączeń oraz wymiany kluczy szyfrowania pomiędzy komputerami. Protokoły tej grupy mogą być wykorzystywane do tworzenia Wirtualnej Sieci Prywatnej (ang. VPN).

VPN oparta na IPsec składa się z dwóch kanałów komunikacyjnych pomiędzy połączonymi komputerami: kanał wymiany kluczy za pośrednictwem którego przekazywane są dane związane z uwierzytelnianiem i szyfrowaniem (klucze) oraz kanału (jednego lub więcej), który niesie pakiety transmitowane poprzez sieć prywatną. Kanał wymiany kluczy jest standardowym protokołem UDP (port 500). Kanały przesyłu danych oparte są na protokole ESP (protokół numer 50) opisanym w dokumencie RFC 2406.

Architektura IPsec[edytuj | edytuj kod]

Protokoły wchodzące w skład architektury IPsec służą do bezpiecznego przesyłania przez sieć pakietów IP. Działają one na zasadzie kapsułkowania, tj. oryginalny (zabezpieczany) pakiet IP jest szyfrowany, otrzymuje nowy nagłówek protokołu IPsec i w takiej formie jest przesyłany przez sieć.

Bezpieczeństwo zapewniane przez IPsec może być dwojakie, w zależności od stosowanego protokołu. I tak: pojawia się problem dystrybucji kluczy symetrycznych. Narzuca się zastosowanie kryptografii asymetrycznej, ale jest ona o wiele wolniejsza od szybkich szyfrów symetrycznych i dodanie ich do protokołów niskiego poziomu, jakimi są ESP i AH (Authentication Header), miałoby znaczący wpływ na wydajność. Te dwa protokoły pozostały więc relatywnie prostymi protokołami niskiego poziomu, a do skomplikowanych zadań dystrybucji klucza i uwierzytelniania stron stworzono oddzielny protokół IKE.

Protokół IKE[edytuj | edytuj kod]

Protokół IKE (Internet Key Exchange) został zaprojektowany w większości przez NSA (National Security Agency) i jest skomplikowany, głównie ze względu na poziom abstrakcji, na jakim operuje. Wystarczy bowiem włożyć do niego własny zestaw algorytmów kryptograficznych, czy wręcz własną arytmetykę (zestaw ten określa się jako DOI (Domain of Interpretation) by otrzymać zupełnie inny od cywilnego protokół, na przykład na potrzeby wojska.

IKE funkcjonalnie składa się z dwóch części: specyfikacji metod kryptograficznych uwierzytelnienia i negocjacji kluczy Oakley (IKE: RFC 2409, IKEv1: RFC 4109, IKEv2: RFC 4306) oraz specyfikacji formatów pakietów i stanów protokołu ISAKMP. W praktyce nazwy ISAKMP używa się zamiennie z IKE.

Podstawowymi celami IKE są poniższe kroki, wykonywane kolejno:

  • uwierzytelnienie obu stron komunikacji wobec siebie za pomocą jednej z poniższych metod (ustalanych przez administratora):
    • hasło znane obu stronom (shared secret)
    • podpisy RSA (konieczna ręczna wymiana kluczy publicznych stron)
    • certyfikaty X.509 (najbardziej uniwersalna)
  • nawiązanie bezpiecznego kanału dla potrzeb IKE nazywanego ISAKMP SA (Security Association)
  • bezpieczne uzgodnienie kluczy kryptograficznych oraz parametrów tuneli IPsec
  • ewentualna ich renegocjacja co określony czas

Po nawiązaniu połączenia przez IKE obie strony mogą już stworzyć właściwe tunele IPsec (ESP lub AH) i rozpocząć komunikację. Jeśli wymagane jest, by klucze kryptograficzne były regularnie (np. co 8 godzin) zmieniane, IKE również to umożliwia.

Praktyczną konsekwencją stosowania IKE jest to, że zamiast ręcznie konfigurować klucze (i wiele innych parametrów) na obu stronach połączenia administrator może w najprostszym przypadku skonfigurować na nich tylko hasło shared secret, by w pełni automatycznie uzyskać tunele IPsec.

Szczegóły IPsec[edytuj | edytuj kod]

Istotną cechą ESP i AH jest mała ilość informacji, jakie potencjalny atakujący otrzymuje w wyniku podsłuchiwania szyfrowanej komunikacji. Po włączeniu sniffera zobaczy on tylko zaszyfrowany pakiet opatrzony dwiema liczbami:

  • SPI (Security Parameters Index)
  • numer sekwencyjny

Wartość SPI jest stała, najczęściej jest generowana losowo i ma kluczowe znaczenie dla stron połączenia, a żadnego dla atakującego. Strony połączenia bowiem na podstawie SPI rozpoznają do jakiej sesji (tunelu) IPsec przynależy dany pakiet i jakie w związku z tym zastosować szyfry oraz klucze do jego rozszyfrowania.

Przykładowo, SPI 0x123456 może oznaczać że dany pakiet należy do kanału IPsec łączącego sieci B i C, szyfrowanego 3DES z kluczem X. Inne SPI mogłoby oznaczać kanał między D i E, szyfrowany AES z kluczem Y. Numer SPI jest ustalany przez strony podczas tworzenia kanału i jest stały podczas jego istnienia.

Numer sekwencyjny jest losowany i zwiększany o 1 z każdym wysłanym przez dany kanał pakietem i służy do rozpoznawania pakietów o kolejności przestawionej podczas wędrówki po sieci oraz chroni przed atakami przez powtórzenie (replay attacks). Ponieważ numer ten jest wartością 32-bitową, po 2^32 wysłanych pakietów kanał musi być zamknięty, a w jego miejsce stworzony nowy, z licznikiem startującym od nowej wylosowanej liczby.

Jednokierunkowość[edytuj | edytuj kod]

Kolejną istotną cechą kanałów IPsec jest ich jednokierunkowość - dany kanał obsługuje tylko ruch idący z hosta A do B. Każda pełna łączność wykorzystuje dwa kanały - jeden od A do B, drugi od B do A. Każdy z nich ma inne SPI, osobny licznik sekwencyjny, inne klucze kryptograficzne.

Taki jednokierunkowy kanał IPsec (ESP lub AH) jest określany nazwą Security Association (która nie ma dobrego polskiego tłumaczenia, stąd w artykule używane jest określenie "kanał"). Każde SA charakteryzuje się przez adresy IP początku i końca oraz SPI.

Klucze kryptograficzne[edytuj | edytuj kod]

Do pełnej łączności między dwoma hostami potrzebne są dwa kanały IPsec. Jeśli wykorzystany zostanie protokół ESP, to każdy kanał będzie wymagał dwóch kluczy kryptograficznych - jednego do szyfrowania danych, drugiego do ochrony integralności i uwierzytelnienia. Jeśli będzie to AH, to odpadnie pierwszy klucz (szyfrujący). W najbardziej złożonym przypadku ESP do pełnej komunikacji będą potrzebne cztery klucze:

  • szyfrujący dla kanału relacji A do B
  • uwierzytelniający dla kanału relacji A do B
  • szyfrujący dla kanału relacji B do A
  • uwierzytelniający dla kanału relacji B do A

Jest to kolejny powód, dla którego ręczna konfiguracja kanałów IPsec jest uciążliwa - w przypadku stosowania IKE wszystkie klucze uzgadniane są automatycznie.

Tryb transportowy i tunelowy[edytuj | edytuj kod]

Nagłówek IPsec - ESP można stosować w dwóch trybach: transportowym lub tunelowym. Typowy pakiet IP wygląda następująco (zakładając, że protokołem wyższej warstwy będzie TCP):

+----+-----+--------------------
| IP | TCP | dane użytkownika...
+----+-----+--------------------

Tryb transportowy polega na tym, że pomiędzy nagłówek IP a TCP dokładamy jeszcze dodatkowo nagłówek IPsec (załóżmy że jest to ESP). Część oznaczona podwójną linią jest zaszyfrowana i całkowicie nieprzezroczysta dla ewentualnego podsłuchującego. Podlega ona także ochronie integralności.

+----+-----+==========================
| IP | ESP | TCP | dane użytkownika...
+----+-----+==========================

Jak widać, w trybie transportowym niewidoczne są dane użytkownika, ale nagłówek IP pozostaje widoczny. Atakujący nie wie zatem, o czym się rozmawia, ale wie za to, kto z kim tę konwersację prowadzi.

Tryb tunelowy zapewnia wyższy poziom ochrony - pakiet użytkownika jest w całości enkapsulowany w ESP, a na początek jest dokładany zupełnie nowy nagłówek IPn:

+-----+-----+===============================
| IPn | ESP | IP | TCP | dane użytkownika...
+-----+-----+===============================

Jeśli stacja A i B będą się łączyły bezpośrednio za pomocą trybu tunelowego to nagłówek IPn będzie praktycznie identyczny jak oryginalny IP i całość będzie praktycznie równa trybowi transportowemu. Ale dzięki trybowi tunelowemu jest możliwe tworzenie wirtualnych sieci prywatnych (VPN), które stanowią główne zastosowanie IPsec.

Kluczową cechą VPN jest możliwość stworzenia szyfrowanego tunelu pomiędzy dwiema bramkami (B) łączącymi dwie części sieci korporacyjnej przez sieć publiczną:

10.1.1.0/24 ----- B1 ========= B2 ------ 10.2.2.0/24

Atakujący widzi wówczas wyłącznie zaszyfrowane pakiety przesyłane pomiędzy B1 i B2. Oryginalne pakiety są ukryte w tunelu i podsłuchującemu nie jest znana ani ich treść, ani nawet zastosowana w sieci korporacyjnej adresacja.

Zaletą stosowania trybu tunelowego jest niewielki narzut wielkości pakietu (mniej niż 2% przy MTU 1500 bajtów) wynikający z konieczności dodawania drugiego nagłówka IP. Wadą trybu transportowego jest niemożność tunelowania w nim pakietów dla innych sieci.

IPSec NAT Traversal[edytuj | edytuj kod]

W przypadku protokołu AH nie jest możliwa zamiana adresu źródłowego w nagłówku pakietu IP, gdyż cały nagłówek zabezpieczony jest przed zmianą. Do nagłówka dodawany jest skrót kryptograficzny powstały z sumy kontrolnej pakietu oraz tajnego hasła. Jakakolwiek modyfikacja pakietu uznana będzie przez drugą stronę za naruszenie integralności danych. Dla protokołu AH nie jest możliwa translacja adresów.

W przypadku protokołu ESP sprawa wygląda lepiej, ponieważ ochronie integralności nie podlega zewnętrzny nagłówek IP, dlatego możliwa jest zamiana źródłowego adresu IP. Jednak gdy istnieje wielu klientów znajdujących się za tym samym routerem (maskaradą), wtedy pojawia się problem, ponieważ protokół ten nie wykorzystuje portów, tak jak to ma miejsce w przypadku protokołów TCP i UDP, dlatego nie można w prosty sposób odróżnić połączeń IPSec inicjowanych z różnych hostów wewnątrz sieci. Rozwiązaniem problemu jest tzw. NAT Traversal.

NAT Traversal polega na kapsułkowaniu pakietów IP na protokół UDP ze standardowym nagłówkiem UDP który już umożliwia translację NAT poprzez routery i transmisję ramek pomiędzy węzłami sieci. Stąd nazwa NAT-Trawersowanie.

Zobacz też[edytuj | edytuj kod]

Linki zewnętrzne[edytuj | edytuj kod]