IPsec

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 4 april 2019; kontroller kräver 22 redigeringar .

IPsec (förkortning för IP-säkerhet ) är en uppsättning protokoll för att säkerställa skyddet av data som överförs över internetprotokollet IP . Tillåter autentisering ( autentisering ), integritetskontroll och/eller kryptering av IP-paket. IPsec inkluderar även protokoll för säkert nyckelutbyteInternet . Det används främst för att organisera VPN- anslutningar.

Historik

Från början skapades Internet som ett säkert medium för överföring av data mellan militären. Eftersom bara en viss krets av människor arbetade med det, folk som var utbildade och hade en idé om säkerhetspolitik, fanns det inget självklart behov av att bygga säkra protokoll. Säkerheten organiserades i nivå med fysisk isolering av objekt från obehöriga, och detta var motiverat när ett begränsat antal maskiner hade tillgång till nätverket. Men när Internet blev offentligt och började aktivt utvecklas och växa uppstod ett sådant behov [1] .

Och 1994 släppte Internet Architecture Board (IAB) rapporten "Internet Architectural Security". Den ägnades främst åt metoder för skydd mot obehörig övervakning, paketförfalskning och dataflödeskontroll. Någon standard eller koncept behövdes för att lösa detta problem. Som ett resultat uppstod säkra protokollstandarder, inklusive IPsec. Till en början inkluderade den tre grundläggande specifikationer som beskrivs i dokumenten (RFC1825, 1826 och 1827), men därefter reviderade IETFs IP Security Protocol- arbetsgrupp dem och föreslog nya standarder (RFC2401 - RFC2412), som fortfarande används idag.

Standarder

IPsec-arkitektur

Konstruktionen av en säker kommunikationskanal kan implementeras på olika nivåer av OSI-modellen . IPsec implementeras på nätverkslagret . Det finns flera motstridiga argument när det gäller valet av implementeringsnivå för säker kanal: å ena sidan stöds valet av de övre nivåerna av deras oberoende av typen av transport (valet av nätverk och länklagerprotokoll), å andra sidan hand kräver varje applikation en separat inställning och konfiguration. Fördelen med att välja de lägre lagren är deras mångsidighet och synlighet för applikationer, nackdelen är beroendet av valet av ett visst protokoll (till exempel PPP eller Ethernet ). Det faktum att IPsec finns i nätverkslagret är en kompromiss i valet av OSI-lagret. IPsec använder det vanligaste nätverkslagerprotokollet - IP , vilket gör användningen av IPsec flexibel - det kan användas för att skydda alla IP-baserade protokoll ( TCP , UDP och andra). Samtidigt är det transparent för de flesta applikationer [2] .

IPsec är en uppsättning Internetstandarder och ett slags "tillägg" till IP-protokollet. Dess kärna består av tre protokoll [3] :

Ett av nyckelbegreppen är också Security Association (SA). Faktum är att SA är en uppsättning parametrar som kännetecknar anslutningen. Till exempel, krypteringsalgoritmen och hashfunktionen som används , hemliga nycklar, paketnummer, etc.

Tunnel och transportsätt

IPsec kan fungera i två lägen: transport och tunnel.

I transportläge är endast data från IP-paketet krypterade eller signerade, den ursprungliga rubriken bevaras. Transportläge används vanligtvis för att upprätta en anslutning mellan värdar. Den kan också användas mellan gateways för att säkra tunnlar organiserade på annat sätt (se t.ex. L2TP ).

I tunnelläge krypteras hela det ursprungliga IP-paketet: data, header, routinginformation, och sedan infogas det i datafältet för ett nytt paket, det vill säga inkapsling sker [4] . Tunnelläge kan användas för att ansluta fjärrdatorer till ett virtuellt privat nätverk eller för att organisera säker dataöverföring över öppna kommunikationskanaler (till exempel Internet) mellan gateways för att kombinera olika delar av ett virtuellt privat nätverk .

IPsec-lägen utesluter inte varandra. På samma värd kan vissa SA:er använda transportläge, medan andra kan använda tunnelläge.

Security Association

