Innholdsfortegnelse:
I april ble en nederlandsk hacker arrestert for det som kalles det største distribuerte angrepet nektetjeneste. Angrepet ble utført på Spamhaus, en antispamorganisasjon, og ifølge ENISA, EUs IT-sikkerhetsbyrå, nådde belastningen på Spamhauss infrastruktur 300 gigabit per sekund, tre ganger den forrige rekorden. Det forårsaket også stor Internett-overbelastning, og satt fast internettinfrastruktur over hele verden.
Selvfølgelig er DNS-angrep neppe sjeldne. Men mens hackeren i Spamhaus-saken bare mente å skade målet hans, pekte de større konsekvensene av angrepet også på det mange kaller en stor feil i Internett-infrastruktur: Domain Name System. Som et resultat har nyere angrep på DNS-infrastruktur gjort det mulig for teknikere og forretningsmenn å lete etter løsninger. Så hva med deg? Det er viktig å vite hvilke alternativer du har for å styrke din egen virksomhets DNS-infrastruktur, samt hvordan DNS-rotserverne fungerer. Så la oss se på noen av problemene, og hva virksomheter kan gjøre for å beskytte seg selv. (Lær mer om DNS i DNS: Én protokoll for å styre dem alle.)
Eksisterende infrastruktur
Domain Name System (DNS) er fra et tidspunkt Internett har glemt. Men det gjør det ikke til gamle nyheter. Med den stadig skiftende trusselen om nettangrep, har DNS blitt undersøkt mye gjennom årene. I sin spede begynnelse tilbød DNS ingen former for godkjenning for å bekrefte identiteten til en avsender eller mottaker av DNS-spørsmål.
Faktisk har kjernenavnservere, eller rotservere, i mange år vært utsatt for omfattende og varierte angrep. I disse dager er de geografisk mangfoldige og drives av forskjellige typer institusjoner, inkludert regjeringsorganer, kommersielle enheter og universiteter, for å opprettholde sin integritet.
Alarmerende nok har noen angrep vært noe vellykket i det siste. Et forkrøplende angrep på rotserverinfrastrukturen skjedde for eksempel i 2002 (les en rapport om det her). Selv om det ikke skapte en merkbar innvirkning for de fleste internettbrukere, trakk den oppmerksomheten til FBI og det amerikanske departementet for hjemlandssikkerhet fordi det var svært profesjonelt og svært målrettet, og påvirket ni av de 13 operative rotserverne. Hadde det vedtatt i mer enn en time, sier eksperter, kunne resultatene ha vært katastrofale, noe som gjorde elementer av internettets DNS-infrastruktur alt annet enn ubrukelige.
Å beseire en så integrert del av internettets infrastruktur ville gitt en vellykket angriper mye kraft. Som et resultat har betydelig tid og investeringer blitt brukt siden problemet med å sikre rotserverinfrastrukturen. (Du kan sjekke ut et kart som viser rotservere og deres tjenester her.)
Sikring av DNS
Bortsett fra kjerneinfrastrukturen, er det like viktig å vurdere hvor robust din egen virksomhets DNS-infrastruktur kan være mot både angrep og fiasko. Det er for eksempel vanlig (og uttalt i noen RFC-er) at navneservere skal ligge på helt forskjellige undernett eller nettverk. Med andre ord, hvis ISP A har full strømbrudd og din primære navneserver faller frakoblet, vil ISP B fremdeles tjene de viktigste DNS-dataene dine til alle som ber om det.
Domain Name System Security Extensions (DNSSEC) er en av de mest populære måtene som virksomheter kan sikre sin egen navneserverinfrastruktur. Dette er et tillegg for å sikre at maskinen som kobler til navneservere er hva den sier at den er. DNSSEC tillater også autentisering for å identifisere hvor forespørslene kommer fra, samt bekrefte at dataene i seg selv ikke er endret underveis. På grunn av den offentlige karakteren til domenenavnsystemet, garanterer imidlertid ikke krypteringen konfidensialitet for dataene, og har heller ikke noe begrep om tilgjengeligheten hvis deler av infrastrukturen skulle mislykkes i noen beskrivelse.
En rekke konfigurasjonsposter brukes til å tilveiebringe disse mekanismene inkludert RRSIG, DNSKEY, DS og NSEC posttyper. (For mer info, sjekk ut 12 DNS-poster som er forklart.)
RRISG brukes når DNSSEC er tilgjengelig for både maskinen som sender inn spørringen og den som sender den. Denne posten blir sendt sammen med den ønskede posttypen.
En DNSKEY som inneholder signert informasjon kan se slik ut:
ripe.net har en DNSKEY posten 257 3 5 AwEAAXf2xwi4s5Q1WHpQVy / kZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk + Y7vZCvSN1AcYy0 / ZjL7cNlkc3Ordl2DialFHPI6 UbSQkIp3l / 5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i958WZJ6LI0pOTNK + BIx8u98b + EVr7C08dPpr9V6Eu / 7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtmJxDT067oJoNBIK + gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XSCm5sNxrRk =
DS, eller delegert signator, blir brukt til å verifisere tillitskjeden slik at en forelder og en barnesone kan kommunisere med en ekstra grad av komfort.
NSEC, eller neste sikre oppføringer, hopper i hovedsak til neste gyldige oppføring i en liste over DNS-oppføringer. Det er en metode som kan brukes til å returnere en ikke-eksisterende DNS-oppføring. Dette er viktig, slik at bare konfigurerte DNS-oppføringer blir klarert som ekte.
NSEC3, en forbedret sikkerhetsmekanisme som hjelper til å dempe angrep i ordbokstil, ble ratifisert i mars 2008 i RFC 5155.
DNSSEC mottak
Selv om mange talsmenn har investert i å distribuere DNSSEC, er det ikke uten kritikerne. Til tross for at den er i stand til å unngå angrep som angrep mellom mennesker, der spørsmål kan kapres og feil mates uten vilje til de som genererer DNS-spørsmål, er det påståtte problemer med kompatibilitet med visse deler av den eksisterende Internett-infrastrukturen. Hovedproblemet er at DNS vanligvis bruker den mindre båndbreddsultne User Datagram Protocol (UDP) mens DNSSEC bruker den tyngre transmisjonsstyringsprotokollen (TCP) for å sende dataene frem og tilbake for større pålitelighet og ansvarlighet. Store deler av den gamle DNS-infrastrukturen, som fylles med millioner av DNS-forespørsler 24 timer i døgnet, syv dager i uken, er kanskje ikke i stand til å øke trafikken. Likevel tror mange at DNSSEC er et stort skritt mot å sikre internettinfrastruktur.
Selv om ingenting i livet er garantert, kan det å ta litt tid å vurdere egen risiko forhindre mange kostbare hodepine i fremtiden. Ved å distribuere DNSSEC, for eksempel, kan du øke tilliten til deler av den viktige DNS-infrastrukturen.
