IPsec

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 4. april 2019; checks kræver 22 redigeringer .

IPsec (forkortelse for IP-sikkerhed ) er et sæt protokoller til at sikre beskyttelsen af ​​data, der transmitteres over internetprotokollen IP . Tillader godkendelse ( godkendelse ), integritetskontrol og/eller kryptering af IP-pakker. IPsec inkluderer også protokoller til sikker nøgleudvekslinginternettet . Det bruges hovedsageligt til at organisere VPN- forbindelser.

Historie

I første omgang blev internettet skabt som et sikkert medie til transmission af data mellem militæret. Da kun en vis kreds af mennesker arbejdede med det, folk der var uddannede og havde en idé om sikkerhedspolitik, var der ikke noget åbenlyst behov for at bygge sikre protokoller. Sikkerheden var organiseret på niveau med fysisk isolering af genstande fra uautoriserede personer, og dette var berettiget, da et begrænset antal maskiner havde adgang til netværket. Men da internettet blev offentligt og aktivt begyndte at udvikle sig og vokse, dukkede et sådant behov op [1] .

Og i 1994 udgav Internet Architecture Board (IAB) rapporten "Internet Architectural Security". Det var hovedsageligt viet til metoder til beskyttelse mod uautoriseret overvågning, pakkeforfalskning og dataflowkontrol. En eller anden standard eller koncept var nødvendig for at løse dette problem. Som et resultat opstod der sikre protokolstandarder, inklusive IPsec. I første omgang omfattede det tre grundlæggende specifikationer beskrevet i dokumenterne (RFC1825, 1826 og 1827), men efterfølgende reviderede IETF IP Security Protocol arbejdsgruppen dem og foreslog nye standarder (RFC2401 - RFC2412), som stadig bruges i dag.

Standarder

IPsec-arkitektur

Konstruktionen af ​​en sikker kommunikationskanal kan implementeres på forskellige niveauer af OSI-modellen . IPsec er implementeret på netværkslaget . Der er flere modstridende argumenter vedrørende valget af implementeringsniveauet for sikker kanal: På den ene side understøttes valget af de øvre niveauer af deres uafhængighed af transporttypen (valget af netværks- og linklagsprotokoller) på den anden side. hånd, kræver hver applikation en separat indstilling og konfiguration. Fordelen ved at vælge de nederste lag er deres alsidighed og synlighed for applikationer, ulempen er afhængigheden af ​​valget af en bestemt protokol (for eksempel PPP eller Ethernet ). Det faktum, at IPsec ligger på netværkslaget, er et kompromis i valget af OSI-laget. IPsec bruger den mest almindelige netværkslagsprotokol - IP , som gør brugen af ​​IPsec fleksibel - den kan bruges til at beskytte alle IP-baserede protokoller ( TCP , UDP og andre). Samtidig er den gennemsigtig for de fleste applikationer [2] .

IPsec er et sæt internetstandarder og en slags "add-on" til IP-protokollen. Dens kerne består af tre protokoller [3] :

Et af nøglebegreberne er også Security Association (SA). Faktisk er SA et sæt parametre, der karakteriserer forbindelsen. For eksempel den anvendte krypteringsalgoritme og hash-funktion , hemmelige nøgler, pakkenummer osv.

Tunnel- og transportformer

IPsec kan fungere i to tilstande: transport og tunnel.

I transporttilstand er det kun dataene i IP-pakken, der er krypteret eller signeret, den originale header bevares. Transporttilstand bruges typisk til at etablere en forbindelse mellem værter. Den kan også bruges mellem gateways til at sikre tunneler organiseret på anden måde (se f.eks. L2TP ).

I tunneltilstand krypteres hele den originale IP-pakke: data, header, routinginformation, og så indsættes den i datafeltet på en ny pakke, det vil sige, at der sker indkapsling [4] . Tunneltilstand kan bruges til at forbinde fjerncomputere til et virtuelt privat netværk eller til at organisere sikker datatransmission over åbne kommunikationskanaler (f.eks. internettet) mellem gateways for at kombinere forskellige dele af et virtuelt privat netværk .

IPsec-tilstande udelukker ikke hinanden. På den samme vært kan nogle SA'er bruge transporttilstand, mens andre kan bruge tunneltilstand.

Security Association