För att börja utbyta data mellan två parter måste du upprätta en anslutning, som kallas SA (Security Association). Konceptet SA är grundläggande för IPsec, i själva verket är dess essens. Den beskriver hur parterna kommer att använda tjänsterna för att tillhandahålla säker kommunikation. En SA-anslutning är enkel (enkelriktad), så två anslutningar måste upprättas för att parterna ska kunna kommunicera. Det är också värt att notera att IPsec-standarderna tillåter säkra kanalslutpunkter att använda både en SA för att överföra trafik från alla värdar som interagerar genom denna kanal och att skapa ett godtyckligt antal säkra associationer för detta ändamål, till exempel en för varje TCP-anslutning . Detta gör det möjligt att välja önskad nivå av skyddsdetalj. [2] Att upprätta en förbindelse börjar med ömsesidig autentisering av parterna. Därefter väljs parametrarna (om autentisering, kryptering, dataintegritetskontroller kommer att utföras) och det erforderliga protokollet (AH eller ESP) för dataöverföring. Därefter väljs specifika algoritmer (till exempel kryptering, hashfunktion) från flera möjliga scheman, av vilka några definieras av standarden (för kryptering - DES , för hashfunktioner - MD5 eller SHA-1 ), andra läggs till av tillverkare av produkter som använder IPsec (t.ex. Triple DES , Blowfish , CAST ) [5] .

Säkerhetsföreningars databas

Alla SA:er lagras i SAD (Security Associations Database) i IPsec-modulen. Varje SA har en unik markör som består av tre element [6] :

IPsec-modulen, med dessa tre parametrar, kan slå upp en särskild SA-post i SAD. Listan över SA-komponenter inkluderar [7] :

Serienummer Ett 32-bitars värde som används för att bilda sekvensnummerfältet i AH- och ESP-huvudena. Sekvensräknare spill En flagga som signalerar överflödet av sekvensnummerräknaren. Spela om attackundertryckningsfönstret Används för att bestämma omsändning av paket. Om värdet i fältet Sekvensnummer inte faller inom det angivna intervallet, förstörs paketet. AH Information den använda autentiseringsalgoritmen, de nödvändiga nycklarna, nycklarnas livslängd och andra parametrar. ESP-information krypterings- och autentiseringsalgoritmer, nödvändiga nycklar, initialiseringsparametrar (till exempel IV), nyckellivslängd och andra parametrar IPsec driftläge tunnel eller transport SA livstid Anges i sekunder eller bytes av information som passerar genom tunneln. Bestämmer varaktigheten av existensen av SA, när detta värde uppnås måste den nuvarande SA avslutas, om nödvändigt, fortsätt anslutningen, en ny SA upprättas. MTU Den maximala paketstorlek som kan skickas över en virtuell krets utan fragmentering.

Varje protokoll (ESP/AH) måste ha sin egen SA för varje riktning, så AH+ESP kräver fyra SA:er för en duplexlänk . Alla dessa data finns i SAD.

SAD innehåller:

Säkerhetspolicydatabas

Utöver SAD-databasen stöder IPsec-implementeringar Security Policy Database (SPD). SPD används för att korrelera inkommande IP-paket med bearbetningsregler för dem. Poster i SPD består av två fält. [8] Den första lagrar paketens karaktäristiska egenskaper, enligt vilka ett eller annat informationsflöde kan urskiljas. Dessa fält kallas väljare. Exempel på väljare som finns i SPD [6] :

Det andra fältet i SPD innehåller säkerhetspolicyn som är associerad med denna paketström. Väljare används för att filtrera utgående paket för att matcha varje paket med en specifik SA. När ett paket anländer jämförs värdena för motsvarande fält i paketet (väljarfält) med de som finns i SPD. När en matchning hittas innehåller säkerhetspolicyfältet information om hur man hanterar detta paket: skicka det oförändrat, kassera det eller bearbeta det. Vid bearbetning innehåller samma fält en länk till motsvarande post i SAD. SA för paketet och dess tillhörande säkerhetsparameterindex (SPI) bestäms sedan, varefter IPsec-operationer (AH- eller ESP-protokolloperationer) utförs. Om paketet kommer in, innehåller det omedelbart SPI - motsvarande bearbetning utförs.

