Innledning
DNS er ryggraden i nettverkskommunikasjon. Uten DNS ville du bli tvunget til å huske IP-adressene til alle klienter og servere i nettverket. Det kan ha vært noe du kunne ha gjort i 1985, men det er egentlig ikke realistisk som vi går inn i det andre tiåret av det 21. århundre. Og DNS kommer til å bli enda viktigere som vi sakte overgang fra IPv4 til IPv6. Mens noen dyktige administratorer realistisk kunne huske de prikkete quad adresser for flere titalls eller kanskje hundrevis av servere, som bare ikke kommer til å skje med IPv6; der IP-adressene er 128bit heksadesimale tall. IPv6 kommer til å bringe DNS tilbake til i forkant av din bevissthet.
Fordi DNS kommer til å bli stadig viktigere, du kommer til å trenge å være sikker på at DNS-serveren løsningen er sikker. Historisk sett var det en stor mengde implisitt tillit til DNS-distribusjoner. Det var en ubetinget tillit at DNS-klienten kunne stole på DNS-serveren, og det var ubetinget tillit at postene returnert fra DNS-serveren til DNS klient var gyldig. Mens denne "gentlemans agreement" har fungert rimelig bra for de siste tiårene, er tiden kommet da vi må være i stand til garantere
at informasjon fra DNS-serveren er gyldig og at klient /server DNS kommunikasjon er sikre.
Dette har meg å tenke på Windows Server 2008 R2 DNS server. Det er flere nye funksjoner i Windows Server 2008 R2 DNS-server som du kan bruke til å forbedre den generelle sikkerheten til DNS-infrastruktur. Disse inkluderer:
- DNS Security Extensions (DNSSEC)
- Kontroll over DNS-overføring oppførsel
- DNS cache låsing
- DNS Socket Pool
I denne artikkelen , jeg kommer til å gi deg en kort oversikt over hver av disse funksjonene, og hvordan du kan bruke dem til å lage et sikrere DNS for nettverket.
DNS Security Extensions (DNSSEC)
DNSSEC er en gruppe av spesifikasjoner fra Internet Engineering Task Force (IETF) som sørger for opprinnelse autentisering av DNS-data, autentisert fornektelse av eksistensen og dataintegritet ( ikke anbefale data konfidensialitet). Formålet med DNSSEC er å beskytte mot falsk DNS-informasjon (for eksempel DNS cache forgiftning), ved hjelp av digital signatures.DNSSEC er faktisk en samling av nye funksjoner lagt til DNS klient /server interaksjon som bidra til å øke sikkerheten for den grunnleggende DNS protokoller. Kjerne DNSSEC funksjonene er spesifisert i:
- RFC 4033
- RFC 4034
- RFC 4035
DNSSEC introduserer flere nye begreper og teknologier på både klient og server side. For eksempel legger DNSSEC fire nye DNS ressurs poster:
- DNSKEY
- RRSIG
- EFF
- DS
Windows Server 2008 R2 Gjennomføring
Windows Server 2008 R2 og Windows 7 er den første Microsoft-operativsystemer for å støtte DNSSEC. Du kan nå signere og vert DNSSEC signert soner for å øke nivået av sikkerhet for DNS-infrastruktur. Følgende DNSSEC relaterte funksjoner blir introdusert i Windows Server 2008 R2:
- Evnen til å signere en sone (det vil si å gi sonen en digital signatur)
- Evnen til å være vert for inngåtte soner
- Ny støtte for DNSSEC protokollen
- Ny støtte for DNSKEY, RRSIG, EFFs, og DS ressurs poster.
DNSSEC kan legge opprinnelse myndighet (bekreftelse og validering av den opprinnelige av DNS-informasjon presentert for DNS-klient), dataintegritet (gi sikkerhet for at data ikke er endret), og autentisert fornektelse av eksistensen til DNS (en signert respons bekrefter at posten ikke finnes).
Windows 7 /Server 2008 R2 DNS Client Forbedringer
I tillegg til DNS server oppdateringer i Windows Server 2008 R2 de, er det noen forbedringer i Windows 7 DNS-klient (som også inkluderer DNS-klienttjenesten i Windows Server 2008 R2):
- Evnen til å kommunisere bevissthet om DNSSEC i DNS-spørringer (som er nødvendig hvis du bestemmer deg for å brukes signert soner)
- Evnen til å behandle DNSKEY, RRSIG, EFFs, og DS ressurs poster.
- Evnen til å avgjøre om DNS server med som den hadde sendt en DNS-spørring har utført validering for klienten.
DNSSEC og NRPT
Hvis er du kjent med Directaccess, er du kanskje interessert i det faktum at DNSSEC utnytter Name Resolution Regler Table (NRPT). DNS-klienten DNSSEC relatert atferd er satt av NRPT. Den NRPT kan du opprette en type politikk basert ruting for DNS-spørringer. For eksempel kan du konfigurere NRPT å sende spørringer for contoso.com
til DNS server 1, mens spørringer for alle andre domener sendes til DNS-serveradressen konfigurert på DNS klientens nettverkskort. Du konfigurere NRPT i Group Policy. Den NRPT brukes også til å aktivere DNSSEC for definerte navnerom, som vist i figur 1 nedenfor.
Figur 1
Forstå hvordan DNSSEC fungerer
Et viktig trekk ved DNSSEC er at det gir deg mulighet til å signere en DNS-sonen - noe som betyr at alle postene for at sonen er også signed.The DNS-klienten kan dra nytte av den digitale signaturen lagt til ressurs poster til bekrefte at de er gyldige. Dette er typisk for hva du ser i andre områder der du har tatt i bruk tjenester som avhenger av PKI. DNS-klienten kan validere at responsen ikke er endret ved hjelp av offentlig /privat nøkkelpar. For å gjøre dette, har DNS-klienten kan konfigureres til å stole på den som signerer signert sonen.
Den nye Windows Server 2008 R2 DNSSEC støtte gjør at du kan signere fil-basert og Active Directory integrerte soner gjennom en offline sone signering verktøyet. Jeg vet det ville vært lettere å ha et GUI-grensesnitt for dette, men jeg antar at Microsoft gikk tom for tid eller skjønte at ikke nok folk faktisk ville bruke denne funksjonen til å gjøre det verdt å gjøre innsats for å skape et praktisk grafisk grensesnitt for signering en sone. Signeringsprosessen er også gjort off-line. Etter at sonen er signert, kan det bli holdt av andre DNS-servere som bruker typisk soneoverføring metoder.
Når konfigurert med en tillitsanker
, er en DNS-server i stand til å validere DNSSEC svar mottatt på vegne av kunden. Men, for å bevise at en DNS svaret er riktig, trenger du å vite minst én nøkkel eller DS rekord som er riktig ut fra andre enn DNS kilder. Disse utgangspunktene kalles tillit anker.
En annen endring i Windows 7 og Windows Server 2008 R2 DNS klient er at det fungerer som en sikkerhetsbevisst spire resolver. Dette betyr at det DNS-klienten vil la DNS-serveren håndtere sikkerhetsvaliderings oppgaver, men det vil forbruke resultatene av sikkerhetsvaliderings arbeidet som utføres av DNS-serveren. DNS-kunder dra nytte av NRPT å avgjøre når de skal se etter valideringsresultater. Etter at kunden bekrefter at responsen er gyldig, vil den returnere resultatene av DNS-spørring til programmet som utløste den første DNS-spørring.
Bruke IPsec med DNSSEC
Generelt , er det en god ide å bruke IPsec å sikre kommunikasjon mellom alle maskinene som deltar på administrert nettverk. Grunnen til dette er at det er veldig enkelt for en inntrenger å sette nettverksanalyse programvare på nettet og fange opp og lese noen ikke-kryptert innhold som beveger seg over ledningen. Men hvis du bruker DNSSEC, må du være oppmerksom på følgende når laging dine IPsec politikk:
- DNSSEC bruker SSL for å sikre forbindelsen mellom DNS klient og server. Det er to fordeler med å bruke SSL: først, det krypterer DNS-spørring trafikken mellom DNS-klienten og DNS-server, og andre, gjør det DNS klienten til å godkjenne identiteten til DNS-serveren, som bidrar til å sikre at DNS-serveren er en klarert maskin og ikke en kjeltring.
- Du må unnta både TCP port 53 og UDP port 53 fra domenet IPsec-policy. Grunnen til dette er at domenet IPsec politikken vil bli brukt og DNSSEC sertifikatbasert autentisering vil ikke bli utført. Sluttresultatet er at klienten vil mislykkes i EKU validering og ende opp med å ikke stole på DNS-serveren.
kontroll over DNS Devolution
DNS-overføring har vært tilgjengelig for en lang tid i Windows DNS-klienter. Nei, det betyr ikke at operativsystemene er mindre utviklet. Devolution tillater klientmaskinene som er medlemmer av et underdomene for å få tilgang til ressurser i den overordnede domenet uten å måtte oppgi nøyaktig FQDN for ressursen.
For eksempel, hvis klienten bruker den primære DNS-suffikset corp.contoso.com Hotell og fristilling er aktivert med en fristilling nivå to, et program forsøker å spørre vertsnavn server1
vil forsøke å løse:
- server1.corp.com
Legg merke til at når devolution nivået er satt til to, fristilling prosessen stopper når det er to etiketter for domenenavnet (i dette tilfellet, corp.com).
Nå, hvis devolution nivået ble satt til tre, vil den devolution prosessen stoppe med server1.corp.contoso.com, . siden server1.contoso.com har bare to etiketter i domenenavnet (contoso.com)
Men fristilling ikke er aktivert i Active Directory-domener når:
- Det er en global suffiks søk Listen tildelt av Group Policy.
- DNS klient har ikke de Append ordnede suffikser av den primære DNS-suffikset boksen valgt i kategorien DNS i Avanserte TCP /IP-innstillinger for IPv4 eller IPv6 Internet Protocol (TCP /IP) Egenskaper av en klient datamaskinens nettverkstilkobling , som vist i Figur 2. Parent suffikser oppnås ved overføring.
Figur 2
Tidligere versjoner av Windows hadde en effektiv overføring nivå to. Hva er nytt i Windows Server 2008 R2 er at du nå kan definere din egen devolution nivå, noe som gir deg mer kontroll over de organisatoriske grenser i et Active Directory-domene når klienter prøver å løse navn i domenet. Du kan stille inn devolution nivået ved hjelp av gruppepolicy, som vist i Figur 3 nedenfor ( Computer Configuration \\ Policies \\ Administrative maler \\ Network \\ DNS Client
).
Figur 3
DNS Cache Locking
Cache låsing i Windows Server 2008 R2 gjør det mulig å kontrollere evnen til å overskrive informasjon som finnes i DNS cache. Når DNS cache låse er slått på, vil DNS-serveren ikke tillate bufrede poster som skal overskrives i løpet av tiden til å leve (TTL) verdi. Dette bidrar til å beskytte din DNS server fra cache forgiftning. Du kan også tilpasse innstillingene som brukes for cache låsing.
Når en DNS-server konfigurert til å utføre rekursjon mottar en DNS-forespørsel, bufrer det resultatene av DNS-spørring før retur informasjonen til maskinen som sendte forespørselen. Som alle caching løsninger, er målet å gjøre det mulig for DNS-serveren for å gi informasjon fra cache med påfølgende forespørsler, slik at det ikke blir nødt til å ta seg tid til å gjenta søket. DNS-serveren holder informasjonen i DNS-serveren hurtigbufferen for en tidsperiode definert av TTL på ressursen posten. Det er imidlertid mulig for informasjon i cache for å bli overskrevet hvis nye opplysninger om at ressurs posten er mottatt av DNS-serveren. Et scenario der dette kan skje er når en angriper forsøker å forgifte DNS cache. Hvis angriperen er vellykket, kan det hende at forgiftet cache returnere falsk informasjon til DNS-klienter og sende kundene til å servere eid av angriperen.
Cache låse er konfigurert som en prosentandel av TTL. For eksempel, dersom buffer låse verdien er satt til 25, og deretter DNS-serveren vil ikke skrive over en bufret inngang til 25% av den tid som er definert ved TTL for ressursen posten har passert. Standardverdien er 100, noe som betyr at hele TTL må passere før den bufrede posten kan oppdateres. Cache låse verdien lagres i CacheLockingPercent
registernøkkelen. Hvis registernøkkelen ikke er tilstede, da DNS-serveren vil bruke standard cache låse verdi på 100. Den foretrukne metoden for å konfigurere cache låse verdien er gjennom dnscmd
kommandolinjeverktøyet.
Et eksempel på hvordan du konfigurerer cache låsing er vist i figur 4 nedenfor. Den prosentvise verdien kan variere fra 0 til 100.
Figur 4
Bading i Windows Server 2008 R2 DNS Socket Pool
< P> OK, så du kan ikke bade i en stikkontakt basseng. Men hva du kan gjøre med Windows Server 2008 R2 DNS socket bassenget er mulig DNS-serveren til å bruke kildeport randomisering ved utstedelse DNS-spørringer. Hvorfor ville du vil gjøre dette? Ettersom kildeport randomisering gir beskyttelse mot visse typer av hurtigbuffer forgiftning angrep, slik som de som er beskrevet over her.
Den første fix inkludert noen standardinnstillinger, men med Windows Server 2008 R2 kan du tilpasse kontakten basseng innstillinger.
Source port randomisering beskytter mot DNS cache forgiftning angrep. Med kildeport randomisering, vil DNS-serveren tilfeldig plukke en kilde port fra en pool av tilgjengelige stikkontakter at det åpner når tjenesten starter. Dette bidrar til å hindre en uautorisert, ekstern angriper fra å sende spesiallagde svar på DNS-forespørsler for å forgifte DNS cache og frem trafikk til steder som er under kontroll av en angriper.
Tidligere versjoner av Windows DNS-serveren som brukes en forutsigbar samling av kildeporter ved utstedelse DNS søket forespørsler. Med den nye DNS socket bassenget, vil DNS-serveren bruker en tilfeldig port nummer valgt ut av stikkontakten bassenget. Dette gjør det mye vanskeligere for en angriper å gjette kilden porten på en DNS-spørring. For ytterligere å hindre at angriperen er en tilfeldig transaksjon ID lagt til blandingen, noe som gjør det enda vanskeligere å utføre cache forgiftning angrep.
Den kontakten bassenget starter med en standard på 2500 stikkontakter. Men hvis du ønsker å gjøre det enda tøffere for angripere, kan du øke den opp til en verdi av 10.000. Jo flere stikkontakter du har tilgjengelig i bassenget, jo vanskeligere det kommer til å være å gjette hvilken socket kommer til å bli brukt, og dermed frustrerende cache poisoning angriperen. På den annen side, kan du konfigurere bassenget verdien til å være null. I så fall, vil du ende opp med en eneste stikkontakt verdi som skal brukes for DNS-spørringer, noe du egentlig ikke ønsker å gjøre. Du kan også konfigurere bestemte porter for å bli ekskludert fra utvalget.
I likhet med DNS cache funksjonen, konfigurerer du den kontakten bassenget med dnscmd
verktøyet. Figuren nedenfor viser et eksempel ved å bruke standardverdiene.
Figur 5
Sammendrag
I denne artikkelen gikk vi over flere nye funksjonene i Windows Server 2008 R2 server og Windows 7 DNS-klient som kan bedre sikkerheten og ytelsen til DNS-infrastruktur. Kombinasjonen av DNSSEC, forbedringer i kontroll over DNS-overføring, sikkerhetsforbedringer i DNS cache og DNS socket pool alle gir overbevisende grunner til å oppgradere dine DNS-servere til Windows Server 2008 R2.
server1.corp.contoso.com Hotell og