Klasyfikacja i analiza wybranych mechanizmów bezpieczeństwa w sieciach VPN - str. 3 - IP - IPSEC - ESP - TELEKOMUNIKACJA - VPN - SIECI - LAN - AH - PPTP - L2TP - PPP - TCP
Mouser Electronics Poland   Przedstawicielstwo Handlowe Paweł Rutkowski   PCBWay  

Energetyka, Automatyka przemysłowa, Elektrotechnika

Dodaj firmę Ogłoszenia Poleć znajomemu Dodaj artykuł Newsletter RSS
strona główna ARTYKUŁY Telekomunikacja Klasyfikacja i analiza wybranych mechanizmów bezpieczeństwa w sieciach VPN
drukuj stronę
poleć znajomemu

Klasyfikacja i analiza wybranych mechanizmów bezpieczeństwa w sieciach VPN

2.3. IPSec VPN


Zestaw protokołów i algorytmów wchodzących w skład IPSec (ang. Internet Protocol Security) służy zapewnieniu wysokiej jakości zabezpieczeń ruchu w sieciach IP. Dwa główne protokoły wykorzystywane w IPSec to AH (ang. Authentication Header) i ESP (ang. Encapsulating Security Payload) [9].

W modelu TCP/IP protokół IPSec znajduje się w warstwie sieci. Oznacza to, że IPSec może zabezpieczyć całość ruchu pomiędzy dwoma sieciami IP niezależnie od stosowanych w tych sieciach aplikacji. Ponadto IPSec, oprócz zapewnienia poufności danych, może ukryć nagłówki IP, w których znajdują się takie informacje jak adresy źródłowe i docelowe.

Z uwagi na fakt, że protokół IPSec potrafi zabezpieczyć wiele aplikacji jednocześnie, stał się bardzo popularny jako zabezpieczenie przesyłu danych przez sieci publiczne takie jak Internet. IPSec jest zbiorem wielu różnych standardów i w zależności od konkretnej konfiguracji i implementacji może zapewnić następujące typy zabezpieczeń:

  • poufność - dane mogą zostać zaszyfrowane, dzięki czemu nawet w wypadku przechwycenia ich przez osoby trzecie, odczytanie ich nie będzie możliwe. Odszyfrować dane może tylko osoba znająca tajny klucz.
  • integralność danych - IPSec może sprawdzić, czy dane nie zostały zmienione podczas przesyłu. Jest to możliwe dzięki dodaniu do wiadomości MAC (ang. Message Authentication Code), czyli pewnego kodu obliczonego w wyniku funkcji, której argumentami jest dana wiadomość oraz tajny klucz. Odbiorca wiadomości może ponownie wyznaczyć kod MAC i porównać go z oryginalnym w celu zweryfikowania poprawności przesłanych danych.
  • uwierzytelnianie - każdy punkt końcowy połączenia IPSec może zweryfikować tożsamość drugiego. Stanowi to zapewnienie, że komunikacja odbywa się z odpowiednią osobą lub urządzeniem.
  • zabezpieczenie przed powtórzeniami - dzięki zastosowaniu numerów sekwencyjnych, te same dane nie zostaną odebrane kilkakrotnie, a w przypadku odebrania w złej kolejności - zostaną poprawnie złożone w całość.
  • zabezpieczenie przed analizą ruchu - IPSec może ukryć takie informacje jak: kto z kim i jak często się komunikuje oraz ile danych zostało przesłanych. Mimo to, liczba przesłanych bitów może zostać policzona.
  • kontrola dostępu - IPSec może dokonać operacji filtrowania w celu zapewnienia dostępu do odpowiednich zasobów sieciowych dla wybranych użytkowników.


Przed rozpoczęciem sesji IPSec wymagane jest, aby strony uczestniczące w transmisji wiedziały, w jaki sposób będą zabezpieczać dane. Zestaw informacji, które należy ustalić to: protokół ESP czy AH oraz algorytmy i klucze kryptograficzne. Zestaw tych informacji określany jest jako SA (ang. Security Association). Każdy tunel VPN powinien posiadać unikalne SA do ochrony wysyłanych i odbieranych informacji, tzn. dla jednego tunelu IPSec wymagane są dwa SA). Urządzenie VPN posiada do tego celu bazę SA ponumerowaną za pomocą unikalnych identyfikatorów o nazwie SPI (ang. Security Parameters Index). Numery SPI przekazywane są w nagłówkach ESP i AH tak, aby urządzenie odbierające pakiety IPSec widziało, w jaki sposób zostały zabezpieczone. Bazy SA w urządzeniach VPN mogą być wpisywane ręcznie przez administratorów lub ustalane automatycznie z użyciem protokołu IKE (ang. Internet Key Exchange).

3.1. Authentication Header

Authentication Header jest jednym z protokołów IPSec, który może zapewnić integralność, uwierzytelnianie, zabezpieczenie przed powtórzeniami oraz kontrolę dostępu [8]. AH nie szyfruje danych. W pierwszych wersjach IPSec, AH zapewniał tylko szyfrowanie bez uwierzytelniania, dlatego też stosowano jednocześnie AH i ESP. W drugiej wersji IPSec dodano możliwość uwierzytelniania w ESP. W związku z tym, protokół AH stał się mniej istotny i coraz rzadziej się go używa [2].

