IPsec (IP biztonság)- protokollkészlet az IP-hálózaton keresztüli biztonságos forgalomtovábbításhoz. Talán a VPNKI rendszer által támogatott legösszetettebb és legkiterjedtebb protokollverem.

Három fő protokollt tartalmaz:

• AH (Authentication Header) - a továbbított adatok integritásának kezelése és hitelesítés

• ESP (Encapsulating Security Payload) – adattitkosítás

• ISAKMP (Internet Security Association and Key Management Protocol) - kapcsolatlétesítés menedzselése, egymás végcsomópontjainak kölcsönös hitelesítése és titkos kulcsok cseréje

Fő használt portok és protokollszámok

• UDP, 500-as port (IKE, kulcskezelés)
• UDP protokoll, 4500-as port (IPSEC NAT-Traversal mód)
• ESP protokoll értéke 50 (IPSEC esetén)
• AH protokoll értéke 51 (IPSEC esetén)

Általánosságban elmondható, hogy az IPsec protokollcsomag nem egyszerű használati eseteit tekintve, amelyek meglehetősen sokrétűek. A protokollon belüli összes interakció alapvető jellemzője azonban az SA (Security Association) koncepciója – ez egy olyan paraméterkészlet, amely arra utal, hogy a felek hogyan fogják tovább használni a protokollok bizonyos tulajdonságait az IPsec-összetételből.

Érdemes megemlíteni az IPsec két fő működési módját is - alagút és szállítás. Durván fogalmazva, szállítási módban csak az IP-csomag hasznos terhe van titkosítva, míg alagút módban minden adat, beleértve az IP-fejlécet is, titkosítva van.

Hitelesítés

A két csomópont közötti kommunikáció az SA létrehozásával kezdődik. Pontosabban, két társításból - az AH és az ESP protokollhoz, mind az egyik, mind a másik irányba. Az SA hitelesítéssel kezdődik, majd a felek megbeszélik a jövőbeli munkamenet-paramétereket:

• az AH protokollhoz – használt hitelesítési algoritmus, kulcsok, kulcs élettartama és egyéb paraméterek,
• az ESP protokollhoz - titkosítási és hitelesítési algoritmusok, kulcsok, inicializálási paraméterek, kulcsok élettartama és egyéb paraméterek.

Itt a felek megállapodnak az IPsec alagútban vagy szállítási módjában.

A folyamat végére több SA-t kell telepítenie, de ... egy kicsit részletesebben arról, hogyan is van ez valójában.

1. és 2. fázis

Az IPsec-ben minden fázisban történik.

Az 1. fázisban megtörténik az első fázis SA létrehozása. Az első fázisban a felek megállapodnak az azonosítási módszerről, a titkosítási algoritmusról, a hash algoritmusról és a Diffie Hellman csoportról. Ezt a fázist három titkosítatlan csomag (agresszív mód) vagy hat titkosítatlan csomag – standard mód – cseréjével lehet áthaladni. Ha minden jól megy, létrejön az 1. fázisú SA, az IKE SA, és átkerül a második fázisba.

A 2. fázisban a felek megállapodnak a szabályzatban, és maguk a kulcsok jönnek létre. Ez a fázis, ellentétben az elsővel, teljesen titkosított, és csak akkor kezdődik, ha az első fázis sikeresen befejeződött. Mivel ebben a fázisban a forgalom teljesen titkosított, nehéz lesz a hibaelhárítás, de ha minden jól megy, létrejön egy fázis 2 SA, az IPSec SA. Ezen a ponton elmondható, hogy az alagút létrejött.

Adattömörítés

Az IPsec-nek nincs saját adattömörítési mechanizmusa, azonban használhatja az IPcomp-mechanizmust, amely tömöríti az IP-csomag tartalmát, mielőtt elküldené az IPsec-folyamatnak. Egyes IPsec démonok támogatják ennek a mechanizmusnak az ipsec.conf konfigurációs fájlokból történő engedélyezését (például a Strongswan csomag)

Automatikus VPN-kapcsolat állapotellenőrzése

Az IPsec-en belül nincs szabványos eszköz a kapcsolat állapotának ellenőrzésére (például ping), így az alagút működése külső eszközökkel ellenőrizhető.

A VPN-kapcsolat leválasztása és a kulcsok megváltoztatása

A két fázisban egyeztetett kulcsoknak a szabályzatban meghatározott ideig kell működniük. Ez azt jelenti, hogy a feleknek át kell menniük az újrakulcsolási eljáráson, különben az egyeztetett SA-k szétesnek. Ahogy fentebb említettük, a felek az 1. fázis (IKE) és a 2. fázis (IPsec) folyamaton keresztül birtokolják a kulcsokat. A módosításukra vonatkozó eljárások eltérőek, csakúgy, mint az ezért felelős időzítők. Annak érdekében, hogy a kommunikáció ne szakadjon meg a kulcscsere folyamata során, a felek először megállapodnak az új SA paramétereiről, és csak a sikeres eljárás után semmisítik meg a régi SA-t.

Az IPsec-ben az egyes fázisokban többféle módon is módosíthatjuk a kulcsokat – hitelesítéssel vagy anélkül, de erre nem fogunk különösebben összpontosítani. Egyszerűen túl sok árnyalat van ehhez az eljáráshoz, ami a szoftver verziójától és az időzítők arányától függ - az IKE és az IPsec esetében.

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 IP Security (IP Security) és kapcsolódó IPSec protokollokról. Ebben a cikkben meghatározzuk, mi az IPSEC, és mely biztonsági protokollok és algoritmusok állnak az IPSEC középpontjában.

Bevezetés

Az IP Security az IP-csomagok átvitele során titkosítással, hitelesítéssel és biztonsággal foglalkozó protokollok sorozata; mostanra közel 20 szabványjavaslattal és 18 RFC-vel rendelkezik.

A Cisco VPN-termékek az IPSec-et használják, amely a gazdag VPN-képességek ipari szabványa. Az IPSec olyan mechanizmust kínál az adatok biztonságos továbbítására IP-hálózatokon, amelyek biztosítják 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 megbízhatóságát. Az IPSec a következő VPN-képességeket biztosítja a Cisco hálózatokon:

• Adatok titkossága... Az IPSec-adatok küldője képes titkosítani a csomagokat, mielőtt azokat a hálózaton keresztül elküldené.
• Adatok integritása... Az IPSec-adatok címzettje 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.
• Adatforrás hitelesítés... Az IPSec-adatok címzettje képes hitelesíteni a fogadott IPSec-csomagok forrását. Ez a szolgáltatás az adatintegritási szolgáltatástól függ.
• Lejátszás védelem... Az IPSec adatok címzettje képes észlelni és visszautasítani a lejátszott csomagokat, megakadályozva azok manipulálását és közvetítői támadások végrehajtását.