For at begynde at udveksle data mellem to parter, skal du oprette en forbindelse, som kaldes SA (Security Association). Konceptet SA er grundlæggende for IPsec, faktisk er dets essens. Den beskriver, hvordan parterne vil bruge tjenesterne til at levere sikker kommunikation. En SA-forbindelse er simpleks (envejs), så der skal etableres to forbindelser for at parterne kan kommunikere. Det er også værd at bemærke, at IPsec-standarderne tillader sikre kanal-endepunkter at bruge både én SA til at transmittere trafik fra alle værter , der interagerer gennem denne kanal , og til at skabe et vilkårligt antal sikre tilknytninger til dette formål, for eksempel én for hver TCP-forbindelse . Dette gør det muligt at vælge det ønskede niveau af beskyttelsesdetalje. [2] Etablering af en forbindelse begynder med gensidig autentificering af parterne. Derefter vælges parametrene (om der skal udføres godkendelse, kryptering, dataintegritetstjek) og den nødvendige protokol (AH eller ESP) til dataoverførsel. Derefter vælges specifikke algoritmer (for eksempel kryptering, hash-funktion) fra flere mulige skemaer, hvoraf nogle er defineret af standarden (for kryptering - DES , for hash-funktioner - MD5 eller SHA-1 ), andre tilføjes af producenter af produkter, der bruger IPsec (f.eks. Triple DES , Blowfish , CAST ) [5] .

Sikkerhedsforeningers database

Alle SA'er er gemt i SAD (Security Associations Database) i IPsec-modulet. Hver SA har en unik markør bestående af tre elementer [6] :

IPsec-modulet, givet disse tre parametre, kan slå en bestemt SA-indgang op i SAD. Listen over SA-komponenter inkluderer [7] :

Serienummer En 32-bit værdi, der bruges til at danne feltet Sekvensnummer i AH- og ESP-headerne. Sekvens tæller overløb Et flag, der signalerer overløbet af sekvensnummertælleren. Genafspil angrebsundertrykkelsesvindue Bruges til at bestemme retransmission af pakker. Hvis værdien i feltet Sekvensnummer ikke falder inden for det angivne interval, bliver pakken ødelagt. AH Information den anvendte autentificeringsalgoritme, de nødvendige nøgler, nøglernes levetid og andre parametre. ESP oplysninger krypterings- og autentificeringsalgoritmer, nødvendige nøgler, initialiseringsparametre (for eksempel IV), nøglelevetid og andre parametre IPsec driftstilstand tunnel eller transport SA levetid Angivet i sekunder eller bytes af information, der passerer gennem tunnelen. Bestemmer varigheden af ​​eksistensen af ​​SA, når denne værdi er nået, skal den nuværende SA afslutte, om nødvendigt fortsætte forbindelsen, en ny SA etableres. MTU Den maksimale pakkestørrelse, der kan sendes over et virtuelt kredsløb uden fragmentering.

Hver protokol (ESP/AH) skal have sin egen SA for hver retning, så AH+ESP kræver fire SA'er til et duplekslink . Alle disse data ligger i SAD.

SAD indeholder:

Sikkerhedspolitikdatabase

Ud over SAD-databasen understøtter IPsec-implementeringer Security Policy Database (SPD). SPD bruges til at korrelere indgående IP-pakker med behandlingsregler for dem. Records i SPD består af to felter. [8] Den første gemmer de karakteristiske træk ved pakkerne, hvorefter den ene eller anden informationsstrøm kan skelnes. Disse felter kaldes vælgere. Eksempler på vælgere, der er indeholdt i SPD [6] :

Det andet felt i SPD'en indeholder sikkerhedspolitikken forbundet med denne pakkestrøm. Vælgere bruges til at filtrere udgående pakker for at matche hver pakke til en specifik SA. Når en pakke ankommer, sammenlignes værdierne af de tilsvarende felter i pakken (selektorfelter) med dem, der er indeholdt i SPD'en. Når et match er fundet, indeholder sikkerhedspolitikfeltet information om, hvordan man håndterer denne pakke: videregive den uændret, kassere den eller behandle den. I tilfælde af behandling indeholder samme felt et link til den tilsvarende post i SAD. SA'en for pakken og dens tilhørende sikkerhedsparameterindeks (SPI) bestemmes derefter, hvorefter IPsec-operationer (AH- eller ESP-protokoloperationer) udføres. Hvis pakken kommer ind, indeholder den straks SPI - den tilsvarende behandling udføres.