Autentiseringshuvud

Format för autentiseringshuvud
offset 16 oktober 0 ett 2 3
16 oktober bit 10 0 ett 2 3 fyra 5 6 7 åtta 9 tio elva 12 13 fjorton femton 16 17 arton 19 tjugo 21 22 23 24 25 26 27 28 29 trettio 31
0 0 Nästa rubrik Nyttolast Len Reserverad
fyra 32 Säkerhetsparameterindex (SPI)
åtta 64 sekvensnummer
C 96 Integritetskontrollvärde (ICV)
Nästa rubriktyp (8 bitar) Typen av protokollhuvud som kommer efter AH-huvudet. Genom att använda det här fältet lär sig den mottagande IP-sec-modulen om det skyddade övre lagrets protokoll. Se RFC 1700 för betydelsen av detta fält för olika protokoll . Innehållslängd (8 bitar) Det här fältet anger den totala storleken på AH-huvudet i 32-bitars ord, minus 2. När man använder IPv6 måste dock längden på rubriken vara en multipel av 8 byte. Reserverad (16 bitar) Reserverad. Fylld med nollor. Säkerhetsinställningar index (32 bitar) Säkerhetsinställningar index. Värdet på detta fält, tillsammans med destinationens IP-adress och säkerhetsprotokoll (AH-protokoll), identifierar unikt den säkra virtuella anslutningen (SA) för detta paket. SPI-värdeintervall 1…255 är reserverat av IANA . Sekvensnummer (32 bitar) Serienummer. Fungerar som skydd mot återsändning. Fältet innehåller ett monotont ökande parametervärde. Även om mottagaren kan välja bort skyddstjänsten för paketåteröverföring, är den obligatorisk och finns alltid i AH-huvudet. Den sändande IPsec-modulen använder alltid detta fält, men mottagaren KAN inte bearbeta det. Autentiseringsdata Digital signatur. Används för att autentisera och verifiera paketets integritet. Måste utfyllas till en multipel av 8 byte för IPv6 och 4 byte för IPv4.

AH-protokollet används för autentisering, det vill säga för att bekräfta att vi kommunicerar med exakt den vi tror att vi är, och att data vi tar emot inte manipuleras under överföring [9] .

Hantera utgående IP-paket

Om den sändande IPsec-modulen bestämmer att paketet är associerat med en SA som kräver AH-bearbetning, börjar bearbetningen. Beroende på läge (transport- eller tunnelläge) infogar den AH-huvudet på olika sätt i IP-paketet. I transportläge visas AH-huvudet efter IP-protokollhuvudet och före protokollhuvudena för det övre lagret (vanligtvis TCP eller UDP ). I tunnelläge inramas hela käll-IP-paketet först med AH-huvudet, sedan med IP-protokollhuvudet. En sådan rubrik kallas yttre, och huvudet på det ursprungliga IP-paketet kallas inre. Därefter måste den sändande IPsec-modulen generera ett sekvensnummer och skriva det i fältet Sekvensnummer . När en SA upprättas sätts sekvensnumret till 0 och ökas med ett innan varje IPsec-paket skickas. Dessutom är det en kontroll för att se om räknaren har gått i cykler. Om den har nått sitt maximala värde, sätts den tillbaka till 0. Om återsändningsförhindrande tjänst används, när räknaren når sitt maximala värde, återställer den sändande IPsec-modulen SA:n. Detta ger skydd mot omsändning av paket - den mottagande IPsec-modulen kontrollerar fältet Sekvensnummer och ignorerar återinkommande paket. Därefter beräknas ICV-kontrollsumman. Det bör noteras att här beräknas kontrollsumman med hjälp av en hemlig nyckel, utan vilken en angripare kommer att kunna räkna om hashen, men utan att känna till nyckeln kommer han inte att kunna bilda den korrekta kontrollsumman. De specifika algoritmerna som används för att beräkna ICV finns i RFC 4305 . För närvarande kan till exempel HMAC-SHA1-96 eller AES-XCBC-MAC-96 algoritmer användas. AH-protokollet beräknar kontrollsumman (ICV) från följande fält i IPsec-paketet [10] :