Protokół Authentication Header ma dwa tryby pracy: tryb transportowy i tryb tunelowania. W trybie tunelowania AH tworzy nowy nagłówek IP dla każdego pakietu. Z kolei w trybie transportowym oryginalny nagłówek IP nie zostaje zmieniony. W momencie przesyłu danych w architekturze gateway-to-gateway lub host-to-gateway adresy źródłowe i docelowe IP zmieniane są na adres IP bramy VPN. Z uwagi na fakt, że protokół AH w trybie transportowym nie może zmieniać oryginalnego nagłówka IP - tryb ten nie jest kompatybilny z architekturami gateway-to-gateway i host-to-gateway. Z tego względu trybu transportowego używa się tylko w architekturze host-to-host.

Jak widać na rysunkach 7 i 8, protokół Authentication Header zapewnia integralność i uwierzytelnianie danych całego pakietu IP [4].






Rysunek 7. Pakiet AH w trybie tunelowania.








Rysunek 8. Pakiet AH w trybie transportowym.



3.2. Encapsulating Security Payload

Encapsulating Security Payload jest następnym protokołem wchodzącym w skład IPSec. W pierwszej wersji zapewniał tylko możliwość szyfrowania. W kolejnej wersji dodano funkcję uwierzytelniania i integralności danych.

Podobnie jak AH, protokół ESP ma dwa tryby pracy: tryb transportowy i tryb tunelowania. W trybie tunelowania dla każdego pakietu tworzony jest nowy nagłówek IP. Oryginalne adresy źródłowe i docelowe zostają zamienione na adresy punktów końcowych połączenia IPSec (punktem końcowym może być host lub brama VPN). Tryb tunelowania jest kompatybilny ze wszystkimi trzema rodzajami architekturami VPN. Pierwotny nagłówek IP jest zamknięty wewnątrz nowego pakietu i może zostać zaszyfrowany. Pozwala to ukryć prawdziwe adresy źródłowe i docelowe. Osoba monitorująca lub podsłuchująca ruch w sieci będzie widzieć tylko adresy punktów końcowych połączenia VPN. Przykładowy pakiet ESP w trybie tunelowania pokazano na rysunku 9 [10].






Rysunek 9 Pakiet ESP w trybie tunelowania.



Tryb transportowy jest rzadziej stosowany. W trybie tym, protokół ESP używa oryginalnego nagłówka IP. W związku z tym, proces szyfrowania, uwierzytelniania i zapewnienia integralności danych obejmuje tylko wewnętrzną część pakietu. Nagłówek zawierający m.in. adresy IP pozostaje jawny.

Tryb transportowy jest niekompatybilny z NAT. Suma kontrolna TCP obliczana jest na podstawie pól TCP oraz IP. Jeśli NAT zmienia adresy IP w pakiecie, istnieje potrzeba przeliczenia sumy kontrolnej TCP. NAT nie może tego dokonać, jeśli zawartość pakietu jest zaszyfrowana. Trybu transportowego używa się głównie w architekturze host-to-host [2]. Przykład pakietu ESP w tym trybie pokazano na rysunku 10 [10].






Rysunek 10. Pakiet ESP w trybie transportowym.




opracowano na podstawie:

    [2]Frankel S., Kent K., Lewkowski R. i inni: Guide to IPsec VPNs, Recommendations of the National Institute of Stadards and Technology, 2005,
    http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf
    [3]Hamzeh K., Pall G. i inni: Point-to-Point Tunneling Protocol (PPTP), Network Working Group, 1999, RFC 2637
    [4]Deal R.: The Complete Cisco VPN Configuration Guide, Cisco Press, Indianapolis 2006
    [5]Lau J., Townsley M., Goyret I.: Layer Two Tunneling Protocol –Version 3 (L2TPv3), Network Working Group, 2005, RFC 3931
    [6]Luo W.: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Network Working Group, 2006, RFC 4667
    [7]Frankel S., Hoffman P., Orebaugh A., Park R.: Guide to SSL VPNs (Draft), Recommendations of the National Institute of Standards and Technology, 2007,
    http://csrc.nist.gov/publications/drafts/SP800-113/Draft-SP800-113.pdf
    [8]Steinberg J., Speed T.: SSL VPN. Understanding, evaluating, and planning secure, web-based remote access, Packt Publishing Ltd., Birmingham 2005
    [9]Kent S., Atkinson R.: Security Architecture for the Internet Protocol, Network Working Group, 1998, RFC 2401
    [10]Kent S., Atkinson R.: IP Encapsulating Security Payload (ESP), Network Working Group, 1998, RFC 2406

follow us in feedly
Średnia ocena:
 
REKLAMA

Otrzymuj wiadomości z rynku elektrotechniki i informacje o nowościach produktowych bezpośrednio na swój adres e-mail.

Zapisz się
Administratorem danych osobowych jest Media Pakiet Sp. z o.o. z siedzibą w Białymstoku, adres: 15-617 Białystok ul. Nowosielska 50, @: biuro@elektroonline.pl. W Polityce Prywatności Administrator informuje o celu, okresie i podstawach prawnych przetwarzania danych osobowych, a także o prawach jakie przysługują osobom, których przetwarzane dane osobowe dotyczą, podmiotom którym Administrator może powierzyć do przetwarzania dane osobowe, oraz o zasadach zautomatyzowanego przetwarzania danych osobowych.
Komentarze (0)
Dodaj komentarz:  
Twój pseudonim: Zaloguj
Twój komentarz:
dodaj komentarz
REKLAMA
Nasze serwisy:
elektrykapradnietyka.com
przegladelektryczny.pl
rynekelektroniki.pl
automatykairobotyka.pl
budowainfo.pl