IPSec opiera się na kilku rozwiązania technologiczne i metod szyfrowania, ale ogólne działanie IPSec można podsumować jako następujące główne kroki:

    Krok 1. Rozpoczęcie procesu IPSec. Ruch, który musi być zaszyfrowany zgodnie z zasadami zabezpieczeń IPSec wynegocjowanymi przez strony IPSec, uruchamia proces IKE.

    Krok 2 Pierwsza faza IKE. Proces IKE uwierzytelnia strony IPSec i negocjuje parametry skojarzeń zabezpieczeń IKE, co tworzy bezpieczny kanał do negocjowania parametrów skojarzeń zabezpieczeń IPSec podczas drugiej fazy IKE.

    Krok 3 Druga faza IKE. Proces IKE negocjuje parametry skojarzeń zabezpieczeń IPSec i ustanawia odpowiednie skojarzenia zabezpieczeń IPSec dla komunikujących się urządzeń.

    Krok 4 Transfer danych. Komunikacja odbywa się między stronami komunikującymi się za pomocą protokołu IPSec, która opiera się na parametrach IPSec i kluczach przechowywanych w bazie danych skojarzeń zabezpieczeń.

    Krok 5 Zamykanie tunelu IPSec. Powiązania zabezpieczeń IPSec są kończone w wyniku ich usunięcia lub przekroczenia limitu czasu życia.

Tryby pracy IPsec

Istnieją dwa tryby działania protokołu IPSec: transport i tunel.

W trybie transportowym szyfrowana jest tylko informacyjna część pakietu IP. Nie ma to wpływu na routing, ponieważ nagłówek pakietu IP nie ulega zmianie. Tryb transportu jest zwykle używany do nawiązywania połączenia między hostami.

W trybie tunelowym cały pakiet IP jest szyfrowany. W celu przesłania go przez sieć umieszczany jest w kolejnym pakiecie IP. W ten sposób uzyskuje się bezpieczny tunel IP. Tryb tunelowy może być używany do łączenia zdalnych komputerów z wirtualną siecią prywatną lub do bezpiecznego przesyłania danych przez otwarte kanałyłącza (Internet) między bramami w celu połączenia różnych części wirtualnej sieci prywatnej.

Negocjacja transformacji IPSec

Podczas działania protokołu IKE negocjowane są przekształcenia IPSec (algorytmy zabezpieczeń IPSec). Transformacje IPSec i powiązane z nimi algorytmy szyfrowania są następujące:

    Protokół AH (Authentication Header - nagłówek uwierzytelniania). Protokół bezpieczeństwa zapewniający uwierzytelnianie i (opcjonalnie) usługę wykrywania powtórek. Protokół AH działa jak podpis cyfrowy i zapewnia, że ​​dane w pakiecie IP nie zostaną naruszone. Protokół AH nie zapewnia usługi szyfrowania i deszyfrowania danych. Ten protokół może być używany samodzielnie lub w połączeniu z protokołem ESP.

    Protokół ESP (Encapsulating Security Payload). Protokół bezpieczeństwa zapewniający prywatność i ochronę danych oraz opcjonalnie usługę uwierzytelniania i wykrywania powtórek. Produkty Cisco IPSec wykorzystują ESP do szyfrowania ładunku pakietów IP. Protokół ESP może być używany samodzielnie lub w połączeniu z AH.

    Standard DES (Data Encryption Standard - standard szyfrowania danych). Algorytm szyfrowania i deszyfrowania danych pakietowych. Algorytm DES jest używany zarówno w protokole IPSec, jak i IKE. Algorytm DES wykorzystuje 56-bitowy klucz, co oznacza nie tylko większe zużycie zasobów obliczeniowych, ale także silniejsze szyfrowanie. Algorytm DES jest algorytmem szyfrowania symetrycznego, który wymaga identycznych tajnych kluczy szyfrowania w urządzeniach każdej ze stron komunikacji IPSec. Algorytm Diffie-Hellmana służy do generowania kluczy symetrycznych. IKE i IPSec używają algorytmu DES do szyfrowania wiadomości.

    „Potrójny” DES (3DES). Wariant DES oparty na wykorzystaniu trzech iteracji standardowego DES z trzema różnymi kluczami, skutecznie potrajający siłę DES. Algorytm 3DES jest używany w IPSec do szyfrowania i odszyfrowywania strumienia danych. Algorytm ten wykorzystuje klucz 168-bitowy, co gwarantuje wysoką siłę szyfrowania. IKE i IPSec używają algorytmu 3DES do szyfrowania wiadomości.

    AES(Zaawansowany Standard Szyfrowania)). Protokół AES wykorzystuje algorytm szyfrowania Rine Dale4, który zapewnia znacznie silniejsze szyfrowanie. Wielu kryptografów uważa, że ​​AES w ogóle nie da się zhakować. AES jest obecnie federalnym standardem przetwarzania informacji. Jest zdefiniowany jako algorytm szyfrowania używany przez organizacje rządowe Stanów Zjednoczonych w celu ochrony poufnych, ale niesklasyfikowanych informacji. Problem z AES polega na tym, że wymaga dużej mocy obliczeniowej w porównaniu z podobnymi protokołami.

Konwersja IPSec wykorzystuje również dwa standardowe algorytmy mieszające w celu zapewnienia uwierzytelniania danych.

    Algorytm MD5 (Przegląd wiadomości 5). Algorytm mieszający używany do uwierzytelniania pakietów danych. Produkty Cisco używają wariantu kodu uwierzytelniania wiadomości HMAC (Hashed Message Authentication Code) obliczanego na poziomie MD5, który zapewnia dodatkowe bezpieczeństwo dzięki mieszaniu. Haszowanie to jednokierunkowy (tj. nieodwracalny) proces szyfrowania, który generuje dane wyjściowe o stałej długości dla wiadomości wejściowej o dowolnej długości. IKE, AH i ESP używają MD5 do uwierzytelniania danych.

    Algorytm SHA-1 (Secure Hash Algorithm-1 – bezpieczny algorytm haszowania 1). Algorytm mieszający używany do uwierzytelniania pakietów danych. Produkty Cisco używają wariantu kodu HMAC, który jest obliczany przy użyciu SHA-1. IKE, AH i ESP używają SHA-1 do uwierzytelniania danych.

W ramach protokołu IKE klucze symetryczne są tworzone przy użyciu algorytmu Diffie-Hellmana, który wykorzystuje DES, 3DES, MD5 i SHA. Protokół Diffie-Hellmana to protokół kryptograficzny oparty na wykorzystaniu kluczy publicznych. Umożliwia dwóm stronom uzgodnienie wspólnego tajnego klucza bez posiadania wystarczająco niezawodnego kanału komunikacji. Udostępnione klucze tajne są wymagane dla algorytmów DES i HMAC. Algorytm Diffie-Hellmana jest używany w IKE do generowania kluczy sesji. Grupy Diffie-Hellmana (DH) - określają „siłę” klucza szyfrowania, który jest używany w procedurze wymiany kluczy. Im wyższy numer grupy, tym „silniejszy” i bezpieczniejszy klucz. Należy jednak wziąć pod uwagę fakt, że wraz ze wzrostem numeru grupy DH wzrasta „siła” i poziom bezpieczeństwa klucza, ale jednocześnie wzrasta obciążenie procesora centralnego, ponieważ więcej czasu i zasobów są potrzebne do wygenerowania „silniejszego” klucza.

Urządzenia WatchGuard obsługują grupy DH 1, 2 i 5:

    Grupa DH 1: klucz 768-bitowy

    Grupa DH 2: 1024-bitowy klucz

    Grupa DH 5: klucz 1536-bitowy

Oba urządzenia, które komunikują się przez VPN, muszą korzystać z tej samej grupy DH. Grupa DH, która ma być używana przez urządzenia, jest wybierana podczas procedury IPSec fazy 1.

Omówiliśmy już koncepcję IPSec, w tym artykule omówimy IPSec bardziej szczegółowo.

Tak więc nazwa IPSec pochodzi od IP Security.
IPSec to zestaw protokołów i algorytmów używanych do ochrony pakietów IP na poziomie warstwy 3.