Bearbetning av inkommande IP-paket

Vid mottagande av ett paket som innehåller ett AH-protokollmeddelande, letar den mottagande IPsec-modulen upp den lämpliga SAD (Security Associations Database) säker virtuell anslutning (SA) med hjälp av destinationens IP-adress, säkerhetsprotokoll (AH) och SPI-index. Om ingen matchande SA hittas, kasseras paketet. Den hittade säkra virtuella anslutningen (SA) indikerar om tjänsten används för att förhindra återöverföring av paket, det vill säga behovet av att kontrollera fältet Sekvensnummer . Om tjänsten används är fältet markerat. Detta använder en skjutfönstermetod för att begränsa buffertminnet som krävs för att protokollet ska fungera. Den mottagande IPsec-modulen bildar ett fönster med en bredd W (vanligtvis väljs W till 32 eller 64 paket). Den vänstra kanten av fönstret motsvarar det minsta sekvensnumret ( Sequence Number ) N för ett korrekt mottaget paket. Ett paket med ett sekvensnummerfält som innehåller ett värde från N+1 till N+W tas emot korrekt. Om det mottagna paketet finns på fönstrets vänstra kant, förstörs det. Den mottagande IPsec-modulen beräknar sedan ICV från lämpliga fält i det mottagna paketet med användning av autentiseringsalgoritmen som den lär sig från SA-posten och jämför resultatet med ICV-värdet som finns i fältet "Integrity Check Value". Om det beräknade ICV-värdet matchar det mottagna, anses det inkommande paketet vara giltigt och accepteras för vidare IP-bearbetning. Om kontrollen misslyckas, förstörs det mottagna paketet [10] .

Encapsulating Security Payload

Encapsulating Security Payload -format
offset 16 oktober 0 ett 2 3
16 oktober bit 10 0 ett 2 3 fyra 5 6 7 åtta 9 tio elva 12 13 fjorton femton 16 17 arton 19 tjugo 21 22 23 24 25 26 27 28 29 trettio 31
0 0 Säkerhetsparameterindex (SPI)
fyra 32 sekvensnummer
åtta 64 nyttolastdata
   
  Vaddering (0-255 oktetter)  
  Pads längd Nästa rubrik
Integritetskontrollvärde (ICV)
Säkerhetsparameterindex (32 bitar) Säkerhetsinställningar Index (liknande motsvarande AH-fält). Värdet på detta fält, tillsammans med destinationens IP-adress och säkerhetsprotokoll (ESP), identifierar unikt den säkra virtuella anslutningen (SA) för detta paket. SPI-värdeintervallet 1…255 är reserverat av IANA för framtida användning. Sekvensnummer (32 bitar) Sekvensnummer (liknande motsvarande AH-fält). Fungerar som skydd mot återsändning. Fältet innehåller ett monotont ökande parametervärde. Även om mottagaren kan välja bort skyddstjänsten för paketåteröverföring, finns den alltid i ESP-huvudet. Avsändaren (sändande IPsec-modul) MÅSTE alltid använda detta fält, men mottagaren behöver kanske inte bearbeta det. nyttolastdata (variabel) Detta fält innehåller data (beroende på valet av läge - tunnel eller transport, antingen hela det inkapslade originalpaketet eller bara dess data kan finnas här) i enlighet med fältet "Nästa rubrik". Detta fält är obligatoriskt och består av ett heltal av byte. Om algoritmen som används för att kryptera det här fältet kräver data för att synkronisera kryptoprocesser (till exempel initialiseringsvektorn - "Initialiseringsvektor" ), kan detta fält innehålla denna data explicit. Vaddering (0-255 oktetter) Tillägg. Nödvändigt, till exempel, för algoritmer som kräver att klartexten är en multipel av ett visst antal byte, såsom blockstorleken för ett blockchiffer. Padslängd (8 bitar) Utfyllnadsstorleken (i byte). Nästa rubrik (8 bitar) Det här fältet anger vilken typ av data som finns i fältet "Nyttlastdata". Integritetskontrollvärde Kontrollera summan. Används för att autentisera och verifiera paketets integritet. Måste vara en multipel av 8 byte för IPv6 och 4 byte för IPv4 [11] .

