Bruk denne dialogboksen til å legge til, redigere, endre prioritet for eller fjerne algoritmekombinasjonene som er tilgjengelige for nøkkelutveksling under forhandlinger i hovedmodus. Du kan angi flere algoritmekombinasjoner, og du kan tilordne hvilken rekkefølge kombinasjonene skal forsøkes med. Den første kombinasjonen i listen som er kompatibel med begge motpartsdatamaskinene, vil bli brukt.
Obs! | |
Den beste fremgangsmåten er å føre opp algoritmekombinasjonene med den høyeste sikkerheten øverst og den laveste sikkerheten nederst. På den måten vil den sikreste algoritmen de to forhandlingsdatamaskinene har felles, bli brukt. Algoritmene som er mindre sikre, kan brukes til bakoverkompatibilitet. |
Slik åpner du denne dialogboksen |
På siden i MMC-snapin-modulen Windows-brannmur med avansert sikkerhet klikker du Egenskaper for Windows-brannmur under Oversikt.
Klikk kategorien IPsec-innstillinger.
Klikk Tilpass under IPsec-standarder.
Velg Avansert under Nøkkelutveksling (hovedmodus), og klikk deretter Tilpass.
Sikkerhetsmetoder
Sikkerhetsmetoder er kombinasjoner av integritetsalgoritmer og krypteringsalgoritmer som beskytter nøkkelutvekslingen. Du kan ha så mange kombinasjoner du behøver, og du kan ordne dem i foretrukket rekkefølge i listen. Kombinasjonene prøves i den rekkefølgen de har i den viste listen. Det første settet som begge motpartsdatamaskinene enes om, brukes. Hvis motpartsdatamaskinen ikke kan bruke noen av de definerte kombinasjonene, mislykkes tilkoblingsforsøket.
Noen algoritmer støttes bare av datamaskiner som kjører denne versjonen av Windows. Hvis du vil ha mer informasjon, kan du se
Du kan legge til en kombinasjon i listen ved å klikke Legg til. Dette åpner dialogboksen Legg til / Rediger sikkerhetsmetode.
Du kan endre rekkefølge på listen ved å merke en kombinasjon og klikke pil opp eller ned.
Obs! | |
Den beste fremgangsmåten er å plassere kombinasjonene med den høyeste sikkerheten øverste og den laveste sikkerheten nederst. Dette sikrer at den sikreste metoden som støttes av begge motpartsdatamaskinene, blir brukt. |
Levetid for nøkler
Levetidsinnstillinger bestemmer når en ny nøkkel genereres. Med levetider for nøkkel kan du fremtvinge generering av en ny nøkkel etter et bestemt intervall, eller når et bestemt antall økter er beskyttet med den gjeldende nøkkelen. Hvis du bruker flere nøkler, sikrer du at hvis en angriper får tilgang til én nøkkel, vises bare et lite utdrag av informasjonen før en ny nøkkel genereres og nettverkstrafikken igjen er beskyttet. Du kan angi levetiden i minutter og i antall økter. Den første terskelen som nås, blir brukt, og nøkkelen genereres på nytt.
Obs! | |
Denne nøkkelregenereringen er bare for nøkkelutveksling i hovedmodus. Disse innstillingene har ikke innvirkning på innstillingene for nøkkellevetid for databeskyttelse i hurtigmodus. |
Minutter
Bruk denne innstillingen til å konfigurere hvor lenge nøkkelen for sikkerhetstilordninger for hovedmodus varer, i minutter. Etter dette intervallet blir en ny nøkkel generert. Etterfølgende økter i hovedmodus bruker den nye nøkkelen.
Maksimumslevetiden er 2 879 minutter (48 timer). Minimumslevetiden er 1 minutt. Vi anbefaler at du bare genererer nye nøkler så ofte som risikoanalysen krever. Hvis nye nøkler genereres for ofte, kan det påvirke ytelsen.
Økter
En økt er en særskilt melding eller et sett med meldinger som er beskyttet av en SA for hurtigmodus. Denne innstillingen angir hvor mange økter for nøkkelgenerering i hurtigmodus som kan beskyttes ved hjelp av samme nøkkelinformasjon for hovedmodus. Når denne terskelen er nådd, tilbakestilles telleren, og en ny nøkkel genereres. Påfølgende kommunikasjon vil bruke den nye nøkkelen. Maksimumsverdien er 2 147 483 647 økter. Minimumsverdien er 0 økter.
En øktgrense på null (0) fører til at genereringen av en ny nøkkel bare fastsettes av innstillingen Levetid for nøkkel (minutter).
Vær forsiktig når du angir svært forskjellige nøkkellevetider for nøkler i hoved- og hurtigmodus. Hvis du for eksempel setter nøkkellevetiden for hovedmodus til åtte timer og nøkkellevetiden for hurtigmodus til to timer, kan det føre til at du har en SA for hurtigmodus i nesten to timer etter at SAen for hovedmodus er utløpt. Dette skjer når sikkerhetstilordningen for hurtigmodus genereres like før sikkerhetstilordningen for hovedmodus utløper.
Viktig! | |
Jo høyere antall økter som er tillatt per nøkkel for hovedmodus, jo større er sjansen for at nøkkelen for hovedmodus blir oppdaget. Hvis du vil begrense antall ganger slik gjenbruk kan forekomme, kan du angi en nøkkelgrense for hurtigmodus. |
Sikkerhet Obs! | |
Du kan konfigurere PFS (Perfect Forward Secrecy) for hovedmodus ved å sette Levetid for nøkkel i økter til 1. Selv om denne konfigurasjonen gir betydelig tilleggsbeskyttelse, går den også i stor grad ut over datamaskin- og nettverksytelsen. Hver nye økt for hurtigmodus genererer nøkkelmaterialet for hovedmodus på nytt, noe som igjen fører til at de to datamaskinene godkjennes på nytt. Vi anbefaler at du bare aktiverer PFS i miljøer der IPsec-trafikk kan bli utsatt for avanserte angripere som kanskje vil prøve å ødelegge den sterke kryptografiske beskyttelsen som IPsec gir. |
Alternativer for nøkkelutveksling
Bruk Diffie-Hellman for å forbedre sikkerheten
Windows Vista og senere versjoner av Windows støtter AuthIP (godkjent IP) i tillegg til IKE (Internett-nøkkelutveksling) for oppretting av den første sikre tilkoblingen der resten av IPsec-parameterne forhandles. IKE bruker bare Diffie-Hellman-utvekslinger. Når AuthIP brukes, kreves det ingen Diffie-Hellman-nøkkelutvekslingsprotokoll. Når godkjenning med Kerberos versjon 5 forespørres, brukes hemmeligheten for tjenestebilletten for Kerberos versjon 5 i stedet for en Diffie-Hellman-verdi. Når sertifikatgodkjenning eller NTLM-godkjenning forespørres, opprettes det en TLS-økt (transportnivåsikkerhet), og hemmeligheten for denne brukes i stedet for Diffie-Hellman-verdien.
Hvis du merker av for dette alternativet, utføres en Diffie-Hellman-utveksling uansett hvilken godkjenningstype som er valgt, og Diffie-Hellman-hemmeligheten brukes til å sikre resten av IPsec-forhandlingene. Bruk dette alternativet når lovbestemte krav angir at en Diffie-Hellman-utveksling må brukes.