IPSec pozwala zagwarantować:
- Poufność - za pomocą szyfrowania
- Integralność danych - poprzez haszowanie i HMAC\
- Uwierzytelnianie – poprzez wykorzystanie podpisów cyfrowych lub klucza wstępnego (PSK).

Wymieniamy główne protokoły IPsec:
■ ESP i AH: Dwa główne protokoły używane w IPsec.
Hermetyzacja ładunku zabezpieczającego (ESP), może zrobić wszystko, co jest wymagane dla IPsec, oraz
Nagłówek uwierzytelniania (AH), może robić wszystko oprócz szyfrowania, szyfrowania danych, - dlatego najczęściej używany jest ESP.
■ Algorytmy szyfrowania zapewniające poufność: DES, 3DES, AES.
■Algorytmy haszujące dla integralności: MD5, SHA.
■ Algorytmy uwierzytelniania: Klucze współdzielone (PSK), podpisy cyfrowe RSA.
■ zarządzanie kluczami: Przykładem może być Diffie-Hellman (DH), który można wykorzystać do
dynamicznie generować klucze symetryczne do wykorzystania przez algorytmy symetryczne; PKI,
który obsługuje funkcję certyfikatów cyfrowych wydawanych przez zaufane urzędy certyfikacji; i Internet
Key Exchange (IKE), która zajmuje się za nas negocjacjami i zarządzaniem
IPsec do działania.

Dlaczego potrzebny jest protokół IPSec

Rozważ poniższą prostą topologię łączenia dwóch biur.

Musimy połączyć oba biura i zrealizować następujące cele:

  • Poufność- dostarczane poprzez szyfrowanie danych.
  • integralność danych- dostarczane przez hashowanie lub przez Zaszyfrowany kod uwierzytelniania wiadomości (HMAC), - metody zapewniające, że dane nie zostały zmienione.
  • Uwierzytelnianie- pod warunkiem przy użyciu klucze współdzielone (PSK), lub Podpisy cyfrowe. A podczas korzystania z HMAC uwierzytelnianie odbywa się przez cały czas.
  • ochrona przed powtórkami- wszystkie pakiety VPN są ponumerowane, co stanowi zabezpieczenie przed ich powtórzeniem.

Protokoły i porty IPSec