Hantera IPsec-utdatapaket

Om den sändande IPsec-modulen fastställer att paketet är associerat med en SA som kräver ESP-bearbetning, börjar bearbetningen. Beroende på läge (transport- eller tunnelläge) behandlas det ursprungliga IP-paketet på olika sätt. I transportläge utför den sändande IPsec-modulen inramningsproceduren för det övre lagrets protokoll (till exempel TCP eller UDP), med hjälp av ESP-huvudet (fälten Säkerhetsparametrar Index och Sekvensnummer i rubriken) och ESP-trailern (resten fält i rubriken efter datafältet) för detta - Nyttolastdata), utan att det påverkar huvudet på det ursprungliga IP-paketet. I tunnelläge ramas IP-paketet in med en ESP-header och en ESP-trailer ( inkapsling ), varefter det ramas in med en extern IP-header (som kanske inte matchar originalet - till exempel om IPsec-modulen är installerad på porten ) [8 ] . Därefter utförs kryptering - i transportläge krypteras endast meddelandet från det övre lagrets protokoll (det vill säga allt som var efter IP-huvudet i källpaketet), i tunnelläge - hela käll-IP-paketet. Den sändande IPsec-modulen från SA-posten bestämmer krypteringsalgoritmen och den hemliga nyckeln . IPsec-standarderna tillåter användning av krypteringsalgoritmerna Triple DES , AES och Blowfish om båda parter stöder dem. Annars används DES enligt RFC 2405 . Eftersom storleken på vanlig text måste vara en multipel av ett visst antal byte, till exempel blockstorleken för blockalgoritmer , utförs även den nödvändiga tillägget av det krypterade meddelandet före kryptering. Det krypterade meddelandet placeras i fältet Nyttolastdata . Fältet Pad Length innehåller längden på dynan . Sedan, som i AH, beräknas sekvensnumret, varefter kontrollsumman (ICV) beräknas. Kontrollsumman, i motsats till AH-protokollet, där vissa fält i IP-huvudet också tas med i beräkningen vid beräkning av den, beräknas i ESP endast av fälten i ESP-paketet minus ICV-fältet. Innan kontrollsumman beräknas fylls den med nollor. ICV-beräkningsalgoritmen, som i AH-protokollet, lär sig den sändande IPsec-modulen från posten om den SA med vilken det behandlade paketet är associerat.

Bearbetning av inkommande IPsec-paket

Vid mottagande av ett paket som innehåller ett ESP-protokollmeddelande, letar den mottagande IPsec-modulen upp den lämpliga säkra virtuella anslutningen (SA) i SAD:n med hjälp av destinations-IP-adressen, säkerhetsprotokollet (ESP) och SPI [8] -index . Om ingen matchande SA hittas, kasseras paketet. Den hittade säkra virtuella anslutningen (SA) indikerar om paketåteröverföringsförhindrande tjänsten används, dvs behovet av att kontrollera sekvensnummerfältet. Om tjänsten används är fältet markerat. För detta, som i AH, används skjutfönstermetoden. Den mottagande IPsec-modulen bildar ett fönster med bredden W. Den vänstra kanten av fönstret motsvarar det minsta sekvensnumret (Sekvensnummer) N för ett korrekt mottaget paket. Ett paket med ett sekvensnummerfält som innehåller ett värde från N+1 till N+W tas emot korrekt. Om det mottagna paketet finns på fönstrets vänstra kant, förstörs det. Sedan, om autentiseringstjänsten används, beräknar den mottagande IPsec-modulen ICV från motsvarande fält i det mottagna paketet med hjälp av autentiseringsalgoritmen som den lär sig från SA-posten och jämför resultatet med ICV-värdet som finns i "Integrity Check Value" fält. Om det beräknade ICV-värdet matchar det mottagna, anses det inkommande paketet vara giltigt. Om kontrollen misslyckas kasseras det mottagande paketet. Därefter dekrypteras paketet. Den mottagande IPsec-modulen lär sig från SA-posten vilken krypteringsalgoritm som används och den hemliga nyckeln. Det bör noteras att kontrollsumman och dekrypteringsproceduren kan utföras inte bara sekventiellt utan också parallellt. I det senare fallet måste verifieringsproceduren för kontrollsumman avslutas före dekrypteringsproceduren, och om ICV-kontrollen misslyckas måste dekrypteringsproceduren också avslutas. Detta möjliggör snabbare upptäckt av trasiga paket, vilket i sin tur ökar skyddsnivån mot överbelastningsattacker ( DOS-attacker ). Vidare sänds det dekrypterade meddelandet i enlighet med nästa rubrikfält för vidare bearbetning.