Authentication Header

Authentication Header -format
forskydninger 16. oktober 0 en 2 3
16. oktober bit 10 0 en 2 3 fire 5 6 7 otte 9 ti elleve 12 13 fjorten femten 16 17 atten 19 tyve 21 22 23 24 25 26 27 28 29 tredive 31
0 0 Næste overskrift Nyttelast Len Reserveret
fire 32 Sikkerhedsparameterindeks (SPI)
otte 64 sekvensnummer
C 96 Integritetstjekværdi (ICV)
Næste headertype (8 bit) Den type protokolheader, der kommer efter AH-headeren. Ved at bruge dette felt lærer det modtagende IP-sec-modul om den beskyttede øvre lagsprotokol. Se RFC 1700 for betydningen af ​​dette felt for forskellige protokoller . Indholdslængde (8 bit) Dette felt angiver den samlede størrelse af AH-headeren i 32-bit ord, minus 2. Men når du bruger IPv6, skal længden af ​​headeren være et multiplum af 8 bytes. Reserveret (16 bit) Reserveret. Fyldt med nuller. Indeks for sikkerhedsindstillinger (32 bit) Indeks for sikkerhedsindstillinger. Værdien af ​​dette felt, sammen med destinations-IP-adressen og sikkerhedsprotokollen (AH-protokol), identificerer entydigt den sikre virtuelle forbindelse (SA) for denne pakke. SPI-værdiområde 1…255 er reserveret af IANA . Sekvensnummer (32 bit) Serienummer. Tjener til at beskytte mod retransmission. Feltet indeholder en monotont stigende parameterværdi. Selvom modtageren kan fravælge beskyttelsestjenesten for pakkegentransmission, er den obligatorisk og er altid til stede i AH-headeren. Det transmitterende IPsec-modul bruger altid dette felt, men modtageren MÅSKE ikke behandle det. Godkendelsesdata Digital signatur. Bruges til at godkende og verificere pakkens integritet. Skal udfyldes til et multiplum af 8 bytes for IPv6 og 4 bytes for IPv4.

AH-protokollen bruges til autentificering, det vil sige for at bekræfte, at vi kommunikerer med præcis den, vi tror, ​​vi er, og at de data, vi modtager, ikke bliver manipuleret med under transit [9] .

Håndtering af output IP-pakker

Hvis det transmitterende IPsec-modul bestemmer, at pakken er forbundet med en SA, der kræver AH-behandling, begynder den at behandle. Afhængigt af tilstanden (transport- eller tunneltilstand) indsætter den AH-headeren forskelligt i IP-pakken. I transporttilstand vises AH-headeren efter IP-protokolheaderen og før protokolheaderne på det øverste lag (typisk TCP eller UDP ). I tunneltilstand indrammes hele kilde-IP-pakken først med AH-headeren, derefter med IP-protokolheaderen. Sådan en header kaldes outer, og headeren på den originale IP-pakke kaldes indre. Derefter skal det transmitterende IPsec-modul generere et sekvensnummer og skrive det i feltet Sekvensnummer . Når en SA er etableret, sættes sekvensnummeret til 0 og øges med én, før hver IPsec-pakke sendes. Derudover er der et tjek for at se om tælleren er gået i cyklusser. Hvis den har nået sin maksimale værdi, sættes den tilbage til 0. Hvis gentransmissionsforebyggelsestjenesten bruges, så nulstiller det transmitterende IPsec-modul SA'en, når tælleren når sin maksimale værdi. Dette giver beskyttelse mod genafsendelse af pakker - det modtagende IPsec-modul vil kontrollere feltet Sekvensnummer og ignorere genindkommende pakker. Dernæst beregnes ICV-kontrolsummen. Det skal bemærkes, at checksummen her beregnes ved hjælp af en hemmelig nøgle, uden hvilken en angriber vil være i stand til at genberegne hashen, men uden at kende nøglen, vil han ikke være i stand til at danne den korrekte kontrolsum. De specifikke algoritmer, der bruges til at beregne ICV, kan findes i RFC 4305 . I øjeblikket kan for eksempel HMAC-SHA1-96 eller AES-XCBC-MAC-96 algoritmer bruges. AH-protokollen beregner kontrolsummen (ICV) ud fra følgende felter i IPsec-pakken [10] :