Az IPSec biztonsági protokollok és algoritmusok szabványalapú készlete. Az IPSec és a kapcsolódó biztonsági protokollok megfelelnek az Internet Engineering Task Force (IETF) által támogatott és az RFC-kben és az IETF-tervezetekben leírt nyílt szabványoknak. Az IPSec a hálózati rétegben működik, hogy biztonságot és hitelesítést biztosítson 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, IPSec-et támogató termék között. Az IPSec támogatása a legkisebbtől a nagyon nagy hálózatig terjed.

Biztonsági Szövetség (SA)

Az IPSec szabványos módot kínál 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 iparági szabványos titkosítási és hitelesítési algoritmusokat (vagyis matematikai képleteket) használ, amelyeket transzformációknak neveznek. 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 a szolgáltatások következetes használatának "tárgyalását". Az IPSec biztonsági társításokat használ az egyeztetendő paraméterek meghatározására.

Védegylet(Security Association – SA) egy megállapodás szerinti adatfeldolgozási szabályzat vagy módszer, amelyet 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 (SAD) mentésre kerülnek.

Az SA mindkét oldalán két számítógép tárolja az SA-ban használt módot, protokollt, algoritmusokat és kulcsokat. Mindegyik SA csak egy irányban használható. 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 kell használni egyetlen csomaghoz (például AH és ESP), akkor két SA-ra van szükség.

Az Internet Key Exchange (IKE) egy hibrid protokoll, amely speciális szolgáltatást biztosít az IPSec számára, nevezetesen az IPSec felek 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 az Internet Security Association and Key Management Protocol-ra (ISAKMP) és az Oakley-re támaszkodik, amelyek az IPSec-átalakítások során használt titkosítási kulcsok létrehozásának és feldolgozásának vezérlésére szolgálnak. Az IKE-t arra is használják, hogy biztonsági kapcsolatokat 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 számos primitív függvényt 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Ütközésálló tulajdonság. 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.