ike

IKE (uttalas haik , förkortning för Internet Key Exchange) är ett protokoll som binder alla IPsec-komponenter till en fungerande helhet. Specifikt tillhandahåller IKE den första autentiseringen av parterna samt deras utbyte av delade hemligheter .

Det är möjligt att manuellt ställa in en sessionsnyckel (inte att förväxla med fördelad nyckel [PSK] för autentisering). I det här fallet används inte IKE. Det här alternativet rekommenderas dock inte och används sällan. Traditionellt arbetar IKE på port 500 UDP .

Det finns IKE och en nyare version av protokollet: IKEv2. Det finns vissa skillnader i specifikationerna och driften av dessa protokoll. IKEv2 upprättar anslutningsparametrar i en enda fas som består av flera steg. IKE-processen kan delas in i två faser.

Första fasen

IKE skapar en säker kanal mellan två noder som kallas IKE-säkerhetsföreningen (IKE SA). Även i denna fas kommer de två noderna överens om en sessionsnyckel med hjälp av Diffie-Hellman-algoritmen . Den första fasen av IKE kan äga rum i ett av två lägen [12] :

Ur säkerhetssynpunkt är det aggressiva läget svagare, eftersom deltagarna börjar utbyta information innan de etablerar en säker kanal, så otillåten avlyssning av data är möjlig. Det här läget är dock snabbare än det huvudsakliga. Enligt IKE-standarden krävs alla implementeringar för att stödja huvudläget , och det är mycket önskvärt att stödja det aggressiva läget .

Andra fasen

I fas två IKE finns det bara ett, snabbt läge. Snabbläge utförs endast efter att den säkra kanalen har etablerats under den första fasen. Den förhandlar fram en gemensam IPsec-policy, erhåller delade hemligheter för IPsec-protokollalgoritmer (AH eller ESP), upprättar en IPsec SA. Användningen av sekventiella nummer ger skydd mot reprisattacker. Snabbläge används också för att granska den aktuella IPsec SA och välja en ny när SA går ut. Som standard uppdaterar snabbläget de delade hemliga nycklarna med hjälp av Diffie-Hellman-algoritmen från den första fasen.

Hur IPsec fungerar