Behandling af indgående IP-pakker

Ved modtagelse af en pakke, der indeholder en AH-protokolmeddelelse, slår det modtagende IPsec-modul op den passende SAD (Security Associations Database) sikre virtuelle forbindelse (SA) ved hjælp af destinations-IP-adressen, sikkerhedsprotokollen (AH) og SPI-indekset. Hvis der ikke findes en passende SA, kasseres pakken. Den fundne sikre virtuelle forbindelse (SA) angiver, om tjenesten bruges til at forhindre gentransmission af pakker, det vil sige behovet for at kontrollere feltet Sekvensnummer . Hvis tjenesten er i brug, er feltet markeret. Dette bruger en glidende vinduesmetode til at begrænse den bufferhukommelse, der kræves for, at protokollen kan fungere. Det modtagende IPsec-modul danner et vindue med en bredde W (normalt vælges W til 32 eller 64 pakker). Venstre kant af vinduet svarer til minimumssekvensnummeret ( sekvensnummer ) N for en korrekt modtaget pakke. En pakke med et sekvensnummerfelt , der indeholder en værdi fra N+1 til N+W, modtages korrekt. Hvis den modtagne pakke er i venstre kant af vinduet, bliver den ødelagt. Det modtagende IPsec-modul beregner derefter ICV'en ud fra de relevante felter i den modtagne pakke ved hjælp af den autentificeringsalgoritme, den lærer fra SA-posten, og sammenligner resultatet med ICV-værdien placeret i feltet "Integrity Check Value". Hvis den beregnede ICV-værdi matcher den modtagne, betragtes den indgående pakke som gyldig og accepteres til yderligere IP-behandling. Hvis kontrollen mislykkes, ødelægges den modtagne pakke [10] .

Encapsulating Security Payload

Encapsulating Security Payload -format
forskydninger 16. oktober 0 en 2 3
16. oktober bit 10 0 en 2 3 fire 5 6 7 otte 9 ti elleve 12 13 fjorten femten 16 17 atten 19 tyve 21 22 23 24 25 26 27 28 29 tredive 31
0 0 Sikkerhedsparameterindeks (SPI)
fire 32 sekvensnummer
otte 64 nyttelast data
   
  Polstring (0-255 oktetter)  
  Pad længde Næste overskrift
Integritetstjekværdi (ICV)
Sikkerhedsparameterindeks (32 bit) Indeks for sikkerhedsindstillinger (svarende til det tilsvarende AH-felt). Værdien af ​​dette felt, sammen med destinations-IP-adressen og sikkerhedsprotokollen (ESP), identificerer entydigt den sikre virtuelle forbindelse (SA) for denne pakke. SPI-værdiområdet på 1…255 er reserveret af IANA til fremtidig brug. Sekvensnummer (32 bit) Sekvensnummer (svarende til det tilsvarende AH-felt). Tjener til at beskytte mod retransmission. Feltet indeholder en monotont stigende parameterværdi. Selvom modtageren kan fravælge beskyttelsestjenesten for pakkegentransmission, er den altid til stede i ESP-headeren. Afsenderen (transmitterende IPsec-modul) SKAL altid bruge dette felt, men modtageren behøver muligvis ikke at behandle det. nyttelastdata (variabel) Dette felt indeholder data (afhængigt af valget af transportform - tunnel eller transport, enten hele den originale indkapslede pakke eller kun dens data kan være her) i overensstemmelse med feltet "Næste overskrift". Dette felt er obligatorisk og består af et helt antal bytes. Hvis algoritmen, der bruges til at kryptere dette felt, kræver data for at synkronisere kryptoprocesser (for eksempel initialiseringsvektoren - "Initialiseringsvektor" ), kan dette felt indeholde disse data eksplicit. Polstring (0-255 oktetter) Tilføjelse. Nødvendigt, for eksempel for algoritmer, der kræver, at klarteksten er et multiplum af et vist antal bytes, såsom blokstørrelsen for en blokchiffer. Pudelængde (8 bit) Udfyldningsstørrelsen (i bytes). Næste overskrift (8 bit) Dette felt specificerer typen af ​​data, der er indeholdt i feltet "Nyttelastdata". Integritetstjekværdi Tjek sum. Bruges til at godkende og verificere pakkens integritet. Skal være et multiplum af 8 bytes for IPv6 og 4 bytes for IPv4 [11] .

