Az IPSec számos dologra támaszkodik technológiai megoldásokés titkosítási módszerek, de az IPSec általános működése a következő fő lépésekben foglalható össze:

1. lépés. Az IPSec folyamat indítása. Az IPSec-felek által megbeszélt IPSec biztonsági szabályzat szerint titkosítandó forgalom elindítja az IKE folyamatot.

2. lépés Az IKE első fázisa. Az IKE-folyamat hitelesíti az IPSec-feleket és egyezteti az IKE biztonsági társítási paramétereit, ami biztonságos csatornát hoz létre az IPSec biztonsági társítási paraméterek egyeztetéséhez az IKE második fázisában.

3. lépés Az IKE második fázisa. Az IKE folyamat egyezteti az IPSec biztonsági társítási paramétereket, és létrehozza a megfelelő IPSec biztonsági társításokat a kommunikáló fél eszközei számára.

4. lépés Adatátvitel. A kommunikáció az IPSec-et kommunikáló felek között zajlik, amely a biztonsági társítási adatbázisban tárolt IPSec-paramétereken és kulcsokon alapul.

5. lépés IPSec alagút lezárása. Az IPSec biztonsági társítások vagy törlésük eredményeként, vagy azért, mert túllépték élettartamuk korlátját, megszűnnek.

IPsec üzemmódok

Az IPSecnek két működési módja van: szállítás és alagút.

Szállítási módban az IP-csomagnak csak az informatív része van titkosítva. Az útválasztást ez nem érinti, mert az IP-csomag fejléce nem változik. A szállítási módot általában a gazdagépek közötti kapcsolat létrehozására használják.

Alagút módban a teljes IP-csomag titkosítva van. Ahhoz, hogy a hálózaton keresztül továbbítható legyen, egy másik IP-csomagba kerül. Így egy biztonságos IP-alagút jön létre. Az alagút mód használható távoli számítógépek virtuális magánhálózathoz való csatlakoztatására vagy adatok biztonságos átvitelére csatornák megnyitása kapcsolatok (internet) az átjárók között a virtuális magánhálózat különböző részeinek összekapcsolására.

IPSec transzformációs egyeztetés

Az IKE protokoll működése során az IPSec transzformációk (IPSec biztonsági algoritmusok) egyeztetése történik. Az IPSec transzformációk és a hozzájuk tartozó titkosítási algoritmusok a következők:

AH protokoll (Authentication Header – hitelesítési fejléc). Biztonsági protokoll, amely hitelesítést és (opcionálisan) visszajátszás-észlelési szolgáltatást biztosít. Az AH protokoll digitális aláírásként működik, és biztosítja, hogy az IP-csomagban lévő adatok ne legyenek manipulálva. Az AH protokoll nem nyújt adattitkosítási és visszafejtési szolgáltatást. Ez a protokoll használható önmagában vagy az ESP protokollal együtt.

ESP (Encapsulating Security Payload) protokoll. Biztonsági protokoll, amely magánélet- és adatvédelmet, valamint opcionálisan hitelesítési és visszajátszás-észlelési szolgáltatást biztosít. A Cisco IPSec-kompatibilis termékek ESP-t használnak az IP-csomagok hasznos terhelésének titkosításához. Az ESP protokoll használható önmagában vagy az AH-val együtt.

DES szabvány (Data Encription Standard – adattitkosítási szabvány). Csomagadat titkosítási és visszafejtési algoritmus. A DES algoritmust mind az IPSec, mind az IKE használja. A DES algoritmus 56 bites kulcsot használ, ami nemcsak nagyobb számítási erőforrás-felhasználást, hanem erősebb titkosítást is jelent. A DES algoritmus egy szimmetrikus titkosítási algoritmus, amely azonos titkos titkosítási kulcsokat igényel az egyes IPSec-kommunikációs felek eszközeiben. A Diffie-Hellman algoritmust használják szimmetrikus kulcsok generálására. Az IKE és az IPSec a DES algoritmust használja az üzenetek titkosításához.

"Triple" DES (3DES). A DES egy változata, amely a szabványos DES három iterációján alapul három különböző kulccsal, gyakorlatilag megháromszorozva a DES erejét. A 3DES algoritmust az IPSec-en belül használják az adatfolyamok titkosítására és visszafejtésére. Ez az algoritmus 168 bites kulcsot használ, amely magas titkosítási erősséget garantál. Az IKE és az IPSec a 3DES algoritmust használja az üzenetek titkosításához.

AES(fejlett titkosítási szabvány)). Az AES protokoll a Rine Dale4 titkosítási algoritmust használja, amely sokkal erősebb titkosítást biztosít. Sok kriptográfus úgy véli, hogy az AES-t egyáltalán nem lehet feltörni. Az AES ma a szövetségi információfeldolgozási szabvány. Ez egy titkosítási algoritmus, amelyet az Egyesült Államok kormányzati szervezetei használnak érzékeny, de nem minősített információk védelmére. Az AES problémája az, hogy sok feldolgozási teljesítményt igényel a hasonló protokollokhoz képest.

Az IPSec konverzió két szabványos kivonatolási algoritmust is használ az adathitelesítés biztosítására.

MD5 algoritmus (5. üzenetkivonat). Az adatcsomagok hitelesítésére használt kivonatoló algoritmus. A Cisco termékek az üzenet-hitelesítési kód MD5-számítású HMAC-változatát használják, amely további biztonságot nyújt a kivonatoláson keresztül. A kivonatolás egy egyirányú (azaz visszafordíthatatlan) titkosítási folyamat, amely fix hosszúságú kimenetet állít elő egy tetszőleges hosszúságú bemeneti üzenethez. Az IKE, az AH és az ESP az MD5-öt használja az adathitelesítéshez.

SHA-1 algoritmus (Secure Hash Algorithm-1 – 1. biztonságos kivonatolási algoritmus). Az adatcsomagok hitelesítésére használt kivonatoló algoritmus. A Cisco termékek a HMAC kód egy változatát használják, amelyet az SHA-1 segítségével számítanak ki. Az IKE, az AH és az ESP SHA-1-et használ az adatok hitelesítésére.

Az IKE protokollon belül a szimmetrikus kulcsok a Diffie-Hellman algoritmussal jönnek létre, amely a DES-t, 3DES-t, MD5-öt és SHA-t használja. A Diffie-Hellman protokoll nyilvános kulcsok használatán alapuló kriptográfiai protokoll. Lehetővé teszi, hogy két fél megállapodjon egy megosztott titkos kulcsban anélkül, hogy kellően megbízható kommunikációs csatornája lenne. Megosztott titkok szükségesek a DES és HMAC algoritmusokhoz. Az IKE-n belül a Diffie-Hellman algoritmust használják a munkamenetkulcsok generálására. Diffie-Hellman (DH) csoportok – meghatározzák a kulcscsere-eljárásban használt titkosítási kulcs "erősségét". Minél magasabb a csoportszám, annál "erősebb" és biztonságosabb a kulcs. Figyelembe kell venni azonban azt a tényt, hogy a DH csoport számának növekedésével a kulcs „ereje” és biztonsági szintje nő, ugyanakkor a központi processzor terhelése nő, mivel több idő és erőforrás. szükségesek egy „erősebb” kulcs létrehozásához.

A WatchGuard eszközök támogatják az 1., 2. és 5. DH csoportot:

DH csoport 1: 768 bites kulcs

DH csoport 2: 1024 bites kulcs

DH csoport 5: 1536 bites kulcs

Mindkét VPN-en keresztül kommunikáló eszköznek ugyanazt a DH-csoportot kell használnia. Az eszközök által használandó DH csoport az IPSec Phase 1 eljárás során kerül kiválasztásra.

Az IPSec fogalmát már tárgyaltuk, ebben a cikkben az IPSec-et fogjuk részletesebben megvizsgálni.

Tehát az IPSec név az IP Security szóból származik.
Az IPSec olyan protokollok és algoritmusok halmaza, amelyek az IP-csomagok védelmére szolgálnak a Layer3 szintjén.

Az IPSec garantálja:
- Titoktartás - titkosítás használata
- Adatintegritás - kivonatoláson és HMAC-en keresztül\
- Hitelesítés – digitális aláírások vagy előre megosztott kulcs (PSK) használatával.

Felsoroljuk a fő IPsec protokollokat:
■ ESP és AH: Az IPsecben használt két fő protokoll.
Encapsulating Security Payload (ESP), mindent meg tud tenni, ami az IPsechez szükséges, és
Hitelesítési fejléc (AH), mindenre képes, kivéve a titkosítást, az adatok titkosítását, - ezért az ESP-t használják leggyakrabban.
■ Titkosító algoritmusok a titoktartás érdekében: DES, 3DES, AES.
■Kivonatolási algoritmusok az integritás érdekében: MD5, SHA.
■ Hitelesítési algoritmusok: Előre megosztott kulcsok (PSK), RSA digitális aláírások.
■ kulcskezelés: Példa erre a Diffie-Hellman (DH), amelyhez használható
szimmetrikus algoritmusok által használt szimmetrikus kulcsok dinamikus generálása; PKI,
amely támogatja a megbízható CA-k által kibocsátott digitális tanúsítványok funkcióját; és az Internet
Kulcscsere (IKE), amely sok tárgyalást és kezelést végez helyettünk
IPsec működéséhez.