IPsec-protokoll kan delas in i fem steg [13] :

  1. Det första steget börjar med att skapa en säkerhetspolicy på varje nod som stöder IPsec-standarden. I detta skede bestäms vilken trafik som ska krypteras, vilka funktioner och algoritmer som kan användas.
  2. Det andra steget är i huvudsak den första fasen av IKE. Syftet är att organisera en säker kanal mellan parterna för den andra fasen av IKE. I det andra steget utförs följande:
    • Autentisering och skydd av nodidentiteter
    • Kontrollera Node IKE SA-policyer för säkert nyckelutbyte
    • Diffie-Hellman utbyte , där varje nod kommer att ha en delad hemlig nyckel
    • Skapar en säker kanal för den andra fasen av IKE
  3. Den tredje fasen är den andra fasen av IKE. Dess uppgift är att skapa en IPsec-tunnel. I det tredje steget utförs följande funktioner:
    • Förhandla IPsec SA-parametrar över en IKE SA-skyddad kanal skapad i den första fasen av IKE
    • IPsec SA är inställd
    • IPsec SA granskas med jämna mellanrum för att säkerställa att den är säker.
    • (Valfritt) ett ytterligare Diffie-Hellman-utbyte utförs
  4. Arbetsstadiet. Efter skapandet av IPsec SA börjar informationsutbytet mellan noderna genom IPsec-tunneln, med användning av protokollen och parametrarna som ställts in i SA:n.
  5. De nuvarande IPsec SA:erna avslutas. Detta inträffar när de tas bort eller när tiden för att leva (definierad i SA i bytes av information som sänds över kanalen eller i sekunder), vars värde finns i SAD på varje nod, löper ut. Om det krävs för att fortsätta överföringen startas IKE-fas två (och den första fasen om det behövs) och sedan skapas nya IPsec-SA:er. Processen att skapa nya SA:er kan också ske före slutet av de nuvarande, om kontinuerlig dataöverföring krävs.

Användning

IPsec-protokollet används främst för att organisera VPN-tunnlar . I detta fall fungerar ESP- och AH-protokollen i tunnelläge. Dessutom, genom att konfigurera säkerhetspolicyer på ett visst sätt, kan protokollet användas för att skapa en brandvägg . Meningen med en brandvägg är att den kontrollerar och filtrerar paketen som passerar genom den i enlighet med de givna reglerna. En uppsättning regler ställs in och skärmen tittar på alla paket som passerar genom den. Om de överförda paketen omfattas av dessa regler, bearbetar brandväggen dem i enlighet med detta [14] . Den kan till exempel avvisa vissa paket och därmed avsluta osäkra anslutningar. Genom att konfigurera säkerhetspolicyn därefter kan du till exempel neka webbtrafik. För att göra detta räcker det att förbjuda att skicka paket som innehåller HTTP- och HTTPS- protokollmeddelanden . IPsec kan också användas för att skydda servrar - för detta kasseras alla paket, förutom paket som är nödvändiga för korrekt prestanda av serverfunktioner. För en webbserver kan du till exempel blockera all trafik förutom anslutningar på TCP-port 80, eller på TCP-port 443 i fall där HTTPS används .

Exempel [15] :

IPsec ger säker användaråtkomst till servern. När du använder ESP-protokollet krypteras alla anrop till servern och dess svar. Tydliga meddelanden skickas dock bakom VPN-gatewayen (i krypteringsdomänen).

Andra exempel på användning av IPsec [16] :

Se även

Länkar

Anteckningar

  1. Stanislav Korotygin , IPSec - protokoll för att skydda nätverkstrafik på IP-nivå Arkiverad kopia av 28 januari 2012 på Wayback Machine .
  2. 1 2 Olifer, 2010 , sid. 890.
  3. Olifer, 2010 , sid. 891.
  4. Kryptografisk terminologi 101 Arkiverad 13 mars 2013 på Wayback Machine , Dru Lavigne, 2002.
  5. Olifer, 2010 , sid. 892.
  6. 1 2 Olifer, 2010 , sid. 898.
  7. Andrew Mason, IPSec-översikt, 2002 , del fem: Säkerhetsföreningar.
  8. 1 2 3 Olifer, 2010 , sid. 896.
  9. RFC 2402 .
  10. 1 2 Olifer, 2010 , sid. 895.
  11. RFC 2406 .
  12. Andrew Mason, IPSec-översikt, 2002 , del fyra: Internetnyckelutbyte (IKE).
  13. Andrew Mason, IPSec-översikt, 2002 , Hur IPSec fungerar.
  14. VPN och IPSec Demystified Arkiverade 5 januari 2011 på Wayback Machine , Dru Lavigne, 2002.
  15. VPN och IPSec på fingrar Arkiverad 12 juli 2013 på Wayback Machine , opennet.ru
  16. Roman Lukovnikov , Praktisk tillämpning av IPSec Arkiverad 8 mars 2013 på Wayback Machine , Hacker magazine

Litteratur