0 Denne artikkelen gir en oversikt over IP-sikkerhet (IP-sikkerhet) og relaterte IPSec-protokoller som er tilgjengelige i Cisco-produkter og brukes til å lage virtuelle private nettverk (VPN-er). I denne artikkelen vil vi definere hva IPSEC er og hvilke sikkerhetsprotokoller og algoritmer som er kjernen i IPSEC.
Introduksjon
IP Security er en pakke med protokoller som omhandler kryptering, autentisering og sikkerhet under transport av IP-pakker; den har nå nesten 20 standardforslag og 18 RFC-er.Cisco VPN-produkter bruker IPSec-pakken med protokoller, som er industristandarden for rike VPN-funksjoner i dag. IPSec tilbyr en mekanisme for sikker overføring av data over IP-nettverk, som sikrer konfidensialitet, integritet og pålitelighet til data som overføres over usikrede nettverk som Internett. IPSec tilbyr følgende VPN-funksjoner på Cisco-nettverk:
- Datakonfidensialitet... Avsenderen av IPSec-data har muligheten til å kryptere pakker før de sendes over nettverket.
- Dataintegritet... Mottakeren av IPSec-dataene har muligheten til å autentisere de kommuniserende partene (enheter eller programvare der IPSec-tunnelene starter og slutter) og IPSec-pakkene sendt av disse partene for å sikre at dataene ikke har blitt endret under overføring.
- Datakildeautentisering... Mottakeren av IPSec-dataene har muligheten til å autentisere kilden til de mottatte IPSec-pakkene. Denne tjenesten avhenger av dataintegritetstjenesten.
- Avspillingsbeskyttelse... Mottakeren av IPSec-dataene kan oppdage og avvise de spilte pakkene, og hindre dem fra å bli tuklet med og fra å utføre formidlingsangrep.
IPSec er et standardbasert sett med sikkerhetsprotokoller og algoritmer. IPSec og relaterte sikkerhetsprotokoller samsvarer med åpne standarder støttet av Internet Engineering Task Force (IETF) og beskrevet i RFC-er og IETF-utkast. IPSec opererer på nettverkslaget for å gi sikkerhet og autentisering for IP-pakker sendt mellom IPSec-enheter (partier) som Cisco-rutere, PIX-brannmurer, Cisco VPN-klienter og -konsentratorer og mange andre produkter som støtter IPSec. IPSec-støtte skalerer fra de minste til svært store nettverkene.
Security Association (SA)
IPSec tilbyr en standard måte å autentisere og kryptere kommunikasjon mellom kommuniserende parter. For å sikre kommunikasjon bruker IPSec industristandard krypterings- og autentiseringsalgoritmer (dvs. matematiske formler) kalt transformasjoner. IPSec bruker åpne standarder for krypteringsnøkkelforhandling og tilkoblingsadministrasjon for å muliggjøre interoperabilitet mellom partene. IPSec-teknologi gir metoder for å tillate IPSec-parter å "forhandle" konsekvent bruk av tjenester. Sikkerhetstilknytninger brukes i IPSec for å spesifisere parameterne som skal forhandles.Forsvarsforbundet(Security Association - SA) er en avtalt policy eller metode for behandling av data som skal utveksles mellom to enheter av kommuniserende parter. En av komponentene i en slik policy kan være algoritmen som brukes til å kryptere data. Begge parter kan bruke samme algoritme for både kryptering og dekryptering. De gyldige SA-parametrene lagres i Security Association Database (SAD) på begge sider.
To datamaskiner på hver side av SA lagrer modus, protokoll, algoritmer og nøkler som brukes i SA. Hver SA brukes kun i én retning. To SA-er kreves for toveis kommunikasjon. Hver SA implementerer én modus og protokoll; Hvis to protokoller skal brukes for en enkelt pakke (som AH og ESP), kreves det derfor to SA-er.
Internet Key Exchange (IKE) er en hybridprotokoll som gir en dedikert tjeneste for IPSec, nemlig autentisering av IPSec-partene, forhandling av IKE- og IPSec-og nøkkelvalg for krypteringsalgoritmer som brukes i IPSec. IKE er avhengig av Internet Security Association and Key Management Protocol (ISAKMP) og Oakley, som brukes til å kontrollere generering og behandling av krypteringsnøkler som brukes i IPSec-transformasjoner. IKE brukes også til å danne sikkerhetstilknytninger mellom potensielle IPSec-parter.
Både IKE og IPSec bruker sikkerhetstilknytninger for å spesifisere kommunikasjonsparametere.
IKE støtter et sett med ulike primitive funksjoner for bruk i protokoller. Blant dem er hash-funksjonen og pseudo-tilfeldig funksjon (PRF).
Hash funksjon Er en kollisjonssikker funksjon. Kollisjonsmotstand forstås som at det er umulig å finne to forskjellige meldinger m1 og m2 slik at
H (m1) = H (m2), hvor H er en hashfunksjon.
Når det gjelder pseudo-tilfeldige funksjoner, nå i stedet for spesielle PRF-er, brukes en hash-funksjon i HMAC-konstruksjonen (HMAC er en meldingsautentiseringsmekanisme som bruker hash-funksjoner). For å definere HMAC trenger vi en kryptografisk hash-funksjon (betegn den som H) og en hemmelig nøkkel K. Vi antar at H er en hash-funksjon, der data hash ved hjelp av en komprimeringsprosedyre som brukes sekvensielt til en sekvens av datablokker. Vi vil angi med B lengden på slike blokker i byte, og lengden på blokkene oppnådd som et resultat av hashing som L (L
ipad = byte 0x36, gjentatt B ganger;
opad = byte 0x5C gjentatt B ganger.
For å beregne HMAC fra "tekst"-dataene, må du utføre følgende operasjon:
H (K XOR opad, H (K XOR ipad, tekst))
Av beskrivelsen følger det at IKE bruker HASH-verdier for å autentisere partene. Merk at HASH i dette tilfellet utelukkende betyr nyttelastnavnet i ISAKMP, og dette navnet har ingenting med innholdet å gjøre.
IPSec-infrastruktur
IPSec VPN-er kan bygges med et bredt utvalg av Cisco-enheter — Cisco-rutere, CiscoSecure PIX-brannmurer, CiscoSecure VPN-klientprogramvare og Cisco 3000- og 5000-seriens VPN-konsentratorer. Cisco-rutere har innebygd VPN-støtte med tilsvarende Cisco-programvarerike funksjoner IOS, som reduserer kompleksiteten til nettverksløsninger og reduserer de totale kostnadene for VPN samtidig som det bygges flerlagsbeskyttelse av tjenestene som tilbys. PIX Firewall er en høyytelses nettverksenhet som kan betjene tunnelendepunkter med høy båndbredde og utmerket brannmurfunksjonalitet. CiscoSecure VPN Client-programvaren støtter de strengeste VPN-kravene for ekstern tilgang for e-handel og mobiltilgangsapplikasjoner, og tilbyr komplette IPSec-implementeringer og pålitelig interoperabilitet mellom Cisco-rutere og PIX-brannmurer.Hvordan IPSec fungerer
IPSec er avhengig av en rekke teknologiløsninger og krypteringsteknikker, men den generelle handlingen til IPSec kan betraktes som følgende hovedtrinn:
- Trinn 1. Start IPSec-prosessen. Trafikk som krever kryptering i henhold til IPSec-sikkerhetspolicyen forhandlet av IPSec-partene starter IKE-prosessen.
- Trinn 2. Fase I av IKE... IKE-prosessen autentiserer IPSec-partene og forhandler parametrene til IKE-sikkerhetsforeningene, noe som skaper en sikker kanal for å forhandle parametrene til IPSec-sikkerhetstilknytningene under den andre fasen av IKE.
- Trinn 3. Andre fase av IKE... IKE-prosessen forhandler parametrene for IPSec-sikkerhetstilknytning og etablerer de riktige IPSec-sikkerhetstilknytningene for de kommuniserende partenhetene.
- Trinn 4. Dataoverføring... Utvekslingen av data mellom de IPSec-kommuniserende partene er basert på IPSec-parametrene og nøklene som er lagret i sikkerhetstilknytningsdatabasen.
- Trinn 5. Slå av IPSec-tunnelen... IPSec sikkerhetstilknytninger avsluttes enten ved å bli fjernet eller ved å overskride levetiden.
I dagens verden brukes ulike VPN-teknologier overalt. Noen (for eksempel PPTP) blir anerkjent som utrygge over tid og dør gradvis ut, andre (OpenVPN), tvert imot, får fart hvert år. Men IPsec VPN er fortsatt den ubestridte lederen og mest anerkjente teknologien for å skape og vedlikeholde sikre private kanaler. Noen ganger, under en penetrasjonstest, kan du finne et seriøst beskyttet nettverk med bare den 500. UDP-porten som stikker ut. Alt annet kan lukkes, lappes og filtreres sikkert.
I en slik situasjon kan tanken oppstå om at det ikke er noe spesielt å gjøre her. Men det er ikke alltid tilfelle. I tillegg er det en utbredt oppfatning at IPsec, selv i standardkonfigurasjoner, er ugjennomtrengelig og gir et tilstrekkelig sikkerhetsnivå. Det er nettopp denne situasjonen vi skal se på i praksis i dag. Men først, for å håndtere IPsec effektivt, må du forstå hva det er og hvordan det fungerer. Dette skal vi gjøre!
IPsec fra innsiden
Før du går direkte til selve IPsec, ville det være greit å huske hvilke typer VPN det er generelt. Det er mange VPN-klassifiseringer, men vi skal ikke dykke dypt inn i nettverksteknologier og ta den enkleste. Derfor vil vi dele VPN inn i to hovedtyper – sted-til-sted VPN-tilkoblinger (de kan også kalles permanente) og fjerntilgang VPN (RA, de er midlertidige).Den første typen tjener til konstant kommunikasjon av forskjellige nettverksøyer, for eksempel et sentralkontor med mange spredte grener. Vel, RA VPN er et scenario når en klient kobler til for en kort periode, får tilgang til visse nettverksressurser og kobler seg trygt fra etter fullført arbeid.
Vi vil være interessert i det andre alternativet, siden i tilfelle et vellykket angrep er det mulig å umiddelbart få tilgang til det interne nettverket til bedriften, noe som er en ganske alvorlig prestasjon for en pentester. IPsec tillater på sin side både sted-til-sted og fjerntilgang VPN-er. Hva slags teknologi er dette og hvilke komponenter består den av?
Det er verdt å merke seg at IPsec ikke er én, men et helt sett med forskjellige protokoller som gir transparent og sikker databeskyttelse. Spesifisiteten til IPsec er at den er implementert på nettverkslaget, og supplerer det på en slik måte at alt skjer ubemerket for påfølgende lag. Hovedproblemet ligger i det faktum at i prosessen med å etablere en forbindelse, må to deltakere i en sikker kanal bli enige om et ganske stort antall forskjellige parametere. De må nemlig autentisere hverandre, generere og utveksle nøkler (og gjennom et utrustet miljø), og også bli enige om hvilke protokoller som skal krypteres dataene.
Det er av denne grunn at IPsec består av en protokollstabel hvis ansvar er å sikre at en sikker tilkobling etableres, drives og administreres. Hele prosessen med å etablere en forbindelse inkluderer to faser: den første fasen brukes for å sikre sikker utveksling av ISAKMP-meldinger allerede i den andre fasen. ISAKMP (Internet Security Association and Key Management Protocol) er en protokoll som forhandler og oppdaterer sikkerhetspolicyer (SA-er) mellom VPN-deltakere. Disse retningslinjene spesifiserer med hvilken protokoll som skal krypteres (AES eller 3DES) og med hvilken som skal autentiseres (SHA eller MD5).
De to hovedfasene av IPsec
Så vi fant ut at først må deltakerne bli enige om hvilke mekanismer som skal brukes for å skape en sikker tilkobling, så nå kommer IKE-protokollen inn. IKE (Internet Key Exchange) brukes til å danne en IPsec SA (Security Association, de samme sikkerhetspolicyene), med andre ord, for å koordinere deltakernes arbeid i en sikker tilkobling. Gjennom denne protokollen blir deltakerne enige om hvilken krypteringsalgoritme som skal brukes, med hvilken algoritme integritetskontrollen skal utføres, og hvordan de skal autentisere hverandre. Det skal bemerkes at det i dag er to versjoner av protokollen: IKEv1 og IKEv2. Vi vil bare være interessert i IKEv1: selv om IETF (The Internet Engineering Task Force) først introduserte den i 1998, er den fortsatt veldig vanlig, spesielt for RA VPN-er (se figur 1).
Ris. 1. Veiviser for Cisco ASDM VPN
Når det gjelder IKEv2, ble de første skissene laget i 2005, den ble fullstendig beskrevet i RFC 5996 (2010), og først på slutten av fjoråret ble den kunngjort som en Internett-standard (RFC 7296). Du kan lese mer om forskjellene mellom IKEv1 og IKEv2 i sidefeltet. Med IKE ryddet opp, la oss gå tilbake til IPsec-fasene. I løpet av den første fasen autentiserer deltakerne hverandre og blir enige om parametrene for å sette opp en spesiell forbindelse designet kun for å utveksle informasjon om de ønskede krypteringsalgoritmene og andre detaljer om den fremtidige IPsec-tunnelen. Parametrene til denne første tunnelen (også kalt ISAKMP-tunnelen) er styrt av ISAKMP-policyen. Først av alt avtales hashes og krypteringsalgoritmer, deretter utveksles Diffie-Hellman (DH)-nøkler, og først da finner man ut hvem som er hvem. Det vil si at det siste trinnet er autentiseringsprosessen, enten ved PSK eller med RSA-nøkkel. Og hvis partene kommer til enighet, etableres det en ISAKMP-tunnel, som den andre fasen av IKE allerede går gjennom.
I den andre fasen blir deltakerne som allerede har tillit til hverandre enige om hvordan de skal bygge hovedtunnelen for direkte overføring av data. De tilbyr hverandre alternativene spesifisert i transform-set-parameteren, og hvis de er enige, løfter de hovedtunnelen. Det er viktig å understreke at når den først er etablert, forsvinner ikke ISAKMP-hjelpetunnelen – den brukes til periodisk å oppdatere SA til hovedtunnelen. Som et resultat setter IPsec på en måte opp ikke én, men to tunneler.
Hvordan behandle data
Nå noen få ord om transform-set. Tross alt må du på en eller annen måte kryptere dataene som går gjennom tunnelen. Derfor, i en typisk konfigurasjon, er transform-set et sett med parametere som eksplisitt spesifiserer hvordan en pakke skal håndteres. Følgelig er det to alternativer for slik databehandling - disse er ESP- og AH-protokollene. ESP (Encapsulating Security Payload) omhandler direkte datakryptering, og kan også sørge for kontroller av dataintegritet. AH (Authentication Header) er på sin side kun ansvarlig for å autentisere kilden og sjekke integriteten til dataene.For eksempel vil kommandoen `crypto ipsec transform-set SET10 esp-aes` fortelle ruteren at et transform-sett kalt `SET10` bare skal fungere med ESP- og AES-kryptering. Når vi ser fremover, vil jeg si at vi heretter vil bruke Cisco-rutere og brannmurer som mål. Egentlig, med ESP er alt mer eller mindre klart, dets virksomhet er å kryptere og dermed sikre konfidensialitet, men hvorfor trenger vi da AH? AH gir dataautentisering, det vil si at den bekrefter at disse dataene kom nøyaktig fra personen vi opprettet forbindelse med og ikke ble endret underveis. Det gir det som noen ganger kalles anti-replay-beskyttelse. I moderne nettverk brukes AH praktisk talt ikke, bare ESP finnes overalt.
Parametrene (alias SA) som er valgt for kryptering av informasjon i IPsec-tunnelen har en levetid, hvoretter de må erstattes. Standard levetid for IPsec SA er 86 400 sekunder, eller 24 timer.
Som et resultat fikk deltakerne en kryptert tunnel med parametere som passer dem alle, og sender datastrømmene som skal krypteres dit. Periodisk, i samsvar med levetid, oppdateres krypteringsnøklene for hovedtunnelen: deltakerne kobler seg igjen via ISAKMP-tunnelen, går gjennom den andre fasen og reetablerer SA.
IKEv1-moduser
Vi har dekket den grunnleggende mekanikken til IPsec som en første tilnærming, men det er noen flere ting å fokusere på. Den første fasen kan blant annet operere i to moduser: hovedmodus eller aggressiv modus. Vi har allerede vurdert det første alternativet ovenfor, men vi er interessert i bare aggressiv modus. Denne modusen bruker tre meldinger (i stedet for seks i hovedmodus). Samtidig gir den som setter i gang forbindelsen alle sine data på en gang – det han vil og det han kan, samt sin del av DH-sentralen. Motparten fullfører da umiddelbart sin del av å generere DH. Som et resultat, i denne modusen, er det faktisk bare to stadier. Det vil si at de to første stadiene fra hovedmodus (hash-matching og DH-utveksling) er så å si komprimert til ett. Som et resultat er denne modusen mye farligere av den grunn at mye teknisk informasjon kommer som svar i klartekst. Og viktigst av alt, VPN-gatewayen kan sende en hash av passordet som brukes til autentisering i den første fasen (dette passordet kalles også ofte den forhåndsdelte nøkkelen eller PSK).Vel, all påfølgende kryptering skjer uendret, som vanlig. Hvorfor er denne modusen fortsatt i bruk? Faktum er at det er mye raskere, omtrent dobbelt så raskt. Av spesiell interesse for pentesteren er det faktum at aggressiv modus veldig ofte brukes i RA IPsec VPN. En annen liten funksjon i RA IPsec VPN når du bruker aggressiv modus: når en klient kontakter en server, sender den en identifikator (gruppenavn). Tunnelgruppenavn (se figur 2) er navnet på oppføringen som inneholder settet med policyer for denne IPsec-tilkoblingen. Dette er allerede en av funksjonene som er spesifikke for Cisco-utstyr.
Ris. 2. Tunnelgruppenavn
To faser var ikke nok
Det ser ut til at dette ikke er et veldig enkelt arbeidsopplegg, men i virkeligheten er det fortsatt litt mer komplisert. Over tid ble det klart at PSK alene ikke var nok til å gi sikkerhet. For eksempel, hvis en ansatts arbeidsstasjon ble kompromittert, kan en angriper umiddelbart få tilgang til hele bedriftens interne nettverk. Derfor ble fase 1.5 utviklet rett mellom første og andre klassiske fase. Forresten, denne fasen brukes vanligvis ikke i en standard sted-til-sted VPN-tilkobling, men brukes når du organiserer eksterne VPN-tilkoblinger (vårt tilfelle). Denne fasen inneholder to nye utvidelser - Extended Authentication (XAUTH) og Mode-Configuration (MODECFG).XAUTH er ekstra brukerautentisering innenfor IKE-protokollen. Denne autentiseringen blir også noen ganger referert til som den andre faktoren til IPsec. Vel, MODECFG tjener til å overføre tilleggsinformasjon til klienten, det kan være en IP-adresse, maske, DNS-server, etc. Det kan sees at denne fasen ganske enkelt utfyller de tidligere vurderte, men nytten er ubestridelig.
IKEv2 vs IKEv1
Begge protokollene opererer på UDP-port 500, men de er inkompatible med hverandre; det er ikke tillatt at det er IKEv1 i den ene enden av tunnelen og IKEv2 i den andre. Her er hovedforskjellene mellom den andre versjonen og den første:IKEv2 inkluderer ikke lenger aggressive eller hovedmoduser.
- I IKEv2 er begrepet den første fasen erstattet av IKE_SA_INIT (utveksling av to meldinger, som sikrer forhandling av kryptering / hashing-protokoller og generering av DH-nøkler), og den andre fasen erstattes av IKE_AUTH (også to meldinger som implementerer den faktiske godkjenning).
- Mode Config (det som ble kalt fase 1.5 i IKEv1) er nå beskrevet direkte i protokollspesifikasjonen og er en integrert del av den.
- En ekstra anti-DoS-angrepsmekanisme er lagt til IKEv2. Essensen er at før du svarer på hver forespørsel om å opprette en sikker tilkobling (IKE_SA_INIT) IKEv2, sender VPN-gatewayen en informasjonskapsel til kilden til en slik forespørsel og venter på svar. Hvis kilden svarte - alt er i orden, kan du begynne å generere DH med den. Hvis kilden ikke reagerer (i tilfelle av et DoS-angrep, dette er hva som skjer, denne teknikken ligner en TCP SYN-flom), så glemmer VPN-gatewayen det ganske enkelt. Uten denne mekanismen, på hver forespørsel fra hvem som helst, ville VPN-gatewayen prøve å generere en DH-nøkkel (som er en ganske ressurskrevende prosess) og ville snart få problemer. Som et resultat, på grunn av det faktum at alle operasjoner nå krever bekreftelse fra den andre siden av forbindelsen, er det umulig å opprette et stort antall halvåpne økter på den angrepne enheten.
Vi går til grensen
Etter å endelig ha funnet ut særegenhetene til IPsec og dens komponenter, kan du gå videre til det viktigste - til praktiske angrep. Topologien vil være ganske enkel og samtidig virkelighetsnær (se fig. 3).
Ris. 3. Generelt nettverksdiagram
Det første trinnet er å finne ut om det er en IPsec VPN-gateway. Du kan gjøre dette ved å utføre en portskanning, men det er en liten særegenhet her. ISAKMP bruker UDP, port 500, mens standard Nmap-skanning kun påvirker TCP-porter. Og resultatet vil være meldingen: `Alle 1000 skannede porter på 37.59.0.253 er filtrert`.
Det ser ut til at alle porter er filtrert og det er ingen åpne porter. Men ved å kjøre kommandoen
Nmap -sU --top-ports = 20 37.59.0.253 Starter Nmap 6.47 (http://nmap.org) kl. 2015-03-21 12:29 GMT Nmap-skanningsrapport for 37.59.0.253 Verten er oppe (0,066s latens) ... PORT STATE SERVICE 500 / udp åpen isakmp
vi er overbevist om at dette ikke er tilfelle, og vi står virkelig overfor en VPN-enhet.
Vi angriper den første fasen
Nå vil vi være interessert i den første fasen, aggressiv modus og autentisering ved hjelp av en forhåndsdelt nøkkel (PSK). I dette scenariet, husk at VPN-enheten eller svaret sender en hashed PSK til initiativtakeren. Et av de mest kjente verktøyene for å teste IKE-protokollen er ike-scan, som følger med Kali Linux-distribusjonen. Ike-scan lar deg sende IKE-meldinger med forskjellige parametere og følgelig dekode og analysere svarpakkene. Prøver å sondere målenheten:[e-postbeskyttet]: ~ # ike-scan -M -A 37.59.0.253 0 returnert håndtrykk; 0 returnerte varsling
Ris. 4. Ike-scan aggressiv modus
`-A`-bryteren indikerer at aggressiv-modusen skal brukes, og `-M` indikerer at resultatene skal vises linje for linje (flerlinje), for enklere lesing. Det kan sees at det ikke ble oppnådd noe resultat. Årsaken er at du må spesifisere den samme identifikatoren, navnet på VPN-gruppen. Selvfølgelig lar ike-scan-verktøyet deg spesifisere denne identifikatoren som en av parameterne. Men siden vi ikke vet det ennå, la oss ta en vilkårlig verdi, for eksempel 0000.
[e-postbeskyttet]: ~ # ike-scan -M -A --id = 0000 37.59.0.253 37.59.0.253 Aggressiv modus Handshake returnert 
Ris. 5. Ike-scan ID
Denne gangen ser vi at svaret ble mottatt (se fig. 5) og vi fikk ganske mye nyttig informasjon. En ganske viktig del av informasjonen som er oppnådd er transformasjonssettet. I vårt tilfelle står det at "Enc = 3DES Hash = SHA1 Group = 2: modp1024 Auth = PSK".
Alle disse parameterne kan spesifiseres for ike-scan-verktøyet ved å bruke `--trans`-bryteren. For eksempel vil `--trans = 5,2,1,2` fortelle deg at krypteringsalgoritmen er 3DES, HMAC-SHA hashing, PSK autentiseringsmetode, og den andre gruppetypen er DH (1024-bit MODP). Du kan se tabeller over samsvar med verdier på denne adressen. La oss legge til en nøkkel til (`-P`) for å vise nyttelasten til pakken direkte, eller snarere PSK-hashen.
[e-postbeskyttet]: ~ # ike-scan -M -A --id = 0000 37.59.0.253 -P 
Ris. 6. Ike-scan nyttelast
Overvinne de første vanskelighetene
Det ser ut til at hasjen er mottatt og du kan prøve å brute den, men det er ikke så enkelt. En gang i tiden, i 2005, var det en sårbarhet på noen Cisco-maskinvare: disse enhetene ga en hash bare hvis angriperen passerte riktig ID-verdi. Nå er det selvfølgelig nesten umulig å finne slikt utstyr og hashed-verdien sendes alltid, uavhengig av om angriperen har sendt riktig ID-verdi eller ikke. Det er åpenbart meningsløst å brute-force feil hasj. Derfor er den første oppgaven å bestemme riktig ID-verdi for å få riktig hash. En nylig oppdaget sårbarhet vil hjelpe oss med dette.Poenget er at det er liten forskjell mellom svarene under den første utvekslingen av meldinger. Kort sagt, når du bruker riktig gruppenavn, er det fire forsøk på å fortsette å etablere VPN-tilkoblingen, pluss to krypterte andrefasepakker. Mens i tilfelle feil ID, kommer bare to pakker som svar. Som du kan se, er forskjellen ganske betydelig, så SpiderLabs (forfatteren av det like interessante Responder-verktøyet) utviklet først PoC og deretter IKEForce-verktøyet for å utnytte denne sårbarheten.
Hva er styrken til IKE
Du kan installere IKEForce i en vilkårlig katalog ved å kjøre kommandoenGit-klone https://github.com/SpiderLabs/ikeforce
Den fungerer i to hovedmoduser - beregningsmodus `-e` (oppregning) og brute force-modus` -b` (bruteforce). Vi kommer til den andre når vi ser på angrepene på den andre faktoren, men nå skal vi håndtere den første. Før du starter selve prosessen med å bestemme IDen, må du angi den nøyaktige verdien til transform-settet. Vi har allerede definert det tidligere, så vi vil spesifisere det med alternativet `-t 5 2 1 2`. Som et resultat vil prosessen med å finne ID-en se slik ut:
Python ikeforce.py 37.59.0.253 -e -w ordlister / group.txt -t 5 2 1 2 
Ris. 7. IKEForce-oppregning
Som et resultat ble riktig ID-verdi raskt oppnådd (fig. 7). Det første trinnet er bestått, du kan gå videre.
Vi får PSK
Nå må du lagre PSK-hashen til en fil med riktig gruppenavn, du kan gjøre dette ved å bruke ike-scan:Ike-scan -M -A --id = vpn 37.59.0.253 -Pkey.psk
Og nå som riktig ID-verdi er funnet og riktig PSK-hash er oppnådd, kan vi endelig starte offline brute-force. Det er ganske mange alternativer for slik brute-force - dette er det klassiske verktøyet psk-crack, og John the Ripper (med en jumbo-patch), og til og med oclHashcat, som, som du vet, lar deg bruke kraften til GPU. For enkelhets skyld bruker vi psk-crack, som støtter både direkte brute-force og ordbokangrep:
Psk-crack -d / usr / share / ike-scan / psk-crack-dictionary key.psk
Ris. 8. Psk-sprekk
Men selv vellykket gjenoppretting av PSK (se figur 8) er bare halve kampen. På dette stadiet må du huske på hva som er neste for oss XAUTH og den andre faktoren til IPsec VPN.
Håndtere den andre faktoren til IPsec
Så la meg minne deg på at XAUTH er ekstra beskyttelse, den andre faktoren for autentisering, og den er i fase 1.5. Det kan være flere XAUTH-alternativer - disse er RADIUS-sjekker, engangspassord (OTP) og en vanlig lokal brukerbase. Vi vil fokusere på en typisk situasjon der den lokale brukerbasen brukes til å teste den andre faktoren. Inntil nylig var det ikke noe offentlig tilgjengelig verktøy for brute-force XAUTH. Men med bruken av IKEForce fikk denne oppgaven en verdig løsning. Å starte XAUTH brute force er ganske enkelt:Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists / passwd.txt -t 5 2 1 2 [+] Program startet i XAUTH Brute Force Mode [+] Enkeltbruker levert - brute forcing passord for bruker: admin [*] XAUTH Autentisering vellykket! Brukernavn: admin Passord: cisco 
Ris. 9. IKEForce XAUTH
Alle tidligere funnet verdier er indikert: ID (nøkkel `-i`), gjenopprettet PSK (nøkkel` -k`) og antatt pålogging (nøkkel `-u`). IKEForce støtter både brute force login og brute force login, som kan spesifiseres med "-U" parameteren. I tilfelle av mulig blokkering av valg, er det et alternativ `-s`, som lar deg redusere hastigheten på brute-force. Verktøyet kommer forresten med flere gode ordbøker, som er spesielt nyttige for å angi verdien til ID-parameteren.
Vi går inn i det interne nettverket
Nå som vi har alle dataene, gjenstår det siste trinnet - selve penetrasjonen i det lokale nettverket. For å gjøre dette trenger vi en slags VPN-klient, som det er veldig mange av. Men når det gjelder Kali, kan du bruke den forhåndsinstallerte VPNC-en uten problemer. For at det skal fungere, må du korrigere én konfigurasjonsfil - `/ etc / vpnc / vpn.conf`. Hvis det ikke er der, må du opprette og fylle ut en rekke åpenbare parametere:IPSec-gateway 37.59.0.253
IPSec ID vpn
IPSec hemmelig cisco123
IKE Authmode psk
Xauth Brukernavn admin
Xauth passord cisco
Her ser vi at absolutt alle dataene som ble funnet i de foregående trinnene ble brukt - ID-verdien, PSK, pålogging og passord for den andre faktoren. Etter det skjer selve forbindelsen med en kommando:
[e-postbeskyttet]: ~ # vpnc vpn
Deaktivering er også ganske enkelt:
[e-postbeskyttet]: ~ # vpnc-disconnect
Du kan sjekke om tilkoblingen fungerer som den skal ved å bruke kommandoen `ifconfig tun0`. 
Ris. 10. VPNC
Hvordan bygge pålitelig beskyttelse
Beskyttelse mot angrepene som vurderes i dag bør være omfattende: du må installere patcher i tide, bruke sterke forhåndsdelte nøkler, som om mulig bør erstattes fullstendig med digitale sertifikater. Passordpolitikk og andre åpenbare elementer av informasjonssikkerhet spiller også en viktig rolle for å sikre sikkerheten. Det skal også bemerkes at situasjonen gradvis endrer seg, og over tid vil bare IKEv2 gjenstå.Hva er bunnlinjen
Vi har dekket revisjonsprosessen for RA IPsec VPN i full detalj. Ja, selvfølgelig, denne oppgaven er langt fra triviell. Det er mange skritt som må tas, og hver av dem kan møte vanskeligheter, men hvis de lykkes, er resultatet mer enn imponerende. Å få tilgang til de interne ressursene i nettverket åpner for det bredeste handlingsrommet. Derfor bør de som er ansvarlige for å beskytte nettverksperimeteren ikke stole på ferdige standardmaler, men nøye tenke over hvert sikkerhetslag. Vel, for de som gjennomfører pentests, er den oppdagede 500. UDP-porten en grunn til å gjennomføre en dyp analyse av IPsec VPN-sikkerheten og muligens få gode resultater.
Abonner på "Hacker"
Encapsulating Security Payload (ESP) sikrer datakonfidensialitet. I tillegg lar den deg identifisere avsenderen av dataene, samt sikre dataintegritet og beskyttelse mot informasjonsreproduksjon.
Forskjellen mellom ESP og Authentication Header (AH) er at ESP krypterer dataene. Samtidig gir begge protokollene identifikasjon, integritetssjekk og beskyttelse mot informasjonsgjengivelse. Når du arbeider med ESP, bruker begge endesystemene en felles nøkkel for å kryptere og dekryptere data.
Hvis kryptering og dataidentifikasjonsmidler brukes samtidig, identifiserer det svarende systemet først pakken, og hvis identifiseringen er vellykket, dekrypterer den pakken. Denne måten å håndtere pakker på reduserer belastningen på systemet og reduserer risikoen for at et tjenestenektangrep kompromitterer sikkerheten.
To måter å bruke ESP på
ESP kan brukes på to måter: i åpen modus og i tunnelmodus. I åpen modus vises ESP-overskriften etter IP-datagramoverskriften. Hvis datagrammet allerede har en IPSec-header, plasseres ESP-headeren før den headeren. ESP-tilhenger og identifikasjonsdata, hvis noen, er angitt etter datafeltet.
I åpen overføringsmodus er IP-hodet verken identifisert eller kryptert. I dette tilfellet kan adressene som er spesifisert i overskriften bli fanget opp under overføringen av datagrammet over nettverket. Datautveksling i åpen overføringsmodus krever færre ressurser enn når du arbeider i tunnelmodus. Denne modusen gir imidlertid et lavere beskyttelsesnivå. I de fleste tilfeller, når du arbeider med ESP-protokollen, brukes den åpne overføringsmodusen.
Tunnelmodus oppretter en ny IP-header som blir den ytterste overskriften til datagrammet. Den etterfølges av ESP-headeren, etterfulgt av selve datagrammet (IP-header og data). ESP-traileren og påloggingsinformasjonen, hvis noen, legges til på slutten av datafeltet. Hvis kryptering og autentisering brukes samtidig, beskytter ESP det originale datagrammet fullt ut, siden det datagrammet blir et datafelt i den nye ESP-pakken. Den nye IP-headeren er ikke beskyttet. Når du oppretter en forbindelse mellom gatewayer, bruk ESP i tunnelmodus.
Ibrukt av ESP
ESP bruker en symmetrisk nøkkel som krypterer og dekrypterer data av sluttsystemer. Før utveksling av data må avsender og mottaker bli enige om en nøkkel de skal bruke. VPN-funksjonen støtter DES, Triple DES (3DES), RC5, RC4, AES eller AES-CBC-kryptering.
Når du bruker AES-krypteringsalgoritmen, kan du aktivere Extended Sequence Number (ESN). ESN lar deg overføre store mengder data med høy hastighet. VPN-tilkoblingen bruker 64-biters sekvensnumre i stedet for 32-biters tall over IPSec. Bruk av 64-biters sekvensnummer øker tiden før en nøkkelendring skjer, noe som forhindrer slutten av sekvensnummerpoolen og sparer systemressurser.
Internet Working Group (IETF) beskriver formelt algoritmene i følgende RFC-er:
Disse og andre RFC-er kan finnes på Internett på følgende nettsted: http://www.rfc-editor.org.
ESP-protokollen støtter HMAC-MD5, HMAC-SHA, HMAC-SHA-256 og AES-XCBC-MAC autentiseringsalgoritmer. Begge algoritmene mottar data med variabel lengde og en privat nøkkel som input, og genererer data med fast lengde (eller en hash-verdi eller MAC). Hvis verdiene til hash-funksjonen beregnet for to meldinger er de samme, er disse meldingene med stor sannsynlighet de samme.
Internet Working Group (IETF) beskriver formelt algoritmene i følgende RFC-er:
Disse RFC-ene kan sees på følgende nettsted: http://www.rfc-editor.org.
VPN-er med IPsec gir fleksibel og skalerbar tilkobling. Bransjeforbindelser kan gi sikker, høyhastighets og pålitelig fjernkommunikasjon. Med VPN med IPsec overføres informasjon fra det private nettverket sikkert over det offentlige nettverket. Dette lar deg lage et virtuelt nettverk i stedet for å bruke en dedikert Layer 2-tilkobling, som vist i figuren. For å sikre datakonfidensialitet er trafikk kryptert.
IPsec er en IETF-standard som definerer hvordan et sikkert VPN-nettverk konfigureres ved hjelp av IP.
IPsec er et rammeverk for åpne standarder som definerer reglene for organisering av sikker kommunikasjon. IPsec er ikke assosiert med spesifikke kryptering- og autentiseringsmetoder, sikkerhetsalgoritmer eller nøkkelutvekslingsteknologi. IPsec bruker eksisterende algoritmer for å gi sikker kommunikasjon. IPsec lar deg lage nye, bedre algoritmer som ikke trenger å justere eksisterende IPsec-standarder for å utvikle.
IPsec opererer på nettverkslaget for å gi beskyttelse og autentisering av IP-pakker mellom kommuniserende IPsec-enheter, også kalt peers. IPsec lar deg sikre banen mellom et par gatewayer, et par datamaskiner eller mellom en gateway og en datamaskin. Som et resultat kan IPsec beskytte praktisk talt all applikasjonstrafikk, siden den kan implementere beskyttelse fra lag 4 til og med lag 7.
Alle implementerte IPsec-løsninger bruker en ukryptert lag 3-header, så det er ingen rutingproblemer. IPsec kjører på toppen av alle Layer 2-protokoller som Ethernet, ATM og Frame Relay.
Følgende er hovedfunksjonene til IPsec:
- IPsec er et rammeverk med åpen standard uavhengig av algoritmer.
- IPsec gir datakonfidensialitet og integritet, samt kildeautentisering.
- IPsec fungerer som en nettverkslagsprotokoll, som beskytter og autentiserer IP-pakker.
IP beskyttelse
- Personvern (kryptering)– I en VPN overføres private data over et offentlig nettverk. Derfor er det viktig å sikre konfidensialiteten til data. For dette blir data kryptert før data overføres over nettverket. Kryptering er prosessen med å kode alle data som sendes fra en datamaskin til en annen til en form som bare mottakerdatamaskinen kan dekode. Hvis meldingen blir fanget opp, vil ikke en angriper (hacker) kunne lese den. IPsec gir avanserte sikkerhetsfunksjoner (for eksempel sterke krypteringsalgoritmer).
- Dataintegritet– Mottakeren kan bekrefte at dataene er overført normalt via Internett og ikke er endret på noen måte. Det er viktig ikke bare å sikre at data er kryptert på det offentlige nettverket, men også å sikre at de ikke har blitt endret under overføring. IPsec gir en mekanisme for å sjekke at det ikke er noen endringer i den krypterte delen av pakken, i hele overskriften eller i hoveddelen av pakkedataene. IPsec garanterer dataintegritet ved å bruke sjekksummer (enkel sjekk med redundans brukes). Hvis det oppdages tukling, fjernes pakken.
- Godkjenning- lar deg sjekke hvem som var kilden til de sendte dataene. Dette er nødvendig for å beskytte mot angrep som bruker spoofing (sender spoofing). Autentisering bidrar til å sikre at en tilkobling opprettes med riktig kommunikasjonspartner. Mottakeren kan bekrefte identiteten til kilden til pakken ved å bekrefte kilden til informasjonen. IPsec bruker IKE-teknologi (Internet Key Exchange) for å autentisere brukere og enheter som kan kommunisere uavhengig. IKE bruker en rekke typer autentisering (inkludert brukernavn og passord, engangspassord, biometri, Pre-Shared Key (PSK) og digitale sertifikater).
- Replay beskyttelse- Gjør det mulig å oppdage og avvise dupliserte pakker, samt forhindre spoofing. Med anti-replay-beskyttelse kan du sikre at en pakke er unik og ikke duplisert. IPsec-pakker er beskyttet ved å sammenligne sekvensnummeret for mottatte pakker med et skyvevindu på destinasjonsverten eller Security Gateway. En pakke med et sekvensnummer som kommer før skyvevinduet anses som forsinket eller duplisert. Forsinkede og dupliserte pakker fjernes.
Akronymet CIA bringer i mange tilfeller tankene til disse tre funksjonene: konfidensialitet, integritet og autentisering.
IPsec-protokollstruktur
Figuren viser at IPsec-sikkerhetstjenester utfører følgende viktige funksjoner:
konfidensialitet
Personvern for VPN-trafikk opprettholdes ved hjelp av kryptering. Åpne (ukrypterte) data som overføres over Internett kan fanges opp og leses. Kryptering brukes for å bevare personvernet til dataene. Digitalt krypterte data forblir uleselige inntil de dekrypteres av en autorisert mottaker.
For å sikre kryptert kommunikasjon, må både avsender og mottaker kjenne reglene som brukes for å transformere den opprinnelige meldingen til kodet form. Regler er basert på algoritmer og matchende nøkler. I krypteringsammenheng er en algoritme en matematisk sekvens av handlinger der en melding, tekst, tall eller alle er kombinert med en tallstreng kalt en nøkkel. Utdataene vises som en uleselig kryptert streng. Krypteringsalgoritmen bestemmer også hvordan den krypterte meldingen dekrypteres. Uten riktig nøkkel er det nesten umulig å dekryptere dataene.
I grafikken kan du se at Gale ønsker å overføre midler elektronisk over Internett til Jeremy. På den lokale siden er dokumentet kombinert med en nøkkel og kryptert. Utgangen er chiffertekst. Denne chifferteksten sendes deretter over Internett. På den eksterne siden blir meldingen igjen kombinert med nøkkelen og sendt gjennom krypteringsalgoritmen i motsatt retning. Utgangen er det originale økonomiske dokumentet.
Konfidensialitet oppnås ved å kryptere trafikk når den går gjennom VPN. Graden av sikkerhet avhenger av lengden på nøkkelen i krypteringsalgoritmen og kompleksiteten til selve algoritmen. Hvis en hacker prøver å knekke en nøkkel gjennom et brute-force-angrep, vil antallet alternativer for brute-force avhenge av lengden på nøkkelen. Behandlingstiden for alle mulige alternativer avhenger av prosessorkraften til angriperens datamaskin. Derfor, jo kortere nøkkelen er, jo lettere er den å knekke. For eksempel, mens det tar en relativt kraftig datamaskin omtrent ett år å knekke en 64-bits nøkkel, kan den samme datamaskinen ta 10 til 19 år å knekke en 128-bits nøkkel.
IPsec-krypteringsalgoritmer
Graden av sikkerhet avhenger av lengden på nøkkelen i krypteringsalgoritmen. Etter hvert som lengden på nøkkelen øker, reduseres sannsynligheten for å bryte chifferen. Men jo lengre nøkkelen er, desto flere prosessorressurser vil kreves for å kryptere og dekryptere data.
DES og 3DES anses ikke lenger som sikre, så AES anbefales for IPsec-kryptering. Det høyeste sikkerhetsnivået for VPN-kryptering mellom Cisco-enheter som bruker IPsec, leveres av 256-bit AES-alternativet. I tillegg, med tanke på å knekke 512-biters og 768-biters Rivest-Shamir-Edlman (RSA)-nøkler, anbefaler Cisco å bruke 2048-biters nøkler i RSA-varianten (hvis brukt under IKE-autentiseringsfasen).
Symmetrisk kryptering
Krypteringsalgoritmer som AES krever en delt hemmelighet for å utføre både kryptering og dekryptering. For å dekode informasjonen må begge nettverksenhetene kjenne nøkkelen. Med symmetrisk nøkkelkryptering (også kalt privat nøkkelkryptering), krypterer hver enhet data før de sendes over nettverket til en annen enhet. Med symmetrisk nøkkelkryptering må du vite hvilke enheter som kommuniserer med hverandre slik at den samme nøkkelen kan konfigureres på hver enhet (se figur 1).
For eksempel lager avsenderen en kodet melding, der hver bokstav endres til neste bokstav to bokstaver senere i alfabetet (det vil si at A blir C, B blir D osv.). I dette tilfellet blir ordet HEMMELIG UGETGV. Avsenderen har allerede informert mottakeren om at den hemmelige nøkkelen er en offset på 2. Når mottakeren mottar en UGETGV-melding, dekoder datamaskinen meldingen bakover med to bokstaver og mottar ordet SECRET. Enhver annen bruker som ser på denne meldingen, ser den i kryptert form. For at en slik melding ikke skal se ut som vrøvl, må du kjenne den hemmelige nøkkelen.
Følgende er funksjonene til symmetriske algoritmer:
- symmetrisk nøkkelkryptografi brukes;
- den samme nøkkelen brukes til kryptering og dekryptering;
- ofte brukt til å kryptere innholdet i en melding.
- Eksempler: DES, 3DES og AES
Hvordan kan krypterings- og dekrypteringsenhetene få informasjon om den delte hemmeligheten? Delte hemmelige nøkler kan selvfølgelig sendes til enhetsadministratorer via e-post, vanlig post eller budpost. Men en annen, sikrere måte er asymmetrisk kryptering.
Asymmetrisk kryptering
Asymmetrisk kryptering bruker forskjellige nøkler for kryptering og dekryptering. Å kjenne en av nøklene forhindrer hackeren i å beregne den andre nøkkelen og dekode informasjonen. En nøkkel brukes til å kryptere meldingen, den andre for å dekryptere den (se figur 2). Du kan ikke utføre krypterings- og dekrypteringsoperasjoner med samme nøkkel.
Et av alternativene for asymmetrisk kryptering er offentlig nøkkelkryptering, som bruker en kombinasjon av hemmelige og offentlige (offentlige) nøkler. Mottakeren gir den offentlige nøkkelen til enhver avsender som mottakeren trenger å kommunisere med. Avsenderen bruker en privat nøkkel for å kryptere meldingen, som kombineres med mottakerens offentlige nøkkel. I tillegg må avsenderen kommunisere sin offentlige nøkkel til mottakeren. Mottakeren vil bruke avsenderens offentlige nøkkel sammen med sin egen private nøkkel for å dekryptere meldingen.
Følgende er funksjonene til asymmetriske algoritmer:
- offentlig nøkkelkryptering brukes;
- forskjellige nøkler brukes til kryptering og dekryptering;
- ofte brukt i digital sertifikat- og nøkkelhåndtering.
Integritet og hashing-algoritmer
Hashing-algoritmer brukes for å sikre integriteten og autentiseringen av VPN-trafikk. Dataintegritet og autentisering er sikret av hash-koder, som sikrer at de overførte meldingene ikke tukles med av uautoriserte personer. En hash-kode, også kalt en meldingssammendrag, er et tall som genereres fra en tekststreng. Hash-koden er mindre enn selve teksten. Den er opprettet ved hjelp av en formel på en slik måte at det er ekstremt usannsynlig å få samme hashkodeverdi fra en annen tekst.
Den opprinnelige avsenderen genererer en meldingshash og sender den sammen med selve meldingen. Mottakeren analyserer meldingen og hashkoden, genererer en annen hashkode basert på de mottatte meldingene, og sammenligner begge hashkodene. Hvis de samsvarer, kan mottakeren rimeligvis være sikker på integriteten til den opprinnelige meldingen.
Grafikken viser at Gale sendte Alex en elektronisk postanvisning på 100 dollar. Jeremy fanget opp og modifiserte overføringen for å vise at han er mottakeren og overføringsbeløpet er 1000 dollar. I dette tilfellet, hvis dataintegritetsalgoritmen ble brukt, vil ikke hashkodene samsvare med hverandre, og transaksjonen vil være ugyldig.
VPN-data overføres over det offentlige Internett. Som vist i figuren er det en mulighet for avskjæring og modifikasjon av disse dataene. Datamaskiner kan legge til hash-koder i meldinger for å beskytte mot denne trusselen. Hvis den overførte hashkoden samsvarer med den mottatte hashkoden, betyr det at integriteten til meldingen er sikret. Men hvis hash-kodene ikke stemmer overens, har meldingen blitt endret.
VPN-er bruker en autentiseringskode for å bekrefte integriteten og autentisiteten til en melding uten å bruke noen ekstra mekanismer.
Hash-basert meldingsautentiseringskode (HMAC) er en mekanisme for autentisering av meldinger ved hjelp av hashing-funksjoner. HMAC Key Exchange er en dataintegritetsalgoritme som garanterer meldingsintegritet. HMAC har to parametere: meldingen som skal legges inn og en hemmelig nøkkel som kun er kjent for forfatteren av meldingen og tiltenkte mottakere. Avsenderen av meldingen bruker HMAC-funksjonen til å lage en verdi (meldingsautentiseringskode) generert ved å behandle den hemmelige nøkkelen og inndatameldingen. Meldingsautentiseringskoden sendes med meldingen. Mottakeren beregner meldingsautentiseringskoden i den mottatte meldingen ved å bruke den samme nøkkelen og HMAC-funksjonen som avsenderen brukte. Mottakeren sammenligner deretter det beregnede resultatet med den mottatte meldingsautentiseringskoden. Hvis begge verdiene samsvarer, betyr det at riktig melding ble mottatt, og mottakeren kan være trygg på at avsenderen er medlem av brukerfellesskapet som bruker denne delte nøkkelen. Den kryptografiske styrken til HMAC-algoritmen avhenger av den kryptografiske styrken til den underliggende hashfunksjonen, størrelsen og kvaliteten på nøkkelen, og lengden på hashfunksjonsresultatet (i biter).
Det er to vanligste HMAC-algoritmer:
- MD5- en 128-bits delt hemmelighet brukes. En melding med vilkårlig lengde og en 128-bits delt hemmelighet kombineres med hverandre og behandles av HMAC-MD5 hashing-algoritmen. Som et resultat genereres en 128-bits hash-kode. Hash-koden legges til den opprinnelige meldingen og omdirigeres til den eksterne siden.
- SHA- SHA-1 bruker en 160-biters delt hemmelighet. Meldingen med variabel lengde og den 160-biters delte hemmeligheten kombineres med hverandre og behandles med HMAC-SHA1 hashing-algoritmen. Resultatet er en 160-bits hash-kode. Hash-koden legges til den opprinnelige meldingen og omdirigeres til den eksterne siden.
Merk... Cisco IOS støtter også 256-biters, 384-biters og 512-biters SHA-alternativer.
IPsec-autentisering
Autentisering støttes på IPsec VPN-er. Hvis forretningspartnerne dine er på god avstand fra deg, er det viktig å vite hvem du snakker med på telefonen, hvem som sender deg en e-post eller faks. Det samme gjelder for VPN-er. Som vist i figuren, må identiteten til enheten i den andre enden av VPN-tunnelen verifiseres før kommunikasjonen kan anses som sikker. Det er to metoder for autentisering av samtalepartneren:
- PSK- en hemmelig nøkkel kjent på forhånd for to brukere som kommuniserer over en sikker kanal. Pre-Shared Key (PSK) bruker symmetriske nøkkelkryptografiske algoritmer. PSK legges inn manuelt ved hver av de kommuniserende nodene (peers) og brukes til å autentisere hverandre. På hver side kombineres PSK med annen informasjon for å danne en autentiseringsnøkkel.
IPsec bruker RSA (Public Key Cryptographic System) for autentisering i IKE-sammenheng. RSA bruker en digital signaturordning der hver enhet signerer et datasett digitalt og overfører det til en annen bruker. RSA-signeringsalgoritmen bruker en sertifiseringsmyndighet (CA) for å generere et digitalt sertifikat med unik identifikator som tildeles hver peer for autentisering. Selve det digitale identitetssertifikatet ligner PSK, men gir et mye høyere sikkerhetsnivå. Hver initiativtaker og responder i en IKE-økt som bruker RSA-signaturer, sender sin egen identitetsverdi, sitt digitale identitetssertifikat og en RSA-signaturverdi sammensatt av flere IKE-verdier. Alle disse dataene er kryptert med en IKE-forhandlet krypteringsmetode (som AES).
En annen autentiseringsmetode er Digital Signature Algorithm (DSA).
IPsec-protokollstruktur
Som nevnt ovenfor beskriver IPsec-protokollpakken en meldingsmetode for å sikre kommunikasjon, men den bygger på eksisterende algoritmer.
Figur 1 viser de to hoved-IPsec-protokollene:
- Autentiseringshode (AH)– AH er en spesiell protokoll som brukes i tilfeller hvor konfidensialitet ikke er påkrevd eller forbudt. Det gir autentisering og dataintegritet for IP-pakker som overføres mellom to systemer. AH gir imidlertid ikke konfidensialitet (kryptering) av data i pakker. All tekst overføres i klartekst (ingen kryptering). Hvis bare AH-protokollen brukes (og ingen andre mekanismer brukes), gir den svak beskyttelse.
- Encapsulating Security Payload (ESP) er en sikkerhetsprotokoll som gir personvern og autentisering ved å kryptere en IP-pakke. IP-pakkekrypteringsprosessen skjuler kilde- og destinasjonsdata og identifikatorer. ESP verifiserer identiteten til den interne IP-pakken og ESP-headeren. Autentisering sikrer identiteten til datakilden og integriteten til dataene. Selv om kryptering og autentiseringsprosedyrer er valgfrie i ESP, må minst én av dem velges.
I fig. Figur 2 viser komponentene i IPsec-konfigurasjonen. Det er fire grunnleggende byggeklosser i IPsec-rammeverket du må velge.
- Personvern (hvis IPsec med ESP er valgt)- den valgte krypteringsalgoritmen skal gi det nødvendige sikkerhetsnivået på best mulig måte: DES, 3DES eller AES. AES anbefales sterkt (AES-GCM gir det høyeste sikkerhetsnivået).
- Integritet- sikrer at innholdet ikke har blitt endret under overføringen. Hashing-algoritmer brukes til å utføre denne funksjonen. Du kan velge MD5 og SHA.
- Godkjenning- Bestemmer hvordan enheter i begge ender av VPN-tunnelen autentiseres. Tilgjengelige alternativer er PSK eller RSA.
- DH-algoritmegruppe- definerer en metode for å generere en delt hemmelighet mellom noder. Det er flere alternativer, men DH24 gir det høyeste nivået av sikkerhet.
Disse byggeklossene kombineres for å gi konfidensialitet, integritet og autentisering for VPN-er over IPsec.
Merk... Denne delen gir en oversikt over IPsec for å hjelpe deg å forstå hvordan IPsec sikrer VPN-tunneler. Prosessen med å konfigurere IPsec VPN-er er utenfor omfanget av dette kurset.
(Internet Security Association and Key Management Protocol (ISAKMP)) - Administrering av nøkler og autentiseringer av sikre tilkoblinger.
IPsec-arkitektur
IPsec, i motsetning til andre velkjente SSL- og TLS-protokoller, opererer på nettverkslaget (lag 3 av OSI-modellen). Dette gjør IPsec mer fleksibel slik at den kan brukes til å sikre enhver TCP- og UDP-basert protokoll. IPsec kan brukes til å gi sikkerhet mellom to IP-verter, mellom to Security Gateways, eller mellom en IP-vert og en Security Gateway. Protokollen er et "tillegg" til IP-protokollen, og behandler de genererte IP-pakkene på måten beskrevet nedenfor. IPsec kan sikre integriteten og/eller konfidensialiteten til data som overføres over et nettverk.
IPsec bruker følgende protokoller for å utføre ulike funksjoner:
- Authentication Header (AH) gir integriteten til den virtuelle tilkoblingen (overførte data), autentisering av informasjonskilden og en tilleggsfunksjon for å forhindre pakkereoverføring
- Encapsulating Security Payload (ESP) kan gi konfidensialitet (kryptering) av overført informasjon, og begrense flyten av konfidensiell trafikk. I tillegg kan den sikre integriteten til den virtuelle tilkoblingen (overførte data), autentisering av informasjonskilden og tilleggsfunksjonen for å forhindre reoverføring av pakker (Når ESP brukes, er det obligatorisk å bruke et eller annet sett med sikkerhetstjenester)
- Security Association (SA) gir en haug med algoritmer og data som gir parametrene som kreves for at AH og/eller ESP skal fungere. Internet Security Association and Key Management Protocol (ISAKMP) gir et rammeverk for autentisering og nøkkelutveksling, nøkkelautentisering.
Sikkerhetsforbundet
Security Association (SA)-konseptet er grunnleggende for IPsec-arkitekturen. SA er en simpleksforbindelse som er dannet for å føre den tilsvarende trafikken over seg. Ved implementering av sikkerhetstjenester dannes en SA basert på bruk av AH- eller ESP-protokollene (eller begge samtidig). SA er definert i henhold til punkt-til-punkt-konseptet og kan operere i to moduser: transportmodus (PTP) og tunnelmodus (RTU). Transportmodus er implementert med en SA mellom to IP-noder. I tunnelmodus danner SA en IP-tunnel.
Alle SA-er er lagret i SADB (Security Associations Database) til IPsec-modulen. Hver SA har en unik markør som består av tre elementer:
- Sikkerhetsparameterindeks (SPI)
- Destinasjons-IP-adresser
- (ESP eller AH)
IPsec-modulen, gitt disse tre parameterne, kan slå opp SADB-oppføringen for en spesifikk SA. Listen over SA-komponenter inkluderer:
Serienummer 32-biters verdi som brukes til å danne feltet Sekvensnummer i overskriftene AH og ESP. Sekvensnummertelleroverløp Et flagg som signaliserer overløp av serienummertelleren. Spill av angrepsundertrykkelsesvinduet på nytt Brukes til å definere retransmission av pakker. Hvis verdien i feltet Sekvensnummer ikke faller innenfor det spesifiserte området, blir pakken ødelagt. Informasjon AH brukt autentiseringsalgoritme, nødvendige nøkler, nøkkellevetid og andre parametere. ESP informasjon krypterings- og autentiseringsalgoritmer, nødvendige nøkler, initialiseringsparametere (for eksempel IV), nøkkellevetid og andre parametere IPsec-driftsmodus tunnel eller transport MTU Den maksimale pakkestørrelsen som kan overføres over en VC uten fragmentering.Siden sikre virtuelle tilkoblinger (SA-er) er simpleks, kreves det minst to SA-er for å etablere en duplekskobling. I tillegg må hver protokoll (ESP / AH) ha sin egen SA for hver retning, det vil si at AH + ESP-bunten krever fire SA-er. Alle disse dataene ligger i SADB.
- AH: Autentiseringsalgoritme.
- AH: hemmelig nøkkel for autentisering
- ESP: krypteringsalgoritme.
- ESP: hemmelig krypteringsnøkkel.
- ESP: bruk autentisering (ja/nei).
- Alternativer for nøkkelbytte
- Rutebegrensninger
- IP-filtreringspolicy
I tillegg til SADB-databasen støtter IPsec-implementeringer Security Policy Database (SPD). En SPD-oppføring består av et sett med IP-header-feltverdier og Upper Layer Protocol-overskriftsfelt. Disse feltene kalles velgere. Velgere brukes til å filtrere utgående pakker for å kartlegge hver pakke til en spesifikk SA. Når en pakke dannes, sammenlignes verdiene til de tilsvarende feltene i pakken (selektorfeltene) med de som finnes i SPD. De tilsvarende SA-ene er funnet. SA, hvis noen, bestemmes deretter for pakken og dens tilhørende sikkerhetsparameterindeks (SPI). Deretter utføres IPsec-operasjoner (AH- eller ESP-protokolloperasjoner).
Eksempler på velgere som er inneholdt i SPD:
- Destinasjons-IP-adresse
- Avsender IP-adresse
- IPsec-protokoll (AH, ESP eller AH + ESP)
- Sender- og mottakerporter
Autentiseringshode
| Forskyvninger | oktett 16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| oktett 16 | Bit 10 | 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 | Neste overskrift | Nyttelast Len | Reservert | |||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | Sekvensnummer | |||||||||||||||||||||||||||||||
| C | 96 | Integritetssjekkverdi (ICV) … |
|||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
AH-protokollen brukes til autentisering, det vil si for å bekrefte at vi kommuniserer med nøyaktig den vi tror vi er og at dataene vi mottar ikke blir ødelagt under overføring.
Utgående IP-pakkebehandling
Hvis den avsendende IPsec-modulen bestemmer at pakken er assosiert med en SA som antar AH-behandling, starter den behandlingen. Den setter inn AH-headeren i IP-pakken forskjellig avhengig av modus (transport eller tunnelering). I transportmodus plasseres AH-overskriften etter IP-protokolloverskriften og før protokolloverskriftene for det øvre laget (vanligvis TCP eller UDP). I tunnelmodus blir hele den originale IP-pakken innrammet først med en AH-header, deretter med en IP-header. Denne overskriften kalles ekstern, og overskriften til den originale IP-pakken kalles intern. Etter det må den overførende IPsec-modulen generere et sekvensielt nummer og skrive det ned i feltet Sekvensnummer... Når SA er etablert, settes sekvensnummeret til 0, og økes med én før hver IPsec-pakke sendes. I tillegg er det en sjekk for å se om telleren har gått i loop. Hvis den når sin maksimale verdi, tilbakestilles den til 0. Hvis anti-retransmission-tjenesten brukes, når telleren når sin maksimale verdi, tilbakestiller den avsendende IPsec-modulen SA. Dermed er beskyttelse mot gjentatt pakkeoverføring sikret - den mottakende IPsec-modulen vil sjekke feltet Sekvensnummer, og ignorer forsøkspakker på nytt. Deretter beregnes ICV-sjekksummen. Det skal bemerkes at her beregnes sjekksummen ved hjelp av en hemmelig nøkkel, uten hvilken en angriper kan beregne hashen på nytt, men uten å kjenne til nøkkelen, vil han ikke være i stand til å danne riktig sjekksum. De spesifikke algoritmene som brukes til å beregne ICV kan finnes i RFC 4305. Foreløpig kan for eksempel algoritmene HMAC-SHA1-96 eller AES-XCBC-MAC-96 brukes. AN-protokollen beregner kontrollsummen (ICV) for følgende felt i IPsec-pakken:
- IP-overskriftsfelt som ikke har blitt endret under sendingen, eller identifisert som de viktigste
- AH-header (felt: "Next Header", "Nyttelast Len," Reservert "," SPI "," Sekvensnummer "," Integrity Check Value ". Feltet" Integrity Check Value " er satt til 0 ved beregning av ICV
- øvre lags protokolldata
Behandling av innkommende IP-pakker
Etter å ha mottatt en pakke som inneholder en AH-melding, ser IPsec-mottaksmodulen etter en tilsvarende Security Association Database (SA) sikker virtuell tilkobling (SA) ved å bruke destinasjons-IP-adressen, Security Protocol (AH) og SPI. Hvis ingen samsvarende SA blir funnet, blir pakken forkastet. En sikret virtuell tilkobling (SA) funnet indikerer om tjenesten for å forhindre pakkereoverføring brukes, dvs. om behovet for å sjekke feltet Sekvensnummer... Hvis tjenesten brukes, er feltet krysset av. For dette brukes skyvevindusmetoden. IPsec-mottaksmodulen danner et vindu med bredden W. Venstre kant av vinduet tilsvarer minimum sekvensnummer ( Sekvensnummer) N riktig mottatt pakke. Pakke med et felt Sekvensnummer, som inneholder en verdi som starter fra N + 1 og slutter med N + W, aksepteres riktig. Hvis den mottatte pakken er på venstre kant av vinduet, blir den ødelagt. IPsec-mottaksmodulen beregner deretter ICV fra de tilsvarende feltene til den mottatte pakken, ved å bruke en autentiseringsalgoritme som den lærer fra SA-posten, og sammenligner resultatet med ICV-verdien som ligger i "Integrity Check Value"-feltet. Hvis den beregnede ICV-verdien sammenfaller med den mottatte, anses den innkommende pakken som gyldig og blir akseptert for videre IP-behandling. Hvis sjekken er negativ, blir mottakspakken forkastet.
| Forskyvninger | oktett 16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| oktett 16 | Bit 10 | 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 | Sikkerhetsparameterindeks (SPI) | |||||||||||||||||||||||||||||||
| 4 | 32 | Sekvensnummer | |||||||||||||||||||||||||||||||
| 8 | 64 | Nyttelastdata | |||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
| … | … | Polstring (0-255 oktetter) | |||||||||||||||||||||||||||||||
| … | … | Pad Lengde | Neste overskrift | ||||||||||||||||||||||||||||||
| … | … | Integritetssjekkverdi (ICV) … |
|||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
Utdata IPsec-pakkebehandling
Hvis den avsendende IPsec-modulen bestemmer at pakken er assosiert med en SA som forventer ESP-behandling, starter den behandlingen. Avhengig av modus (transport eller tunnelering), behandles den originale IP-pakken annerledes. I transportmodus utfører den sendende IPsec-modulen den øvre lagprotokollinnramming (innkapsling) prosedyren (for eksempel TCP eller UDP) ved å bruke ESP-headeren og ESP-traileren, uten å påvirke headeren til den originale IP-pakken. I tunnelmodus blir IP-pakken innrammet av en ESP-header og en ESP-trailer, og deretter innrammet av en ekstern IP-header. Deretter utføres kryptering - i transportmodus er kun protokollmeldingen over det underliggende laget kryptert (det vil si alt som var etter IP-headeren i den originale pakken), i tunnelmodus krypteres hele den originale IP-pakken. Sendende IPsec-modulen bestemmer krypteringsalgoritmen og den hemmelige nøkkelen fra SA-posten. IPsec-standardene tillater bruk av trippel-DES, AES og Blowfish krypteringsalgoritmer. Siden størrelsen på klarteksten må være et multiplum av et visst antall byte, for eksempel blokkstørrelsen for blokkalgoritmer, utføres også nødvendig tillegg av den krypterte meldingen før kryptering. Den krypterte meldingen plasseres i feltet Nyttelastdata... I felt Pad Lengde passer til lengden på polstringen. Deretter, som i AH, beregner den Sekvensnummer... Deretter beregnes kontrollsummen (ICV). Kontrollsummen, i motsetning til AH-protokollen, hvor noen felt i IP-headeren også tas med i beregningen, i ESP beregnes kun av feltene til ESP-pakken minus ICV-feltet. Før kontrollsummen beregnes, fylles den med nuller. Algoritmen for å beregne ICV, som i AH-protokollen, lærer den overførende IPsec-modulen fra posten om SA-en som pakken som behandles er assosiert med.
Behandler innkommende IPsec-pakker
Ved mottak av en pakke som inneholder en ESP-protokollmelding, ser IPsec-mottaksmodulen etter den tilsvarende sikre virtuelle tilkoblingen (SA) i Security Associations Database (SADB) ved å bruke destinasjons-IP-adressen, sikkerhetsprotokollen (ESP) og SPI-indeksen. Hvis ingen samsvarende SA blir funnet, blir pakken forkastet. En sikret virtuell tilkobling (SA) funnet indikerer om tjenesten for å forhindre pakkereoverføring brukes, dvs. behovet for å sjekke sekvensnummer-feltet. Hvis tjenesten brukes, er feltet krysset av. For dette, så vel som i AH, brukes skyvevindusmetoden. Den mottakende IPsec-modulen danner et vindu med bredden W. Venstre kant av vinduet tilsvarer minimum sekvensnummer N for en korrekt mottatt pakke. En pakke med et sekvensnummerfelt som inneholder en verdi som strekker seg fra N + 1 til N + W, aksepteres korrekt. Hvis den mottatte pakken er på venstre kant av vinduet, blir den ødelagt. Deretter, hvis autentiseringstjenesten brukes, beregner IPsec-mottaksmodulen ICV fra de tilsvarende feltene til den mottatte pakken ved å bruke autentiseringsalgoritmen den lærer fra SA-posten og sammenligner resultatet med ICV-verdien som ligger i "Integrity Check Value" felt. Hvis den beregnede ICV-verdien faller sammen med den mottatte, anses den innkommende pakken som gyldig. Hvis sjekken er negativ, blir mottakspakken forkastet. Deretter dekrypteres pakken. IPsec-mottakeren lærer fra SA-posten hvilken krypteringsalgoritme og hemmelig nøkkel som brukes. Det skal bemerkes at prosedyren for sjekksum og dekryptering ikke bare kan utføres sekvensielt, men også parallelt. I sistnevnte tilfelle må kontrollsumprosedyren avsluttes før dekrypteringsprosedyren, og dersom ICV-kontrollen mislykkes, må dekrypteringsprosedyren også stoppe. Dette gir mulighet for raskere oppdagelse av dårlige pakker, som igjen forbedrer beskyttelsen mot DOS-angrep (Denial of Service). Videre, den dekrypterte meldingen i samsvar med feltet Neste overskrift videresendes for videre behandling.
Bruk
IPsec brukes primært til VPN-tunneler. I dette tilfellet fungerer ESP- og AH-protokollene i tunnelmodus. I tillegg, ved å konfigurere sikkerhetspolicyer på en bestemt måte, kan protokollen brukes til å lage en brannmur. Poenget med en brannmur er at den kontrollerer og filtrerer pakker som passerer gjennom den i samsvar med spesifiserte regler. Et sett med regler er satt opp, og skjermen ser på alle pakker som passerer gjennom den. Hvis de overførte pakkene er underlagt disse reglene, behandler brannmuren dem deretter. For eksempel kan den avvise visse pakker, og dermed avslutte usikre tilkoblinger. Ved å justere sikkerhetspolicyen deretter, kan du for eksempel nekte Internett-trafikk. For å gjøre dette er det nok å forby sending av pakker der meldinger fra HTTP- og HTTPS-protokollene er innebygd. IPsec kan også brukes til å beskytte servere ved å droppe alle pakker bortsett fra de som er nødvendige for å utføre serverfunksjoner på riktig måte. Du kan for eksempel blokkere all trafikk for webserveren bortsett fra tilkoblinger over TCP-port 80, eller over TCP-port 443 i tilfeller der HTTPS brukes.
se også
Lenker
- IPSec-konfigurasjonsbeskrivelse (cisco.com)
| Virtuelle private nettverk (VPN) | |
|---|---|
| Programvare | |
