DZWON

Są tacy, którzy czytają tę wiadomość przed tobą.
Zapisz się, aby otrzymywać najnowsze artykuły.
E-mail
Nazwa
Nazwisko
Jak chcesz czytać Dzwon?
Bez spamu

(Internet Key Exchange (IKE)) - Wymiana kluczy.

  • RFC 2410 (Algorytm szyfrowania NULL i jego użycie z IPsec) — algorytm szyfrowania NULL i jego użycie.
  • RFC 2411 (mapa drogowa dokumentu bezpieczeństwa IP) — dalszy rozwój standardu.
  • RFC 2412 (The OAKLEY Key Determination Protocol) — sprawdzanie zgodności kluczy.
  • Architektura IPsec

    IPsec, w przeciwieństwie do innych dobrze znanych protokołów SSL i TLS, działa w warstwie sieciowej (warstwa 3 modelu OSI). Dzięki temu protokół IPsec jest bardziej elastyczny, dzięki czemu można go używać do ochrony dowolnego protokołu opartego na TCP i UDP. Protokół IPsec może służyć do zapewnienia bezpieczeństwa między dwoma hostami IP, między dwiema bramami bezpieczeństwa lub między hostem IP a bramą bezpieczeństwa. Protokół jest „dodatkiem” do protokołu IP i przetwarza wygenerowane pakiety IP w sposób opisany poniżej. IPsec może zapewnić integralność i/lub poufność danych przesyłanych przez sieć.

    IPsec używa następujących protokołów do wykonywania różnych funkcji:

    • Nagłówek uwierzytelniania (AH) zapewnia integralność połączenia wirtualnego (przesyłanych danych), uwierzytelnienie źródła informacji oraz dodatkową funkcję zapobiegającą ponownej transmisji pakietów
    • Encapsulating Security Payload (ESP) może zapewnić poufność (szyfrowanie) przesyłanych informacji, ograniczając przepływ poufnego ruchu. Ponadto może zapewnić integralność połączenia wirtualnego (przesyłane dane), uwierzytelnienie źródła informacji oraz dodatkową funkcję zapobiegającą ponownej transmisji pakietów (za każdym razem, gdy używany jest ESP, należy użyć jednego lub drugiego zestawu usług bezpieczeństwa)
    • Stowarzyszenie Security Association (SA) zapewnia szereg algorytmów i danych, które zapewniają parametry wymagane do działania AH i / lub ESP. Internet Security Association and Key Management Protocol (ISAKMP) zapewnia strukturę uwierzytelniania i wymiany kluczy, uwierzytelnianie kluczy.

    Stowarzyszenie Bezpieczeństwa

    Pojęcie „Secure Virtual Connection” (SA, „Security Association”) ma fundamentalne znaczenie dla architektury IPsec. SA jest połączeniem simpleksowym utworzonym w celu przenoszenia przez nie odpowiedniego ruchu. Wdrażając usługi bezpieczeństwa, SA tworzone jest w oparciu o wykorzystanie protokołów AH lub ESP (lub obu jednocześnie). SA jest zdefiniowany zgodnie z koncepcją punkt-punkt i może działać w dwóch trybach: trybie transportu (PTP) i trybie tunelowania (RTU). Tryb transportu jest zaimplementowany z SA między dwoma węzłami IP. W trybie tunelowania SA tworzy tunel IP.

    Wszystkie SA są przechowywane w SADB (Security Associations Database) modułu IPsec. Każdy SA posiada unikalny znacznik składający się z trzech elementów:

    • Indeks parametrów bezpieczeństwa (SPI)
    • Docelowe adresy IP
    • identyfikator protokołu bezpieczeństwa (ESP lub AH)

    Moduł IPsec, mając te trzy parametry, może wyszukać wpis SADB dla określonego SA. Lista komponentów SA obejmuje:

    Numer seryjny 32-bitowa wartość używana do utworzenia pola Numer sekwencji w nagłówkach AH i ESP. Przepełnienie licznika numerów sekwencji Flaga sygnalizująca przepełnienie licznika numeru seryjnego. Powtórka okna tłumienia ataków Służy do definiowania retransmisji pakietów. Jeśli wartość w polu Numer sekwencji nie mieści się w określonym zakresie, pakiet zostaje zniszczony. Informacje AH używany algorytm uwierzytelniania, wymagane klucze, czas życia klucza i inne parametry. Informacje ESP algorytmy szyfrowania i uwierzytelniania, wymagane klucze, parametry inicjalizacji (np. IV), czas życia klucza i inne parametry Tryb pracy IPsec tunel lub transport MTU Maksymalny rozmiar pakietu, który może być przesłany przez VC bez fragmentacji.

    Ponieważ bezpieczne połączenia wirtualne (SA) są simpleksowe, co najmniej dwa SA są wymagane do ustanowienia łącza dupleksowego. Dodatkowo każdy protokół (ESP/AH) musi mieć własne SA dla każdego kierunku, czyli paczka AH+ESP wymaga czterech SA. Wszystkie te dane znajdują się w SADB.

    • AH: Algorytm uwierzytelniania.
    • AH: tajny klucz do uwierzytelniania
    • ESP: algorytm szyfrowania.
    • ESP: tajny klucz szyfrowania.
    • ESP: użyj uwierzytelniania (tak / nie).
    • Opcje wymiany kluczy
    • Ograniczenia routingu
    • Polityka filtrowania IP

    Oprócz bazy danych SADB implementacje protokołu IPsec obsługują bazę danych zasad zabezpieczeń (SPD). Wpis SPD składa się z zestawu wartości pól nagłówka IP i pól nagłówka protokołu Upper Layer Protocol. Te pola nazywane są selektorami. Selektory są używane do filtrowania wychodzących pakietów w celu dopasowania każdego pakietu do określonego SA. Podczas tworzenia pakietu wartości odpowiednich pól w pakiecie (pola selektora) są porównywane z tymi zawartymi w SPD. Znaleziono odpowiednie SA. SA, jeśli istnieje, jest następnie określana dla pakietu i skojarzonego z nim indeksu parametrów bezpieczeństwa (SPI). Następnie wykonywane są operacje IPsec (operacje protokołu AH lub ESP).

    Przykłady selektorów zawartych w SPD:

    • Docelowy adres IP
    • Adres IP nadawcy
    • Protokół IPsec (AH, ESP lub AH + ESP)
    • Porty nadawcy i odbiorcy

    Nagłówek uwierzytelniania

    Nagłówek uwierzytelniania format
    Przesunięcia Oktet 16 0 1 2 3
    Oktet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    0 0 Następny nagłówek Ładowność Len Skryty
    4 32
    8 64 Numer sekwencji
    C 96 Wartość kontroli integralności (ICV)
    Następny nagłówek(8 bitów) Typ nagłówka protokołu następującego po nagłówku AH. Korzystając z tego pola, odbierający moduł IP-sec uczy się o chronionym protokole wyższego poziomu. Wartości tego pola dla różnych protokołów można znaleźć w RFC 1700. Ładowność Len(8 bitów) To pole określa całkowity rozmiar nagłówka AH w słowach 32-bitowych minus 2. Jednak w przypadku korzystania z protokołu IPv6 długość nagłówka musi być wielokrotnością 8 bajtów. Skryty(16 bitów) Zarezerwowane. Wypełniony zerami. Indeks parametrów bezpieczeństwa(32 bity) Indeks parametrów bezpieczeństwa. Wartość tego pola, wraz z docelowym adresem IP i protokołem bezpieczeństwa (protokół AH), jednoznacznie identyfikuje zabezpieczone połączenie wirtualne (SA) dla tego pakietu. Zakres wartości SPI 1 ... 255 jest zarezerwowany przez IANA. Numer sekwencji(32 bity) Numer kolejny. Służy do ochrony przed retransmisją. Pole zawiera monotonicznie rosnącą wartość parametru. Chociaż odbiorca może zrezygnować z usługi ochrony retransmisji pakietów, jest to obowiązkowe i zawsze znajduje się w nagłówku AH. Wysyłający moduł IPsec zawsze używa tego pola, ale odbiorca może go nie przetwarzać. Wartość kontroli integralności

    Protokół AH służy do uwierzytelniania, to znaczy do potwierdzania, że ​​komunikujemy się z dokładnie tym, kim myślimy, że jesteśmy i że dane, które otrzymujemy, nie są uszkodzone podczas przesyłania.

    Przetwarzanie wychodzących pakietów IP

    Jeśli wysyłający moduł IPsec ustali, że pakiet jest skojarzony z SA, który zakłada przetwarzanie AH, rozpoczyna przetwarzanie. Wstawia nagłówek AH do pakietu IP w różny sposób w zależności od trybu (transport lub tunelowanie). W trybie transportu nagłówek AH jest umieszczany po nagłówku protokołu IP i przed nagłówkami protokołu wyższej warstwy (zazwyczaj TCP lub UDP). W trybie tunelowania cały oryginalny pakiet IP jest ramkowany najpierw przez nagłówek AH, a następnie przez nagłówek protokołu IP. Ten nagłówek nazywa się zewnętrznym, a nagłówek oryginalnego pakietu IP nazywany jest wewnętrznym. Następnie transmitujący moduł IPsec musi wygenerować kolejny numer i zapisać go w polu Numer sekwencji... Po ustanowieniu SA numer sekwencyjny jest ustawiany na 0 i jest zwiększany o jeden przed wysłaniem każdego pakietu IPsec. Ponadto sprawdzane jest, czy licznik się zapętlił. Jeśli osiągnie wartość maksymalną, jest resetowany do 0. W przypadku korzystania z usługi antyretransmisyjnej, gdy licznik osiągnie wartość maksymalną, wysyłający moduł IPsec resetuje SA. W ten sposób zapewniona jest ochrona przed wielokrotną transmisją pakietów - odbiorczy moduł IPsec sprawdzi pole Numer sekwencji i zignoruj ​​pakiety ponawiania. Następnie obliczana jest suma kontrolna ICV. Należy zauważyć, że tutaj suma kontrolna jest obliczana przy użyciu tajnego klucza, bez którego atakujący będzie mógł ponownie obliczyć skrót, ale bez znajomości klucza nie będzie w stanie utworzyć prawidłowej sumy kontrolnej. Konkretne algorytmy używane do obliczania ICV można znaleźć w RFC 4305. Obecnie można stosować np. algorytmy HMAC-SHA1-96 lub AES-XCBC-MAC-96. Protokół AN oblicza sumę kontrolną (ICV) dla następujących pól w pakiecie IPsec:

    • Pola nagłówka IP, które nie zostały zmodyfikowane podczas transmisji lub są zidentyfikowane jako najważniejsze
    • Nagłówek AH (pola: „Następny nagłówek”, „Długość ładunku”, „Zarezerwowane”, „SPI”, „Numer sekwencyjny”, „Wartość kontrolna integralności”. Pole „Wartość kontrolna integralności” jest ustawione na 0 podczas obliczania ICV
    • dane protokołu wyższej warstwy
    Jeśli pole może ulec zmianie podczas transportu, to jego wartość jest ustawiana na 0 przed obliczeniem ICV. Wyjątkiem są pola, które mogą się zmieniać, ale których wartość można przewidzieć po otrzymaniu. Przy obliczaniu ICV nie są one wypełnione zerami. Przykładem modyfikowalnego pola może być pole sumy kontrolnej, przykładem modyfikowalnego, ale predefiniowanego pola może być adres IP odbiorcy. Bardziej szczegółowy opis pól, które są brane pod uwagę przy obliczaniu ICV można znaleźć w standardzie RFC 2402.

    Przetwarzanie przychodzących pakietów IP

    Po odebraniu pakietu zawierającego komunikat AH, odbierający moduł IPsec wyszukuje odpowiednie bezpieczne połączenie wirtualne (SA) bazy danych skojarzeń zabezpieczeń (SADB) przy użyciu docelowego adresu IP, protokołu bezpieczeństwa (AH) i SPI. Jeśli nie zostanie znalezione pasujące SA, pakiet jest odrzucany. Znalezione bezpieczne połączenie wirtualne (SA) wskazuje, czy używana jest usługa zapobiegania retransmisji pakietów, tj. o potrzebie sprawdzenia pola Numer sekwencji... Jeśli usługa jest używana, to pole jest zaznaczone. W tym celu stosuje się metodę okna przesuwnego. Moduł odbiorczy IPsec tworzy okno o szerokości W. Lewa krawędź okna odpowiada minimalnej liczbie sekwencyjnej ( Numer sekwencji) N poprawnie odebranych pakietów. Pakiet z polem Numer sekwencji, który zawiera wartość rozpoczynającą się od N + 1 i kończącą się na N + W, jest akceptowana poprawnie. Jeśli odebrany pakiet znajduje się na lewym brzegu okna, zostaje zniszczony. Moduł odbierający IPsec oblicza następnie ICV na podstawie odpowiednich pól odebranego pakietu przy użyciu algorytmu uwierzytelniania, którego uczy się z rekordu SA i porównuje wynik z wartością ICV umieszczoną w polu „Wartość sprawdzania integralności”. Jeżeli obliczona wartość ICV pokrywa się z otrzymaną, to przychodzący pakiet jest uważany za ważny i akceptowany do dalszego przetwarzania IP. Jeśli wynik testu jest negatywny, pakiet odbiorczy jest odrzucany.

    Hermetyzacja ładunku zabezpieczającego format
    Przesunięcia Oktet 16 0 1 2 3
    Oktet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    0 0 Indeks parametrów bezpieczeństwa (SPI)
    4 32 Numer sekwencji
    8 64 Dane ładunku
    Dopełnienie (0-255 oktetów)
    Długość podkładki Następny nagłówek
    Wartość kontroli integralności (ICV)
    Indeks parametrów bezpieczeństwa(32 bity) Indeks parametrów bezpieczeństwa. Wartość tego pola, wraz z docelowym adresem IP i protokołem bezpieczeństwa (protokół AH), jednoznacznie identyfikuje zabezpieczone połączenie wirtualne (SA) dla tego pakietu. Zakres wartości SPI 1 ... 255 jest zarezerwowany przez IANA do wykorzystania w przyszłości. Numer sekwencji(32 bity) Numer kolejny. Służy do ochrony przed retransmisją. Pole zawiera monotonicznie rosnącą wartość parametru. Chociaż odbiorca może odrzucić usługę ochrony przed retransmisją pakietów, jest ona zawsze obecna w nagłówku AH. Nadawca (wysyłający moduł IPsec) MUSI zawsze używać tego pola, ale odbiorca może nie musieć go przetwarzać. Dane ładunku(zmienna) To pole zawiera dane zgodne z polem „Następny nagłówek”. To pole jest wymagane i składa się z całkowitej liczby bajtów. Jeśli algorytm używany do szyfrowania tego pola wymaga danych do synchronizacji procesów kryptograficznych (na przykład „Wektor inicjujący”), to pole może zawierać te dane w formie jawnej. Wyściółka(0-255 oktetów) Dodawanie. Jest to konieczne na przykład dla algorytmów, które wymagają, aby tekst jawny był wielokrotnością pewnej liczby bajtów), na przykład rozmiar bloku dla szyfru blokowego. Długość podkładki(8 bitów) Rozmiar dopełnienia (w bajtach). Następny nagłówek(8 bitów) To pole określa rodzaj danych zawartych w polu „Dane ładunku”. Wartość kontroli integralności Sprawdź sumę. Musi być wielokrotnością 8 bajtów dla IPv6 i 4 bajtów dla IPv4.

    Wyjściowe przetwarzanie pakietów IPsec

    Jeśli wysyłający moduł IPsec ustali, że pakiet jest skojarzony z SA, który oczekuje przetwarzania ESP, rozpoczyna przetwarzanie. W zależności od trybu (tryb transportu lub tunelowania) oryginalny pakiet IP jest przetwarzany w różny sposób. W trybie transportu wysyłający moduł IPsec wykonuje procedurę ramkowania (enkapsulacji) protokołu wyższej warstwy (na przykład TCP lub UDP) przy użyciu nagłówka ESP i nagłówka ESP, bez wpływu na nagłówek oryginalnego pakietu IP. W trybie tunelowania pakiet IP jest ramkowany przez nagłówek ESP i nagłówek ESP, a następnie ramkowany przez zewnętrzny nagłówek IP. Następnie wykonywane jest szyfrowanie - w trybie transportowym szyfrowana jest tylko wiadomość protokołu powyżej warstwy bazowej (tj. wszystko, co było po nagłówku IP w oryginalnym pakiecie), w trybie tunelowania szyfrowany jest cały oryginalny pakiet IP. Wysyłający moduł IPsec określa algorytm szyfrowania i tajny klucz z rekordu SA. Standardy IPsec pozwalają na użycie algorytmów szyfrowania potrójnego DES, AES i Blowfish. Ponieważ rozmiar tekstu jawnego musi być wielokrotnością pewnej liczby bajtów, na przykład rozmiar bloku dla algorytmów blokowych, konieczne dodanie zaszyfrowanej wiadomości jest również wykonywane przed szyfrowaniem. Zaszyfrowana wiadomość jest umieszczana w polu Dane ładunku... W terenie Długość podkładki pasuje do długości wyściółki. Następnie, podobnie jak w AH, oblicza Numer sekwencji... Następnie obliczana jest suma kontrolna (ICV). Suma kontrolna, w przeciwieństwie do protokołu AH, gdzie niektóre pola nagłówka IP są również brane pod uwagę przy jej obliczaniu, w ESP obliczana jest tylko przez pola pakietu ESP minus pole ICV. Przed obliczeniem sumy kontrolnej jest wypełniana zerami. Algorytm obliczania ICV, podobnie jak w protokole AH, wysyłający moduł IPsec uczy się z zapisu o SA, z którym powiązany jest przetwarzany pakiet.

    Przetwarzanie przychodzących pakietów IPsec

    Po odebraniu pakietu zawierającego komunikat protokołu ESP, odbierający moduł IPsec szuka odpowiedniego bezpiecznego połączenia wirtualnego (SA) w bazie danych skojarzeń zabezpieczeń (SADB) przy użyciu docelowego adresu IP, protokołu zabezpieczeń (ESP) i indeksu SPI. Jeśli nie zostanie znalezione pasujące SA, pakiet jest odrzucany. Znalezione bezpieczne połączenie wirtualne (SA) wskazuje, czy używana jest usługa zapobiegania retransmisji pakietów, tj. konieczność zaznaczenia pola Numer Sekwencji. Jeśli usługa jest używana, to pole jest zaznaczone. W tym celu, podobnie jak w AH, stosuje się metodę okna przesuwnego. Odbierający moduł IPsec tworzy okno o szerokości W. Lewa krawędź okna odpowiada minimalnemu numerowi sekwencji N prawidłowo odebranego pakietu. Pakiet z polem Sequence Number zawierającym wartość z zakresu od N+1 do N+W jest akceptowany poprawnie. Jeśli odebrany pakiet znajduje się na lewym brzegu okna, zostaje zniszczony. Następnie, jeśli używana jest usługa uwierzytelniania, moduł odbierający IPsec oblicza ICV z odpowiednich pól odebranego pakietu przy użyciu algorytmu uwierzytelniania, którego uczy się z rekordu SA i porównuje wynik z wartością ICV umieszczoną w polu Wartość sprawdzania integralności. Jeśli obliczona wartość ICV pokrywa się z otrzymaną, to przychodzący pakiet jest uważany za ważny. Jeśli wynik testu jest negatywny, pakiet odbiorczy jest odrzucany. Następnie pakiet jest deszyfrowany. Odbiornik IPsec uczy się z rekordu SA, który algorytm szyfrowania i tajny klucz jest używany. Należy zauważyć, że procedurę sprawdzania sumy kontrolnej i deszyfrowania można przeprowadzić nie tylko sekwencyjnie, ale także równolegle. W tym drugim przypadku procedura weryfikacji sumy kontrolnej powinna zakończyć się przed procedurą deszyfrowania, a jeśli weryfikacja ICV się nie powiedzie, procedura deszyfrowania również powinna się zatrzymać. Pozwala to na szybsze wykrywanie złych pakietów, co z kolei zwiększa poziom ochrony przed atakami typu „odmowa usługi” (DOS). Ponadto odszyfrowana wiadomość zgodnie z polem Następny nagłówek przekazane do dalszego przetwarzania.

    Stosowanie

    Protokół IPsec jest używany głównie w tunelach VPN. W tym przypadku protokoły ESP i AH działają w trybie tunelowania. Ponadto, dostosowując polityki bezpieczeństwa w określony sposób, protokół może zostać wykorzystany do stworzenia zapory. Celem zapory jest to, że kontroluje i filtruje przechodzące przez nią pakiety zgodnie z określonymi regułami. Ustanowiony zostaje zestaw reguł, a ekran przegląda wszystkie przechodzące przez niego pakiety. Jeśli przesyłane pakiety podlegają tym regułom, zapora odpowiednio je przetwarza. Na przykład może odrzucić niektóre pakiety, przerywając w ten sposób niezabezpieczone połączenia. Odpowiednio dostosowując politykę bezpieczeństwa, możesz na przykład zablokować ruch internetowy. W tym celu wystarczy zabronić wysyłania pakietów, w których osadzone są komunikaty protokołów HTTP i HTTPS. Protokół IPsec może być również używany do ochrony serwerów przez odrzucanie wszystkich pakietów poza tymi, które są potrzebne do prawidłowego wykonywania funkcji serwera. Na przykład w przypadku serwera sieci Web można zablokować cały ruch z wyjątkiem połączeń przez port TCP 80 lub TCP 443 w przypadku korzystania z protokołu HTTPS.

    Zobacz też

    Spinki do mankietów

    • Opis konfiguracji IPSec (cisco.com)

    IPsec nie jest pojedynczym protokołem, ale systemem protokołów zaprojektowanym do ochrony danych w warstwie sieciowej sieci IP. W tym artykule opisano teorię wykorzystania protokołu IPsec do tworzenia tunelu VPN.

    Wstęp

    VPN oparty na technologii IPsec można podzielić na dwie części:

    • Internetowy protokół wymiany kluczy (IKE)
    • Protokoły IPsec (AH / ESP / oba)

    Pierwsza część (IKE) to faza negocjacji, podczas której dwaj partnerzy sieci VPN decydują, które metody zostaną użyte do ochrony ruchu IP przesyłanego między nimi. Ponadto IKE służy również do zarządzania połączeniami, wprowadzając koncepcję Security Associations (SA) dla każdego połączenia. SA są kierowane tylko w jedną stronę, więc typowe połączenie IPsec wykorzystuje dwa SA.

    Druga część to dane IP, które muszą zostać zaszyfrowane i uwierzytelnione przed przesłaniem metodami uzgodnionymi w pierwszej części (IKE). Można użyć różnych protokołów IPsec: AH, ESP lub obu.

    Sekwencję ustanawiania VPN przez IPsec można podsumować w następujący sposób:

    • IKE negocjuje IKE Layer Security
    • IKE negocjuje zabezpieczenia warstwy IPsec
    • chronione dane są przesyłane przez VPN IPsec

    IKE, internetowa wymiana kluczy

    Aby zaszyfrować i uwierzytelnić dane, należy wybrać metodę szyfrowania / uwierzytelniania (algorytm) oraz używane w nich klucze. Zadanie protokołu Internet Key Exchange, IKE, sprowadza się w tym przypadku do dystrybucji tych „kluczy sesji” i uzgodnienia algorytmów, które będą chronić dane pomiędzy punktami VPN.

    Główne zadania IKE:

    • Uwierzytelnianie swoich punktów VPN
    • Organizacja nowych połączeń IPsec (poprzez tworzenie par SA)
    • Zarządzanie bieżącymi połączeniami

    IKE śledzi połączenia, przypisując każdemu z nich Security Associations, SA. SA opisuje parametry konkretnego połączenia, w tym protokół IPsec (AH/ESP lub oba), klucze sesji używane do szyfrowania/odszyfrowywania i/lub uwierzytelniania danych. SA jest jednokierunkowe, więc wiele SA jest używanych na połączenie. W większości przypadków, gdy używany jest tylko ESP lub AH, dla każdego połączenia tworzone są tylko dwie SA, jedna dla ruchu przychodzącego i jedna dla ruchu wychodzącego. Gdy ESP i AH są używane razem, wymagane są SA cztery.

    Proces negocjacji IKE przebiega przez kilka etapów (faz). Te fazy obejmują:

    1. IKE Faza 1:
      - Negocjowanie ochrony samego IKE (tunel ISAKMP)
    2. IKE faza 2 (IKE faza 2):
      - Wynegocjowano ochronę IPsec
      - Odbieranie danych z pierwszej fazy w celu wygenerowania kluczy sesji

    Połączenia IKE i IPsec są ograniczone pod względem czasu trwania (w sekundach) i ilości przesyłanych danych (w kilobajtach). Ma to na celu poprawę bezpieczeństwa.
    Czas trwania połączenia IPsec jest zazwyczaj krótszy niż IKE. Dlatego po wygaśnięciu połączenia IPsec nowe połączenie IPsec jest ponownie tworzone w drugiej fazie negocjacji. Pierwsza faza negocjacji jest używana tylko podczas ponownego nawiązywania połączenia IKE.

    Do negocjacji IKE wprowadzono Propozycję IKE, która jest propozycją zabezpieczenia danych. Punkt VPN inicjujący połączenie IPsec wysyła listę (ofertę), która określa różne metody zabezpieczania połączenia.
    Negocjacje mogą być prowadzone zarówno w sprawie nawiązania nowego połączenia IPsec, jak i nawiązania nowego połączenia IKE. W przypadku IPsec danymi chronionymi jest ruch przesyłany przez tunel VPN, a w przypadku IKE danymi chronionymi są dane z samych negocjacji IKE.
    Punkt VPN, który otrzymał listę (ofertę) wybiera z niej najbardziej odpowiednią i wskazuje ją w odpowiedzi. Jeśli nie można wybrać żadnej z ofert, brama VPN odmówi.
    Oferta zawiera wszystkie informacje niezbędne do wyboru algorytmu szyfrowania, uwierzytelniania itp.

    Faza I IKE - Negocjacje bezpieczeństwa IKE (tunel ISAKMP)
    W pierwszej fazie negocjacji punkty VPN uwierzytelniają się wzajemnie na podstawie klucza wstępnego. Do uwierzytelniania używany jest algorytm skrótu: MD5, SHA-1, SHA-2.
    Jednak przed wzajemnym uwierzytelnieniem, aby nie przesyłać informacji w postaci zwykłego tekstu, peery VPN dokonują opisanej wcześniej wymiany Propozycji. Dopiero po wybraniu oferty, która pasuje do obu punktów VPN, punkty VPN każdego z nich są uwierzytelniane.
    Uwierzytelnianie można przeprowadzić na różne sposoby: za pomocą kluczy wstępnych, certyfikatów lub. Najpopularniejszą metodą uwierzytelniania są klucze współdzielone.
    Faza I Negocjacja IKE może przebiegać w jednym z dwóch trybów: głównym i agresywnym. Główny tryb jest dłuższy, ale też bezpieczniejszy. W jego trakcie wymienianych jest sześć wiadomości. Tryb agresywny jest szybszy, ograniczony do trzech wiadomości.
    Głównym zadaniem pierwszego etapu IKE jest wymiana kluczy Diffie-Hellman. Opiera się na szyfrowaniu kluczem publicznym, każda ze stron szyfruje parametr uwierzytelnienia (Pre-Shared Key) kluczem publicznym sąsiada, który po otrzymaniu tej wiadomości odszyfrowuje ją swoim kluczem prywatnym. Innym sposobem wzajemnego uwierzytelniania stron jest użycie certyfikatów.

    Faza II IKE — negocjacje dotyczące bezpieczeństwa IPsec
    W drugiej fazie dokonuje się wyboru sposobu ochrony połączenia IPsec.
    Druga faza wykorzystuje materiał kluczowania wyodrębniony z wymiany kluczy Diffie-Hellman, która miała miejsce w pierwszej fazie. Na podstawie tego materiału tworzone są klucze sesji, które służą do ochrony danych w tunelu VPN.

    Jeśli mechanizm jest używany Doskonała tajemnica przekazywania (PFS) następnie nowa wymiana kluczy Diffie-Hellman będzie używana do każdej drugiej fazy negocjacji. Nieznacznie zmniejszając szybkość działania, procedura ta zapewnia, że ​​klucze sesji są od siebie niezależne, co zwiększa ochronę, ponieważ nawet jeśli jeden z kluczy zostanie naruszony, nie można go użyć do brutalnego wymuszenia pozostałych.

    W drugiej fazie negocjacji IKE istnieje tylko jeden tryb działania, zwany trybem szybkim. Podczas negocjacji drugiego etapu wymieniane są trzy komunikaty.

    Pod koniec drugiej fazy nawiązywane jest połączenie VPN.

    Parametry IKE.
    Podczas nawiązywania połączenia wykorzystywanych jest kilka parametrów, bez których negocjacji nie jest możliwe nawiązanie połączenia VPN.

    • Identyfikacja punktu końcowego
      Jak węzły uwierzytelniają się nawzajem. Najczęściej używanym jest klucz współdzielony. Uwierzytelnianie oparte na kluczu współdzielonym wykorzystuje algorytm Diffie-Hellmana.
    • Sieć lokalna i zdalna / host
      Określa ruch, który będzie przesyłany przez tunel VPN.
    • Tunel lub środek transportu.
      IPsec może działać w dwóch trybach: tunelowym i transportowym. Wybór trybu zależy od chronionych obiektów.
      Tryb tunelowy służy do ochrony między odległymi obiektami, tj. Pakiet IP jest całkowicie zamknięty w nowym i tylko połączenie między dwoma punktami VPN będzie widoczne dla zewnętrznego obserwatora. Prawdziwe źródłowe i docelowe adresy IP będą widoczne dopiero po dekapsulacji pakietu, gdy zostanie on odebrany w punkcie odbioru VPN. Dlatego tryb tunelowy jest najczęściej używany do połączeń VPN.
      Tryb transportu chroni dane pakietów IP (TCP, UDP i protokoły wyższych warstw), a oryginalny nagłówek pakietu IP zostanie zachowany. W ten sposób obserwator będzie widział oryginalne źródło i cel, ale nie przesyłane dane. Ten tryb jest najczęściej używany podczas zabezpieczania lokalnego połączenia sieciowego między hostami.
    • Zdalna brama
      Punkt VPN jest odbiorcą bezpiecznego połączenia, które odszyfruje/uwierzytelni dane z drugiej strony i wyśle ​​je do miejsca docelowego.
    • Tryb pracy IKE
      Negocjacja IKE może działać w dwóch trybach: podstawowy oraz agresywny.
      Różnica między nimi polega na tym, że w trybie agresywnym używana jest mniejsza liczba pakietów, co pozwala na szybsze nawiązanie połączenia. Z drugiej strony tryb agresywny nie przesyła niektórych parametrów negocjacji, takich jak grupy Diffie-Hellmana i PFS, co wymaga ich identycznej konfiguracji w punktach uczestników połączenia.
    • Protokoły IPsec
      Istnieją dwa protokoły IPsec, Authentication Header (AH) i Encapsulating Security Payload (ESP), które wykonują funkcje szyfrowania i uwierzytelniania.
      ESP umożliwia szyfrowanie, uwierzytelnianie indywidualnie lub jednocześnie.
      AH umożliwia tylko uwierzytelnianie. Różnica w przypadku uwierzytelniania ESP polega na tym, że AH uwierzytelnia również zewnętrzny nagłówek IP, co pozwala potwierdzić, że pakiet rzeczywiście pochodzi ze wskazanego w nim źródła.
    • Szyfrowanie IKE
      Określa używany algorytm szyfrowania IKE i jego klucze. Obsługiwane są różne algorytmy szyfrowania symetrycznego, na przykład: DES, 3DES, AES.
    • Uwierzytelnianie IKE
      Algorytm uwierzytelniania używany w negocjacjach IKE. Może być: SHA, MD5.
    • Grupy IKE Diffie-Hellman (DH)
      Grupa DF używana do wymiany kluczy IKE. Im większa grupa, tym większy rozmiar kluczy wymiany.
    • Żywotność połączenia IKE
      Wskazuje na to zarówno czas (sekundy), jak i wielkość przesyłanych danych (kilobajty). Gdy tylko jeden z liczników osiągnie wartość progową, rozpoczyna się nowa pierwsza faza. Jeśli żadne dane nie zostały przesłane od czasu utworzenia połączenia IKE, żadne nowe połączenia nie zostaną utworzone, dopóki jedna ze stron nie zechce utworzyć połączenia VPN.
    • PFS
      Po wyłączeniu PFS materiał do generowania klucza zostanie pobrany w pierwszej fazie negocjacji IKE w momencie wymiany klucza. W drugiej fazie negocjacji IKE na podstawie otrzymanego materiału zostaną wygenerowane klucze sesji. Po włączeniu PFS, podczas tworzenia nowych kluczy sesji, materiał do nich będzie używany za każdym razem, gdy nowy. W związku z tym, jeśli klucz zostanie naruszony, nie można na jego podstawie utworzyć nowych kluczy.
      PFS może być używany w dwóch trybach: pierwszy PFS na kluczach wyzwoli nową wymianę kluczy w pierwszej fazie IKE za każdym razem, gdy rozpocznie się negocjacja
      druga faza. Drugi tryb, PFS na tożsamościach, usuwa skojarzenia zabezpieczeń pierwszej fazy za każdym razem po zakończeniu negocjacji drugiej fazy, zapewniając w ten sposób, że żadna negocjacja drugiej fazy nie jest szyfrowana tym samym kluczem, co poprzednia.
    • Grupy IPsec DH
      Dane grupy DF są podobne do tych używanych w IKE, tylko są używane dla PFS.
    • Szyfrowanie IPsec
      Algorytm używany do szyfrowania danych. Używany podczas korzystania z ESP w trybie szyfrowania. Przykład algorytmu: DES, 3DES, AES.
    • Uwierzytelnianie IPsec
      Algorytm używany do uwierzytelniania przesyłanych danych. Używane w przypadku AH lub ESP w trybie uwierzytelniania. Przykład algorytmu: SHA, MD5.
    • Żywotność IPsec
      Żywotność połączenia VPN jest wskazywana zarówno przez czas (sekundy), jak i rozmiar przesyłanych danych (kilobajty). Licznik, który jako pierwszy osiągnie limit, rozpocznie regenerację kluczy sesji. Jeśli żadne dane nie zostały przesłane od czasu utworzenia połączenia IKE, żadne nowe połączenia nie zostaną utworzone, dopóki jedna ze stron nie zechce utworzyć połączenia VPN.

    Metody uwierzytelniania IKE

    • Tryb ręczny
      Najprostsza z metod, w której nie jest używany IKE, a klucze uwierzytelniania i szyfrowania oraz niektóre inne parametry są ustawiane ręcznie w obu punktach połączenia VPN.
    • Klucze współdzielone (PSK)
      Wstępnie wprowadzony klucz współdzielony w obu punktach połączenia VPN. Różnica w stosunku do poprzedniej metody polega na tym, że wykorzystuje ona protokół IKE, który umożliwia uwierzytelnianie punktów końcowych i używanie zmieniających się kluczy sesji zamiast stałych kluczy szyfrowania.
    • Certyfikaty
      Każdy punkt VPN używa: własnego klucza prywatnego, własnego klucza publicznego, własnego certyfikatu, w tym własnego klucza publicznego i podpisanego przez zaufany urząd certyfikacji. W przeciwieństwie do poprzedniej metody pozwala uniknąć wprowadzania jednego wspólnego klucza we wszystkich punktach połączenia VPN, zastępując go osobistymi certyfikatami podpisanymi przez zaufany urząd.

    Protokoły IPsec

    Do ochrony przesyłanych danych wykorzystywane są protokoły IPsec. Wybór protokołu i jego kluczy następuje podczas negocjacji IKE.

    AH (nagłówek uwierzytelniania)

    AH zapewnia możliwość uwierzytelniania przesyłanych danych. W tym celu wykorzystywana jest kryptograficzna funkcja skrótu w odniesieniu do danych zawartych w pakiecie IP. Dane wyjściowe tej funkcji (hash) są wysyłane wraz z pakietem i umożliwiają zdalnemu punktowi VPN sprawdzenie integralności oryginalnego pakietu IP, potwierdzając, że nie został on zmodyfikowany po drodze. Oprócz danych pakietu IP AH uwierzytelnia również część swojego nagłówka.

    W trybie transportu AH osadza swój nagłówek po oryginalnym pakiecie IP.
    W trybie tunelu AH wstawia swój nagłówek po zewnętrznym (nowym) nagłówku IP i przed wewnętrznym (oryginalnym) nagłówkiem IP.

    ESP (Enkapsulacja ładunku zabezpieczającego)

    ESP jest używany do szyfrowania, uwierzytelniania lub obu w odniesieniu do pakietu IP.

    W trybie transportu ESP protokół wstawia swój nagłówek po oryginalnym nagłówku IP.
    W trybie tunelu ESP nagłówek znajduje się po zewnętrznym (nowym) nagłówku IP i przed wewnętrznym (oryginalnym).

    Dwie główne różnice między ESP i AH to:

    • ESP oprócz uwierzytelniania zapewnia również szyfrowanie (AH nie zapewnia tego)
    • ESP w trybie tunelu uwierzytelnia tylko oryginalny nagłówek IP (AH uwierzytelnia również zewnętrzny).

    Praca za NAT (przechodzenie NAT)
    Zaimplementowano osobną specyfikację wspierającą pracę za NAT. Jeśli punkt końcowy VPN obsługuje tę specyfikację, protokół IPsec obsługuje NAT, jednak istnieją pewne wymagania.
    Obsługa NAT składa się z dwóch części:

    • Na poziomie IKE urządzenia końcowe komunikują się ze sobą w zakresie obsługi, przechodzenia NAT oraz wersji obsługiwanej specyfikacji.
    • W warstwie ESP wygenerowany pakiet jest enkapsulowany w UDP.

    NAT Traversal jest używany tylko wtedy, gdy oba punkty końcowe go obsługują.
    Definicja NAT: Obaj partnerzy VPN wysyłają skróty swoich adresów IP wraz z portem UDP źródła negocjacji IKE. Informacje te są wykorzystywane przez odbiorcę do ustalenia, czy zmienił się źródłowy adres IP i/lub port. Jeśli te parametry nie zostały zmienione, ruch nie przechodzi przez NAT i mechanizm NAT Traversal nie jest potrzebny. Jeśli adres lub port został zmieniony, oznacza to, że między urządzeniami jest NAT.

    Gdy punkty końcowe ustalą, że przechodzenie NAT jest potrzebne, negocjacja IKE jest przenoszona z portu UDP 500 do portu 4500. Dzieje się tak, ponieważ niektóre urządzenia nieprawidłowo obsługują sesję IKE na porcie 500 podczas korzystania z NAT.
    Kolejny problem pojawia się, ponieważ protokół ESP jest protokołem warstwy transportowej i znajduje się bezpośrednio nad protokołem IP. Z tego powodu pojęcia portu TCP/UDP nie mają do niego zastosowania, co uniemożliwia połączenie się więcej niż jednego klienta z tą samą bramą przez NAT. Aby rozwiązać ten problem, ESP jest pakowany do datagramu UDP i wysyłany do portu 4500, tego samego portu, którego używa IKE, gdy włączona jest funkcja NAT Traversal.
    NAT Traversal jest wbudowany w protokoły, które go obsługują i działa po wyjęciu z pudełka.

    krótkie tło historyczne pojawienia się protokołu

    W 1994 roku Internet Architecture Board (IAB) opublikował raport dotyczący bezpieczeństwa architektury internetowej. W dokumencie tym opisano główne obszary zastosowań dodatkowych narzędzi bezpieczeństwa w Internecie, a mianowicie ochronę przed nieautoryzowanym monitorowaniem, spoofing pakietów oraz kontrolę przepływu danych. Wśród pierwszych i najważniejszych zidentyfikowanych zabezpieczeń była potrzeba opracowania koncepcji i podstawowych mechanizmów zapewniających integralność i poufność strumieni danych. Ponieważ zmiana podstawowych protokołów z rodziny TCP/IP spowodowałaby całkowitą przebudowę Internetu, postawiono zadanie zapewnienia bezpieczeństwa wymiany informacji w otwartych sieciach telekomunikacyjnych w oparciu o istniejące protokoły. W ten sposób zaczęto tworzyć specyfikację Secure IP, uzupełniającą protokoły IPv4 i IPv6.

    Architektura IPSec

    IP Security to zestaw protokołów zajmujących się szyfrowaniem, uwierzytelnianiem i bezpieczeństwem podczas transportu pakietów IP; obecnie ma prawie 20 propozycji standardów i 18 specyfikacji RFC.
    Specyfikacja bezpieczeństwa IP (znana dziś jako IPsec) jest opracowywana przez Grupę Roboczą ds. Protokołu Bezpieczeństwa IP IETF. Protokół IPsec pierwotnie składał się z 3 niezależnych od algorytmu podstawowych specyfikacji opublikowanych jako architektura zabezpieczeń IP, nagłówek uwierzytelniania (AH), dokumenty RFC dotyczące enkapsulacji danych (ESP) (RFC 1825, 1826 i 1827). Należy zauważyć, że w listopadzie 1998 roku Grupa Robocza IP Security Protocol zaproponowała nowe wersje tych specyfikacji, które są obecnie projektami norm, RFC2401 - RFC2412. Zauważ, że RFC1825-27 jest przestarzały od kilku lat i tak naprawdę nie jest używany. Ponadto istnieje kilka specyfikacji zależnych od algorytmów wykorzystujących protokoły MD5, SHA, DES.

    Rys. 1. Architektura IPSec

    Grupa Robocza ds. Protokołu Bezpieczeństwa IP opracowuje również protokoły do ​​zarządzania kluczowymi informacjami. Zadaniem tej grupy jest opracowanie Internet Key Management Protocol (IKMP), protokołu zarządzania kluczami warstwy aplikacji, który jest niezależny od używanych protokołów bezpieczeństwa. Obecnie badane są koncepcje zarządzania kluczami przy użyciu protokołu Internet Security Association and Key Management Protocol (ISAKMP) oraz protokołu Oakley Key Determination Protocol. Specyfikacja ISAKMP opisuje mechanizmy negocjowania atrybutów wykorzystywanych protokołów, podczas gdy protokół Oakley umożliwia instalowanie kluczy sesji na komputerach w Internecie. Wcześniej rozważano również możliwości wykorzystania mechanizmów zarządzania kluczami SKIP, ale obecnie takie możliwości praktycznie nigdzie nie są wykorzystywane. Nowe standardy zarządzania kluczowymi informacjami mogą obsługiwać podobne do Kerberos Centra dystrybucji kluczy. Protokoły zarządzania kluczami dla protokołu IPSec opartego na protokole Kerberos są obecnie rozwiązywane przez stosunkowo nową grupę roboczą Kerberized Internet Negotiation of Keys (KINK).
    Gwarancje integralności i poufności danych w specyfikacji IPsec są zapewniane poprzez zastosowanie odpowiednio mechanizmów uwierzytelniania i szyfrowania. Te z kolei opierają się na przedwstępnej umowie stron o wymianie informacji tzw. „kontekst bezpieczeństwa” – stosowane algorytmy kryptograficzne, algorytmy zarządzania kluczowymi informacjami i ich parametrami. Specyfikacja IPsec umożliwia stronom obsługę wymiany informacji o różnych protokołach i parametrach do uwierzytelniania i szyfrowania pakietów danych, a także różnych schematów dystrybucji kluczy. W tym przypadku wynikiem negocjacji kontekstu bezpieczeństwa jest ustalenie indeksu parametrów bezpieczeństwa (SPI), który jest wskaźnikiem na pewien element wewnętrznej struktury strony wymiany informacji, opisujący możliwe zestawy parametrów bezpieczeństwa .
    Zasadniczo IPSec, który stanie się integralną częścią IPv6, działa w warstwie trzeciej, czyli warstwie sieci. Dzięki temu przesyłane pakiety IP będą chronione w sposób przejrzysty dla aplikacji sieciowych i infrastruktury. W przeciwieństwie do protokołu SSL (Secure Socket Layer), który działa w czwartej (tj. transportowej) warstwie i jest ściślej związany z wyższymi warstwami modelu OSI, IPSec został zaprojektowany w celu zapewnienia niskiego poziomu bezpieczeństwa.

    Rys. 2. Model OSI/ISO

    Protokół IPSec dodaje nagłówek do danych IP, które są gotowe do wysłania przez VPN, aby zidentyfikować chronione pakiety. Pakiety te są enkapsulowane w innych pakietach IP przed wysłaniem przez Internet. IPSec obsługuje kilka typów szyfrowania, w tym Data Encryption Standard (DES) i Message Digest 5 (MD5).
    Aby ustanowić bezpieczne połączenie, obaj uczestnicy sesji muszą być w stanie szybko negocjować parametry bezpieczeństwa, takie jak algorytmy i klucze uwierzytelniania. Protokół IPSec obsługuje dwa typy schematów zarządzania kluczami, za pomocą których uczestnicy mogą negocjować parametry sesji. To podwójne wsparcie spowodowało w tamtym czasie pewne tarcia w Grupie Roboczej IETF.
    W obecnej wersji IP, IPv4, może być używany albo Internet Secure Association Key Management Protocol (ISAKMP) albo Simple Key Management for Internet Protocol. W nowszej wersji IP, IPv6, będziesz musiał użyć ISAKMP, obecnie znanego jako IKE, chociaż możliwość użycia SKIP nie jest wykluczona. Należy jednak pamiętać, że SKIP przez długi czas nie był uważany za kluczowego kandydata do zarządzania i został usunięty z listy możliwych kandydatów już w 1997 roku.

    Nagłówki AH i ESP

    uwierzytelniający nagłówek AH

    Nagłówek uwierzytelniania (AH) jest normalnym opcjonalnym nagłówkiem i zwykle znajduje się między głównym nagłówkiem pakietu IP a polem danych. Obecność AH w żaden sposób nie wpływa na proces przekazywania informacji warstwy transportowej i wyższych. Głównym i jedynym celem AH jest zapewnienie ochrony przed atakami związanymi z nieautoryzowanymi zmianami zawartości paczki, w tym przed podszywaniem się pod oryginalny adres warstwy sieciowej. Protokoły wyższego poziomu muszą zostać zmodyfikowane w celu weryfikacji autentyczności otrzymanych danych.
    Format AH jest dość prosty i składa się z 96-bitowego nagłówka oraz danych o zmiennej długości składających się z 32-bitowych słów. Nazwy pól dość wyraźnie odzwierciedlają ich zawartość: Next Header wskazuje na następny nagłówek, Payload Len reprezentuje długość pakietu, SPI jest wskaźnikiem do kontekstu bezpieczeństwa, a Sequence Number Field zawiera numer sekwencyjny pakietu.

    Rys. 3. Format nagłówka AH

    Numer sekwencyjny pakietu został wprowadzony w AH w 1997 roku jako część procesu rewizji specyfikacji IPsec. Wartość tego pola jest generowana przez nadawcę i służy do ochrony przed atakami związanymi z ponownym wykorzystaniem danych w procesie uwierzytelniania. Ponieważ Internet nie gwarantuje kolejności dostarczania pakietów, odbiorca musi przechowywać informacje o maksymalnej liczbie sekwencyjnej pakietu, który pomyślnie przeszedł uwierzytelnianie oraz o odebraniu określonej liczby pakietów zawierających poprzednie numery sekwencyjne (zwykle 64).
    W przeciwieństwie do algorytmów obliczania sumy kontrolnej stosowanych w protokołach przesyłania informacji przez komutowane linie komunikacyjne lub przez kanały sieci lokalnej i skupiających się na korygowaniu przypadkowych błędów w medium transmisyjnym, mechanizmy zapewniające integralność danych w otwartych sieciach telekomunikacyjnych muszą być zabezpieczone przed celowymi zmianami. Jednym z tych mechanizmów jest specjalne zastosowanie algorytmu MD5: w procesie generowania AH funkcja skrótu jest sekwencyjnie wyliczana z kombinacji samego pakietu i pewnego wcześniej uzgodnionego klucza, a następnie z kombinacji otrzymanego wyniku i przekształcony klucz. Ten mechanizm jest używany domyślnie, aby zapewnić wszystkim implementacjom IPv6 co najmniej jeden wspólny algorytm, który nie podlega ograniczeniom eksportu.

    enkapsulacja zaszyfrowanych danych ESP

    W przypadku enkapsulacji zaszyfrowanych danych, nagłówek ESP jest ostatnim z serii opcjonalnych nagłówków „widocznych” w pakiecie. Ponieważ głównym celem ESP jest zapewnienie poufności danych, różne rodzaje informacji mogą wymagać znacząco różnych algorytmów szyfrowania. W konsekwencji format ESP może ulegać znaczącym zmianom w zależności od zastosowanych algorytmów kryptograficznych. Można jednak wyróżnić następujące pola obowiązkowe: SPI, które wskazuje kontekst bezpieczeństwa, oraz Pole numeru sekwencyjnego, które zawiera numer sekwencyjny pakietu. Pole „Dane uwierzytelniające ESP” (suma kontrolna) jest opcjonalne w nagłówku ESP. Odbiorca pakietu ESP odszyfrowuje nagłówek ESP i wykorzystuje parametry i dane zastosowanego algorytmu szyfrowania do dekodowania informacji warstwy transportowej.

    Rys. 4. Format nagłówka ESP

    Istnieją dwa sposoby zastosowania ESP i AH (a także ich kombinacje) - transport i tunel:
    Tryb transportu służy do szyfrowania pola danych pakietu IP zawierającego protokoły warstwy transportowej (TCP, UDP, ICMP), które z kolei zawierają informacje o usługach aplikacji. Przykładem aplikacji dla środka transportu jest transmisja wiadomości e-mail. Wszystkie węzły pośrednie na trasie pakietu od źródła do miejsca docelowego używają tylko informacji warstwy sieci publicznej i ewentualnie niektórych opcjonalnych nagłówków pakietów (w IPv6). Wadą trybu transportu jest brak mechanizmów ukrywania konkretnego nadawcy i odbiorcy pakietu oraz możliwość analizy ruchu. Wynikiem takiej analizy mogą być informacje o wielkościach i kierunkach przepływu informacji, obszarach zainteresowań abonentów, lokalizacji menedżerów.
    Tryb tunelowy zakłada szyfrowanie całego pakietu, łącznie z nagłówkiem warstwy sieciowej. Tryb tunelowy jest używany, gdy konieczne jest ukrycie wymiany informacji między organizacją a światem zewnętrznym. Jednocześnie pola adresowe nagłówka warstwy sieciowej pakietu korzystającego z trybu tunelu są wypełniane przez zaporę sieciową organizacji i nie zawierają informacji o konkretnym nadawcy pakietu. Podczas przesyłania informacji ze świata zewnętrznego do sieci lokalnej organizacji adres sieciowy zapory jest używany jako adres docelowy. Po tym, jak zapora odszyfruje początkowy nagłówek warstwy sieci, pakiet jest przekazywany do odbiorcy.

    Stowarzyszenia Bezpieczeństwa

    Security Association (SA) to połączenie, które zapewnia usługi bezpieczeństwa dla ruchu, który przez nie przechodzi. Dwa komputery po każdej stronie SA przechowują tryb, protokół, algorytmy i klucze używane w SA. Każdy SA jest używany tylko w jednym kierunku. Do komunikacji dwukierunkowej wymagane są dwa SA. Każdy SA implementuje jeden tryb i protokół; tak więc, jeśli dwa protokoły mają być używane dla jednego pakietu (takie jak AH i ESP), wymagane są dwa SA.

    Polityka bezpieczeństwa

    Polityka bezpieczeństwa jest przechowywana w bazie danych SPD (Security Policy Database). SPD może określić jedną z trzech akcji dla pakietu danych: odrzucić pakiet, nie przetwarzać pakietu za pomocą IPSec, przetwarzać pakiet za pomocą IPSec. W tym drugim przypadku SPD wskazuje również, którego SA należy użyć (jeśli oczywiście odpowiednie SA zostało już utworzone) lub wskazuje z jakimi parametrami należy utworzyć nowe SA.
    SPD to bardzo elastyczny mechanizm kontrolny, który pozwala na bardzo dobrą kontrolę nad przetwarzaniem każdego pakietu. Pakiety są klasyfikowane według dużej liczby pól, a SPD może sprawdzić niektóre lub wszystkie pola, aby określić odpowiednią akcję. Może to spowodować, że cały ruch między dwoma komputerami będzie przenoszony przy użyciu pojedynczego SA lub oddzielne SA są używane dla każdej aplikacji, a nawet dla każdego połączenia TCP.

    Protokół ISAKMP / Oakley

    ISAKMP definiuje ogólną strukturę protokołów używanych do ustanawiania SA i wykonywania innych kluczowych funkcji zarządzania. ISAKMP obsługuje kilka obszarów interpretacji (DOI), z których jednym jest IPSec-DOI. ISAKMP nie definiuje pełnego protokołu, ale dostarcza „bloków konstrukcyjnych” dla różnych DOI i protokołów wymiany kluczy.
    Protokół Oakley jest protokołem określania klucza, który wykorzystuje algorytm zastępowania klucza Diffie-Hellmana. Protokół Oakley obsługuje Perfect Forward Secrecy (PFS). Obecność PFS oznacza, że ​​nie można odszyfrować całego ruchu, jeśli jakikolwiek klucz w systemie zostanie naruszony.

    Protokół IKE

    IKE jest domyślnym protokołem wymiany kluczy dla ISAKMP i jest obecnie jedynym. IKE znajduje się na szczycie ISAKMP i faktycznie tworzy zarówno ISAKMP SA, jak i IPSec SA. IKE obsługuje zestaw różnych podstawowych funkcji używanych w protokołach. Wśród nich jest funkcja skrótu i ​​funkcja pseudolosowa (PRF).
    Funkcja skrótu jest funkcją odporną na kolizje. Odporność na kolizje rozumiana jest jako fakt, że nie można znaleźć dwóch różnych komunikatów m1 i m2, takich, że H (m1) = H (m2), gdzie H jest funkcją mieszającą.
    Jeśli chodzi o funkcje pseudolosowe, obecnie zamiast specjalnych PRF w konstrukcji HMAC używana jest funkcja haszująca (HMAC to mechanizm uwierzytelniania wiadomości wykorzystujący funkcje haszujące). Aby zdefiniować HMAC, potrzebujemy kryptograficznej funkcji skrótu (oznacz ją jako H) i tajnego klucza K. Zakładamy, że H jest funkcją skrótu, w której dane są haszowane przy użyciu procedury kompresji stosowanej sekwencyjnie do sekwencji bloków danych. Przez B oznaczymy długość takich bloków w bajtach, a długość bloków otrzymanych w wyniku haszowania jako L (L

    ipad = bajt 0x36 powtórzony B razy;
    opad = bajt 0x5C powtórzony B razy.

    Aby obliczyć HMAC z danych „tekstowych”, należy wykonać następującą operację:

    H (K XOR opad, H (K XOR ipad, tekst))

    Z opisu wynika, że ​​IKE używa wartości HASH do uwierzytelnienia stron. Zauważ, że HASH w tym przypadku oznacza wyłącznie nazwę ładunku w ISAKMP i ta nazwa nie ma nic wspólnego z jej zawartością.

    ataki na AH, ESP i IKE

    Wszystkie rodzaje ataków na komponenty IPSec można podzielić na następujące grupy: ataki wykorzystujące ograniczone zasoby systemowe (typowym przykładem jest atak typu „odmowa usługi”, atak typu „odmowa usługi” lub atak DOS), ataki wykorzystujące funkcje i błędy konkretnej implementacji IPSec i wreszcie ataki oparte na słabościach samych protokołów AH i ESP. Ataki czysto kryptograficzne można zignorować - oba protokoły definiują pojęcie „transformacji”, gdzie cała kryptografia jest ukryta. Jeśli zastosowany kryptoalgorytm jest stabilny, a zdefiniowane nim przekształcenia nie wprowadzają dodatkowych słabości (nie zawsze tak jest, dlatego słuszniej jest wziąć pod uwagę stabilność całego systemu - Protocol-Transform-Algorithm), to z tego po stronie wszystko jest w porządku. Co pozostaje? Replay Attack - niwelowany za pomocą Sequence Number (w jednym przypadku to nie działa - przy korzystaniu z ESP bez uwierzytelnienia i bez AH). Co więcej, kolejność wykonywania czynności (najpierw szyfrowanie, potem uwierzytelnianie) gwarantuje szybkie odrzucanie „złych” pakietów (co więcej, według najnowszych badań w świecie kryptografii jest to najbezpieczniejsza kolejność działań, w niektórych odwrotna kolejność). , choć bardzo szczególne przypadki, mogą prowadzić do potencjalnych luk w zabezpieczeniach; na szczęście ani SSL, ani IKE, ani inne popularne protokoły z kolejnością działania „najpierw uwierzytelnij, zaszyfruj drugie” nie mają zastosowania w tych szczególnych przypadkach, a zatem nie nie mają tych otworów). Atak Denial-of-Service pozostaje.

    Jak wiecie, jest to atak, przed którym nie ma pełnej ochrony. Niemniej jednak szybkie odrzucanie złych pakietów i brak jakiejkolwiek zewnętrznej reakcji na nie (zgodnie z RFC) pozwala mniej lub bardziej radzić sobie z tym atakiem. Zasadniczo większość (jeśli nie wszystkie) znane ataki sieciowe (sniffing, spoofing, porwanie itp.) AH i ESP, jeśli są używane prawidłowo, są skutecznie odpierane. IKE jest trochę bardziej skomplikowane. Protokół jest bardzo złożony i trudny do analizy. Dodatkowo ze względu na literówki (we wzorze na obliczanie HASH_R) gdy został napisany i nie do końca udane rozwiązania (ten sam HASH_R i HASH_I) zawiera kilka potencjalnych „dziur” (w szczególności w pierwszej fazie nie wszystkie Payloady w wiadomości są uwierzytelnione), jednak nie są bardzo poważne i prowadzą co najwyżej do odmowy nawiązania połączenia.IKE jest mniej lub bardziej skutecznie zabezpieczone przed atakami typu replay, spoofing, sniffing, porwanie. W przypadku kryptografii sprawa jest nieco bardziej skomplikowana - nie jest wykonywana, jak w AH i ESP, osobno, ale jest zaimplementowana w samym protokole. Jednak przy użyciu trwałych algorytmów i prymitywów (PRF) nie powinno być problemu. W pewnym stopniu za słabość IPsec można uznać, że DES jest wskazywany jako jedyny obowiązkowy kryptoalgorytm w obecnych specyfikacjach (dotyczy to zarówno ESP, jak i IKE), którego 56 bitów klucza nie jest już uważane za wystarczające. Niemniej jednak jest to słabość czysto formalna - same specyfikacje są niezależne od algorytmu, a prawie wszyscy znani dostawcy już dawno zaimplementowali 3DES (a niektórzy już zaimplementowali AES). pozostaje odmowa usługi ...

    Ocena protokołu IPSec

    IPSec otrzymał mieszane recenzje od ekspertów. Z jednej strony należy zauważyć, że protokół IPSec jest najlepszym spośród wszystkich innych protokołów ochrony danych przesyłanych przez sieć wcześniej opracowanych (w tym opracowanym przez Microsoft PPTP). Z drugiej strony istnieje nadmierna złożoność i nadmiarowość protokołu. Na przykład Niels Ferguson i Bruce Schneier w swojej książce „A Cryptographic Evaluation of IPsec” zauważają, że znaleźli poważne problemy z bezpieczeństwem w prawie wszystkich głównych komponentach IPsec. Autorzy ci zwracają również uwagę, że pakiet protokołów wymaga znacznej pracy, aby zapewnić dobry poziom bezpieczeństwa.

    Rozważ architekturę rodziny protokołów IPSec. Celem tej rodziny protokołów jest zapewnienie różnych usług ochrony warstwy IP dla protokołów IPv4 i IPv6. Rozważ usługi bezpieczeństwa świadczone przez protokoły IPSec i wykorzystanie tych protokołów w sieciach TCP/IP.

    Gdy te usługi są poprawnie zainstalowane, nie zakłócają pracy użytkowników, hostów i innych komponentów internetowych, które nie korzystają z tych usług bezpieczeństwa w celu ochrony swojego ruchu. Usługi te są niezależne od algorytmu. Oznacza to możliwość dodawania nowych algorytmów kryptograficznych bez zmiany samych protokołów. Na przykład różne grupy użytkowników mogą korzystać z różnych zestawów algorytmów.

    Zdefiniowano standardowy zestaw domyślnych algorytmów, aby zapewnić interoperacyjność w całym Internecie. Użycie tych algorytmów w połączeniu z ochroną ruchu zapewnianą przez IPSec i protokoły zarządzania kluczami umożliwi projektantowi systemu i aplikacji zapewnienie wysokiego stopnia bezpieczeństwa kryptograficznego.

    IPSec można zaimplementować zarówno w systemie operacyjnym, jak iw routerze lub zaporze.

    IPSec zapewnia poufność, integralność danych, kontrola dostępu oraz uwierzytelnianie źródła danych dla datagramów IP. Usługi te są świadczone przez utrzymywanie stanu pomiędzy źródłem i miejscem docelowym datagramów IP. Ten stan definiuje określone usługi bezpieczeństwa na poziomie datagramu, algorytmy kryptograficzne używane do świadczonych usług oraz klucze dla tych algorytmów.

    Wymieńmy główne zadania protokołów IPSec:

    1. Zapewnienie ochrony kryptograficznej na poziomie IP dla protokołów IPv4 i IPv6, czyli zapewnienie poufności i integralności danych oraz integralności określonej sekwencji datagramów.
    2. Zapewnia przejrzystość ruchu IP, który nie wymaga użycia protokołów IPSec.
    3. Zapewnienie rozszerzalności, tj. możliwość dodawania nowych zestawów algorytmów bez zmiany samego protokołu.

    IPSec jest przeznaczony do bezpiecznej komunikacji przy użyciu kryptografii dla protokołów IPv4 i IPv6. Usługi bezpieczeństwa obejmują kontrola dostępu, uczciwość i poufność dane i ochronę przed atakami powtórek, co zapewnia gwarancja integralności określonej sekwencji datagramów. Usługi te są świadczone w warstwie IP, zapewniając bezpieczeństwo dla protokołów IP i wyższych warstw.

    IPSec obsługuje dwie formy integralności: integralność danych oraz integralność określonej sekwencji datagramu. Integralność danych wykrywa modyfikację określonego datagramu IP, niezależnie od sekwencji datagramu w strumieniu ruchu. Datagram Sequence Integrity to usługa przeciwdziałania odpowiedzi, która wykrywa otrzymanie zduplikowanych datagramów IP. Jest to w przeciwieństwie do integralności połączenia, dla której istnieją bardziej rygorystyczne wymagania dotyczące integralności ruchu, a mianowicie zdolność do wykrywania utraconych lub zmienionych wiadomości.

    Rozważ implementację protokołów IPSec, głównych komponentów systemu i ich interakcji w celu świadczenia usług bezpieczeństwa.

    Protokół IPSec działa na hoście (H) lub Security Gateway (SG), aby chronić ruch IP. Termin „brama bezpieczeństwa” jest używany w odniesieniu do routera, który implementuje protokoły IPsec.

    Ochrona opiera się na wymaganiach zdefiniowanych w bazie danych zasad bezpieczeństwa (SPD) ustawionej i utrzymywanej przez administratora. Ogólnie, pakiety są przetwarzane na jeden z trzech sposobów, w oparciu o nagłówek IP i informacje transportowe zapisane w SPD. Każdy pakiet jest albo odrzucany, przekazywany bez przetwarzania, albo przetwarzany zgodnie z rekordem SPD dla tego pakietu.

    Możliwe sposoby wdrożenia IPSec

    Istnieje kilka sposobów implementacji protokołu IPSec na hoście lub w połączeniu z routerem lub zaporą (w celu utworzenia bramy bezpieczeństwa).

    1. Integracja IPSec z określoną implementacją protokołu IP. Wymaga to dostępu do kodu źródłowego IP i odbywa się zarówno na hostach, jak i bramach bezpieczeństwa.
    2. Implementacje typu „bump-in-the-stack” (BITS), w których IPSec jest implementowany „na dole” istniejącej implementacji stosu protokołów IP, zagnieżdżając jej implementację między standardową implementacją protokołu IP a sterownikami sieci lokalnej. Dostęp do kodu źródłowego stosu IP nie jest w tym przypadku wymagany. To podejście jest zwykle implementowane na hostach, gdy IPSec jest zaimplementowany jako biblioteka podłączalna.
    3. Korzystanie z zewnętrznego procesora kryptograficznego. Jest to powszechnie określane jako implementacja „Bump-in-the-wire” (BITW). Takie implementacje mogą być używane zarówno na hostach, jak i bramach. Zazwyczaj urządzenia BITW są adresowalne IP.

    Protokoły bezpieczeństwa ruchu i koncepcja bezpiecznego skojarzenia

    Usługi ochrony ruchu świadczone przez IPSec są implementowane przy użyciu dwóch bezpiecznych protokołów ruchu: nagłówka uwierzytelniania (AH) i Encapsulating Security Payload (ESP).

    Aby chronić ruch w IPSec, zdefiniowano następujące protokoły:

    1. Protokół Encapsulating Security Payload (ESP) zapewnia poufność i integralność protokołów znajdujących się wyżej w stosie protokołów i może opcjonalnie zapewnić usługę anti-replay, tj. integralność pewnej sekwencji datagramów.
    2. Protokół Authentication Header (AH) zapewnia integralność protokołów znajdujących się wyżej w stosie protokołów oraz integralność poszczególnych pól nagłówka IP, które nie zmieniają się podczas transmisji od nadawcy do odbiorcy, dodatkowo usługa anti-replay może być dostarczone, tj integralność pewnej sekwencji datagramów. W IPSec v2 implementacja tego protokołu jest opcjonalna.
    3. Parametry tych protokołów są zdefiniowane w protokole dystrybucji kluczy Internet Key Exchange (IKE).

    Z ruchem zabezpieczonym przez IPSec kojarzy się koncepcja Security Association (SA). SA zawiera wszystkie informacje wymagane do wykonywania różnych usług związanych z bezpieczeństwem sieci.

    SA jest simpleksem (jednokierunkowym) połączenie logiczne utworzone między dwoma punktami końcowymi, które są zabezpieczone przy użyciu jednego z protokołów IPSec. ESP i AH przenoszą ruch przez SA. Cały ruch przenoszony przez SA jest przetwarzany zgodnie z polityką bezpieczeństwa ustawioną na końcach połączenia.

    Opiszmy różne aspekty zarządzania SA, zdefiniujmy możliwe sposoby zarządzania polityką bezpieczeństwa, jak obsłużyć ruch i zarządzać SA.

    SA określa parametry usług bezpieczeństwa, które są stosowane do ruchu. Zazwyczaj dwukierunkowe połączenie między dwoma hostami lub między dwiema bramami zabezpieczeń wymaga dwóch skojarzeń zabezpieczeń (po jednej dla każdego kierunku).

    Rozważymy SA tylko dla połączeń unicast.

    Zdefiniowano dwa tryby SA: tryb transportu i tryb tunelowania. Tryb transportu służy do tworzenia VPN między dwoma hostami. W IPv4 nagłówek protokołu bezpieczeństwa trybu transportu pojawia się bezpośrednio po nagłówku IP. W ESP tryb transportu SA zapewnia usługi bezpieczeństwa tylko dla protokołów wyższych warstw, a nie dla nagłówka IP. W przypadku AH ochrona obejmuje również poszczególne części nagłówka IP.

    Innym trybem SA jest tryb tunelowania. Jeżeli jednym z końców połączenia jest Security Gateway, to zgodnie ze standardami IPSec SA musi być ono wykonane w trybie tunelowym, ale wielu producentów dopuszcza w tym przypadku zarówno tryb tunelowy, jak i transportowy. Zauważ, że gdy ruch jest przeznaczony dla Security Gateway, na przykład w przypadku poleceń ping lub SNMP, Security Gateway jest traktowany jako host i jest zwykle używany tryb transportu... W razie potrzeby można zainstalować dwa hosty tryb tunelowy.

    W trybie tunelu dodawany jest zewnętrzny nagłówek IP z adresami bramek bezpieczeństwa. Wewnętrzny nagłówek IP wskazuje hosty docelowe. Nagłówek protokołu bezpieczeństwa znajduje się za zewnętrznym nagłówkiem IP i przed wewnętrznym nagłówkiem IP. Jeśli AH jest używany w trybie tunelu, części zewnętrznego nagłówka IP są bezpieczne, podobnie jak cały tunelowany pakiet IP, tj. wszystkie wewnętrzne nagłówki są chronione, podobnie jak wszystkie protokoły wyższych warstw. Jeśli używany jest ESP, chroniony jest tylko pakiet tunelowany, a nie zewnętrzny nagłówek.

    Podsumowując krótko:

    1. Gospodarz może obsługiwać oba rodzaje transportu, zarówno transport, jak i tunel.
    2. Brama bezpieczeństwa zwykle używa tylko trybu tunelowego. Jeśli obsługuje tryb transportu, to ten tryb jest zwykle używany tylko wtedy, gdy bezpieczna brama jest odbiorcą ruchu, na przykład do zarządzania siecią.

    Zestaw zaimplementowanych

    DZWON

    Są tacy, którzy czytają tę wiadomość przed tobą.
    Zapisz się, aby otrzymywać najnowsze artykuły.
    E-mail
    Nazwa
    Nazwisko
    Jak chcesz czytać Dzwon?
    Bez spamu