Håndtering af IPsec-outputpakker

Hvis det transmitterende IPsec-modul bestemmer, at pakken er knyttet til en SA, der kræver ESP-behandling, begynder den at behandle. Afhængig af tilstanden (transport- eller tunneltilstand) behandles den originale IP-pakke forskelligt. I transporttilstand udfører det transmitterende IPsec-modul rammeproceduren for protokollen for det øverste lag (f.eks. TCP eller UDP) ved hjælp af ESP-headeren (felterne Sikkerhedsparametre Indeks og Sekvensnummer i overskriften) og ESP-traileren (de resterende felter i overskriften efter datafeltet) for dette. - Nyttedata), uden at det påvirker overskriften på den originale IP-pakke. I tunneltilstand indrammes IP-pakken med en ESP-header og en ESP-trailer ( indkapsling ), hvorefter den indrammes med en ekstern IP-header (som muligvis ikke matcher den originale - hvis IPsec-modulet f.eks. er installeret på porten ) [8 ] . Dernæst udføres kryptering - i transporttilstand er det kun beskeden fra den øvre lags protokol, der krypteres (det vil sige alt, der var efter IP-headeren i kildepakken), i tunneltilstand - hele kilde-IP-pakken. Det transmitterende IPsec-modul fra SA-indgangen bestemmer krypteringsalgoritmen og den hemmelige nøgle . IPsec-standarderne tillader brugen af ​​Triple DES , AES og Blowfish -krypteringsalgoritmerne, hvis begge parter understøtter dem. Ellers bruges DES som specificeret i RFC 2405 . Da størrelsen af ​​den almindelige tekst skal være et multiplum af et vist antal bytes, for eksempel blokstørrelsen for blokalgoritmer , udføres den nødvendige tilføjelse af den krypterede meddelelse også før kryptering. Den krypterede besked placeres i feltet Nyttedata . Feltet Pad Længde indeholder længden af ​​puden . Derefter beregnes, som i AH, Sekvensnummeret, hvorefter kontrolsummen (ICV) beregnes. Kontrolsummen, i modsætning til AH-protokollen, hvor nogle felter i IP-headeren også tages i betragtning ved beregningen af ​​den, beregnes i ESP kun af felterne i ESP-pakken minus ICV-feltet. Inden kontrolsummen udregnes, udfyldes den med nuller. ICV-beregningsalgoritmen, som i AH-protokollen, lærer det transmitterende IPsec-modul fra posten om den SA, som den behandlede pakke er forbundet med.

Behandling af indgående IPsec-pakker

Ved modtagelse af en pakke, der indeholder en ESP-protokolmeddelelse, slår det modtagende IPsec-modul op den passende sikre virtuelle forbindelse (SA) i SAD'et ved hjælp af destinations-IP-adressen, sikkerhedsprotokol (ESP) og SPI [8] -indekset . Hvis der ikke findes en passende SA, kasseres pakken. Den fundne sikre virtuelle forbindelse (SA) angiver, om pakkegentransmissionsforhindringstjenesten bliver brugt, dvs. behovet for at kontrollere feltet Sekvensnummer. Hvis tjenesten er i brug, er feltet markeret. Til dette, som i AH, bruges skydevinduemetoden. Det modtagende IPsec-modul danner et vindue med bredden W. Venstre kant af vinduet svarer til minimum sekvensnummer (sekvensnummer) N for en korrekt modtaget pakke. En pakke med et sekvensnummerfelt, der indeholder en værdi fra N+1 til N+W, modtages korrekt. Hvis den modtagne pakke er i venstre kant af vinduet, bliver den ødelagt. Derefter, hvis godkendelsestjenesten bruges, beregner det modtagende IPsec-modul ICV'en ud fra de tilsvarende felter i den modtagne pakke ved hjælp af godkendelsesalgoritmen, som den lærer fra SA-posten og sammenligner resultatet med ICV-værdien placeret i "Integrity Check Value" Mark. Hvis den beregnede ICV-værdi matcher den modtagne, anses den indgående pakke for at være gyldig. Hvis kontrollen mislykkes, kasseres den modtagende pakke. Derefter dekrypteres pakken. Det modtagende IPsec-modul lærer fra SA-indgangen, hvilken krypteringsalgoritme der bruges, og den hemmelige nøgle. Det skal bemærkes, at checksum-kontrollen og dekrypteringsproceduren ikke kun kan udføres sekventielt, men også parallelt. I sidstnævnte tilfælde skal kontrolsumverifikationsproceduren afsluttes før dekrypteringsproceduren, og hvis ICV-kontrollen mislykkes, skal dekrypteringsproceduren også afsluttes. Dette muliggør hurtigere detektion af ødelagte pakker, hvilket igen øger beskyttelsesniveauet mod lammelsesangreb ( DOS-angreb ). Yderligere transmitteres den dekrypterede meddelelse i overensstemmelse med Next Header -feltet til yderligere behandling.