Miért van szükség az IPSec-re?

Tekintsük a következő egyszerű topológiát két iroda összekapcsolására.

Össze kell kötnünk a két irodát, és a következő célokat kell teljesítenünk:

• Titoktartás- adattitkosítással biztosított.
• adatintegritás- kivonatoláson keresztül vagy keresztül Kivonatolt üzenet hitelesítési kód (HMAC), - módszerek annak biztosítására, hogy az adatok nem változtak.
• Hitelesítés- felhasználásával biztosított előre megosztott kulcsok (PSK), vagy digitális aláírások. HMAC használatakor pedig a hitelesítés mindig megtörténik.
• visszajátszás elleni védelem- minden VPN-csomag számozott, ami védelmet jelent az ismétlődésük ellen.

IPSec protokollok és portok

IKEv1 1. fázis	UDP 500-as port	Az IKEv1 Phase 1 UDP:500-at használ az egyeztetéshez.
NAT-T (NAT átjárás)	4500-as UDP port	A NAT-bejárást az eszközök használják a NAT bejárására. Ha mindkét eszköz NAT-on keresztül csatlakozik egymáshoz: hamis 4500-as UDP-portot akarnak behelyezni fejléc minden IPsec-csomagon (az ESP fejléc előtt). túlélni egy NAT-eszközt, amely egyébként problémát okozhat ESP-munkamenet nyomon követése (4. réteg 50. protokoll)
ESP	Layer 4 protokoll 50	Minden IPSec-csomag az ESP 4-es rétegbeli protokollja (IP Protocol #50), minden adat benne van. Általában az ESP-t (és nem az AH-t) használják. NAT-T használata esetén az ESP fejlécet a második UDP fejléc zárja.
AH	Layer 4 protokoll 51	Az AH-csomagok az AH 4. rétegbeli protokollja (IP Protokoll #51). Az AH nem támogatja a hasznos adatok titkosítását, ezért ritkán használják.

IPSec működés

A biztonságos VPN-kapcsolat létrehozásához az IPSec a protokollt használja Internetes kulcscsere (IKE).
Az IKE egy keretrendszer Internet Security Association, szintén Kulcskezelési protokoll (ISAKMP)

Tehát a mi konfigurációnkban mindkét útválasztó úgy fog működni, mint VPN-átjáró vagy IPsec társak.

Tegyük fel, hogy egy felhasználó a 10.0.0.0 hálózaton csomagot küld a 172.16.0.0 hálózatnak.
Mivel az alagút még nem jött létre, az R1 tárgyalásokat kezdeményez a második útválasztóval, az R2-vel.

1. lépés: Tárgyaljon az IKEv1 Phase 1 alagútról

Az első lépés a routerek között emelkedik Internetes kulcscsere (IKE) 1. fázisú alagút.
Egy ilyen alagút nem a felhasználói adatok továbbítására szolgál, hanem hivatalos célokra, a menedzsment forgalom védelmére szolgál.

Az IKE 1. fázisú alagút megemelése két módban történhet:
- fő mód
- agresszív mód
A fő mód nagyszámú csomag cseréjét igényli, de biztonságosabbnak is tekinthető.

Az IKE 1. fázisú alagút emeléséhez a következő elemeket kell egyeztetni:

• Hash algoritmus: Lehet, hogy üzenet kivonat 5 algoritmus (MD5) vagy Biztonságos hash
  Algoritmus (SHA).
• Titkosító algoritmus: Digitális titkosítási szabvány (DES)(gyenge, nem ajánlott), Tripla DES (3DES)(kicsit jobb) ill Fejlett titkosítási szabvány (AES)(ajánlott) Az AES különböző hosszúságú kulcsokat használhat: minél hosszabb, annál biztonságosabb.
• Diffie-Hellman (DH) csoport használható: A DH „csoport” a modulus méretére vonatkozik (hossza
  a kulcs) a DH kulcscseréhez használható. Az 1. csoport 768 bitet, a 2. csoport 1024 bitet használ, és
  Az 5. csoport az 1536-ot használja. A biztonságosabb DH csoportok a következő generációs titkosítás részét képezik
  (NGE):
  - 14. vagy 24. csoport: 2048 bites DH-t biztosít
  - 15. és 16. csoport: 3072 bites és 4096 bites DH támogatás
  - 19. vagy 20. csoport: Támogatja a 256 bites, illetve a 384 bites ECDH csoportokat

  A DH feladata kulcsanyag (szimmetrikus kulcsok) előállítása. Ezeket a kulcsokat az adatok átvitelére fogják használni.
  A DH maga aszimmetrikus, de szimmetrikus kulcsokat generál.

• Hitelesítési módszer: formában lehet előre megosztott kulcs (PSK) vagy RSA aláírások
• élettartam: IKE 1. fázisú alagút élettartama. Az egyetlen paraméter, amely nem feltétlenül egyezik. Minél rövidebb az élettartam, annál gyakrabban cserélik a kulcsokat, és annál biztonságosabb.

2. lépés: Futtassa a DH kulcscserét

Miután az útválasztók megállapodtak az IKE 1. fázisú szabályzatában, megkezdhetik a DH kulcscsere folyamatát. A DH lehetővé teszi két olyan eszköz számára, amelyek még nem rendelkeznek biztonságos kapcsolattal közöttük, hogy biztonságosan kicseréljék a szimmetrikus kulcsokat, amelyeket szimmetrikus algoritmusok, például AES használnak.

3. lépés: A Peer hitelesítése

Az utolsó dolog, amit az IKE 1. fázisában megtesznek, a kölcsönös gazdagép-hitelesítés, amely kétféleképpen történhet (PSK vagy RSA digitális aláírás)
Ha a hitelesítés sikeres, a rendszer az IKE 1. fázisú alagútját veszi figyelembe. Az alagút kétirányú.

4. lépés: IKE 2. fázis

Miután az IKE 1. fázis alagútja felemelkedett, az útválasztók elkezdik emelni az IKE 1. fázis alagútját.
Ahogy már említettük, az IKE 1. fázis alagútja pusztán szolgáltatási, felügyeleti alagút, és minden tárgyalási forgalom áthalad rajta, hogy felemelje az IKE 2. fázisú alagútját.
Az IKE Phase 2 tunnel kivonatolási és titkosítási algoritmusokat is használ.
Az IKE 2. fázisú alagút megemelése a következő módok egyikében történhet:
- gyors mód

Az IKE Phase 2 alagútja valójában két egyirányú alagútból áll, i.e. azt mondhatjuk, hogy létrejöttek:
Egy IKE Phase 1 alagút, amely kétirányú, és szolgáltatási funkciókhoz használható.
És két IKE Phase 2 alagút, amelyek egyirányúak, és amelyek a hasznos forgalom titkosítására szolgálnak.
Mindezeket az alagutakat más néven is hívják biztonsági megállapodások a két VPN-társ között vagy biztonsági egyesületek (SA).
Minden SA saját egyedi számmal rendelkezik.

Most, miután az IKE Phase 2 alagútját felemelték, a külső interfészekből kijövő összes csomag titkosítva lesz.

Bemutató példa

Tekintsen egy példát az IPsec konfigurálására ezzel a sémával.

1. Érdekes forgalom konfigurálása
   Először is meg kell határoznunk a titkosítandó forgalmat.
   Router R1

   ip hozzáférési lista kiterjesztett VPN-ACL engedély ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

   Router R2

   ip hozzáférési lista kiterjesztett VPN-ACL engedély ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

2. 1. fázis konfigurálása (ISAKMP)
   Az 1. fázis egy szolgáltatási célokra használt alagutat hoz létre: megosztott titkos kulcsok cseréje, hitelesítés, IKE biztonsági szabályzatok egyeztetése stb.
   Több isakmp házirend is létrehozható különböző prioritásokkal.

   Router R1

   crypto isakmp kulcs titkos kulcs címe 200.200.200.1

   Router R2

   crypto isakmp policy 1 titkosítás 3des hash md5 hitelesítés előzetes megosztási csoport 2

   crypto isakmp kulcs titkos kulcs címe 100.100.100.1

   Itt a kulcs a PSK (Preshared Key), amelyet az útválasztók használnak az IKE 1. fázisú hitelesítéshez.

3. 2. fázis konfigurálása (IPSEC)
   Az IKE Phase 2 Tunnel célja a hasznos forgalom átvitele két iroda hostjai között.
   A Phase 2 Tunnel paraméterei transzformációs halmazokba vannak csoportosítva.
   Router R1

   crypto ipsec transform-set TRSET esp-3des esp-md5-hmac ! crypto map VPNMAP 10 ipsec-isakmp set peer 200.200.200.1 set transform-set TRSET match address VPN-ACL ! interfész FastEthernet0/0 titkosítási térkép VPNMAP

   Router R2

   crypto ipsec transform-set TRSET esp-3des esp-md5-hmac ! crypto map VPNMAP 10 ipsec-isakmp set peer 100.100.100.1 set transform-set TRSET match address VPN-ACL ! interfész FastEthernet0/0 titkosítási térkép VPNMAP

   Mindkét gazdagép a TRSET esp-3des esp-md5-hmac titkosítási ipsec transzformációs készletet használta.
   Ez azt jelenti, hogy a titkosításhoz a 3des, a hitelesítéshez pedig az md5-hmac lesz használva.

   titkosítási térkép kerül alkalmazásra az interfészen. A kriptotérkép az adott feltételeknek megfelelő forgalmat követi nyomon. A kriptográfiai térképünk egy 100.100.100.1 címû útválasztóval fog mûködni, amelyet az ACL belsõ forgalma állított be, és a transzformációs beállítású TRSET-et alkalmazza erre a forgalomra.

IPSec ellenőrzés

Általában a hasznos parancsok listája a következő:
crypto isakmp szabályzat megjelenítése
kriptográfiai térkép megjelenítése
mutasd meg a crypto isakmp részleteit
mutasd meg a crypto ipsec sa
aktív kriptomotor-kapcsolatok megjelenítése

A gyakorlatban a következők a leghasznosabbak:

A modern világban mindenhol különféle VPN-technológiákat használnak. Néhányat (például a PPTP-t) bizonytalannak ismernek el az idő múlásával, és fokozatosan elhalnak, míg mások (OpenVPN) éppen ellenkezőleg, évről évre lendületet kapnak. A biztonságos privát csatornák létrehozásának és fenntartásának vitathatatlan vezető és legismertebb technológiája azonban továbbra is az IPsec VPN. Néha penteszteléskor komolyan védett hálózatot találhat, amelyből csak az 500. UDP port áll ki. Minden más zárható, foltozható és megbízhatóan szűrhető. Ilyen helyzetben felmerülhet a gondolat, hogy nincs itt semmi különös. De ez nem mindig van így. Emellett széles körben elterjedt az a vélemény, hogy az IPsec még alapértelmezett konfigurációkban is bevehetetlen, és megfelelő szintű biztonságot nyújt. Pontosan ezt a helyzetet fogjuk ma megvizsgálni. De először az IPsec elleni küzdelem érdekében a lehető leghatékonyabban ki kell találnia, hogy mi az, és hogyan működik. Ezt fogjuk tenni!

IPsec belülről

Mielőtt közvetlenül magához az IPsec-hez fordulna, jó lenne emlékezni arra, hogy általában milyen típusú VPN-ek léteznek. Sok VPN-besorolás létezik, de nem merülünk el mélyen a hálózati technológiákban, hanem a legegyszerűbbet választjuk. Ezért a VPN-t két fő típusra osztjuk - helyek közötti VPN-kapcsolatokra (ezeket állandónak is nevezhetjük) és távoli hozzáférésű VPN-re (RA, ezek is ideiglenesek).
Az első típus különféle hálózati szigetek tartós összekapcsolására szolgál, például egy központi iroda sok szétszórt fiókkal. Nos, az RA VPN egy olyan forgatókönyv, amikor egy kliens rövid ideig csatlakozik, hozzáfér bizonyos hálózati erőforrásokhoz, és a munka befejezése után biztonságosan megszakad.

Minket a második lehetőség fog érdekelni, hiszen egy sikeres támadás esetén azonnal hozzá lehet jutni a vállalkozás belső hálózatához, ami egy pentester számára elég komoly teljesítmény. Az IPsec viszont lehetővé teszi mind a helyek közötti, mind a távoli hozzáférésű VPN megvalósítását. Mi ez a technológia és milyen összetevőkből áll?

Érdemes megjegyezni, hogy az IPsec nem egy, hanem különböző protokollok egész halmaza, amelyek átlátható és biztonságos adatvédelmet biztosítanak. Az IPsec sajátossága, hogy a hálózati rétegben valósul meg, kiegészítve azt oly módon, hogy minden észrevétlenül történjen a következő rétegekben. A fő nehézség abban rejlik, hogy a kapcsolat létrehozása során egy biztonságos csatorna két résztvevőjének meglehetősen sok különböző paraméterben kell megegyeznie. Ugyanis hitelesíteniük kell egymást, kulcsokat kell generálniuk és kicserélniük (és nem megbízható médiumon keresztül), valamint meg kell állapodniuk abban is, hogy milyen protokollokkal titkosítják az adatokat.

Ez az oka annak, hogy az IPsec egy csomó protokollból áll, amelyek feladata a biztonságos kapcsolat létrehozása, működtetése és kezelése. A teljes kapcsolatépítési folyamat két szakaszból áll: az első fázis a biztosítására szolgál biztonságos csere Az ISAKMP üzenetek már a második fázisban vannak. ISAKMP (Internet Security Association) és Kulcs A Management Protocol egy protokoll, amelyet a VPN-kapcsolat résztvevői közötti biztonsági szabályzatok (SA) egyeztetésére és frissítésére használnak. Ezek a házirendek csak azt határozzák meg, hogy melyik protokollal kell titkosítani (AES vagy 3DES), és melyikkel kell hitelesíteni (SHA vagy MD5).

Az IPsec két fő fázisa

Így rájöttünk, hogy a résztvevőknek először meg kell állapodniuk abban, hogy milyen mechanizmusok segítségével hoznak létre biztonságos kapcsolatot, így most az IKE protokoll lép működésbe. Az IKE (Internet Key Exchange) az IPsec SA (Security Association, ugyanazok a biztonsági szabályzatok) létrehozására szolgál, más szóval a biztonságos kapcsolat résztvevőinek munkájának koordinálására. Ezen a protokollon keresztül a résztvevők megállapodnak abban, hogy melyik titkosítási algoritmust használják, melyik algoritmussal ellenőrzik az integritást és hogyan hitelesítik egymást. Meg kell jegyezni, hogy ma a protokollnak két verziója létezik: IKEv1 és IKEv2. Minket csak az IKEv1 fog érdekelni: annak ellenére, hogy az IETF (The Internet Engineering Task Force) először 1998-ban vezette be, még mindig nagyon elterjedt, különösen RA VPN-eknél (lásd 1. ábra).

Ami az IKEv2-t illeti, 2005-ben készültek az első vázlatok, az RFC 5996-ban (2010) teljes körűen leírták, és csak tavaly év végén jelentették be internetes szabványnak (RFC 7296). Az IKEv1 és az IKEv2 közötti különbségekről az oldalsávban olvashat bővebben. Miután foglalkoztunk az IKE-vel, visszatérünk az IPsec fázisaihoz. Az első fázisban a résztvevők hitelesítik egymást, és megállapodnak a paraméterekben egy speciális kapcsolat létrehozásához, amely csak a kívánt titkosítási algoritmusokról és a jövőbeni IPsec alagút egyéb részleteiről való információcserét szolgálja. Ennek az első alagútnak (ISAKMP alagútnak is nevezik) paramétereit az ISAKMP házirend határozza meg. Először is megegyeznek a hash-ekről és a titkosítási algoritmusokról, majd következik a Diffie-Hellman (DH) kulcscsere, és csak ezután dől el, hogy ki kicsoda. Vagyis az utolsó lépés a hitelesítési folyamat, akár PSK-, akár RSA-kulccsal. Ha pedig megállapodnak a felek, akkor létrejön egy ISAKMP alagút, amelyen már az IKE második üteme halad át.

A második fázisban az egymásban már megbízó résztvevők megállapodnak abban, hogyan építik ki a fő alagutat a közvetlen adatátvitelhez. Felajánlják egymásnak a transform-set paraméterben megadott opciókat, és ha egyetértenek, felemelik a fő alagutat. Fontos hangsúlyozni, hogy miután létrejött, a másodlagos ISAKMP alagút nem megy sehova – a fő alagút SA-jának időszakos frissítésére szolgál. Ennek eredményeként az IPsec valamilyen módon nem egy, hanem két egész alagutat hoz létre.

Az adatok feldolgozásának módja

Most néhány szó a transzformációról. Végül is valahogyan titkosítani kell az alagúton áthaladó adatokat. Ezért egy tipikus konfigurációban a transform-set olyan paraméterek halmaza, amelyek kifejezetten meghatározzák, hogyan kell feldolgozni a csomagot. Ennek megfelelően két lehetőség van az ilyen adatfeldolgozásra - ezek az ESP és az AH protokollok. Az ESP (Encapsulating Security Payload) közvetlenül foglalkozik az adattitkosítással, és az adatok integritásának ellenőrzésére is képes. Az AH (Authentication Header) viszont csak a forrás hitelesítéséért és az adatok sértetlenségének ellenőrzéséért felelős.

Például a crypto ipsec transform-set SET10 esp-aes parancs közli az útválasztóval, hogy a SET10 nevű transzformációs készlet csak az ESP protokollal és AES titkosítással működjön. A jövőre nézve azt mondom, hogy a továbbiakban a Cisco útválasztókat és tűzfalakat használjuk célként. Tulajdonképpen az ESP-vel többé-kevésbé minden világos, az a feladata, hogy titkosítson és ezzel biztosítsa a titkosságot, de akkor miért van szükségünk AH-ra? Az AH adathitelesítést biztosít, azaz megerősíti, hogy ezek az adatok attól származnak, akivel kapcsolatot létesítettünk, és nem változtatták meg őket menet közben. Ez biztosítja az úgynevezett visszajátszás elleni védelmet. A modern hálózatokban gyakorlatilag nem használják az AH-t, mindenhol csak ESP található.

Az IPsec-alagútban lévő információk titkosítására kiválasztott paraméterek (más néven SA-k) élettartammal rendelkeznek, majd le kell cserélni őket. Az IPsec SA alapértelmezett élettartama 86400 másodperc vagy 24 óra.
Ennek eredményeként a résztvevők egy titkosított alagutat kaptak a számukra megfelelő paraméterekkel, és oda küldik a titkosítandó adatfolyamokat. Időnként, az élettartamnak megfelelően, a fő alagút titkosítási kulcsai frissítésre kerülnek: a résztvevők újra csatlakoznak az ISAKMP alagúton keresztül, átmennek a második fázison, és újra létrehozzák az SA-t.

IKEv1 módok

Első közelítésként megvizsgáltuk az IPsec működésének alapvető mechanikáját, de van még néhány dolog, amire összpontosítani kell. Az első fázis többek között két üzemmódban működhet: fő módban vagy agresszív módban. A fenti első lehetőséget már megvizsgáltuk, de minket az agresszív mód érdekel. Ebben az üzemmódban három üzenet kerül felhasználásra (a fő módban lévő hat helyett). Ugyanakkor az, aki kezdeményezi a csatlakozást, egyszerre megadja minden adatát - mit akar és mit tud, valamint a DH-cserének a részét. A másik oldal ezután azonnal befejezi a részét a DH generációból. Ennek eredményeként ebben a módban valójában csak két szakasz van. Vagyis a fő mód első két szakasza (a hash-ek koordinálása és a DH-csere) mintegy egybe van tömörítve. Ennek eredményeként ez a mód sokkal veszélyesebb abból az okból, hogy sok technikai információ nyílt szövegben. És ami a legfontosabb, a VPN-átjáró el tudja küldeni az első fázisban a hitelesítéshez használt jelszó kivonatát (ezt a jelszót gyakran hívják előre megosztott kulcsnak vagy PSK-nak).

Nos, minden ezt követő titkosítás változtatás nélkül történik, mint általában. Akkor miért alkalmazzák még mindig ezt a rendszert? A helyzet az, hogy sokkal gyorsabb, körülbelül kétszer olyan gyors. A pentesterek számára különösen érdekes az a tény, hogy az agresszív módot nagyon gyakran használják az RA IPsec VPN-ben. Az RA IPsec VPN másik apró jellemzője agresszív mód használatakor: amikor egy kliens hozzáfér a szerverhez, elküld neki egy azonosítót (csoportnevet). Az alagútcsoport neve (lásd: 2. ábra) annak a bejegyzésnek a neve, amely az IPsec-kapcsolat házirendjét tartalmazza. Ez már a Cisco berendezések egyik jellemzője.

Két fázis nem volt elég

Úgy tűnik, hogy kiderül, és így nem túl sok egyszerű áramkör munka, de a valóságban még mindig egy kicsit bonyolultabb. Idővel világossá vált, hogy egyetlen PSK nem elég a biztonság biztosításához. Például, ha egy alkalmazott munkaállomását feltörik, a támadó azonnal hozzáférhet a vállalat teljes belső hálózatához. Ezért az 1.5 fázist közvetlenül az első és a második klasszikus fázis között fejlesztették ki. Egyébként ezt a fázist általában nem szabványos helyek közötti VPN-kapcsolatban használják, hanem távoli VPN-kapcsolatok szervezésekor (a mi esetünkben). Ez a fázis két új bővítményt tartalmaz: Extended Authentication (XAUTH) és Mode-Configuration (MODECFG).

A XAUTH egy további felhasználói hitelesítés az IKE protokollon belül. Ezt a hitelesítést néha az IPsec második tényezőjének nevezik. Nos, a MODECFG az átvitelt szolgálja további információ kliens, ez lehet IP-cím, maszk, DNS-kiszolgáló stb. Látható, hogy ez a fázis egyszerűen kiegészíti a korábban figyelembe vetteket, de hasznossága tagadhatatlan.

IKEv2 vs IKEv1

Mindkét protokoll az 500-as számú UDP porton működik, de nem kompatibilisek egymással, az alagút egyik végén az IKEv1, a másik végén az IKEv2 esetében nem megengedett a helyzet. Íme a fő különbségek a második és az első verzió között:

• Az IKEv2-ben már nincsenek olyan fogalmak, mint az agresszív vagy a fő mód.
• Az IKEv2-ben az első fázis kifejezést az IKE_SA_INIT (két üzenet cseréje, amely biztosítja a titkosítási/kivonatolási protokollok egyeztetését és a DH-kulcsok generálását), a második fázist pedig az IKE_AUTH (szintén két üzenet, amelyek a tényleges hitelesítést hajtják végre).
• A Mode Config (amit az IKEv1-ben 1.5-ös fázisnak neveztek) most közvetlenül a protokoll specifikációjában van leírva, és annak szerves részét képezi.
• Az IKEv2 egy további mechanizmust ad a DoS támadások elleni védelemhez. Lényege, hogy a biztonságos kapcsolat (IKE_SA_INIT) IKEv2 létesítése során minden egyes kérés megválaszolása előtt a VPN-átjáró cookie-t küld az ilyen kérés forrásának, és várja a választ. Ha a forrás azt válaszolta - minden rendben van, akkor elkezdheti vele a DH generálást. Ha a forrás nem válaszol (ami DoS támadás esetén történik, ez a technika hasonló a TCP-hez SYN árvíz), akkor a VPN-átjáró egyszerűen megfeledkezik róla. E nélkül a mechanizmus nélkül a VPN-átjáró minden kérés esetén megpróbálna létrehozni egy DH-kulcsot (ami meglehetősen erőforrás-igényes folyamat), és hamarosan problémákba ütközne. Ennek eredményeként, mivel most már minden művelet megerősítést igényel a kapcsolat másik oldaláról, lehetetlen nagyszámú félig nyitott munkamenetet létrehozni a támadott eszközön.

A határhoz megyünk

Miután végre rájöttünk az IPsec és összetevői működésének sajátosságaira, áttérhetünk a fő dologra - a gyakorlati támadásokra. A topológia meglehetősen egyszerű lesz, ugyanakkor közel áll a valósághoz (lásd 3. ábra).

Az első lépés az IPsec VPN-átjáró meglétének meghatározása. Ezt megteheti portszkenneléssel, de itt van egy kis csavar. Az ISAKMP az UDP protokollt, az 500-as portot használja, míg az Nmap alapértelmezett vizsgálata csak a TCP portokat érinti. Az eredmény egy üzenet lesz: A 37.59.0.253 összes 1000 beolvasott portja szűrve van.

Úgy tűnik, hogy minden port szűrve van, és nincsenek nyitott portok. De a parancs végrehajtása után

Nmap -sU --top-ports=20 37.59.0.253 Az Nmap 6.47 indítása (http://nmap.org) 2015-03-21 12:29 GMT Nmap vizsgálati jelentés a 37.59.0.253-hoz. A gazdagép felállt (0,066 s késleltetés) . PORT STATE SZOLGÁLTATÁS 500/udp nyitott isakmp

megbizonyosodunk arról, hogy ez nem így van, és valóban van előttünk egy VPN-eszköz.

Az első fázis megtámadása

Most az első fázis, az agresszív mód és az előre megosztott kulcs (PSK) hitelesítés lesz érdekelt. Ebben a forgatókönyvben ne feledje, hogy a VPN-eszköz vagy a válaszadó kivonatolt PSK-t küld a kezdeményezőnek. Az IKE protokoll tesztelésének egyik leghíresebb segédprogramja az ike-scan, a disztribúció része Kali Linux. Az Ike-scan lehetővé teszi az IKE üzenetek küldését különféle paraméterekkel, és ennek megfelelően a válaszcsomagok dekódolását és elemzését. Megpróbálja megvizsgálni a céleszközt:

[e-mail védett]:~# ike-scan -M -A 37.59.0.253 0 visszaadott kézfogás; 0 visszaküldött értesítés

Az -A kapcsoló azt jelzi, hogy agresszív módot kell használni, az -M pedig azt, hogy az eredményeket soronként (többsoros) kell megjeleníteni a könnyebb olvashatóság érdekében. Látható, hogy nem született eredmény. Ennek az az oka, hogy meg kell adnia ugyanazt az azonosítót, a VPN-csoport nevét. Természetesen az ike-scan segédprogram lehetővé teszi, hogy ezt az azonosítót az egyik paramétereként adja meg. De mivel még ismeretlen számunkra, vegyünk egy tetszőleges értéket, például 0000-et.

[e-mail védett]:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Agresszív mód Kézfogás visszatérve

Ezúttal azt látjuk, hogy a válasz megérkezett (lásd: 5. ábra), és elég sok mindennel láttuk el hasznos információ. Egy igen fontos kapott információ a transzformációs halmaz. Esetünkben ezt írja: "Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK".

Mindezek az opciók az ike-scan segédprogramhoz is megadhatók a --trans kapcsolóval. Például a --trans=5,2,1,2 3DES titkosítási algoritmust, HMAC-SHA kivonatolást, PSK hitelesítési módszert és egy második DH csoport típust (1024 bites MODP) jelent. Ezen a címen tekintheti meg az értékleképezési táblázatokat. Adjunk hozzá még egy kulcsot (-P), hogy közvetlenül megjelenítsük a csomag rakományát, vagy inkább a PSK hash-ét.

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

Az első nehézségek leküzdése

Úgy tűnik, hogy a hash megérkezett, és megpróbálhatja letörölni, de minden nem ilyen egyszerű. Valamikor régen, 2005-ben, volt egy biztonsági rés néhány Cisco hardveren: ezek az eszközök csak akkor adtak vissza hash-t, ha a támadó a megfelelő azonosítóértéket továbbította. Mostantól persze szinte lehetetlen megfelelni az ilyen berendezéseknek, és mindig a kivonatolt érték kerül elküldésre, függetlenül attól, hogy a támadó a helyes azonosító értéket küldte-e vagy sem. Nyilvánvalóan értelmetlen a rossz hash-t kitörölni. Ezért az első feladat a helyes azonosító érték meghatározása, hogy megkapjuk a megfelelő hash-t. Ebben pedig egy nemrég felfedezett sebezhetőség segít nekünk. A lényeg az, hogy a kezdeti üzenetváltás során van egy kis eltérés a válaszok között. Röviden, a helyes csoportnév használatakor négy kísérlet van a VPN-kapcsolat létrehozására, valamint két titkosított 2. fázisú csomag. Míg hibás azonosító esetén csak két csomag érkezik válaszként. Amint látható, a különbség meglehetősen jelentős, ezért a SpiderLabs (a szintén érdekes Responder eszköz szerzője) először a PoC-t, majd az IKEForce segédprogramot fejlesztette ki a biztonsági rés kihasználására.

Mi az IKE erőssége

Az IKEForce-t tetszőleges könyvtárba telepítheti a parancs futtatásával

Git klón https://github.com/SpiderLabs/ikeforce

Két fő módban működik - számítási mód -e (felsorolás) és brute force mód -b (bruteforce). A másodikhoz akkor fogunk eljutni, amikor a második tényező elleni támadásokat nézzük, de most az elsővel fogunk foglalkozni. Mielőtt elkezdené az azonosító meghatározásának folyamatát, be kell állítania a transzformációs halmaz pontos értékét. Korábban már definiáltuk, ezért a -t 5 2 1 2 opcióval fogjuk megadni. Ennek eredményeként az azonosító megtalálásának folyamata a következőképpen fog kinézni:

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

Ennek eredményeként elég gyorsan megkaptuk a helyes azonosító értéket (7. ábra). Az első lépés megtörtént, mehet tovább.

Szerezd meg a PSK-t

Most a megfelelő csoportnév használatával el kell mentenie a PSK-kivonatot egy fájlba, ezt megteheti az ike-scan segítségével:

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

És most, hogy a megfelelő azonosító érték felvétele és a megfelelő PSK-kivonat megtörtént, végre elindíthatjuk az offline brute force-ot. Nagyon sok lehetőség van az ilyen nyers erőre - ez a klasszikus psk-crack segédprogram, és a John the Ripper (egy jumbo patch-el), és még az oclHashcat is, amely, mint tudod, lehetővé teszi a GPU erejének használatát. . Az egyszerűség kedvéért a psk-crack-et fogjuk használni, amely támogatja a közvetlen nyers erő és a szótári támadásokat is:

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

De még a PSK sikeres visszaállítása (lásd 8. ábra) is csak a siker fele. Ebben a szakaszban emlékeznünk kell arra, hogy a XAUTH és a második IPsec VPN-faktor vár ránk.

A második IPsec-tényező kezelése

Tehát hadd emlékeztesselek arra, hogy a XAUTH egy kiegészítő védelem, a második hitelesítési tényező, és az 1.5 fázisban van. Az XAUTH-nak több lehetősége is lehet - ez egy ellenőrzés a RADIUS protokoll használatával, és egyszeri jelszavak(OTP), és a szokásos helyi felhasználói bázis. A standard helyzetre összpontosítunk, amikor a helyi felhasználói bázist használják a második tényező ellenőrzésére. Egészen a közelmúltig nem volt nyilvánosan elérhető XAUTH brute force eszköz. De az IKEForce megjelenésével ez a feladat méltó megoldást kapott. A XAUTH brute force egyszerűen elindul:

Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]A program XAUTH Brute Force módban indult [+]Egyetlen felhasználó által biztosított - nyers kényszerítés a felhasználó jelszavai: admin [*]XAUTH Authentication Sikeres! Felhasználónév: admin Jelszó: cisco

Ebben az esetben az összes korábban talált érték megjelenik: ID (-i kulcs), visszaállított PSK (-k kulcs) és feltételezett bejelentkezés (-u kulcs). Az IKEForce támogatja a bejelentkezési brute-force keresést és az iterációt a bejelentkezési listán, amely a -U paraméterrel adható meg. Esetleges egyezés blokkolása esetén van a -s opció, amivel csökkenthető a nyers erő sebessége. A segédprogramhoz egyébként több jó szótár is tartozik, amelyek különösen hasznosak az ID paraméter értékének beállításához.

Belépés a belső hálózatba

Most, hogy minden adatunk megvan, marad az utolsó lépés - a tényleges behatolás a helyi hálózatba. Ehhez szükségünk van valamilyen VPN kliensre, amiből nagyon sok van. De Kali esetében könnyedén használhatja a már előre telepített - VPNC-t. Ahhoz, hogy működjön, ki kell javítania egy konfigurációs fájlt - /etc/vpnc/vpn.conf . Ha nincs ott, akkor létre kell hoznia és ki kell töltenie számos nyilvánvaló paramétert:

IPSec átjáró 37.59.0.253 IPSec ID vpn IPSec titkos cisco123 IKE Authmode psk Xauth Felhasználónév admin Xauth jelszó cisco

Itt látjuk, hogy az előző lépésekben talált összes adatot felhasználtuk - az azonosító, a PSK, a bejelentkezési név és a második tényező jelszava értéke. Ezt követően maga a kapcsolat egy paranccsal történik:

[e-mail védett]:~# vpnc vpn

A letiltása is nagyon egyszerű:

[e-mail védett]:~# vpnc-disconnect

Az ifconfig tun0 paranccsal ellenőrizheti, hogy működik-e a kapcsolat.

Hogyan építsünk ki erős védelmet

A ma tárgyalt támadások elleni védelemnek átfogónak kell lennie: időben kell telepíteni a javításokat, erős előre megosztott kulcsokat kell használni, amelyeket lehetőség szerint teljes egészében digitális tanúsítványokra kell cserélni. A jelszópolitika és az információbiztonság egyéb nyilvánvaló elemei is fontos szerepet játszanak a biztonság biztosításában. Azt is meg kell jegyezni, hogy a helyzet fokozatosan változik, és idővel csak az IKEv2 marad meg.

Mi az eredmény

Részletesen ismertettük az RA IPsec VPN audit folyamatát. Igen, persze, ez a feladat korántsem triviális. Sok lépést kell megtenni, és mindegyikre nehézségek várhatnak, de ha sikerül, az eredmény több mint lenyűgöző. A hálózat belső erőforrásaihoz való hozzáférés nyitja meg a legszélesebb teret további intézkedés. Ezért a hálózat kerületének védelméért felelős személyeknek nem szabad kész alapértelmezett sablonokra hagyatkozniuk, hanem gondosan mérlegelniük kell az egyes biztonsági rétegeket. Nos, azok számára, akik penetrációs teszteket végeznek, az észlelt UDP 500-as port lehetőséget nyújt az IPsec VPN biztonságának mélyreható elemzésére, és esetleg jó eredményekre.

0 Ez a cikk áttekintést nyújt a Cisco termékekben elérhető és virtuális magánhálózatok (VPN) létrehozására használt IPSEC-ről (IP Security) és a kapcsolódó IPSec-protokollokról. Ebben a cikkben meghatározzuk, mi az IPSEC, és milyen protokollok és biztonsági algoritmusok állnak az IPSEC mögött.

Bevezetés

Az IP Security az IP-csomagok továbbítása során titkosítással, hitelesítéssel és biztonsággal foglalkozó protokollok sorozata; most közel 20 szabványjavaslatot és 18 RFC-t tartalmaz.

A Cisco VPN-termékek az IPSec protokollcsomagot használják, amely ma a gazdag VPN-szolgáltatások iparági szabványa. Az IPSec mechanizmust biztosít az adatok biztonságos továbbítására IP-hálózatokon keresztül, biztosítva a nem biztonságos hálózatokon, például az interneten keresztül továbbított adatok bizalmasságát, integritását és érvényességét. Az IPSec a következő VPN-képességeket biztosítja a Cisco hálózatokon:

• Adatvédelem. Az IPSec-adatok küldője képes a csomagok titkosítására, mielőtt azokat a hálózaton keresztül továbbítaná.
• Adatok integritása. Az IPSec-adatok fogadója képes hitelesíteni a vele kommunikáló feleket (azokat az eszközöket vagy szoftvereket, amelyeken az IPSec-alagutak indulnak és végződnek), valamint az általuk küldött IPSec-csomagokat, hogy megbizonyosodjon arról, hogy az adatok nem módosultak az átvitel során.
• Adatok eredetének hitelesítése. Az IPSec-vevő képes hitelesíteni a kapott IPSec-csomagok forrását. Ez a szolgáltatás az adatintegritási szolgáltatástól függ.
• Játékvédelem. Az IPSec-vevő képes észlelni és elutasítani a visszajátszott csomagokat, megakadályozva azok hamisítását és a köztes támadásokat.

Az IPSec biztonsági protokollok és algoritmusok szabványalapú készlete. Az IPSec technológia és a kapcsolódó biztonsági protokollok megfelelnek az IETF (Internet Engineering Task Force) által fenntartott és az RFC specifikációkban és az IETF-tervezetekben leírt nyílt szabványoknak. Az IPSec a hálózati rétegben működik, biztonságot és hitelesítést biztosítva az IPSec-eszközök (felek), például Cisco útválasztók, PIX tűzfalak, Cisco VPN kliensek és koncentrátorok, valamint sok más, az IPSec-et támogató termék között. Az IPSec támogatás lehetővé teszi a méretezést a legkisebbtől a nagyon nagy hálózatig.

Biztonsági Szövetség (SA)

Az IPSec szabványos módot biztosít a kommunikáló felek közötti kommunikáció hitelesítésére és titkosítására. A kommunikáció biztonsága érdekében az IPSec szabványos titkosítási és hitelesítési algoritmusokat (vagyis matematikai képleteket) használ, amelyeket fordításoknak nevezünk. Az IPSec nyílt szabványokat használ a titkosítási kulcsok egyeztetésére és a kapcsolatkezelésre, hogy lehetővé tegye a felek közötti együttműködést. Az IPSec technológia olyan módszereket biztosít, amelyek lehetővé teszik az IPSec-felek számára, hogy „tárgyalják” a szolgáltatások megállapodás szerinti használatát. Az IPSec biztonsági társításokat használ az egyeztetendő paraméterek meghatározásához.

Védegylet(Security Association – SA) az adatok kezelésének elfogadott szabályzata vagy módszere, amelyet állítólag a kommunikáló felek két eszköze között kell kicserélni. Egy ilyen házirend egyik összetevője lehet az adatok titkosítására használt algoritmus. Mindkét fél ugyanazt az algoritmust használhatja a titkosításhoz és a visszafejtéshez. Az érvényes SA-paraméterek mindkét oldalon a Security Association Database-ban (SAD) vannak tárolva.

Az SA mindkét oldalán található két számítógép tárolja az SA-ban használt módot, protokollt, algoritmusokat és kulcsokat. Minden SA csak egy irányban használatos. Két SA szükséges a kétirányú kommunikációhoz. Minden SA egy módot és protokollt valósít meg; így ha két protokollt (például AH és ESP) kell használni egy csomaghoz, akkor két SA-ra van szükség.

Az IKE (Internet Key Exchange) egy hibrid protokoll, amely speciális szolgáltatásokat nyújt az IPSec számára, nevezetesen az IPSec fél hitelesítését, az IKE és IPSec biztonsági társítási paraméterek egyeztetését, valamint az IPSec-en belül használt titkosítási algoritmusok kulcs kiválasztását. Az IKE protokoll az Internet Security Association and Key Management Protocol (ISAKMP) és az Oakley protokollokra támaszkodik, amelyek az IPSec átalakításokhoz használt titkosítási kulcsok előállításának és feldolgozásának vezérlésére szolgálnak. Az IKE protokollt arra is használják, hogy biztonsági társulásokat hozzanak létre a potenciális IPSec-felek között.
Mind az IKE, mind az IPSec biztonsági társításokat használ a kommunikációs paraméterek megadásához.
Az IKE különféle primitív függvényeket támogat a protokollokban való használatra. Ezek közé tartozik a hash függvény és a pszeudo-véletlen függvény (PRF).

hash függvény egy ütközésálló funkció. Ütközésállóságon azt értjük, hogy nem lehet két különböző m1 és m2 üzenetet találni úgy, hogy

H(m1)=H(m2), ahol H a hash függvény.

A pszeudo-véletlen függvények tekintetében jelenleg a speciális PRF-ek helyett hash függvényt használnak a HMAC tervezésben (a HMAC egy hash függvényeket használó üzenet-hitelesítési mechanizmus). A HMAC meghatározásához szükségünk van egy kriptográfiai hash függvényre (H-vel jelölve) és egy titkos kulcsra K. Feltételezzük, hogy H hash függvény, ahol az adatok kivonatolása egy adatblokkok sorozatára szekvenciálisan alkalmazott tömörítési eljárással történik. B-vel jelöljük az ilyen blokkok hosszát bájtban, és a hashelés eredményeként kapott blokkok hosszát L (L
ipad = 0x36 bájt B-szer megismétlve;
opad = 0x5C bájt B-szer ismételve.

A HMAC "szöveges" adatokból történő kiszámításához a következő műveletet kell végrehajtania:

H(K XOR opad, H(K XOR ipad, szöveg))

A leírásból az következik, hogy az IKE HASH értékeket használ a felek hitelesítésére. Vegye figyelembe, hogy a HASH ebben az esetben csak a Payload nevet jelenti az ISAKMP-ben, és ennek a névnek semmi köze a tartalomhoz.

IPSec infrastruktúra

Az IPSec VPN-ek számos Cisco-eszköz – Cisco útválasztók, CiscoSecure PIX tűzfalak, CiscoSecure VPN kliensszoftverek, valamint Cisco VPN 3000 és 5000 sorozatú koncentrátorok – segítségével építhetők. iOS, ami csökkenti a bonyolultságot hálózati megoldásokés csökkenti a VPN teljes költségét a nyújtott szolgáltatások többszintű védelmének lehetőségével. A PIX tűzfal nagy teljesítményű hálózati eszköz, amely kiszolgálhatja az alagút végpontjait, és magas áteresztőképességés gyönyörű funkcionalitás tűzfal. Szoftver A CiscoSecure VPN-kliens támogatja a legszigorúbb távoli hozzáférésű VPN-követelményeket az e-kereskedelmi és mobil hozzáférési alkalmazásokhoz, így az IPSec-szabványok teljes körű megvalósítását kínálja, és megbízható együttműködést biztosít a Cisco útválasztók és a PIX tűzfalak között.

Hogyan működik az IPSec

Az IPSec számos technológiai megoldásra és titkosítási módszerre támaszkodik, de az IPSec működése a következő fő lépésekben foglalható össze:

• 1. lépés: Indítsa el az IPSec folyamatot. Az IPSec-felek által megbeszélt IPSec biztonsági szabályzat szerint titkosítandó forgalom elindítja az IKE folyamatot.
• 2. lépés IKE fázis. Az IKE-folyamat hitelesíti az IPSec-feleket és egyezteti az IKE biztonsági társítási paramétereit, ami biztonságos csatornát hoz létre az IPSec biztonsági társítási paraméterek egyeztetéséhez az IKE második fázisában.
• 3. lépés Az IKE 2. fázisa. Az IKE folyamat egyezteti az IPSec biztonsági társítási paramétereket, és létrehozza a megfelelő IPSec biztonsági társításokat a kommunikáló fél eszközei számára.
• 4. lépés Adatátvitel. A kommunikáció az IPSec-et kommunikáló felek között zajlik, amely a biztonsági társítási adatbázisban tárolt IPSec-paramétereken és kulcsokon alapul.
• 5. lépés: Zárja le az IPSec alagutat. Az IPSec biztonsági társítások vagy törlésük eredményeként, vagy azért, mert túllépték élettartamuk korlátját, megszűnnek.

A következő szakaszok részletesebben ismertetik ezeket a lépéseket.

a jegyzőkönyv megjelenésének rövid történeti háttere

1994-ben az Internet Architecture Board (IAB) kiadta az "Internet Architectural Security" című jelentést. Ez a dokumentum ismerteti az interneten található további biztonsági eszközök fő alkalmazási területeit, nevezetesen a jogosulatlan megfigyelés elleni védelmet, a csomaghamisítást és az adatfolyam-szabályozást. A kiemelt és legfontosabb védelmi intézkedések között jelezték az adatáramlás integritását és bizalmasságát biztosító koncepció és alapvető mechanizmusok kidolgozásának szükségességét. Mivel a TCP / IP család alapprotokolljainak megváltoztatása az Internet teljes szerkezeti átalakulását okozná, a feladat a nyílt távközlési hálózatokban a meglévő protokollokon alapuló információcsere biztonságának biztosítása volt. Így az IPv4 és IPv6 protokollok mellett elkezdődött a Secure IP specifikáció létrehozása.

IPSec architektúra

Az IP Security az IP-csomagok továbbítása során titkosítással, hitelesítéssel és biztonsággal foglalkozó protokollok sorozata; most közel 20 szabványjavaslatot és 18 RFC-t tartalmaz.
Az IP Security specifikációt (ma IPsec néven ismert) az IETF IP Security Protocol Working Groupja fejleszti. Az IPsec kezdetben 3 algoritmusfüggetlen alapspecifikációt tartalmazott, amelyeket RFC-ként tettek közzé: „IP Security Architecture”, „Authentication Header (AH)”, „Encrypted Data Encapsulation (ESP)” (RFC1825, 1826 és 1827). Meg kell jegyezni, hogy 1998 novemberében az IP Biztonsági Protokoll Munkacsoport javasolta ezen specifikációk új verzióit, amelyek jelenleg előzetes szabványok státuszával rendelkeznek, ezek az RFC2401 - RFC2412. Vegye figyelembe, hogy az RFC1825-27 már több éve elavultnak számít, és nem igazán használják. Ezenkívül számos algoritmusfüggő specifikáció létezik, amelyek az MD5, SHA, DES protokollokat használják.

1. ábra. IPSec architektúra

Az IP Biztonsági Protokoll Munkacsoport kulcsfontosságú információkezelési protokollokat is fejleszt. Ennek a csoportnak a feladata az Internet Key Management Protocol (IKMP) fejlesztése, egy alkalmazási rétegbeli kulcskezelési protokoll, amely független a használt biztonsági protokolloktól. A kulcskezelési koncepciók jelenleg az Internet Security Association and Key Management Protocol (ISAKMP) specifikációja és az Oakley Key Determination Protocol használatával készülnek. Az ISAKMP specifikáció leírja a használt protokollok attribútumainak egyeztetésének mechanizmusait, míg az Oakley protokoll lehetővé teszi munkamenetkulcsok beállítását az interneten lévő számítógépeken. Korábban a SKIP kulcskezelési mechanizmusok alkalmazásának lehetőségeit is mérlegelték, de ma már gyakorlatilag sehol nem alkalmaznak ilyen lehetőségeket. A folyamatban lévő kulcsfontosságú információkezelési szabványok valószínűleg támogatni fogják a Kerberos rendszerben használt kulcselosztó központokat. Protokollok kulcskezelés a Kerberos-alapú IPSec esetében jelenleg a viszonylag új KINK (Kerberized Internet Negotiation of Keys) munkacsoport dolgozik ezen.
Az IPsec specifikációban szereplő adatintegritási és bizalmassági garanciákat hitelesítési, illetve titkosítási mechanizmusok biztosítják. Ez utóbbiak pedig a felek előzetes megállapodásán alapulnak az úgynevezett információcseréről. "biztonsági kontextus" - alkalmazott kriptográfiai algoritmusok, kulcsinformáció-kezelési algoritmusok és paramétereik. Az IPsec-specifikáció lehetőséget biztosít a felek számára információcserére, hogy támogassa az adatcsomagok hitelesítését és titkosítását szolgáló különféle protokollokat és paramétereket, valamint különféle kulcselosztási sémákat. Ugyanakkor a biztonsági kontextus egyeztetésének eredménye egy biztonsági paraméterindex (SPI) létrehozása, amely az információcsere oldal belső szerkezetének egy bizonyos elemére mutat, amely leírja a lehetséges biztonsági paraméterkészleteket.
Valójában az IPv6 részévé váló IPSec a harmadik rétegben, azaz a hálózati rétegben működik. Ennek eredményeként a továbbított IP-csomagokat a hálózati alkalmazások és infrastruktúra számára átlátható módon védik. Ellentétben az SSL-lel (Secure Socket Layer), amely a negyedik (azaz szállítási) rétegen működik, és szorosabban kapcsolódik az OSI modell magasabb rétegeihez, az IPSec-et alacsony szintű biztonságra tervezték.

2. ábra. OSI/ISO modell

Az IPSec fejlécet ad a VPN-en keresztüli küldésre kész IP-adatokhoz a védett csomagok azonosítása érdekében. Az interneten keresztül történő továbbítás előtt ezeket a csomagokat más IP-csomagokba foglalják. Az IPSec többféle titkosítást támogat, beleértve a Data Encryption Standard (DES) és a Message Digest 5 (MD5) titkosítást.
A biztonságos kapcsolat létrehozásához a munkamenet mindkét résztvevőjének képesnek kell lennie arra, hogy gyorsan megállapodjon a biztonsági paraméterekről, például a hitelesítési algoritmusokról és kulcsokról. Az IPSec kétféle kulcskezelési sémát támogat, amelyeken keresztül a résztvevők egyeztethetik a munkamenet-paramétereket. Ez a kettős támogatás némi súrlódást okozott akkoriban az IETF Munkacsoportban.
Az IP jelenlegi verziójával, az IPv4-gyel vagy az Internet Secure Association Key Management Protocol (ISAKMP), vagy az Internet Protocol egyszerű kulcskezelése használható. Az IP új verziójával, az IPv6-tal már az IKE-ként ismert ISAKMP-t kell használni, bár az SKIP továbbra is lehetséges. Nem szabad azonban elfelejteni, hogy a SKIP már nem számít kulcsfontosságú vezetőjelöltnek, és már 1997-ben lekerült a lehetséges jelöltek listájáról.

AH és ESP fejlécek

AH hitelesítési fejléc

A hitelesítési fejléc (AH) egy normál opcionális fejléc, és általában a fő IP-csomag fejléce és az adatmező között található. Az AH jelenléte nem befolyásolja a transzport és a magasabb rétegek információátviteli folyamatát. Az AH fő és egyetlen célja, hogy védelmet nyújtson a csomag tartalmának jogosulatlan megváltoztatásával összefüggő támadások ellen, beleértve a forráscím meghamisítását is. hálózati réteg. A magasabb szintű protokollokat módosítani kell a kapott adatok hitelességének ellenőrzése érdekében.
Az AH formátum meglehetősen egyszerű, és egy 96 bites fejlécből és 32 bites szavak változó hosszúságú adataiból áll. A mezőnevek meglehetősen egyértelműen tükrözik a tartalmukat: a Next Header a következő fejlécet, a Payload Len a csomag hosszát, az SPI a biztonsági kontextusra mutató mutató, a Sequence Number Field pedig a csomag sorszámát tartalmazza.

3. ábra. AH fejléc formátum

A csomagsorszámot 1997-ben vezették be az AH-ba az IPsec specifikáció felülvizsgálati folyamata során. Ennek a mezőnek az értékét a feladó állítja elő, és a hitelesítési folyamat adatainak újrafelhasználásával kapcsolatos támadások elleni védelemre szolgál. Mivel az internet nem garantálja a csomagok kézbesítési sorrendjét, a címzettnek meg kell őriznie a sikeresen hitelesített csomag maximális sorszámát, valamint bizonyos számú, korábbi sorszámot tartalmazó csomag fogadását (általában ez a szám 64).
Ellentétben a betárcsázós kommunikációs vonalakon vagy LAN-csatornákon keresztül történő információtovábbításra szolgáló protokollokban használt ellenőrzőösszeg kiszámítására szolgáló algoritmusokkal, amelyek az átviteli közeg véletlenszerű hibáinak kijavítására összpontosítanak, a nyílt távközlési hálózatokban az adatintegritási mechanizmusoknak rendelkezniük kell az adatátvitel ellen. célzott változtatásokat. Az egyik ilyen mechanizmus az MD5 algoritmus egy speciális alkalmazása: az AH kialakítása során magának a csomagnak és valamilyen előre egyeztetett kulcsnak a kombinációjából, majd az eredmény és a transzformált kulcs kombinációjából szekvenciálisan egy hash függvényt számítanak ki. kulcs. Ezt a mechanizmust alapértelmezés szerint alkalmazzák annak érdekében, hogy az IPv6 összes megvalósítását legalább egy olyan közös algoritmussal biztosítsák, amelyre nem vonatkoznak exportkorlátozások.

titkosított ESP adatok tokozása

Titkosított adatbeágyazás esetén az ESP fejléc az utolsó „látható” opcionális fejléc a csomagban. Mivel az ESP fő célja az adatok titkosságának biztosítása, a különböző típusú információkhoz jelentősen eltérő titkosítási algoritmusok szükségesek. Ezért az ESP formátum jelentős változásokon mehet keresztül a használt kriptográfiai algoritmusoktól függően. A következő kötelező mezők azonban megkülönböztethetők: a biztonsági kontextust jelző SPI és a csomag sorszámát tartalmazó Sequence Number Field. Az "ESP hitelesítési adatok" (ellenőrző összeg) mező nem kötelező az ESP fejlécében. Az ESP csomag címzettje dekódolja az ESP fejlécet, és az alkalmazott titkosítási algoritmus paramétereit és adatait használja a szállítási réteg információinak dekódolásához.

4. ábra. ESP fejléc formátum

Az ESP és AH (valamint ezek kombinációinak) két alkalmazási módja létezik - szállítás és alagút:
Az átviteli mód a szállítási réteg protokollokat (TCP, UDP, ICMP) tartalmazó IP-csomag adatmezőjének titkosítására szolgál, amely viszont alkalmazásszolgáltatási információkat tartalmaz. A szállítási mód alkalmazására példa az átvitel Email. A küldőtől a fogadóig tartó csomag útjának minden közbenső csomópontja csak a nyilvános hálózati réteg információit és esetleg néhány opcionális csomagfejlécet használ (IPv6-ban). A szállítási mód hátránya a csomag konkrét feladójának és címzettjének elrejtésére szolgáló mechanizmusok hiánya, valamint a forgalomelemzés lehetősége. Egy ilyen elemzés eredménye információ lehet az információtovábbítás mennyiségéről és irányáról, az előfizetők érdeklődési területeiről, a vezetők elhelyezkedéséről.
Az alagút mód a teljes csomagot titkosítja, beleértve a hálózati réteg fejlécét is. Alagút módot akkor használunk, ha el kell rejteni a szervezet információcseréjét a külvilággal. Ugyanakkor egy alagút módot használó csomag hálózati réteg fejlécének címmezőit a szervezet tűzfala tölti ki, és nem tartalmaznak információt a csomag konkrét feladójáról. A külvilágból a szervezet helyi hálózatába történő információátvitel során a tűzfal hálózati címét használjuk célcímként. Miután a tűzfal visszafejtette a kezdeti hálózati réteg fejlécét, a csomag elküldésre kerül a címzettnek.

Biztonsági Egyesületek

A Security Association (SA) egy olyan kapcsolat, amely biztonsági szolgáltatásokat nyújt a rajta áthaladó forgalom számára. Az SA mindkét oldalán található két számítógép tárolja az SA-ban használt módot, protokollt, algoritmusokat és kulcsokat. Minden SA csak egy irányban használatos. Két SA szükséges a kétirányú kommunikációhoz. Minden SA egy módot és protokollt valósít meg; így ha két protokollt (például AH és ESP) kell használni egy csomaghoz, akkor két SA-ra van szükség.

Biztonsági politika

A biztonsági házirendet az SPD (Security Policy Database) tárolja. Az SPD három művelet egyikét adhatja meg egy adatcsomaghoz: a csomag elvetése, a csomag feldolgozása ne IPSec-cel, a csomag feldolgozása IPSec-cel. Utóbbi esetben az SPD azt is meghatározza, hogy melyik SA-t kell használni (persze feltételezve, hogy egy megfelelő SA már elkészült), vagy megadja, hogy milyen paraméterekkel kell új SA-t létrehozni.
Az SPD egy nagyon rugalmas vezérlési mechanizmus, amely nagyon jó menedzsment minden egyes csomag feldolgozása. A csomagokat nagyszámú mező osztályozza, és az SPD ellenőrizheti a mezők egy részét vagy mindegyikét a megfelelő művelet meghatározásához. Ez azt eredményezheti, hogy a két gép közötti teljes forgalom egyetlen SA-n keresztül kerül továbbításra, vagy külön SA-kat használnak minden egyes alkalmazáshoz vagy akár minden TCP-kapcsolathoz.

ISAKMP/Oakley protokoll

Az ISAKMP protokoll meghatározza az SA létrehozásához és egyéb kulcskezelési funkciók végrehajtásához használt protokollok általános struktúráját. Az ISAKMP számos értelmezési tartományt (DOI) támogat, amelyek közül az egyik az IPSec-DOI. Az ISAKMP nem határoz meg egy teljes protokollt, hanem "építőelemeket" biztosít a különböző DOI-khoz és kulcscsere protokollokhoz.
Az Oakley protokoll egy kulcsmeghatározási protokoll, amely a Diffie-Hellman kulcshelyettesítő algoritmust használja. Az Oakley protokoll támogatja a Perfect Forward Secrecy (PFS) funkciót. A PFS jelenléte azt jelenti, hogy az összes forgalom nem dekódolható, ha a rendszer bármely kulcsa sérül.

IKE protokoll

Az IKE az ISAKMP alapértelmezett kulcscsere protokollja, és jelenleg ez az egyetlen. Az IKE az ISAKMP tetején helyezkedik el, és mind az ISAKMP SA, mind az IPSec SA tényleges létrehozását végzi. Az IKE különféle primitív függvényeket támogat a protokollokban való használatra. Ezek közé tartozik a hash függvény és a pszeudo-véletlen függvény (PRF).
A hash függvény olyan függvény, amely ellenáll az ütközéseknek. Az ütközésállóság alatt azt a tényt értjük, hogy lehetetlen két különböző m1 és m2 üzenetet találni úgy, hogy H(m1)=H(m2), ahol H egy hash függvény.
A pszeudo-véletlen függvények tekintetében jelenleg a speciális PRF-ek helyett hash függvényt használnak a HMAC tervezésben (a HMAC egy hash függvényeket használó üzenet-hitelesítési mechanizmus). A HMAC meghatározásához szükségünk van egy kriptográfiai kivonatoló függvényre (amelyet H-val jelölünk) és egy titkos kulcsra K. Feltételezzük, hogy H egy hash-függvény, ahol az adatok kivonatolása egy adatblokkok sorozatára szekvenciálisan alkalmazott tömörítési eljárással történik. B-vel jelöljük az ilyen blokkok hosszát bájtban, és a hashelés eredményeként kapott blokkok hosszát L (L

ipad = 0x36 bájt B-szer megismétlve;
opad = 0x5C bájt B-szer ismételve.

A HMAC "szöveges" adatokból történő kiszámításához a következő műveletet kell végrehajtania:

H(K XOR opad, H(K XOR ipad, szöveg))

A leírásból az következik, hogy az IKE HASH értékeket használ a felek hitelesítésére. Ne feledje, hogy a HASH ebben az esetben kizárólag az ISAKMP Payload nevére utal, és ennek a névnek semmi köze a tartalomhoz.

támadások AH, ESP és IKE ellen

Az IPSec-összetevők elleni támadások minden típusa a következő csoportokba sorolható: a rendszererőforrások végességét kihasználó támadások (tipikus példa erre a szolgáltatásmegtagadási támadás, szolgáltatásmegtagadási vagy DOS-támadás), a szolgáltatásokat, ill. egy adott IPSec implementáció hibái, és végül maguk az AH és ESP protokollok gyengeségein alapuló támadások. A tisztán kriptográfiai támadásokat figyelmen kívül lehet hagyni – mindkét protokoll meghatározza az „átalakítások” fogalmát, ahol minden titkosítás rejtve van. Ha a használt kriptoalgoritmus rezisztens, és a vele definiált transzformáció nem okoz további gyengeségeket (ez nem mindig van így, ezért helyesebb a teljes rendszer stabilitását figyelembe venni - Protokoll-Transform-Algoritm), akkor ettől kezdve oldalán minden rendben. Ami marad? Replay Attack - a Sequence Number használatával szintetizálva (egyetlen esetben nem működik - ESP hitelesítés és AH nélkül). Továbbá a műveletek sorrendje (először titkosítás, majd hitelesítés) garantálja a "rossz" csomagok gyors elutasítását (sőt a kriptográfia világában végzett legújabb kutatások szerint ez a műveleti sorrend a legbiztonságosabb, fordított sorrend bizonyos esetekben, bár nagyon speciális esetekben, potenciális biztonsági résekhez vezethetnek; szerencsére sem az SSL, sem az IKE, sem más, "először hitelesít, majd titkosít" protokollt használó protokollok nem tartoznak ezekhez a különleges esetekhez, ezért nem is rendelkeznek ezek a lyukak). Marad a szolgáltatásmegtagadási támadás.

Mint tudják, ez egy támadás, amely ellen nincs teljes védelem. Azonban a rossz csomagok gyors elutasítása és a rájuk adott külső reakció hiánya (az RFC szerint) lehetővé teszi, hogy többé-kevésbé jól kezeljük ezt a támadást. Elvileg a legtöbb (ha nem az összes) ismert hálózati támadást (szippantás, hamisítás, eltérítés stb.) az AH és az ESP sikeresen felveszi, ha helyesen használják őket. Az IKE-vel ez egy kicsit bonyolultabb. A protokoll nagyon összetett, nehezen elemezhető. Ezen túlmenően az írási hibák (a HASH_R kiszámításának képletében) és a nem teljesen sikeres megoldások (ugyanaz a HASH_R és HASH_I) miatt számos lehetséges "lyukat" tartalmaz (főleg, hogy az üzenetben nincs minden hasznos adat hitelesítve Az első fázisban azonban ezek nem túl komolyak, és legfeljebb a kapcsolat létrehozásának megtagadásához vezetnek.Az IKE többé-kevésbé sikeresen védett az olyan támadásokkal szemben, mint a visszajátszás, hamisítás, szippantás, eltérítés. A kriptográfiával ez valamivel bonyolultabb - nem külön jelenítik meg, mint az AH-ban és az ESP-ben, hanem magában a protokollban valósítják meg. Perzisztens algoritmusok és primitívek (PRF) használata esetén azonban nem lehet probléma. Bizonyos mértékig az IPsec gyengéjének tekinthető, hogy a jelenlegi specifikációkban a DES az egyetlen kötelező kriptográfiai algoritmus a megvalósításhoz (ez igaz az ESP-re és az IKE-re is), amelynek kulcsának 56 bitjét már nem veszik figyelembe. elegendő. Mindazonáltal ez pusztán formai gyengeség – maguk a specifikációk algoritmusfüggetlenek, és szinte minden jól ismert gyártó már régóta implementálta a 3DES-t (és néhányan már megvalósították az AES-t). Így, ha helyesen implementálják, a szolgáltatásmegtagadás továbbra is a a legveszélyesebb támadás.

IPSec protokoll kiértékelése

Az IPSec protokoll vegyes értékeléseket kapott a szakértőktől. Egyrészt meg kell jegyezni, hogy az IPSec protokoll a legjobb a hálózaton keresztül továbbított adatok védelmére szolgáló összes többi, korábban kifejlesztett protokoll közül (beleértve a Microsoft PPTP által fejlesztettet is). A másik oldal szerint a protokoll túlzott bonyolultsága és redundanciája. Például Niels Ferguson és Bruce Schneier "A Cryptographic Evaluation of IPsec" című munkájában megjegyzi, hogy az IPsec szinte minden fő összetevőjében komoly biztonsági problémákat találtak. Ezek a szerzők arra is rámutatnak, hogy a protokollcsomag sok munkát igényel a megfelelő biztonsági szint biztosítása érdekében.