IKEv1 Faza 1 port UDP 500 IKEv1 Phase 1 używa UDP:500 do negocjacji.
NAT-T (NAT
przemierzanie) 		port UDP 4500 NAT Traversal jest używany przez urządzenia do przechodzenia przez NAT. Jeśli oba urządzenia łączą się ze sobą przez NAT: chcą umieścić fałszywy port UDP 4500
nagłówek na każdym pakiecie IPsec (przed nagłówkiem ESP) do
przetrwać urządzenie NAT, które w przeciwnym razie może mieć problem
śledzenie sesji ESP (protokół warstwy 4 50)
ESP Protokół warstwy 4
50 		Wszystkie pakiety IPSec są protokołem warstwy 4 ESP (protokół IP # 50), wszystkie dane są w nim zawarte. Zwykle używany jest ESP (a nie AH). W przypadku korzystania z NAT-T, nagłówek ESP jest zamykany przez drugi nagłówek UDP.
AH Protokół warstwy 4
51 		Pakiety AH to protokół warstwy 4 AH (protokół IP #51). AH nie obsługuje szyfrowania ładunku i dlatego jest rzadko używany.

Operacja IPSec

Aby zwiększyć bezpieczeństwo połączenia VPN, IPSec używa protokołu Internetowa wymiana kluczy (IKE).
IKE to udostępniony framework Stowarzyszenie bezpieczeństwa internetowego, jak również Protokół zarządzania kluczami (ISAKMP)

Tak więc w naszej konfiguracji oba routery będą działać jako Brama VPN lub rówieśnicy IPsec.

Załóżmy, że użytkownik w sieci 10.0.0.0 wysyła pakiet do sieci 172.16.0.0.
Ponieważ tunel nie został jeszcze utworzony, R1 rozpocznie negocjacje z drugim routerem, R2.

Krok 1: Negocjuj tunel IKEv1 fazy 1

Powstaje pierwszy krok między routerami Internet Key Exchange (IKE) tunel fazy 1.
Taki tunel nie jest przeznaczony do przesyłania danych użytkownika, ale jest używany do celów urzędowych, do ochrony ruchu związanego z zarządzaniem.

Podnoszenie tunelu IKE Phase 1 można wykonać w dwóch trybach:
-tryb główny
- tryb agresywny
Tryb główny wymaga wymiany dużej liczby pakietów, ale jest również uważany za bezpieczniejszy.

Aby podnieść tunel IKE fazy 1, należy wynegocjować następujące elementy:

  • Algorytm haszujący: Mogłoby być algorytm skrótu wiadomości 5 (MD5) lub Bezpieczny hasz
    Algorytm (SHA)    .
  • Algorytm szyfrowania: Standard szyfrowania cyfrowego (DES)(słaba, nie polecana), Potrójny DES (3DES)(nieco lepiej) lub Zaawansowany standard szyfrowania (AES)(zalecane) AES może używać kluczy o różnej długości: im dłuższe, tym bezpieczniejsze.
  • Grupa Diffie-Hellman (DH) do użycia: „Grupa” DH odnosi się do rozmiaru modułu (długość
    klucz), który ma być używany do wymiany kluczy DH. Grupa 1 używa 768 bitów, grupa 2 używa 1024 i
    grupa 5 używa 1536. Bezpieczniejsze grupy DH są częścią szyfrowania nowej generacji
    (NGE):
    - Grupa 14 lub 24: Zapewnia 2048-bitową DH
    - Grupy 15 i 16: Obsługa 3072-bitowej i 4096-bitowej DH
    - Grupa 19 lub 20: obsługuje odpowiednio 256-bitowe i 384-bitowe grupy ECDH

    Zadaniem DH jest wygenerowanie materiału klucza (kluczy symetrycznych). Te klucze będą używane do przesyłania danych.
    Samo DH jest asymetryczne, ale generuje klucze symetryczne.

  • Metoda Uwierzytelnienia: może być w formie klucz wstępny (PSK) lub Podpisy RSA
  • dożywotni: Żywotność tunelu IKE fazy 1. Jedyny parametr, który może się nie zgadzać. Im krótsza żywotność, tym częściej klucze będą wymieniane i tym bezpieczniej.

Krok 2: Uruchom wymianę kluczy DH

Gdy routery uzgodnią zasady IKE Phase 1, mogą rozpocząć proces wymiany kluczy DH. DH umożliwia dwóm urządzeniom, które nie mają jeszcze między sobą bezpiecznego połączenia, bezpieczną wymianę kluczy symetrycznych, które będą używane przez algorytmy symetryczne, takie jak AES.

Krok 3: Uwierzytelnij partnera

Ostatnią rzeczą, która zostanie wykonana w IKE Phase 1, jest wzajemne uwierzytelnianie hosta, które można wykonać na dwa sposoby (podpisy cyfrowe PSK lub RSA)
Jeśli uwierzytelnianie się powiedzie, tunel IKE Phase 1 jest uważany za włączony. Tunel jest dwukierunkowy.

Krok 4: Faza IKE 2

Po podniesieniu tunelu IKE fazy 1 routery zaczynają podnosić tunel IKE fazy 1.
Jak już wspomniano, tunel IKE fazy 1 jest wyłącznie tunelem usługowym, zarządzającym i cały ruch negocjacyjny przechodzi przez niego w celu podniesienia tunelu IKE fazy 2.
Tunel IKE Phase 2 wykorzystuje również algorytmy mieszające i szyfrujące.
Podniesienie tunelu IKE Phase 2 można wykonać w jednym z następujących trybów:
- szybki tryb

Tunel IKE Phase 2 w rzeczywistości składa się z dwóch tuneli jednokierunkowych, tj. możemy powiedzieć, że powstają:
Jeden tunel IKE Phase 1, który jest dwukierunkowy, używany do funkcji usługowych.
Oraz dwa tunele IKE Phase 2, które są jednokierunkowe i służą do szyfrowania użytecznego ruchu.
Wszystkie te tunele są również nazywane jako umowy o bezpieczeństwie między dwoma partnerami VPN lub stowarzyszenia bezpieczeństwa (SA).
Każdy SA ma swój unikalny numer.

Teraz, po podniesieniu tunelu IKE Phase 2, wszystkie pakiety wychodzące z zewnętrznych interfejsów będą szyfrowane.

Przykład ustawienia


Rozważmy przykład konfigurowania protokołu IPsec przy użyciu tego schematu jako przykładu.

  1. Skonfiguruj interesujący ruch
    Najpierw musimy zdefiniować ruch, który będziemy szyfrować.
    Router R1
    rozszerzona lista dostępu ip VPN-ACL zezwolenie ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

    Router R2

    rozszerzona lista dostępu ip VPN-ACL zezwolenie ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
  2. Konfiguracja fazy 1 (ISAKMP)
    Faza 1 uruchamia tunel używany do celów usługowych: wymiana współdzielonych tajnych kluczy, uwierzytelnianie, negocjowanie polityk bezpieczeństwa IKE itp.
    Można utworzyć wiele polityk isakmp z różnymi priorytetami.

    Router R1

    adres klucza kryptograficznego isakmp 200.200.200.1

    Router R2

    crypto isakmp policy 1 szyfrowanie 3des hash uwierzytelnianie md5 grupa pre-share 2
    adres klucza kryptograficznego isakmp 100.100.100.1

    Tutaj kluczem jest PSK (Preshared Key) używany przez routery do uwierzytelniania IKE Phase 1.

  3. Skonfiguruj fazę 2 (IPSEC)
    Celem tunelu IKE Phase 2 jest przesyłanie użytecznego ruchu między hostami dwóch biur.
    Parametry tunelu fazy 2 są pogrupowane w zestawy zwane zestawami przekształceń.
    Router R1
    crypto ipsec zestaw transformacji TRSET esp-3des esp-md5-hmac ! mapa kryptograficzna VPNMAP 10 ipsec-isakmp ustaw peer 200.200.200.1 ustaw transform-set TRSET dopasuj adres VPN-ACL ! interfejs FastEthernet0/0 mapa kryptograficzna VPNMAP

    Router R2

    crypto ipsec zestaw transformacji TRSET esp-3des esp-md5-hmac ! mapa kryptograficzna VPNMAP 10 ipsec-isakmp ustaw peer 100.100.100.1 ustaw transform-set TRSET dopasuj adres VPN-ACL ! interfejs FastEthernet0/0 mapa kryptograficzna VPNMAP

    Oba hosty używały zestawu kryptograficznego ipsec transform-set TRSET esp-3des esp-md5-hmac.
    Oznacza to, że 3des będzie używany do szyfrowania, a md5-hmac do uwierzytelniania.

    mapa kryptograficzna jest stosowana do interfejsu. Mapa kryptowalut śledzi ruch, który spełnia podane warunki. Nasza mapa kryptograficzna będzie działać z routerem o adresie 100.100.100.1, ustawionym przez ruch wewnętrzny ACL i zastosuje do tego ruchu transform-set TRSET.

Kontrola IPSec

Ogólnie lista przydatnych poleceń jest następująca:
pokaż politykę isakmp krypto
pokaż mapę krypto
pokaż krypto isakmp sa szczegóły
pokaż krypto ipsec sa
pokaż aktywne połączenia silnika kryptograficznego

W praktyce najbardziej przydatne są:


We współczesnym świecie wszędzie stosowane są różne technologie VPN. Niektóre (na przykład PPTP) są z czasem rozpoznawane jako niepewne i stopniowo wymierają, podczas gdy inne (OpenVPN), wręcz przeciwnie, nabierają rozpędu każdego roku. Jednak niekwestionowanym liderem i najbardziej rozpoznawalną technologią tworzenia i utrzymywania bezpiecznych kanałów prywatnych jest nadal IPsec VPN. Czasami podczas penttestów można znaleźć poważnie chronioną sieć, w której wystaje tylko 500. port UDP. Wszystko inne można zamknąć, załatać i niezawodnie przefiltrować. W takiej sytuacji może pojawić się myśl, że nie ma tu nic specjalnego do zrobienia. Ale nie zawsze tak jest. Ponadto powszechnie uważa się, że IPsec, nawet w domyślnych konfiguracjach, jest nie do zdobycia i zapewnia odpowiedni poziom bezpieczeństwa. To jest dokładnie sytuacja, której przyjrzymy się dzisiaj. Ale najpierw, aby jak najskuteczniej walczyć z IPsec, musisz dowiedzieć się, co to jest i jak działa. To właśnie zrobimy!

IPsec od wewnątrz

Zanim przejdziemy bezpośrednio do samego IPsec, dobrze byłoby pamiętać, jakie ogólnie istnieją typy VPN. Istnieje wiele klasyfikacji VPN, ale nie będziemy zagłębiać się w technologie sieciowe i brać pod uwagę najprostszą. Dlatego podzielimy VPN na dwa główne typy - połączenia VPN typu site-to-site (można je również nazwać stałymi) i VPN dostępu zdalnego (RA, są również tymczasowe).
Pierwszy typ służy do trwałego połączenia różnych wysp sieciowych, na przykład centrali z wieloma rozproszonymi oddziałami. Otóż ​​RA VPN to scenariusz, w którym klient łączy się na krótki czas, uzyskuje dostęp do określonych zasobów sieciowych i po zakończeniu pracy zostaje bezpiecznie odłączony.

Interesuje nas druga opcja, ponieważ w przypadku udanego ataku możliwe jest natychmiastowe uzyskanie dostępu do wewnętrznej sieci przedsiębiorstwa, co jest dość poważnym osiągnięciem dla pentestera. Z kolei IPsec umożliwia wdrożenie zarówno VPN typu site-to-site, jak i dostępu zdalnego. Czym jest ta technologia i z jakich komponentów się składa?

Warto zauważyć, że IPsec to nie jeden, ale cały zestaw różnych protokołów, które zapewniają przejrzystą i bezpieczną ochronę danych. Specyfiką IPsec jest to, że jest zaimplementowany w warstwie sieci, uzupełniając go w taki sposób, że wszystko dzieje się niepostrzeżenie dla kolejnych warstw. Główna trudność polega na tym, że w procesie nawiązywania połączenia dwóch uczestników bezpiecznego kanału musi uzgodnić dość dużą liczbę różnych parametrów. Mianowicie muszą się wzajemnie uwierzytelniać, generować i wymieniać klucze (i za pośrednictwem niezaufanego nośnika), a także uzgadniać, którymi protokołami szyfrować dane.

Z tego powodu IPsec składa się ze stosu protokołów, których obowiązkiem jest zapewnienie ustanowienia, obsługi i zarządzania bezpiecznym połączeniem. Cały proces nawiązywania połączenia składa się z dwóch faz: pierwsza faza służy do zapewnienia: bezpieczna wymiana Komunikaty ISAKMP są już w drugiej fazie. ISAKMP (Stowarzyszenie Bezpieczeństwa Internetu) i klucz Management Protocol to protokół używany do negocjowania i aktualizowania zasad zabezpieczeń (SA) między uczestnikami połączenia VPN. Te zasady określają tylko, który protokół ma być szyfrowany (AES lub 3DES) i za pomocą którego należy się uwierzytelniać (SHA lub MD5).

Dwie główne fazy IPsec

Dowiedzieliśmy się więc, że najpierw uczestnicy muszą uzgodnić, jakie mechanizmy zostaną wykorzystane do utworzenia bezpiecznego połączenia, więc teraz w grę wchodzi protokół IKE. IKE (Internet Key Exchange) służy do tworzenia IPsec SA (Security Association, te same zasady bezpieczeństwa), innymi słowy do koordynowania pracy uczestników bezpiecznego połączenia. Dzięki temu protokołowi uczestnicy uzgadniają, który algorytm szyfrowania zostanie użyty, który algorytm będzie używany do sprawdzania integralności i sposobu wzajemnego uwierzytelniania. Należy zauważyć, że obecnie istnieją dwie wersje protokołu: IKEv1 i IKEv2. Interesuje nas tylko IKEv1: pomimo faktu, że IETF (The Internet Engineering Task Force) wprowadził go po raz pierwszy w 1998 roku, nadal jest bardzo powszechnie używany, zwłaszcza w przypadku sieci VPN RA (patrz Rysunek 1).

Jeśli chodzi o IKEv2, jego pierwsze szkice powstały w 2005 roku, został on w pełni opisany w RFC 5996 (2010), a dopiero pod koniec ubiegłego roku został ogłoszony jako standard internetowy (RFC 7296). Możesz przeczytać więcej o różnicach między IKEv1 i IKEv2 na pasku bocznym. Zajmując się IKE, wracamy do faz IPsec. W pierwszej fazie uczestnicy wzajemnie się uwierzytelniają i uzgadniają parametry konfiguracji specjalnego połączenia, przeznaczonego wyłącznie do wymiany informacji o pożądanych algorytmach szyfrowania i innych szczegółach przyszłego tunelu IPsec. Parametry tego pierwszego tunelu (nazywanego również tunelem ISAKMP) są określane przez zasady ISAKMP. Przede wszystkim uzgadniane są skróty i algorytmy szyfrowania, potem następuje wymiana kluczy Diffie-Hellman (DH) i dopiero wtedy decyduje się kto jest kim. Oznacza to, że ostatnim krokiem jest proces uwierzytelniania, za pomocą klucza PSK lub RSA. A jeśli strony dojdą do porozumienia, powstaje tunel ISAKMP, przez który przechodzi już druga faza IKE.

W drugiej fazie uczestnicy, którzy już sobie ufają, uzgadniają, jak zbudować główny tunel do bezpośredniej transmisji danych. Oferują sobie nawzajem opcje określone w parametrze transform-set i jeśli się zgadzają, podnoszą główny tunel. Należy podkreślić, że po ustanowieniu tunel pomocniczy ISAKMP nigdzie nie prowadzi - służy do okresowej aktualizacji SA tunelu głównego. W rezultacie IPsec w pewien sposób ustanawia nie jeden, ale dwa całe tunele.

Jak przetwarzać dane

Teraz kilka słów o transform-set. W końcu konieczne jest w jakiś sposób zaszyfrowanie danych przechodzących przez tunel. Dlatego w typowej konfiguracji transform-set jest zestawem parametrów, które wyraźnie określają sposób przetwarzania pakietu. W związku z tym istnieją dwie opcje takiego przetwarzania danych - są to protokoły ESP i AH. ESP (Encapsulating Security Payload) zajmuje się bezpośrednio szyfrowaniem danych, a także może zapewnić kontrolę integralności danych. Z kolei AH (Authentication Header) odpowiada jedynie za uwierzytelnienie źródła i sprawdzenie integralności danych.

Na przykład polecenie crypto ipsec transform-set SET10 esp-aes poinformuje router, że zestaw transformacji o nazwie SET10 powinien działać tylko z protokołem ESP i szyfrowaniem AES. Patrząc w przyszłość powiem, że dalej będziemy używać routerów i zapór sieciowych Cisco jako celu. Właściwie wszystko jest mniej więcej jasne z ESP, jego zadaniem jest szyfrowanie i tym samym zapewnienie poufności, ale po co nam wtedy AH? AH zapewnia uwierzytelnianie danych, czyli potwierdza, że ​​te dane pochodzą od tego, z którym nawiązaliśmy połączenie i nie zostały po drodze zmienione. Zapewnia to, co czasami nazywa się ochroną przed powtórkami. W nowoczesnych sieciach AH praktycznie nie jest używany, wszędzie można znaleźć tylko ESP.

Parametry (tzw. SA) wybrane do szyfrowania informacji w tunelu IPsec mają okres istnienia, po którym muszą zostać wymienione. Domyślny okres istnienia IPsec SA to 86400 sekund, czyli 24 godziny.
W efekcie uczestnicy otrzymali zaszyfrowany tunel o parametrach, które im wszystkim odpowiadają i przesyłają tam strumienie danych do zaszyfrowania. Okresowo, zgodnie z czasem życia, aktualizowane są klucze szyfrujące dla głównego tunelu: uczestnicy ponownie łączą się przez tunel ISAKMP, przechodzą przez drugą fazę i ponownie ustanawiają SA.

Tryby IKEv1

Jako pierwsze przybliżenie przyjrzeliśmy się podstawowej mechanice działania protokołu IPsec, ale jest jeszcze kilka rzeczy, na których należy się skoncentrować. Pierwsza faza może między innymi działać w dwóch trybach: trybie głównym lub trybie agresywnym. Rozważaliśmy już pierwszą opcję powyżej, ale interesuje nas tryb agresywny. W tym trybie wykorzystywane są trzy komunikaty (zamiast sześciu w trybie głównym). Jednocześnie ten, kto inicjuje połączenie, podaje od razu wszystkie swoje dane – czego chce i co może zrobić, a także swoją część wymiany DH. Druga strona natychmiast uzupełnia swoją część pokolenia DH. W rezultacie w tym trybie w rzeczywistości są tylko dwa etapy. Oznacza to, że pierwsze dwa etapy z trybu głównego (koordynacja skrótów i wymiana DH) są niejako skompresowane w jeden. W rezultacie ten tryb jest znacznie bardziej niebezpieczny, ponieważ dużo Specyfikacja w postaci zwykłego tekstu. A co najważniejsze, brama VPN może wysłać skrót hasła, które jest używane do uwierzytelniania w pierwszej fazie (to hasło jest często nazywane kluczem wstępnym lub PSK).

Cóż, wszystkie kolejne szyfrowanie odbywa się jak zwykle bez zmian. Dlaczego więc nadal stosuje się ten reżim? Faktem jest, że jest znacznie szybszy, około dwa razy szybszy. Szczególnie interesujący dla pentestera jest fakt, że tryb agresywny jest bardzo często używany w RA IPsec VPN. Kolejna mała cecha RA IPsec VPN podczas korzystania z trybu agresywnego: gdy klient uzyskuje dostęp do serwera, wysyła mu identyfikator (nazwę grupy). Nazwa grupy tuneli (patrz Rysunek 2) to nazwa wpisu zawierającego zestaw zasad dla tego połączenia IPsec. To już jedna z cech charakterystycznych dla sprzętu Cisco.


Dwie fazy nie wystarczyły

Wydawałoby się, że okazuje się, a więc nie za dużo prosty obwód praca, ale w rzeczywistości jest to jeszcze trochę bardziej skomplikowane. Z biegiem czasu stało się jasne, że do zapewnienia bezpieczeństwa nie wystarczy tylko jeden PSK. Na przykład, jeśli stacja robocza pracownika zostanie naruszona, osoba atakująca może natychmiast uzyskać dostęp do całej sieci wewnętrznej przedsiębiorstwa. Dlatego faza 1.5 została opracowana między pierwszą a drugą fazą klasyczną. Nawiasem mówiąc, ta faza zwykle nie jest używana w standardowym połączeniu VPN typu lokacja-lokacja, ale jest używana podczas organizowania zdalnych połączeń VPN (w naszym przypadku). Ta faza zawiera dwa nowe rozszerzenia — Extended Authentication (XAUTH) i Mode-Configuration (MODECFG).

XAUTH to dodatkowe uwierzytelnianie użytkownika w ramach protokołu IKE. To uwierzytelnianie jest czasami określane jako drugi czynnik protokołu IPsec. Cóż, MODECFG służy do przenoszenia Dodatkowe informacje klienta, może to być adres IP, maska, serwer DNS i tak dalej. Widać, że ta faza po prostu uzupełnia te wcześniej rozważane, ale jej przydatność jest niezaprzeczalna.

IKEv2 kontra IKEv1

Oba protokoły działają na porcie UDP numer 500, ale są ze sobą niezgodne, sytuacja nie jest dozwolona dla IKEv1 na jednym końcu tunelu i IKEv2 na drugim. Oto główne różnice między drugą wersją a pierwszą:

  • W IKEv2 nie ma już takich koncepcji jak tryby agresywne czy główne.
  • W IKEv2 termin pierwsza faza jest zastąpiona przez IKE_SA_INIT (wymiana dwóch komunikatów zapewniająca negocjację protokołów szyfrowania/hashowania i generowanie kluczy DH), a druga faza przez IKE_AUTH (również dwie wiadomości implementujące faktyczne uwierzytelnianie).
  • Mode Config (co nazwano fazą 1.5 w IKEv1) jest teraz opisane bezpośrednio w specyfikacji protokołu i jest jej integralną częścią.
  • IKEv2 dodaje dodatkowy mechanizm ochrony przed atakami DoS. Jego istotą jest to, że przed odpowiedzią na każde żądanie w nawiązaniu bezpiecznego połączenia (IKE_SA_INIT) IKEv2, brama VPN wysyła plik cookie do źródła takiego żądania i czeka na odpowiedź. Jeśli źródło odpowiedziało - wszystko jest w porządku, możesz zacząć z nim generować DH. Jeśli źródło nie odpowiada (co ma miejsce w przypadku ataku DoS, ta technika jest podobna do TCP SYN powodzi), brama VPN po prostu o tym zapomina. Bez tego mechanizmu, przy każdym żądaniu od kogokolwiek, brama VPN próbowałaby wygenerować klucz DH (co jest procesem wymagającym dużych zasobów) i wkrótce napotkałaby problemy. W efekcie, ze względu na to, że wszystkie operacje wymagają teraz potwierdzenia z drugiej strony połączenia, niemożliwe jest stworzenie dużej liczby półotwartych sesji na zaatakowanym urządzeniu.

Idziemy do granicy

Po poznaniu w końcu specyfiki działania protokołu IPsec i jego komponentów, możemy przejść do najważniejszej rzeczy - do praktycznych ataków. Topologia będzie dość prosta i jednocześnie zbliżona do rzeczywistości (patrz rys. 3).


Pierwszym krokiem jest określenie obecności bramy IPsec VPN. Możesz to zrobić, wykonując skanowanie portów, ale jest tutaj mały zwrot. ISAKMP używa protokołu UDP, port 500, podczas gdy domyślne skanowanie za pomocą Nmapa dotyczy tylko portów TCP. Rezultatem będzie komunikat: Wszystkie 1000 przeskanowanych portów w 37.59.0.253 jest filtrowanych .

Wygląda na to, że wszystkie porty są filtrowane i nie ma otwartych portów. Ale po wykonaniu polecenia

Nmap -sU --top-ports=20 37.59.0.253 Uruchamiam Nmapa 6.47 (http://nmap.org) o 21.03.2015 r. 12:29 GMT Raport skanowania Nmapa dla 37.59.0.253 Host jest aktywny (opóźnienie 0,066s) . USŁUGA STANU PORTU 500/udp otwarta isakmp

upewniamy się, że tak nie jest i naprawdę mamy przed sobą urządzenie VPN.

Atakowanie pierwszej fazy

Teraz interesuje nas pierwsza faza, tryb agresywny i uwierzytelnianie z kluczem wstępnym (PSK). W tym scenariuszu należy pamiętać, że urządzenie sieci VPN lub responder wysyła zaszyfrowane PSK do inicjatora. Jednym z najbardziej znanych narzędzi do testowania protokołu IKE jest ike-scan, który jest zawarty w dystrybucji Kali Linux. Ike-scan umożliwia wysyłanie wiadomości IKE o różnych parametrach oraz, odpowiednio, dekodowanie i analizowanie pakietów odpowiedzi. Próba sondowania urządzenia docelowego:

[e-mail chroniony]:~# ike-scan -M -A 37.59.0.253 0 zwrócony uścisk dłoni; 0 zwrócone powiadomienie

Przełącznik -A wskazuje, że należy użyć trybu agresywnego, a -M wskazuje, że wyniki powinny być wyświetlane linia po linii (multilinia) w celu łatwiejszego odczytu. Widać, że nie uzyskano żadnego wyniku. Powodem jest to, że musisz podać ten sam identyfikator, nazwę grupy VPN. Oczywiście narzędzie ike-scan pozwala określić ten identyfikator jako jeden z jego parametrów. Ale ponieważ nadal nie jest nam znana, weźmy dowolną wartość, na przykład 0000.

[e-mail chroniony]:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Zwrócono uzgadnianie w trybie agresywnym

Tym razem widzimy, że otrzymaliśmy odpowiedź (patrz rys. 5) i otrzymaliśmy całkiem sporo przydatna informacja. Dość ważną informacją, jaką otrzymujemy, jest zestaw przekształceń. W naszym przypadku jest to "Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK".

Wszystkie te opcje można również określić dla narzędzia ike-scan za pomocą przełącznika --trans. Na przykład --trans=5,2,1,2 powie algorytm szyfrowania 3DES, haszowanie HMAC-SHA, metodę uwierzytelniania PSK i drugi typ grupy DH (1024-bitowy MODP). Możesz wyświetlić tabele mapowania wartości pod tym adresem. Dodajmy jeszcze jeden klucz (-P), aby bezpośrednio wyświetlić ładunek pakietu, a raczej hash PSK.

[e-mail chroniony]:~# ike-scan -M -A --id=0000 37.59.0.253 -P

Pokonywanie pierwszych trudności

Wydawałoby się, że hasz został odebrany i można spróbować go brutalnie, ale wszystko nie jest takie proste. Dawno, dawno temu, w 2005 roku, w niektórych urządzeniach Cisco istniała luka: urządzenia te zwracały hash tylko wtedy, gdy atakujący przesłał poprawną wartość identyfikatora. Teraz oczywiście jest prawie niemożliwe, aby spotkać się z takim sprzętem, a wartość zahaszowana jest zawsze wysyłana, niezależnie od tego, czy atakujący wysłał poprawną wartość identyfikatora, czy nie. Oczywiście nie ma sensu brutalować niewłaściwego skrótu. Dlatego pierwszym zadaniem jest określenie poprawnej wartości identyfikatora, aby uzyskać poprawny hash. Pomoże nam w tym niedawno odkryta luka. Chodzi o to, że jest niewielka różnica między odpowiedziami podczas początkowej wymiany wiadomości. Krótko mówiąc, przy użyciu prawidłowej nazwy grupy są cztery próby kontynuowania nawiązywania połączenia VPN plus dwa zaszyfrowane pakiety fazy 2. Natomiast w przypadku nieprawidłowego identyfikatora w odpowiedzi przychodzą tylko dwa pakiety. Jak widać, różnica jest dość znacząca, więc SpiderLabs (autor nie mniej interesującego narzędzia Responder) opracował najpierw PoC, a następnie narzędzie IKEForce, aby wykorzystać tę lukę.

Jaka jest siła IKE

Możesz zainstalować IKEForce w dowolnym katalogu, uruchamiając polecenie

Klon Gita https://github.com/SpiderLabs/ikeforce

Działa w dwóch głównych trybach - trybie obliczeniowym -e (wyliczanie) i trybie brute force -b (bruteforce). Do drugiego dojdziemy, gdy spojrzymy na ataki na drugi czynnik, ale teraz zajmiemy się pierwszym. Przed rozpoczęciem właściwego procesu określania identyfikatora należy ustawić dokładną wartość zestawu przekształceń. Zdefiniowaliśmy go już wcześniej, więc określimy go opcją -t 5 2 1 2 . W rezultacie proces wyszukiwania identyfikatora będzie wyglądał tak:

Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2

W efekcie dość szybko uzyskano prawidłową wartość ID (rys. 7). Minął pierwszy krok, możesz przejść dalej.

Zdobądź PSK

Teraz konieczne jest, używając prawidłowej nazwy grupy, aby zapisać hash PSK do pliku, można to zrobić za pomocą ike-scan:

Skanowanie Ike -M -A --id=vpn 37.59.0.253 -Pkey.psk

A teraz, gdy pobrano poprawną wartość identyfikatora i uzyskano poprawny hash PSK, możemy wreszcie rozpocząć brute force w trybie offline. Opcji takiej brutalnej siły jest wiele - jest to klasyczne narzędzie psk-crack i John the Ripper (z łatką jumbo), a nawet oclHashcat, który, jak wiadomo, pozwala wykorzystać moc GPU . Dla uproszczenia użyjemy psk-crack, który obsługuje zarówno bezpośrednie ataki typu brute force, jak i słownikowe:

Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk

Ale nawet pomyślne przywrócenie PSK (patrz rysunek 8) to tylko połowa sukcesu. Na tym etapie musimy pamiętać, że w następnej kolejności czeka na nas XAUTH i drugi czynnik IPsec VPN.

Radzenie sobie z drugim czynnikiem IPsec

Przypomnę więc, że XAUTH to dodatkowa ochrona, drugi czynnik uwierzytelniania i znajduje się w fazie 1.5. Istnieje kilka opcji dla XAUTH - jest to sprawdzenie za pomocą protokołu RADIUS i hasła jednorazowe(OTP) i zwykłą lokalną bazę użytkowników. Skoncentrujemy się na standardowej sytuacji, w której do sprawdzenia drugiego czynnika wykorzystywana jest lokalna baza użytkowników. Do niedawna nie było publicznie dostępnego narzędzia XAUTH brute force. Ale wraz z pojawieniem się IKEForce zadanie to otrzymało godne rozwiązanie. Brute Force XAUTH jest uruchamiany po prostu:

Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program uruchomiony w trybie Brute Force XAUTH [+]Dostarczono jednego użytkownika - brutalne wymuszanie hasła dla użytkownika: admin [*]Uwierzytelnianie XAUTH powiodło się! Nazwa użytkownika: admin Hasło: cisco

W tym przypadku wskazane są wszystkie wcześniej znalezione wartości: ID (klucz -i), przywrócony PSK (klucz -k) i domniemany login (klucz -u). IKEForce obsługuje zarówno wyszukiwanie brute-force przy logowaniu, jak i iterację na liście logowań, którą można określić za pomocą parametru -U. W przypadku możliwego zablokowania meczu dostępna jest opcja -s, która pozwala zmniejszyć prędkość brute force. Nawiasem mówiąc, narzędzie zawiera kilka dobrych słowników, szczególnie przydatnych do ustawiania wartości parametru ID.

Wejście do sieci wewnętrznej

Teraz, gdy mamy już wszystkie dane, pozostaje ostatni krok - faktyczna penetracja sieci lokalnej. Aby to zrobić, potrzebujemy pewnego rodzaju klienta VPN, których jest bardzo dużo. Ale w przypadku Kali możesz bez problemu skorzystać z już preinstalowanego - VPNC. Aby to zadziałało, musisz poprawić jeden plik konfiguracyjny - /etc/vpnc/vpn.conf . Jeśli go tam nie ma, musisz utworzyć i wypełnić szereg oczywistych parametrów:

Brama IPSec 37.59.0.253 Identyfikator IPSec vpn Sekret IPSec cisco123 Tryb uwierzytelniania IKE psk Nazwa użytkownika Xauth admin Hasło Xauth cisco

Tutaj widzimy, że wykorzystano absolutnie wszystkie dane znalezione w poprzednich krokach - wartość identyfikatora, PSK, loginu i hasła drugiego czynnika. Następnie samo połączenie następuje za pomocą jednego polecenia:

[e-mail chroniony]:~# vpnc vpn

Wyłączenie jest również dość proste:

[e-mail chroniony]:~# vpnc-rozłącz

Możesz sprawdzić, czy połączenie działa, używając polecenia ifconfig tun0.

Jak zbudować silną ochronę?

Ochrona przed omawianymi dzisiaj atakami powinna być kompleksowa: trzeba na czas instalować łatki, używać silnych kluczy wstępnych, które w miarę możliwości należy całkowicie zastąpić certyfikatami cyfrowymi. Polityka haseł i inne oczywiste elementy bezpieczeństwa informacji również odgrywają ważną rolę w zapewnieniu bezpieczeństwa. Należy również zauważyć, że sytuacja stopniowo się zmienia i z czasem pozostanie tylko IKEv2.

Jaki jest wynik

Szczegółowo omówiliśmy proces audytu RA IPsec VPN. Tak, oczywiście to zadanie nie jest trywialne. Jest wiele kroków, które należy podjąć, a trudności mogą czekać na każdy z nich, ale jeśli się powiedzie, wynik jest więcej niż imponujący. Uzyskanie dostępu do wewnętrznych zasobów sieci otwiera najszersze możliwości dalsze działanie. Dlatego osoby odpowiedzialne za ochronę granic sieci nie powinny polegać na gotowych domyślnych szablonach, ale dokładnie rozważyć każdą warstwę bezpieczeństwa. Cóż, dla tych, którzy przeprowadzają testy penetracyjne, wykryty port UDP 500 jest okazją do przeprowadzenia głębokiej analizy bezpieczeństwa IPsec VPN i być może uzyskania dobrych wyników.

0 Ten artykuł zawiera omówienie protokołu IPSEC (IP Security) i powiązanych protokołów IPSec dostępnych w produktach Cisco i używanych do tworzenia wirtualnych sieci prywatnych (VPN). W tym artykule zdefiniujemy czym jest IPSEC oraz jakie protokoły i algorytmy bezpieczeństwa leżą u podstaw IPSEC.

Wstęp

IP Security to zestaw protokołów zajmujących się szyfrowaniem, uwierzytelnianiem i bezpieczeństwem w transporcie pakietów IP; obecnie zawiera prawie 20 propozycji standardów i 18 specyfikacji RFC.

Produkty Cisco VPN wykorzystują pakiet protokołów IPSec, który jest obecnie standardem branżowym zapewniającym bogate możliwości VPN. IPSec zapewnia mechanizm bezpiecznej transmisji danych w sieciach IP, zapewniając poufność, integralność i ważność danych przesyłanych przez niezabezpieczone sieci, takie jak Internet. IPSec zapewnia następujące możliwości VPN w sieciach Cisco:

  • Prywatność danych. Nadawca danych IPSec ma możliwość szyfrowania pakietów przed przekazaniem ich przez sieć.
  • Integralność danych. Odbiorca danych IPSec ma możliwość uwierzytelniania komunikujących się z nim stron (urządzeń lub oprogramowania, na których rozpoczynają się i kończą tunele IPSec) oraz pakietów IPSec wysyłanych przez te strony, aby upewnić się, że dane nie zostały zmodyfikowane podczas przesyłania.
  • Uwierzytelnianie pochodzenia danych. Odbiornik IPSec ma możliwość uwierzytelnienia źródła otrzymywanych pakietów IPSec. Ta usługa zależy od usługi integralności danych.
  • Zagraj w ochronę. Odbiornik IPSec może wykrywać i odrzucać ponownie odtwarzane pakiety, zapobiegając ich podszywaniu się i atakom typu man-in-the-middle.

IPSec to oparty na standardach zestaw protokołów i algorytmów bezpieczeństwa. Technologia IPSec i powiązane protokoły bezpieczeństwa są zgodne z otwartymi standardami utrzymywanymi przez IETF (Internet Engineering Task Force) i opisanymi w specyfikacjach RFC i projektach IETF. IPSec działa w warstwie sieciowej, zapewniając bezpieczeństwo i uwierzytelnianie pakietów IP przesyłanych między urządzeniami (stronami) IPSec, takimi jak routery Cisco, zapory PIX, klienci i koncentratory Cisco VPN oraz wiele innych produktów obsługujących IPSec. Obsługa IPSec umożliwia skalowanie od najmniejszych do bardzo dużych sieci.

Stowarzyszenie Bezpieczeństwa (SA)

Protokół IPSec zapewnia standardowy sposób uwierzytelniania i szyfrowania komunikacji między komunikującymi się stronami. Aby zabezpieczyć komunikację, IPSec wykorzystuje standardowe algorytmy szyfrowania i uwierzytelniania (tj. formuły matematyczne) zwane tłumaczeniami. IPSec wykorzystuje otwarte standardy do negocjacji klucza szyfrowania i zarządzania połączeniami, aby umożliwić współdziałanie między stronami. Technologia IPSec zapewnia metody, które umożliwiają stronom IPSec „negocjowanie” uzgodnionego wykorzystania usług. IPSec używa skojarzeń zabezpieczeń do określenia parametrów do negocjacji.

Stowarzyszenie Obrony(Security Association - SA) to uzgodniona polityka lub metoda obsługi danych, które mają być wymieniane między dwoma urządzeniami komunikujących się stron. Jednym ze składników takiej polityki może być algorytm służący do szyfrowania danych. Obie strony mogą używać tego samego algorytmu zarówno do szyfrowania, jak i deszyfrowania. Prawidłowe parametry SA są przechowywane w bazie danych Security Association Database (SAD) obu stron.

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 (takie jak AH i ESP) muszą być użyte dla jednego pakietu, to wymagane są dwa SA.

IKE (Internet Key Exchange) to protokół hybrydowy, który zapewnia określone usługi dla IPSec, a mianowicie uwierzytelnianie stron IPSec, negocjowanie parametrów skojarzeń bezpieczeństwa IKE i IPSec oraz wybór klucza dla algorytmów szyfrowania używanych w ramach IPSec. Protokół IKE opiera się na protokołach Internet Security Association and Key Management Protocol (ISAKMP) oraz Oakley, które służą do sterowania generowaniem i przetwarzaniem kluczy szyfrowania używanych w przekształceniach IPSec. Protokół IKE jest również używany do tworzenia powiązań bezpieczeństwa między potencjalnymi stronami IPSec.
Zarówno protokół IKE, jak i IPSec używają skojarzeń zabezpieczeń do określania parametrów komunikacji.
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. Przez odporność na zderzenia rozumie się 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ą skrótu.

W odniesieniu do funkcji pseudolosowych, obecnie zamiast specjalnych PRF w projekcie HMAC stosowana jest funkcja haszująca (HMAC to mechanizm uwierzytelniania wiadomości wykorzystujący funkcje haszujące). Aby określić HMAC, potrzebujemy kryptograficznej funkcji skrótu (oznaczonej jako H) i tajnego klucza K. Zakładamy, że H jest funkcja skrótu, gdzie 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”, musisz wykonać następującą operację:

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

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

Infrastruktura IPSec

Sieci IPSec VPN można budować przy użyciu różnych urządzeń Cisco - routerów Cisco, CiscoSecure PIX Firewalls, oprogramowania klienckiego CiscoSecure VPN oraz koncentratorów Cisco VPN z serii 3000 i 5000. iOS, co zmniejsza złożoność rozwiązanie sieciowe i obniża całkowity koszt VPN z możliwością budowania wielopoziomowej ochrony świadczonych usług. Zapora PIX ma wysoką wydajność Urządzenie sieciowe, który może obsługiwać punkty końcowe tuneli, zapewniając im wysoką wydajność i piękny funkcjonalność zapora. Oprogramowanie Klient CiscoSecure VPN obsługuje najbardziej rygorystyczne wymagania dotyczące zdalnego dostępu VPN dla aplikacji handlu elektronicznego i dostępu mobilnego, oferując pełną implementację standardów IPSec i zapewniając niezawodną interoperacyjność między routerami Cisco i zaporami PIX Firewall.

Jak działa IPSec


IPSec opiera się na wielu rozwiązaniach technologicznych i metodach szyfrowania, ale działanie IPSec można podsumować w następujących głównych krokach:
  • Krok 1: Rozpocznij proces IPSec. Ruch, który musi być zaszyfrowany zgodnie z zasadami zabezpieczeń IPSec wynegocjowanymi przez strony IPSec, uruchamia proces IKE.
  • Krok 2 Faza IKE. Proces IKE uwierzytelnia strony IPSec i negocjuje parametry skojarzeń zabezpieczeń IKE, co tworzy bezpieczny kanał do negocjowania parametrów skojarzeń zabezpieczeń IPSec podczas drugiej fazy IKE.
  • Krok 3 Faza 2 IKE. Proces IKE negocjuje parametry skojarzeń zabezpieczeń IPSec i ustanawia odpowiednie skojarzenia zabezpieczeń IPSec dla komunikujących się urządzeń.
  • Krok 4. Transfer danych. Komunikacja odbywa się między stronami komunikującymi się za pomocą protokołu IPSec, która opiera się na parametrach IPSec i kluczach przechowywanych w bazie danych skojarzeń zabezpieczeń.
  • Krok 5: Zakończ tunel IPSec. Powiązania zabezpieczeń IPSec są kończone w wyniku ich usunięcia lub przekroczenia limitu czasu życia.
Poniższe sekcje opisują te kroki bardziej szczegółowo.

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

W 1994 roku Internet Architecture Board (IAB) opublikował raport „Internet Architectural Security”. W dokumencie tym opisano główne obszary zastosowania dodatkowych narzędzi bezpieczeństwa w Internecie, a mianowicie ochronę przed nieautoryzowanym monitorowaniem, spoofing pakietów oraz kontrolę przepływu danych. Wśród priorytetowych i najważniejszych środków ochronnych wskazano potrzebę opracowania koncepcji i podstawowych mechanizmów zapewniających integralność i poufność przepływów danych. Ponieważ zmiana podstawowych protokołów z rodziny TCP/IP spowodowałaby całkowitą przebudowę Internetu, zadaniem było zapewnienie 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 w transporcie pakietów IP; obecnie zawiera prawie 20 propozycji standardów i 18 specyfikacji RFC.
Specyfikacja bezpieczeństwa IP (znana dziś jako IPsec) jest opracowywana przez grupę roboczą protokołu bezpieczeństwa IP IETF. Początkowo protokół IPsec zawierał 3 niezależne od algorytmu specyfikacje podstawowe opublikowane jako RFC „Architektura bezpieczeństwa IP”, „Nagłówek uwierzytelniania (AH)”, „Encrypted Data Encapsulation (ESP)” (RFC1825, 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 obecnie mają status standardów wstępnych, są to RFC2401 - RFC2412. Zauważ, że RFC1825-27 jest uważany za przestarzały przez kilka lat i nie jest tak naprawdę używany. Ponadto istnieje kilka specyfikacji zależnych od algorytmów, które wykorzystują protokoły MD5, SHA, DES.

Rys.1. Architektura IPSec

Grupa Robocza ds. Protokołu Bezpieczeństwa IP opracowuje również protokoły 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 stosowanych protokołów bezpieczeństwa. Koncepcje zarządzania kluczami są obecnie rozważane przy użyciu specyfikacji 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, natomiast protokół Oakley umożliwia ustawianie 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. Tworzone standardy zarządzania informacjami kluczowymi będą prawdopodobnie obsługiwać Centra Dystrybucji Kluczy podobne do tych stosowanych w systemie Kerberos. Protokoły zarządzanie kluczami w przypadku protokołu IPSec opartego na protokole Kerberos pracuje obecnie nad nim stosunkowo nowa grupa robocza KINK (Kerberized Internet Negotiation of Keys).
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ępnym porozumieniu stron o tzw. wymianie informacji. „kontekst bezpieczeństwa” – stosowane algorytmy kryptograficzne, algorytmy zarządzania informacją kluczową i ich parametry. Specyfikacja IPsec umożliwia stronom wymianę informacji w celu obsługi różnych protokołów i parametrów uwierzytelniania i szyfrowania pakietów danych, a także różnych schematów dystrybucji kluczy. Jednocześnie 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.
W rzeczywistości IPSec, który stanie się częścią IPv6, działa w warstwie trzeciej, czyli w 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 powiązany z wyższymi warstwami modelu OSI, IPSec został zaprojektowany w celu zapewnienia niskiego poziomu bezpieczeństwa.

Rys.2. Model OSI/ISO

IPSec dodaje nagłówek do danych IP gotowych do wysłania przez VPN w celu identyfikacji chronionych pakietów. Przed przesłaniem przez Internet pakiety te są enkapsulowane w innych pakietach IP. 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 uzgodnić parametry bezpieczeństwa, takie jak algorytmy i klucze uwierzytelniania. Protokół IPSec obsługuje dwa typy schematów zarządzania kluczami, dzięki którym uczestnicy mogą negocjować parametry sesji. To podwójne wsparcie spowodowało w tamtym czasie pewne tarcia w Grupie Roboczej IETF.
W obecnej wersji protokołu IP, IPv4, może być używany albo Internet Secure Association Key Management Protocol (ISAKMP) albo Simple Key Management for Internet Protocol. W nowej wersji IP, IPv6, ISAKMP, teraz znany jako IKE, będzie musiał być używany, chociaż SKIP jest nadal możliwe. Należy jednak pamiętać, że SKIP nie jest już uważany za kluczowego kandydata do kierownictwa i został usunięty z listy możliwych kandydatów już w 1997 roku.

Nagłówki AH i ESP

Nagłówek uwierzytelniania 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 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 adres źródłowy. Warstwa sieci. Protokoły wyższego poziomu muszą zostać zmodyfikowane w celu przeprowadzenia weryfikacji autentyczności otrzymanych danych.
Format AH jest dość prosty i składa się z 96-bitowego nagłówka i danych o zmiennej długości 32-bitowych słów. Nazwy pól dość wyraźnie odzwierciedlają ich zawartość: Next Header wskazuje 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 do AH w 1997 roku podczas 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 procesu uwierzytelniania. Ponieważ Internet nie gwarantuje kolejności, w jakiej pakiety będą dostarczane, odbiorca musi przechowywać informację o maksymalnym numerze sekwencyjnym pakietu, który został pomyślnie uwierzytelniony, oraz o odebraniu określonej liczby pakietów zawierających poprzednie numery sekwencyjne (zwykle liczba ta jest 64).
W przeciwieństwie do algorytmów obliczania sumy kontrolnej stosowanych w protokołach przesyłania informacji po liniach komu- nikacyjnych wdzwanianych lub po kanałach LAN i nastawionych na korygowanie przypadkowych błędów w medium transmisyjnym, mechanizmy integralności danych w otwartych sieciach telekomunikacyjnych muszą posiadać zabezpieczenia przed ukierunkowane zmiany. Jednym z tych mechanizmów jest specjalne zastosowanie algorytmu MD5: podczas tworzenia AH funkcja skrótu jest sekwencyjnie wyliczana z kombinacji samego pakietu i pewnego wcześniej uzgodnionego klucza, a następnie z kombinacji wyniku i przekształconego klucz. Mechanizm ten jest stosowany domyślnie w celu zapewnienia wszystkim implementacjom protokołu IPv6 co najmniej jednego wspólnego algorytmu, który nie podlega ograniczeniom eksportu.

enkapsulacja zaszyfrowanych danych ESP

W przypadku enkapsulacji zaszyfrowanych danych, nagłówek ESP jest ostatnim z opcjonalnych nagłówków „widocznych” w pakiecie. Ponieważ głównym celem ESP jest zapewnienie poufności danych, różne rodzaje informacji mogą wymagać użycia znacząco różnych algorytmów szyfrowania. Dlatego format ESP może ulegać znacznym zmianom w zależności od zastosowanych algorytmów kryptograficznych. Można jednak rozróżnić następujące pola obowiązkowe: SPI wskazujący kontekst bezpieczeństwa oraz Pole numeru sekwencyjnego zawierające numer sekwencyjny pakietu. Pole „Dane uwierzytelniające ESP” (suma kontrolna) jest opcjonalne w nagłówku ESP. Odbiorca pakietu ESP odszyfrowuje nagłówek ESP i używa parametrów i danych 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 zastosowania środka transportu jest transmisja E-mail. Wszystkie węzły pośrednie na ścieżce pakietu od nadawcy do odbiorcy 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ści i kierunku przepływu informacji, obszarach zainteresowań subskrybentów, lokalizacji menedżerów.
Tryb tunelowy szyfruje cały pakiet, w tym nagłówek warstwy sieciowej. Tryb tunelowy jest używany, gdy konieczne jest ukrycie wymiany informacji organizacji ze światem zewnętrznym. Jednocześnie pola adresowe nagłówka pakietu na poziomie sieci w trybie 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 zostanie wysłany 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 (takie jak AH i ESP) muszą być użyte dla jednego pakietu, to wymagane są dwa SA.

Polityka bezpieczeństwa

Polityka bezpieczeństwa jest przechowywana w bazie danych SPD (Security Policy Database). SPD może określić jedno z trzech działań dla pakietu danych: odrzucić pakiet, nie przetwarzać pakietu za pomocą IPSec, przetwarzać pakiet za pomocą IPSec. W tym drugim przypadku SPD określa również, którego SA użyć (oczywiście zakładając, że odpowiednie SA zostało już utworzone) lub określa, z jakimi parametrami należy utworzyć nowe SA.
SPD to bardzo elastyczny mechanizm sterowania, który pozwala na bardzo dobre zarządzanie przetwarzanie 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 wysyłany przy użyciu pojedynczego SA lub oddzielne SA będą używane dla każdej aplikacji, a nawet dla każdego połączenia TCP.

Protokół ISAKMP/Oakley

Protokół ISAKMP definiuje ogólną strukturę protokołów używanych do ustanawiania SA i wykonywania innych kluczowych funkcji zarządzania. ISAKMP obsługuje kilka Domen Interpretacji (DOI), z których jedną 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 przy użyciu algorytmu podstawienia 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 zajmuje się faktycznym tworzeniem 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 mieszająca to funkcja odporna 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ą.
W odniesieniu do funkcji pseudolosowych, obecnie zamiast specjalnych PRF w projekcie HMAC stosowana jest funkcja haszująca (HMAC to mechanizm uwierzytelniania wiadomości wykorzystujący funkcje haszujące). Aby zdefiniować HMAC, potrzebujemy kryptograficznej funkcji mieszającej (oznaczonej jako H) i tajnego klucza K. Zakładamy, że H jest funkcją mieszającą, 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”, musisz wykonać następującą operację:

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

Z opisu wynika, że ​​IKE wykorzystuje wartości HASH do uwierzytelniania stron. Zauważ, że HASH w tym przypadku odnosi się wyłącznie do nazwy ładunku w ISAKMP i ta nazwa nie ma nic wspólnego z jego zawartością.

ataki na AH, ESP i IKE

Wszystkie typy ataków na komponenty IPSec można podzielić na następujące grupy: ataki wykorzystujące skończoność zasobów systemowych (typowym przykładem jest atak Denial of Service, Denial-of-service lub 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 odporny, a transformacja nim zdefiniowana nie wprowadza 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 nie działa - przy użyciu ESP bez uwierzytelnienia i bez AH). Co więcej, kolejność czynności (najpierw szyfrowanie, potem uwierzytelnianie) gwarantuje szybkie odrzucenie „złych” pakietów (co więcej, według najnowszych badań w świecie kryptografii, właśnie ta kolejność czynności jest najbezpieczniejsza, kolejność odwrotna). w niektórych, choć bardzo szczególnych przypadkach, może prowadzić do potencjalnych luk w zabezpieczeniach; na szczęście ani SSL, ani IKE, ani inne popularne protokoły z protokołem „najpierw uwierzytelnij, a następnie zaszyfruj” nie należą do tych szczególnych przypadków, a zatem nie mają te otwory). Pozostaje atak Denial-of-Service.

Jak wiecie, jest to atak, przed którym nie ma pełnej ochrony. Jednak szybkie odrzucanie złych pakietów i brak jakiejkolwiek zewnętrznej reakcji na nie (według RFC) sprawia, że ​​mniej lub bardziej dobrze radzi sobie z tym atakiem. Zasadniczo większość (jeśli nie wszystkie) znane ataki sieciowe (sniffing, spoofing, porwanie itp.) są skutecznie zwalczane przez AH i ESP, jeśli są używane prawidłowo. Z IKE sprawa jest nieco bardziej skomplikowana. Protokół jest bardzo złożony, trudny do analizy. Dodatkowo ze względu na literówki (we wzorze na obliczanie HASH_R) przy jego pisaniu oraz nie do końca udane rozwiązania (ten sam HASH_R i HASH_I) zawiera kilka potencjalnych „dziur” (w szczególności nie wszystkie Payloady w wiadomości są uwierzytelniane w w pierwszej fazie), jednak nie są one bardzo poważne i prowadzą co najwyżej do odmowy nawiązania połączenia.IKE jest mniej lub bardziej skutecznie chronione przed atakami typu replay, spoofing, sniffing, porwanie. W przypadku kryptografii sprawa jest nieco bardziej skomplikowana - nie jest renderowana osobno, jak w AH i ESP, ale jest zaimplementowana w samym protokole. Jednak przy użyciu trwałych algorytmów i prymitywów (PRF) nie powinno być problemów. W pewnym stopniu za słabość IPsec można uznać, że DES jest wskazywany jako jedyny obowiązkowy algorytm kryptograficzny do implementacji w obecnych specyfikacjach (dotyczy to zarówno ESP, jak i IKE), którego 56 bitów klucza nie jest już brane pod uwagę wystarczający. Niemniej jednak jest to czysto formalna słabość - same specyfikacje są niezależne od algorytmu, a prawie wszyscy znani dostawcy od dawna implementują 3DES (a niektórzy już zaimplementowali AES). najbardziej „niebezpieczny” atak.

Ocena protokołu IPSec

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