ike

IKE (udtales haik , forkortelse for Internet Key Exchange) er en protokol, der binder alle IPsec-komponenter til en fungerende helhed. Specifikt sørger IKE for den første autentificering af parterne samt deres udveksling af fælles hemmeligheder .

Det er muligt manuelt at indstille en sessionsnøgle (ikke at forveksle med foruddelt nøgle [PSK] til godkendelse). I dette tilfælde bruges IKE ikke. Denne mulighed anbefales dog ikke og bruges sjældent. Traditionelt opererer IKE på port 500 UDP .

Der er IKE og en nyere version af protokollen: IKEv2. Der er nogle forskelle i specifikationerne og driften af ​​disse protokoller. IKEv2 etablerer forbindelsesparametre i en enkelt fase bestående af flere trin. IKE-processen kan opdeles i to faser.

Første fase

IKE opretter en sikker kanal mellem to noder kaldet IKE-sikkerhedsforeningen (IKE SA). Også i denne fase bliver de to noder enige om en sessionsnøgle ved hjælp af Diffie-Hellman-algoritmen . Den første fase af IKE kan foregå i en af ​​to tilstande [12] :

Fra et sikkerhedssynspunkt er den aggressive tilstand svagere, da deltagerne begynder at udveksle information, før de etablerer en sikker kanal, så uautoriseret aflytning af data er mulig. Denne tilstand er dog hurtigere end den primære. Ifølge IKE-standarden kræves enhver implementering for at understøtte hovedtilstanden , og det er yderst ønskeligt at understøtte den aggressive tilstand .

Anden fase

I fase to IKE er der kun én, hurtig tilstand. Hurtig tilstand udføres kun, efter at den sikre kanal er blevet etableret i den første fase. Den forhandler en fælles IPsec-politik, opnår delte hemmeligheder for IPsec-protokolalgoritmer (AH eller ESP), etablerer en IPsec SA. Brugen af ​​sekventielle numre giver beskyttelse mod replay-angreb. Hurtig tilstand bruges også til at gennemgå den aktuelle IPsec SA og vælge en ny, når SA'en udløber. Som standard opdaterer hurtig tilstand de delte hemmelige nøgler ved hjælp af Diffie-Hellman-algoritmen fra den første fase.

Sådan fungerer IPsec

IPsec-protokoller kan opdeles i fem trin [13] :

  1. Det første trin begynder med oprettelsen af ​​en sikkerhedspolitik på hver node, der understøtter IPsec-standarden. På dette stadie bestemmes det, hvilken trafik der skal krypteres, hvilke funktioner og algoritmer der kan bruges.
  2. Den anden fase er i det væsentlige den første fase af IKE. Dens formål er at organisere en sikker kanal mellem parterne for anden fase af IKE. På anden fase udføres følgende:
    • Autentificering og beskyttelse af node identiteter
    • Kontrol af Node IKE SA-politikker for sikker nøgleudveksling
    • Diffie-Hellman-udveksling , hvorved hver node vil have en fælles hemmelig nøgle
    • Oprettelse af en sikker kanal til anden fase af IKE
  3. Den tredje fase er anden fase af IKE. Dens opgave er at skabe en IPsec-tunnel. På den tredje fase udføres følgende funktioner:
    • Forhandle IPsec SA-parametre over en IKE SA-beskyttet kanal oprettet i første fase af IKE
    • IPsec SA er indstillet
    • IPsec SA gennemgås med jævne mellemrum for at sikre, at den er sikker.
    • (Valgfrit) en yderligere Diffie-Hellman-udveksling udføres
  4. Arbejdsstadie. Efter oprettelsen af ​​IPsec SA begynder udvekslingen af ​​information mellem knudepunkterne gennem IPsec-tunnelen ved at bruge de protokoller og parametre, der er indstillet i SA.
  5. De nuværende IPsec SA'er er afsluttet. Dette sker, når de fjernes, eller når tiden til at leve (defineret i SA i bytes af information transmitteret over kanalen eller i sekunder), hvis værdi er indeholdt i SAD'en på hver knude, udløber. Hvis det er påkrævet at fortsætte overførslen, startes IKE fase to (og den første fase om nødvendigt), og derefter oprettes nye IPsec SA'er. Processen med at oprette nye SA'er kan også finde sted inden udgangen af ​​de nuværende, hvis kontinuerlig dataoverførsel er påkrævet.

Brug

IPsec-protokollen bruges hovedsageligt til at organisere VPN-tunneller . I dette tilfælde fungerer ESP- og AH-protokollerne i tunneltilstand. Derudover kan protokollen bruges til at oprette en firewall ved at konfigurere sikkerhedspolitikker på en bestemt måde . Betydningen af ​​en firewall er, at den kontrollerer og filtrerer de pakker, der passerer gennem den, i overensstemmelse med de givne regler. Et sæt regler er sat op, og skærmen ser på alle pakker, der passerer gennem det. Hvis de transmitterede pakker er underlagt disse regler, behandler firewallen dem i overensstemmelse hermed [14] . For eksempel kan den afvise visse pakker og derved afslutte usikre forbindelser. Ved at konfigurere sikkerhedspolitikken i overensstemmelse hermed kan du f.eks. nægte webtrafik. For at gøre dette er det nok at forbyde at sende pakker, der indeholder HTTP- og HTTPS -protokolmeddelelser . IPsec kan også bruges til at beskytte servere - til dette kasseres alle pakker, undtagen pakker, der er nødvendige for den korrekte udførelse af serverfunktioner. For en webserver kan du f.eks. blokere al trafik undtagen forbindelser på TCP-port 80 eller på TCP-port 443 i tilfælde, hvor HTTPS bruges .

Eksempel [15] :

IPsec giver sikker brugeradgang til serveren. Når du bruger ESP-protokollen, er alle opkald til serveren og dens svar krypteret. Der sendes dog klare beskeder bag VPN-gatewayen (i krypteringsdomænet).

Andre eksempler på brug af IPsec [16] :

Se også

Links

Noter

  1. Stanislav Korotygin , IPSec - protokol til beskyttelse af netværkstrafik på IP-niveau Arkiveret kopi af 28. januar 2012 på Wayback Machine .
  2. 1 2 Olifer, 2010 , s. 890.
  3. Olifer, 2010 , s. 891.
  4. Kryptografisk terminologi 101 Arkiveret 13. marts 2013 på Wayback Machine , Dru Lavigne, 2002.
  5. Olifer, 2010 , s. 892.
  6. 1 2 Olifer, 2010 , s. 898.
  7. Andrew Mason, IPSec Overview, 2002 , Femte del: Sikkerhedsforeninger.
  8. 1 2 3 Olifer, 2010 , s. 896.
  9. RFC 2402 .
  10. 1 2 Olifer, 2010 , s. 895.
  11. RFC 2406 .
  12. Andrew Mason, IPSec Overview, 2002 , Del fire: Internet Key Exchange (IKE).
  13. Andrew Mason, IPSec Overview, 2002 , How IPSec works.
  14. VPN'er og IPSec Demystified Arkiveret 5. januar 2011 på Wayback Machine , Dru Lavigne, 2002.
  15. VPN og IPSec på fingrene Arkiveret 12. juli 2013 på Wayback Machine , opennet.ru
  16. Roman Lukovnikov , Praktisk anvendelse af IPSec Arkiveret 8. marts 2013 på Wayback Machine , Hacker magazine

Litteratur