Ami a pszeudo-véletlen függvényeket illeti, most a speciális PRF-ek helyett hash függvényt használnak a HMAC konstrukcióban (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 (jelezzük H-ként) é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, a kivonatolás eredményeként kapott blokkok hosszát pedig L (L
ipad = 0x36 bájt, B-szer ismételve;
opad = 0x5C bájt B-szer ismételve.

A HMAC kiszámításához a "szöveg" adatokból 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 kizárólag a Payload nevet jelenti az ISAKMP-ben, és ennek a névnek semmi köze a tartalomhoz.

IPSec infrastruktúra

Az IPSec VPN-ek a Cisco eszközök széles skálájával építhetők fel – Cisco útválasztókkal, CiscoSecure PIX tűzfalakkal, CiscoSecure VPN kliensszoftverekkel és Cisco 3000 és 5000 sorozatú VPN-koncentrátorokkal. amely csökkenti a hálózati megoldások összetettségét és csökkenti a VPN teljes költségét, miközben a nyújtott szolgáltatások többrétegű védelmét építi ki. A PIX Firewall egy nagy teljesítményű hálózati eszköz, amely nagy sávszélességgel és kiváló tűzfalfunkciókkal képes kiszolgálni alagútvégpontokat. A CiscoSecure VPN kliensszoftver 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 azáltal, hogy teljes IPSec-szabványokat é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 technikára támaszkodik, de az IPSec általános 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 egyeztetett IPSec biztonsági szabályzatnak megfelelően titkosítást igénylő forgalom elindítja az IKE-folyamatot.
• 2. lépés. Az IKE I. fázisa... Az IKE folyamat hitelesíti az IPSec feleket és egyezteti az IKE biztonsági társulások paramétereit, ami biztonságos csatornát hoz létre az IPSec biztonsági társítások paramétereinek 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... Az IPSec-et kommunikáló felek közötti kommunikáció a biztonsági társítási adatbázisban tárolt IPSec-paraméterek és kulcsok alapján történik.
• 5. lépés: Az IPSec-alagút leállítása... Az IPSec biztonsági társítások vagy eltávolításuk, vagy élettartamuk túllépése esetén megszűnnek.

Ezeket a lépéseket részletesebben ismertetjük a következő szakaszokban.

(The Internet Key Exchange (IKE)) - Kulcscsere.

RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – A nulla titkosítási algoritmus és annak használata.

RFC 2411 (IP Security Document Roadmap) – A szabvány továbbfejlesztése.

RFC 2412 (The OAKLEY Key Determination Protocol) – Kulcsmegfelelőségi ellenőrzés.

IPsec architektúra

Az IPsec, a többi jól ismert SSL és TLS protokolltól eltérően, a hálózati rétegben (az OSI modell 3. rétegében) működik. Ez rugalmasabbá teszi az IPsec-et, így bármely TCP és UDP alapú protokoll védelmére használható. Az IPsec két IP-állomás, két biztonsági átjáró, vagy egy IP-gazdagép és egy biztonsági átjáró közötti biztonság biztosítására használható. A protokoll az IP-protokoll „kiegészítője”, és a generált IP-csomagokat az alábbiakban leírt módon dolgozza fel. Az IPsec képes biztosítani a hálózaton keresztül továbbított adatok integritását és/vagy titkosságát.

Az IPsec a következő protokollokat használja különböző funkciók végrehajtására:

• A hitelesítési fejléc (AH) biztosítja a virtuális kapcsolat (átvitt adatok) integritását, az információforrás hitelesítését és egy további funkciót a csomagok újraküldésének megakadályozására.
• Az Encapsulating Security Payload (ESP) biztosíthatja a továbbított információk bizalmas kezelését (titkosítását), korlátozva a bizalmas forgalom áramlását. Ezen túlmenően biztosíthatja a virtuális kapcsolat integritását (továbbított adatok), az információforrás hitelesítését és a csomagok újraküldésének megakadályozására szolgáló kiegészítő funkciót (ESP használatakor kötelező az egyik vagy másik biztonsági szolgáltatás használata)
• A Security Association (SA) egy csomó algoritmust és adatot biztosít, amelyek biztosítják az AH és/vagy ESP működéséhez szükséges paramétereket. Az Internet Security Association and Key Management Protocol (ISAKMP) keretet biztosít a hitelesítéshez és a kulcscseréhez, a kulcshitelesítéshez.

Biztonsági Egyesület

A "Secure Virtual Connection" (SA, "Security Association") koncepciója alapvető az IPsec architektúrában. Az SA egy szimplex kapcsolat, amely úgy van kialakítva, hogy a megfelelő forgalmat továbbítsa rajta. A biztonsági szolgáltatások megvalósítása során az AH vagy ESP protokollok (vagy mindkettő egyidejű) használata alapján SA jön létre. Az SA pont-pont koncepció szerint van definiálva, és két üzemmódban működhet: szállítási módban (PTP) és alagút üzemmódban (RTU). A szállítási mód két IP-csomópont közötti SA-val valósul meg. Alagút módban az SA IP alagutat képez.

Az összes SA-t az IPsec-modul SADB-jében (Security Associations Database) tárolja. Minden SA egyedi markerrel rendelkezik, amely három elemből áll:

• Biztonsági paraméter-index (SPI)
• Cél IP-címek
• biztonsági protokoll azonosító (ESP vagy AH)

Az IPsec modul e három paraméter alapján meg tudja keresni egy adott SADB bejegyzést. Az SA komponensek listája a következőket tartalmazza:

Sorozatszám A mező létrehozásához használt 32 bites érték Sorszám az AH és ESP címsorokban. Sorozatszám számláló túlcsordulás Jelző, amely a sorozatszám-számláló túlcsordulását jelzi. Visszajátszás támadás elnyomása ablak Csomagok újraküldésének meghatározására szolgál. Ha az érték a mezőben Sorszám nem esik a megadott tartományba, akkor a csomag megsemmisül. Információk AH használt hitelesítési algoritmus, a szükséges kulcsok, a kulcs élettartama és egyéb paraméterek. ESP információ titkosítási és hitelesítési algoritmusok, szükséges kulcsok, inicializálási paraméterek (például IV), kulcs élettartama és egyéb paraméterek IPsec üzemmód alagút vagy szállítás MTU A maximális csomagméret, amely töredezettség nélkül továbbítható egy VC-n.

Mivel a biztonságos virtuális kapcsolatok (SA-k) szimplexek, legalább két SA-ra van szükség a duplex kapcsolat létrehozásához. Ezenkívül minden protokollnak (ESP / AH) saját SA-val kell rendelkeznie minden irányhoz, azaz az AH + ESP köteg négy SA-t igényel. Mindezek az adatok a SADB-ben találhatók.

• AH: Hitelesítési algoritmus.
• AH: titkos kulcs a hitelesítéshez
• ESP: titkosítási algoritmus.
• ESP: titkos titkosítási kulcs.
• ESP: hitelesítés használata (igen / nem).
• Lehetőségek a kulcscserére
• Útvonali korlátozások
• IP-szűrési szabályzat

Az SADB-adatbázison kívül az IPsec-megvalósítások támogatják a Security Policy Database-t (SPD). Az SPD-bejegyzés IP-fejlécmezők értékeinek készletéből és Upper Layer Protocol fejlécmezőiből áll. Ezeket a mezőket szelektoroknak nevezzük. A szelektorok a kimenő csomagok szűrésére szolgálnak, hogy az egyes csomagokat egy adott SA-hoz leképezzék. Amikor egy csomag létrejön, a csomagban lévő megfelelő mezők (választó mezők) értékeit összehasonlítják az SPD-ben szereplőkkel. A megfelelő SA-k megtalálhatók. Az SA, ha van, ezután meghatározásra kerül a csomaghoz és a hozzá tartozó biztonsági paraméterek indexéhez (SPI). Ezután az IPsec műveletek (AH vagy ESP protokoll műveletek) végrehajtásra kerülnek.

Példák az SPD-ben található szelektorokra:

• Cél IP-címe
• Feladó IP-címe
• IPsec protokoll (AH, ESP vagy AH + ESP)
• Feladó és fogadó portok

Hitelesítési fejléc

Hitelesítési fejléc formátum

Eltolások	Oktett 16	0								1								2								3
Oktett 16	10. bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Következő fejléc								Hasznos teher Len								Fenntartott
4	32
8	64	Sorszám
C	96	Integritás-ellenőrzési érték (ICV) …
…	…

Következő fejléc(8 bit) Az AH fejlécet követő protokollfejléc típusa. Ennek a mezőnek a használatával a fogadó IP-sec modul megismeri a védett felső szintű protokollt. Ennek a mezőnek az értékei a különböző protokollokhoz az RFC 1700-ban találhatók. Hasznos teher Len(8 bit) Ez a mező az AH fejléc teljes méretét adja meg 32 bites szavakban, mínusz 2. Azonban IPv6 használatakor a fejléc hosszának 8 bájt többszörösének kell lennie. Fenntartott(16 bit) Fenntartva. Nullákkal töltve. Biztonsági paraméterek indexe(32 bit) A biztonsági paraméterek indexe. Ennek a mezőnek az értéke a cél IP-címével és biztonsági protokolljával (AH-protokoll) együtt egyedileg azonosítja a csomag biztonságos virtuális kapcsolatát (SA). Az 1...255 közötti SPI-értéktartományt az IANA fenntartja. Sorszám(32 bit) Sorozatszám. Az újraadás elleni védelemre szolgál. A mező monoton növekvő paraméterértéket tartalmaz. Bár a címzett leiratkozhat a csomag-újraátvitel védelmi szolgáltatásról, ez kötelező, és mindig jelen van az AH fejlécben. A küldő IPsec modul mindig ezt a mezőt használja, de előfordulhat, hogy a fogadó nem dolgozza fel. Integritás-ellenőrzési érték

Az AH protokoll a hitelesítésre szolgál, vagyis annak megerősítésére, hogy pontosan azzal kommunikálunk, akinek gondoljuk magunkat, és a kapott adatok nem sérülnek meg az átvitel során.

Kimenő IP-csomag feldolgozás

Ha a küldő IPsec-modul megállapítja, hogy a csomag AH-feldolgozást feltételező SA-hoz van társítva, akkor megkezdi a feldolgozást. A módtól függően (szállítási vagy alagútmódosítási mód) eltérően illeszti be az AH fejlécet az IP-csomagba. Szállítási módban az AH-fejléc az IP-protokoll-fejléc után és a felső rétegbeli protokollfejlécek (általában TCP vagy UDP) elé kerül. Tunneling módban a teljes eredeti IP-csomagot először az AH fejléc, majd az IP protokoll fejléce keretezi. Ezt a fejlécet külsőnek, az eredeti IP-csomag fejlécét pedig belsőnek nevezzük. Ezt követően az átvitelt végző IPsec modulnak sorszámot kell generálnia, és fel kell írnia a mezőbe Sorszám... Az SA létrehozásakor a sorszám 0 lesz, és minden IPsec-csomag elküldése előtt eggyel nő. Ezen kívül van egy ellenőrzés, hogy a számláló hurkolt-e. Ha eléri a maximális értéket, akkor visszaáll 0-ra. Ha az újraküldés elleni szolgáltatást használják, amikor a számláló eléri a maximális értéket, a küldő IPsec modul alaphelyzetbe állítja az SA-t. Így biztosított a csomag ismételt elküldése elleni védelem – a fogadó IPsec modul ellenőrzi a mezőt Sorszám, és figyelmen kívül hagyja az újrapróbálkozási csomagokat. Ezután kiszámítjuk az ICV ellenőrző összeget. Meg kell jegyezni, hogy itt az ellenőrző összeget egy titkos kulcs segítségével számítják ki, amely nélkül a támadó újra tudja számítani a hash-t, de a kulcs ismerete nélkül nem tudja kialakítani a megfelelő ellenőrző összeget. Az ICV kiszámításához használt speciális algoritmusok az RFC 4305-ben találhatók. Jelenleg például a HMAC-SHA1-96 vagy az AES-XCBC-MAC-96 algoritmusok használhatók. Az AN protokoll kiszámítja az ellenőrző összeget (ICV) az IPsec-csomag következő mezőihez:

• Azok az IP-fejlécmezők, amelyeket nem módosítottak a sugárzás során, vagy amelyeket a legfontosabbként azonosítottak
• AH-fejléc (Mezők: "Next Header", "Payload Len", Reserved "," SPI "," Sequence Number "," Integrity Check Value ". Az" Integrity Check Value "mező 0-ra van állítva az ICV kiszámításakor
• felső réteg protokoll adatai

Ha a mező változhat a szállítás során, akkor az ICV kiszámítása előtt az értékét 0-ra állítjuk. Kivételt képeznek azok a mezők, amelyek változhatnak, de amelyek értéke előre jelezhető átvételkor. Az ICV kiszámításakor nincsenek nullákkal töltve. Példa módosítható mezőre az ellenőrző összeg mező, egy módosítható, de előre meghatározott mezőre példa lehet a címzett IP-címe. Az RFC 2402 szabványban található részletesebb leírás arról, hogy mely mezőket veszik figyelembe az ICV kiszámításakor.

Bejövő IP-csomagok feldolgozása

Az AH-üzenetet tartalmazó csomag fogadása után a fogadó IPsec-modul megkeresi a megfelelő Security Associations Database (SADB) biztonságos virtuális kapcsolatot (SA) a cél IP-cím, a Security Protocol (AH) és az SPI használatával. Ha nem található megfelelő SA, a csomag eldobásra kerül. A talált biztonságos virtuális kapcsolat (SA) jelzi, hogy a csomag-újraátvitelt megakadályozó szolgáltatás használatban van-e, pl. a mező ellenőrzésének szükségességéről Sorszám... Ha a szolgáltatást használja, akkor a mező be van jelölve. Ehhez a csúszóablak módszert alkalmazzuk. Az IPsec fogadó modul egy W szélességű ablakot alkot. Az ablak bal széle megfelel a minimális sorszámnak ( Sorszám) N helyesen fogadott csomag. Csomag mezővel Sorszám, amely egy N + 1-től kezdődő és N + W-re végződő értéket tartalmaz, helyesen kerül elfogadásra. Ha a fogadott csomag az ablak bal szélén van, megsemmisül. Az IPsec fogadó modul ezután kiszámítja az ICV-t a fogadott csomag megfelelő mezőiből az SA rekordból tanult hitelesítési algoritmus segítségével, és összehasonlítja az eredményt az "Integrity Check Value" mezőben található ICV értékkel. Ha a számított ICV érték egybeesik a fogadott értékkel, akkor a bejövő csomag érvényesnek minősül és elfogadásra kerül további IP feldolgozásra. Ha az ellenőrzés negatív, akkor a fogadó csomag eldobásra kerül.

Biztonsági hasznos teher beágyazása formátum

Eltolások	Oktett 16	0								1								2								3
Oktett 16	10. bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Biztonsági paraméterek indexe (SPI)
4	32	Sorszám
8	64	Rakományadatok
…	…
…	…
…	…									Kitöltés (0-255 oktett)
…	…																	Pad hossza								Következő fejléc
…	…	Integritás-ellenőrzési érték (ICV) …
…	…

Biztonsági paraméterek indexe(32 bit) A biztonsági paraméterek indexe. Ennek a mezőnek az értéke a cél IP-címével és biztonsági protokolljával (AH-protokoll) együtt egyedileg azonosítja a csomag biztonságos virtuális kapcsolatát (SA). Az 1...255 közötti SPI-értéktartományt az IANA fenntartja későbbi használatra. Sorszám(32 bit) Sorozatszám. Az újraadás elleni védelemre szolgál. A mező monoton növekvő paraméterértéket tartalmaz. Bár a címzett megtagadhatja a csomag-újraátvitel védelmi szolgáltatást, az mindig jelen van az AH fejlécben. A küldőnek (a küldő IPsec-modulnak) mindig KELL használnia ezt a mezőt, de előfordulhat, hogy a fogadónak nem kell feldolgoznia. Rakományadatok(változó) Ez a mező a "Következő fejléc" mező szerinti adatokat tartalmazza. Ez a mező kötelező, és egész számú bájtból áll. Ha a mező titkosításához használt algoritmus a titkosítási folyamatok szinkronizálásához adatokat igényel (például az inicializálási vektort - "Initialization Vector"), akkor ez a mező explicit formában tartalmazhatja ezeket az adatokat. Párnázás(0-255 oktett) Összeadás. Szükséges például olyan algoritmusok esetében, amelyek megkövetelik, hogy a nyílt szöveg egy bizonyos számú bájt többszöröse legyen), például a blokk-rejtjel blokkméretére. Pad hossza(8 bit) Kitöltés mérete (byte-ban). Következő fejléc(8 bit) Ez a mező határozza meg a "Payload data" mezőben található adatok típusát. Integritás-ellenőrzési érték Ellenőrző összeg. IPv6 esetén 8 bájt, IPv4 esetén 4 bájt többszörösének kell lennie.

Kimeneti IPsec-csomagfeldolgozás

Ha a küldő IPsec-modul megállapítja, hogy a csomag olyan SA-hoz van társítva, amely ESP-feldolgozást vár, akkor megkezdi a feldolgozást. A módtól függően (szállítási vagy tunneling mód) az eredeti IP-csomag feldolgozása eltérően történik. Szállítási módban a küldő IPsec-modul végrehajtja a felső réteg protokoll-keretezési (beágyazási) eljárását (például TCP vagy UDP) az ESP-fejléc és az ESP-trailer használatával anélkül, hogy az eredeti IP-csomag fejlécét befolyásolná. Alagút módban az IP-csomagot egy ESP-fejléc és egy ESP-trailer keretezi, majd egy külső IP-fejléc keretezi. Ezt követően a titkosítást hajtják végre - szállítási módban csak az alatta lévő réteg feletti protokoll üzenet (vagyis minden, ami az eredeti csomag IP-fejléce után volt), alagút módban a teljes eredeti IP-csomag titkosítva van. A küldő IPsec modul meghatározza a titkosítási algoritmust és a titkos kulcsot az SA rekordból. Az IPsec szabványok lehetővé teszik a tripla DES, AES és Blowfish titkosítási algoritmusok használatát. Mivel a nyílt szöveg méretének bizonyos számú bájt többszörösének kell lennie, például a blokk-algoritmusok blokkméretének, a titkosított üzenet szükséges hozzáadása is megtörténik a titkosítás előtt. A titkosított üzenet a mezőbe kerül Hasznosterhelési adatok... A terepen Pad hossza illeszkedik a párnázás hosszához. Ezután, mint az AH-ban, kiszámítja Sorszám... Ezután kiszámítjuk az ellenőrző összeget (ICV). Az ellenőrző összeget, az AH protokolltól eltérően, ahol az IP fejléc egyes mezőit is figyelembe veszik a számításnál, az ESP-ben csak az ESP csomag mezőiből számítják ki az ICV mezővel. Az ellenőrző összeg kiszámítása előtt nullákkal töltjük fel. Az ICV kiszámításának algoritmusa, mint az AH protokollban, a küldő IPsec modul a rekordból tanul arról az SA-ról, amelyhez a feldolgozott csomag hozzá van rendelve.

Bejövő IPsec-csomagok feldolgozása

Az ESP-üzenetet tartalmazó csomag fogadása után a fogadó IPsec-modul megkeresi a megfelelő biztonságos virtuális kapcsolatot (SA) a Security Associations Database-ban (SADB) a cél IP-cím, a biztonsági protokoll (ESP) és az SPI-index használatával. Ha nem található megfelelő SA, a csomag eldobásra kerül. A talált biztonságos virtuális kapcsolat (SA) jelzi, hogy a csomag-újraátvitelt megakadályozó szolgáltatás használatban van-e, pl. a Sorozatszám mező ellenőrzésének szükségessége. Ha a szolgáltatást használja, akkor a mező be van jelölve. Ehhez, akárcsak az AH-ban, a csúszóablak módszert alkalmazzák. A fogadó IPsec modul egy W szélességű ablakot hoz létre. Az ablak bal széle megfelel a helyesen vett csomag minimális N sorozatszámának. Az N + 1 és N + W közötti értéket tartalmazó Sorozatszám mezővel rendelkező csomagokat a rendszer helyesen fogadja el. Ha a fogadott csomag az ablak bal szélén van, megsemmisül. Ezután, ha a hitelesítési szolgáltatást használják, az IPsec fogadó modul a kapott csomag megfelelő mezőiből kiszámítja az ICV-t az SA rekordból tanult hitelesítési algoritmus segítségével, és összehasonlítja az eredményt az "Integrity Check Value"-ban található ICV értékkel. terület. Ha a számított ICV érték egybeesik a fogadott értékkel, akkor a bejövő csomag érvényesnek minősül. Ha az ellenőrzés negatív, akkor a fogadó csomag eldobásra kerül. Ezután a csomag visszafejtésre kerül. Az IPsec-vevő az SA rekordból tanulja meg, hogy melyik titkosítási algoritmust és titkos kulcsot használja. Megjegyzendő, hogy az ellenőrzőösszeg-ellenőrzési és visszafejtési eljárás nem csak szekvenciálisan, hanem párhuzamosan is végrehajtható. Ez utóbbi esetben az ellenőrzőösszeg-ellenőrzési eljárásnak a visszafejtési eljárás előtt be kell fejeződnie, és ha az ICV-ellenőrzés sikertelen, a visszafejtési eljárásnak is le kell állnia. Ez lehetővé teszi a rossz csomagok gyorsabb észlelését, ami viszont javítja a szolgáltatásmegtagadási (DOS) támadások elleni védelmet. Továbbá a visszafejtett üzenet a mezőnek megfelelően Következő fejléc továbbítottuk további feldolgozásra.

Használat

Az IPsec-et elsősorban VPN-alagutakhoz használják. Ebben az esetben az ESP és AH protokollok alagút üzemmódban működnek. Ezenkívül a biztonsági házirendek meghatározott módon történő konfigurálásával a protokoll tűzfal létrehozására is használható. A tűzfal lényege, hogy meghatározott szabályok szerint vezérli és szűri a rajta áthaladó csomagokat. Létrejön egy szabálykészlet, és a képernyő megnézi az összes azon áthaladó csomagot. Ha a továbbított csomagokra ezek a szabályok vonatkoznak, a tűzfal ennek megfelelően dolgozza fel azokat. Például vissza tud utasítani bizonyos csomagokat, megszakítva ezzel a nem biztonságos kapcsolatokat. A biztonsági szabályzat megfelelő beállításával például letilthatja az internetes forgalmat. Ehhez elég letiltani a HTTP és HTTPS protokoll üzeneteit tartalmazó csomagok küldését. Az IPsec a szerverek védelmére is használható az összes csomag eldobásával, kivéve azokat, amelyek a kiszolgáló funkcióinak megfelelő végrehajtásához szükségesek. Például blokkolhatja a webszerver teljes forgalmát, kivéve a 80-as TCP-porton vagy a 443-as TCP-porton keresztüli kapcsolatokat, ha HTTPS-t használnak.

Lásd még

Linkek

• IPSec konfiguráció leírása (cisco.com)

Virtuális magánhálózatok (VPN)
Szoftver	Chaply Check Point VPN-1 Cisco Systems VPN-kliens CloudVPN CryptoLink Gbridge Hamachi Jabpunch Microsoft Forefront Unified Access Gateway n2n Hálózati menedzser OpenVPN Openswan plan OpenVPN Edition (ZeroGC Gaming Client) rp-pppoe Social VPN strongSwan Tinc tcpcrypt Vyatta Wippien
Mechanizmusok
Szállító menedzselt

Biztonsági mechanizmusok be

Az IPsec nem egyetlen protokoll, hanem protokollok rendszere, amelyet az IP-hálózatok hálózati rétegének adatainak védelmére terveztek. Ez a cikk leírja az IPsec használatának elméletét VPN-alagút létrehozására.

Bevezetés

Az IPsec technológián alapuló VPN két részre osztható:

• Internet Key Exchange Protocol (IKE)
• IPsec protokollok (AH / ESP / mindkettő)

Az első rész (IKE) a tárgyalási fázis, melynek során a két VPN-társ dönti el, hogy melyik módszerrel védi a közöttük küldött IP-forgalmat. Ezen túlmenően az IKE-t a kapcsolatkezelésre is használják azáltal, hogy minden kapcsolathoz bevezeti a Security Association (SA) fogalmát. Az SA-k csak egyirányúak, így egy tipikus IPsec-kapcsolat két SA-t használ.

A második rész az IP-adatok, amelyeket titkosítani és hitelesíteni kell, mielőtt az első részben megállapodott módszerekkel (IKE) továbbítanák őket. Különféle IPsec protokollok használhatók: AH, ESP vagy mindkettő.

A VPN IPsec-en keresztüli létrehozásának sorrendje a következőképpen foglalható össze:

• Az IKE megtárgyalja az IKE rétegbiztonságot
• Az IKE tárgyalja az IPsec-réteg biztonságát
• A védett adatok továbbítása VPN IPsec-en keresztül történik

IKE, internetes kulcscsere

Az adatok titkosításához és hitelesítéséhez ki kell választani a titkosítási/hitelesítési módszert (algoritmust) és az azokban használt kulcsokat. Az Internet Key Exchange protokoll, az IKE feladata ebben az esetben ezeknek a "munkamenetkulcsoknak" a szétosztásában és a VPN-pontok közötti adatok védelmét szolgáló algoritmusok egyeztetésében rejlik.

Az IKE fő feladatai:

• Egymás VPN-pontjainak hitelesítése
• Új IPsec kapcsolatok szervezése (SA párok létrehozásával)
• Aktuális kapcsolatok kezelése

Az IKE nyomon követi a kapcsolatokat úgy, hogy mindegyikhez hozzárendel egy biztonsági szövetséget, SA. Az SA egy adott kapcsolat paramétereit írja le, beleértve az IPsec protokollt (AH / ESP vagy mindkettő), az adatok titkosításához / visszafejtéséhez és / vagy hitelesítéséhez használt munkamenet kulcsokat. Az SA egyirányú, így kapcsolatonként több SA-t használnak. A legtöbb esetben, amikor csak ESP vagy AH van használatban, csak két SA jön létre minden egyes kapcsolathoz, egy a bejövő és egy a kimenő forgalomhoz. Ha az ESP-t és az AH-t együtt használják, négy SA-ra van szükség.

Az IKE tárgyalási folyamata több szakaszon (fázison) megy keresztül. Ezek a fázisok a következők:

1. IKE 1. fázis:
   - Magának az IKE védelmének tárgyalása (ISAKMP alagút)
2. IKE 2. fázis (IKE Phase-2):
   - IPsec védelem egyeztetve
   - Adatok fogadása az első fázisból a munkamenetkulcsok generálásához

Az IKE- és IPsec-kapcsolatok időtartama (másodpercben) és az átvitt adatok mennyisége (kilobájtban) korlátozott. Ez a biztonság javítása érdekében történik.
Az IPsec-kapcsolat időtartama általában rövidebb, mint az IKE. Ezért, amikor az IPsec-kapcsolat lejár, az egyeztetés második szakaszában új IPsec-kapcsolat jön létre. Az egyeztetés első fázisa csak az IKE-kapcsolat újralétesítésekor használatos.

Az IKE-tárgyaláshoz bevezetik az IKE-javaslatot, amely az adatok védelmére vonatkozó javaslat. Az IPsec-kapcsolatot kezdeményező VPN-pont egy listát (ajánlatot) küld, amely különböző módszereket határoz meg a kapcsolat biztosítására.
Tárgyalni lehet mind új IPsec kapcsolat létesítéséről, mind új IKE kapcsolat létesítéséről. Az IPsec esetében a védett adat a VPN alagúton keresztül továbbított forgalom, az IKE esetében pedig maguk az IKE tárgyalások adatai.
A listát (ajánlatot) fogadó VPN-pont kiválasztja belőle a legmegfelelőbbet, és ezt jelzi a válaszban. Ha egyik ajánlat sem választható ki, a VPN-átjáró visszautasítja.
Az ajánlat tartalmazza az összes szükséges információt a titkosítási és hitelesítési algoritmus kiválasztásához stb.

I. fázis IKE – IKE biztonsági egyeztetés (ISAKMP alagút)
Az egyeztetés első szakaszában a VPN-ek egy előre megosztott kulcs alapján hitelesítik egymást. A hitelesítéshez a hash algoritmust használják: MD5, SHA-1, SHA-2.
Egymás hitelesítése előtt azonban, hogy ne tiszta szövegben továbbítsák az információkat, a VPN-társak elvégzik a korábban leírt Javaslatok cseréjét. Csak a mindkét VPN-pontnak megfelelő ajánlat kiválasztása után kerül sor egymás VPN-pontjainak hitelesítésére.
A hitelesítés többféleképpen történhet: Előre megosztott kulcsokon, tanúsítványokon, ill. A megosztott kulcsok a leggyakoribb hitelesítési módszerek.
Az I. fázisú IKE egyeztetés két mód egyikében történhet: fő és agresszív. A fő mód hosszabb, de biztonságosabb is. A folyamat során hat üzenetet váltanak ki. Az agresszív mód gyorsabb, három üzenetre korlátozódik.
Az IKE első fázisának fő munkája a Diffie-Hellman kulcscserében rejlik. Nyilvános kulcsú titkosításon alapul, mindkét oldal titkosítja a hitelesítési paramétert (Pre-Shared Key) a szomszéd nyilvános kulcsával, aki ezt az üzenetet megkapva a privát kulcsával visszafejti. A felek egymás közötti hitelesítésének másik módja a tanúsítványok használata.

II. fázis IKE – IPsec biztonsági tárgyalás
A második fázisban az IPsec-kapcsolat védelmének módját választják ki.
A második fázis az első fázisban lezajlott Diffie-Hellman kulcscseréből kinyert kulcsanyagot használja. Ezen anyag alapján munkamenetkulcsokat hoznak létre, amelyek a VPN alagútban lévő adatok védelmére szolgálnak.

Ha a mechanizmust használják Tökéletes továbbítási titok (PFS) akkor minden második tárgyalási fázishoz egy új Diffie-Hellman kulcscsere kerül felhasználásra. Kissé csökkentve a munka sebességét, ez az eljárás biztosítja, hogy a munkamenet-kulcsok függetlenek legyenek egymástól, ami növeli a védelmet, mert még ha valamelyik billentyű sérül is, akkor sem használható a többi durva erőszakra.

Az IKE egyeztetés második fázisának egyetlen üzemmódja van, ezt gyors üzemmódnak hívják. A második szakasz tárgyalása során három üzenetet váltanak ki.

A második fázis végén VPN-kapcsolat jön létre.

IKE paraméterek.
A kapcsolat létesítése során számos olyan paraméter kerül felhasználásra, amelyek egyeztetése nélkül lehetetlen VPN-kapcsolatot létrehozni.

• Végpont azonosítás
  Hogyan hitelesítik egymást a csomópontok. A leggyakrabban használt kulcs a megosztott kulcs. A megosztott kulcson alapuló hitelesítés a Diffie-Hellman algoritmust használja.
• Helyi és távoli hálózat / gazdagép
  Meghatározza a VPN-alagúton keresztül továbbított forgalmat.
• Alagút vagy szállítási mód.
  Az IPsec két módban működhet: alagútban és szállításban. Az üzemmód kiválasztása a védett objektumoktól függ.
  Alagút mód távoli objektumok közötti védelemre szolgál, pl. Az IP-csomag teljesen egy újba van burkolva, és csak a két VPN-pont közötti kapcsolat lesz látható a külső szemlélő számára. A valódi forrás és cél IP-cím csak a csomag kicsomagolása után lesz látható, amikor a VPN fogadópontja megérkezik. Ezért VPN-kapcsolatokhoz leggyakrabban az alagút módot használják.
  Szállítási mód védi az IP-csomagadatokat (TCP, UDP és felső réteg protokollok), és maga az eredeti IP-csomag fejléc is megmarad. Így a megfigyelő látni fogja az eredeti forrást és célállomást, de a továbbított adatokat nem. Ezt a módot leggyakrabban a gazdagépek közötti helyi hálózati kapcsolat biztosítására használják.
• Távoli átjáró
  A VPN-pont a biztonságos kapcsolat címzettje, amely dekódolja / hitelesíti a másik oldalról származó adatokat, és elküldi a végső célállomásra.
• IKE üzemmód
  Az IKE egyeztetés két módban működhet: alapvetőés agresszív.
  A különbség a kettő között az, hogy agresszív módban kevesebb csomagot használnak fel, ami gyorsabb kapcsolatépítést tesz lehetővé. Másrészt az agresszív mód nem továbbít néhány egyeztetési paramétert, például a Diffie-Hellman csoportokat és a PFS-t, ami megköveteli, hogy azokat előzetesen azonos módon konfigurálják a csatlakozási pontokon.
• IPsec protokollok
  Két IPsec protokoll létezik, a hitelesítési fejléc (AH) és az Encapsulating Security Payload (ESP), amelyek titkosítási és hitelesítési funkciókat látnak el.
  Az ESP lehetővé teszi a titkosítást, hitelesítést egyénileg vagy egyidejűleg.
  Az AH csak hitelesítést tesz lehetővé. Az ESP-hitelesítéssel szemben az a különbség, hogy az AH hitelesíti a külső IP-fejlécet is, így megbizonyosodhatunk arról, hogy a csomag valóban a benne megjelölt forrásból származik-e.
• IKE titkosítás
  Meghatározza a használandó IKE titkosítási algoritmust és annak kulcsait. Különféle szimmetrikus titkosítási algoritmusok támogatottak, például: DES, 3DES, AES.
• IKE hitelesítés
  Az IKE egyeztetés során használt hitelesítési algoritmus. Lehet: SHA, MD5.
• IKE Diffie-Hellman (DH) csoportok
  Az IKE kulcscseréhez használt DF csoport. Minél nagyobb a csoport, annál nagyobb a cserekulcsok mérete.
• IKE kapcsolat élettartama
  Ezt mind az idő (másodperc), mind az átvitt adatok mérete (kilobyte) jelzi. Amint az egyik számláló eléri a küszöbértéket, egy új első fázis kezdődik. Ha az IKE-kapcsolat létrehozása óta nem történt adatátvitel, akkor nem jön létre új kapcsolat mindaddig, amíg valamelyik fél VPN-kapcsolatot nem akar létrehozni.
• PFS
  Ha a PFS le van tiltva, a kulcsgenerálási anyag az IKE-egyeztetés első fázisában, a kulcscsere időpontjában kerül lekérésre. Az IKE egyeztetés második szakaszában a beérkezett anyagok alapján munkamenetkulcsokat generálnak. Ha a PFS engedélyezve van, új szekciókulcsok létrehozásakor a hozzájuk tartozó anyag minden új kulcs létrehozása után kerül felhasználásra. Így ha egy kulcs kompromittálódik, akkor az alapján nem lehet új kulcsokat létrehozni.
  A PFS két módban használható: az első PFS a kulcsokon új kulcscserét indít el az IKE első fázisában minden tárgyalás megkezdésekor.
  második fázis. A második mód, a PFS az identitásokon, minden alkalommal eltávolítja az első fázis SA-kat a második fázis egyeztetés után, ezáltal biztosítva, hogy a második fázis egyeztetés ne legyen titkosítva ugyanazzal a kulccsal, mint az előző.
• IPsec DH csoportok
  A DF csoport adatai hasonlóak az IKE-ben használtakhoz, csak a PFS-hez használják őket.
• IPsec titkosítás
  Az adatok titkosítására használt algoritmus. Az ESP titkosítási módban történő használatakor használatos. Algoritmus példa: DES, 3DES, AES.
• IPsec hitelesítés
  A továbbított adatok hitelesítésére használt algoritmus. AH vagy ESP esetén használatos hitelesítési módban. Példa az algoritmusra: SHA, MD5.
• IPsec élettartam
  A VPN-kapcsolat élettartamát mind az idő (másodperc), mind az átvitt adatok mérete (kilobyte) jelzi. A korlátot elsőként elérő számláló megkezdi a munkamenetkulcsok újragenerálását. Ha az IKE-kapcsolat létrehozása óta nem történt adatátvitel, akkor nem jön létre új kapcsolat mindaddig, amíg valamelyik fél VPN-kapcsolatot nem akar létrehozni.

IKE hitelesítési módszerek

• Kézi mód
  A módszerek közül a legegyszerűbb, amelyben nem használunk IKE-t, valamint a hitelesítési és titkosítási kulcsokat, valamint néhány egyéb paramétert mindkét VPN csatlakozási ponton manuálisan állítjuk be.
• Előre megosztott kulcsok (PSK)
  Egy előre megadott megosztott kulcs a VPN-kapcsolat mindkét pontján. A különbség az előző módszertől az, hogy IKE-t használ, amely lehetővé teszi a végpontok hitelesítését, és változó munkamenetkulcsokat használ a rögzített titkosítási kulcsok helyett.
• Tanúsítványok
  Minden VPN-pont a következőket használja: saját privát kulcsa, saját nyilvános kulcsa, saját tanúsítványa, beleértve a saját nyilvános kulcsát, és amelyet egy megbízható hitelesítésszolgáltató ír alá. Az előző módszertől eltérően elkerüli, hogy a VPN-kapcsolat minden pontján egyetlen megosztott kulcsot adjanak meg, és azt megbízható hatóság által aláírt személyes tanúsítványokra cserélik.

IPsec protokollok

Az IPsec protokollok a továbbított adatok védelmére szolgálnak. A protokoll és a kulcsok kiválasztása az IKE egyeztetés során történik.

AH (hitelesítési fejléc)

Az AH lehetőséget biztosít a továbbított adatok hitelesítésére. Ehhez egy kriptográfiai hash függvényt használnak az IP-csomagban lévő adatokkal kapcsolatban. Ennek a függvénynek a kimenete (hash) a csomaggal együtt kerül elküldésre, és lehetővé teszi a távoli VPN-pont számára, hogy ellenőrizze az eredeti IP-csomag integritását, megerősítve, hogy az nem módosult az út során. Az IP-csomagadatokon kívül az AH a fejlécének egy részét is hitelesíti.

Szállítási módban az AH a fejlécét az eredeti IP-csomag után ágyazza be.
Alagút módban az AH a fejlécét a külső (új) IP-fejléc után és a belső (eredeti) IP-fejléc elé illeszti.

ESP (Encapsulating Security Payload)

Az ESP titkosításra, hitelesítésre vagy mindkettőre használható egy IP-csomag vonatkozásában.

ESP szállítási módban a protokoll az eredeti IP-fejléc mögé szúrja be a fejlécet.
ESP tunnel módban a fejléc a külső (új) IP fejléc után és a belső (eredeti) előtt található.

A két fő különbség az ESP és az AH között:

• Az ESP a hitelesítés mellett titkosítást is biztosít (az AH ezt nem biztosítja)
• Az ESP alagút módban csak az eredeti IP-fejlécet hitelesíti (az AH a külsőt is hitelesíti).

Munka a NAT (NAT Traversal) mögött
Külön specifikáció került bevezetésre a NAT mögötti munka támogatására. Ha a VPN-végpont támogatja ezt a specifikációt, az IPsec támogatja a NAT-ot, azonban vannak bizonyos követelmények.
A NAT támogatás két részből áll:

• Az IKE szintjén a végeszközök kommunikálnak egymással a támogatásról, a NAT-bejárásról és a támogatott specifikáció verziójáról.
• Az ESP rétegben a generált csomag UDP-be van tokozva.

A NAT-bejárás csak akkor használatos, ha mindkét végpont támogatja.
A NAT definíciója: Mindkét VPN-társ elküldi IP-címének kivonatát az IKE-egyeztetés forrásának UDP-portjával együtt. Ezt az információt használja a címzett annak meghatározására, hogy a forrás IP-címe és/vagy portja megváltozott-e. Ha ezek a paraméterek nem változtak, akkor a forgalom nem halad át a NAT-on, és nincs szükség a NAT-bejárási mechanizmusra. Ha a cím vagy a port megváltozott, akkor NAT van az eszközök között.

Miután a végpontok megállapítják, hogy NAT-bejárásra van szükség, az IKE-egyeztetés az 500-as UDP-portról a 4500-as portra kerül. Ez azért történik, mert egyes eszközök helytelenül kezelik az 500-as porton lévő IKE-munkamenetet a NAT használatakor.
Egy másik probléma azért merül fel, mert az ESP protokoll egy szállítási réteg protokoll, és közvetlenül az IP tetején található. Emiatt a TCP / UDP port fogalma nem alkalmazható rá, ami lehetetlenné teszi, hogy egynél több kliens csatlakozzon ugyanahhoz az átjáróhoz NAT-on keresztül. A probléma megoldása érdekében az ESP-t egy UDP-datagramba csomagolják, és a 4500-as portra küldik, ugyanarra a portra, amelyet az IKE használ, amikor a NAT-bejárás engedélyezett.
A NAT Traversal be van építve az azt támogató protokollokba, és már a dobozból is működik.

Az IPSec fogalmát már tárgyaltuk, ebben a cikkben az IPSec-et fogjuk közelebbről megvizsgálni.

Tehát az IPSec név az IP Security szóból származik.
Az IPSec protokollok és algoritmusok gyűjteménye, amelyek az IP-csomagok védelmére szolgálnak Layer3 szinten.

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.

Soroljuk fel a fő IPsec protokollokat:
■ ESP és AH: Az IPsecben használt két fő protokoll.
Encapsulating Security Payload (ESP), mindent megtehet, ami az IPsec-hez 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 használják leggyakrabban az ESP-t.
■ 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), amit lehet használni
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.

Biztosítanunk kell a két iroda összekapcsolását és az alábbi célokat teljesíteni:

• Titoktartás- adattitkosítással biztosított.
• Adatok integritása- 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 megvédi őket az ismétléstől.

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 bejá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 követése (4. réteg 50. protokoll)
ESP	Layer 4 protokoll 50	Minden IPSec-csomag az ESP 4. rétegbeli protokollja (IP Protocol # 50), amely az összes adatot magába foglalja. Általában ESP-t használnak (nem AH-t). NAT-T használata esetén az ESP fejlécet a második UDP fejléc fedi.
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, amelyet a Internet Security Association, és 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 R2 útválasztóval.

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 felhasználói adatok továbbítására szolgál, hanem szolgáltatási 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 tekinthető.

Az IKE 1. fázisú alagútjának emeléséhez a következő elemeket kell megtárgyalni:

• 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 a 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 billentyűket, é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 irányelvében, 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, hogy biztonságosan cseréljenek szimmetrikus kulcsokat, amelyeket szimmetrikus algoritmusok, például AES fognak használni.

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

Az utolsó dolog, amit az IKE 1. fázisában megtesznek, a gazdagépek kölcsönös hitelesítése, amely két módszerrel (PSK vagy RSA digitális aláírás) történhet.
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 felemelni az IKE 1. fázis alagútját.
Mint már említettük, az IKE 1. fázisú alagútja pusztán szolgáltatási, felügyeleti alagút, és az összes tárgyalási forgalom ezen halad át az IKE 2. fázisú alagút felemelése érdekében.
Az IKE Phase 2 alagútja kivonatolási és titkosítási algoritmusokat is használ.
Az IKE 2. fázisú alagút emelése egyetlen módban hajtható végre:
- gyors mód

Az IKE Phase 2 alagút valójában két egyirányú alagút, azaz. azt mondhatjuk, hogy létrejöttek:
Egy IKE Phase 1 alagút, amely kétirányú a háztartásban.
És két IKE Phase 2 alagút, amelyek egyirányúak, és amelyeket a hasznos forgalom titkosítására használnak.
Mindezeket az alagutakat úgy is emlegetik 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észeket elhagyó összes csomag titkosítva lesz.

Konfigurációs példa

Tekintsünk egy példát az IPsec-konfigurációra ennek a diagramnak a példájá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 üzleti célokra használt alagutat hoz létre: titkos kulcsok megosztása, 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

   Ez a kulcs a PSK (előre megosztott kulcs), 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 teherforgalom átvitele a 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 kriptográfiai 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 kriptográfiai 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.

   kriptotérkép felkerül a felületre. A CryptoMap a meghatározott feltételeknek megfelelő forgalmat figyeli. A kriptográfiai térképünk egy 100.100.100.1 címû útválasztóval fog mûködni, amelyet az ACL állított be a belsõ forgalomhoz, é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
mutasd meg a kriptográfiai térképet
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: