Sikre domenet og navnetjenerne

Hvis noen får endret domenets navnetjenere eller DNS-poster, kan de sende nettstedet til en annen server, endre hvor e-post mottas eller gjøre hele domenet utilgjengelig. Derfor er kontoene, fullmaktene og gjenopprettingsplanen minst like viktige som DNSSEC og robust infrastruktur.

En liten bedrift bør som minimum vite:

• hvilken virksomhet som er registrert som domeneabonnent
• hvilken domeneforhandler som kan endre delegeringen
• hvilken DNS-leverandør som publiserer sonen
• hvilke navngitte personer som har administratortilgang
• hvordan en feil endring oppdages og rulles tilbake
• hvordan leverandørene kontaktes hvis vanlig innlogging er borte

Norids veileder om domenenavn og risikohåndtering er laget for virksomheter der domenet støtter normal drift eller viktige leveranser. Bruk kontrollene under som et praktisk startpunkt, og skaler dem etter konsekvensen av nedetid eller misbruk.

1. Kartlegg kontrollkjeden

Domene, DNS, nettsted og e-post ligger ofte hos forskjellige leverandører. Dokumenter minst disse rollene:

Den siste raden er lett å glemme. Hvis all gjenoppretting går til it@bedrift.no, kan feil MX-poster eller kapret DNS stenge kanalen dere trenger for å få hjelp. Ha en kontrollert alternativ kontaktmåte som ikke er avhengig av det rammede domenet.

Bruk oppslagsguiden for navnetjenere for å bekrefte den tekniske delen. Ikke stol bare på et gammelt regneark eller på at logoen i ett kontrollpanel forteller hvem som har hele kontrollen.

2. Sikre kontoene som kan endre domenet

En angriper trenger ikke å bryte DNS-protokollen hvis en administrator kan lures til å gi fra seg innloggingen.

Gjør dette hos både domeneforhandler og DNS-leverandør:

1. Bruk navngitte brukere fremfor én delt administrator.
2. Aktiver flerfaktorautentisering der tjenesten støtter det.
3. Lagre unike passord og gjenopprettingskoder kontrollert.
4. Begrens administratorer til personer som faktisk gjør endringer.
5. Fjern tidligere ansatte og leverandører med en gang behovet opphører.
6. Kontroller gjenopprettingsadresse, telefon og alternative kontaktdata.
7. Bruk en separat administratorkonto hvis leverandøren støtter roller.

NSMs grunnprinsipp om brukere og tilgangsbehov anbefaler oversikt over kontoer, brukere, leverandører og særskilte rettigheter. NSM anbefaler også flerfaktor for brukere med driftsoppgaver og tilgang til kritiske systemer.

Ha minst to personer som kan starte en hendelseshåndtering, men ikke gi alle full administrator bare for å ha en reserve. En stedfortreder kan ha kontrollert, dokumentert tilgang som testes med faste mellomrom.

3. Beskytt abonnent- og forhandlerforholdet

Kontroller jevnlig at:

• virksomheten fortsatt er riktig abonnent
• organisasjons- og kontaktopplysninger er oppdatert
• varsel om fornyelse når en overvåket adresse
• faktura og manuell fornyelse ikke avhenger av én ansatt
• fullmakt ved flytting eller abonnentendring er dokumentert
• domenet ikke kan utløpe ubemerket

Aktiver registrar- eller overføringslås hvis domeneforhandleren tilbyr en relevant funksjon, og dokumenter hvordan den låses opp. Funksjoner og navn varierer mellom leverandører. En lås erstatter ikke riktig abonnent, sikker konto eller kontroll på flyttekode.

For .no har abonnenten bruksrett til domenet og ansvar for at opplysningene er riktige. Les hvem som kontrollerer bedriftens domene før ansvar fordeles.

4. Velg robust autoritativ DNS

For et .no-domene krever Norid minst to navnetjenere som er riktig satt opp og fungerer. Antall servernavn alene sier likevel lite om reell robusthet dersom alle avhenger av samme maskin, nett eller feilkonfigurasjon.

Vurder DNS-leverandøren ut fra:

• geografisk og nettverksmessig distribuert tjeneste
• dokumentert tilgjengelighet og hendelseshåndtering
• støtte for DNSSEC
• navngitte brukere, tofaktor og passende roller
• endringshistorikk eller revisjonslogg
• eksport eller annen måte å dokumentere aktiv sone på
• støttekanal og verifisert prosess ved kontotap

Anycast og flere noder kan bedre tilgjengeligheten ved feil og trafikkangrep, men beskytter ikke mot at en autorisert konto publiserer feil verdi. Sekundær DNS kan gi uavhengig publisering, men krever riktig soneoverføring og overvåking. Arkitektur og tilgangskontroll løser forskjellige risikoer.

5. Bruk DNSSEC med en plan

DNSSEC gjør det mulig for validerende resolvere å oppdage manipulerte eller ugyldige DNS-svar. Det beskytter ikke administratorkontoen, skjuler ikke informasjon og krypterer ikke oppslaget.

Før aktivering må dere vite:

• hvem som genererer og roterer sonenøklene
• hvem som publiserer DS-posten i overordnet sone
• hvordan validering testes eksternt
• hvordan nøkkelrullering koordineres
• hvordan feil DS eller signatur kan fjernes eller rettes

En gammel DS-post kombinert med nye, usignerte navnetjenere kan gi SERVFAIL hos validerende resolvere. Derfor skal DNSSEC inngå i planen for hvert navnetjenerbytte. Bruk DNSSEC-guiden med flytterekkefølge og tester før produksjonsendring.

6. Kontroller hver DNS-endring

En skrivefeil i MX eller en slettet TXT-post kan være like skadelig som et angrep. Bruk en enkel endringsrutine også i små virksomheter:

1. Beskriv ønsket resultat og hvilke tjenester som berøres.
2. Noter eller eksporter gjeldende verdier, TTL og DNSSEC-status.
3. Angi hvem som bestilte og hvem som godkjente endringen.
4. Reduser TTL i god tid hvis en planlagt flytting krever rask tilbakeføring.
5. Endre bare nødvendige poster.
6. Kontroller svar direkte fra alle autoritative navnetjenere.
7. Test nettsted, e-post og andre berørte tjenester utenfor eget nett.
8. Dokumenter ny normaltilstand og tidspunkt for tilbakeføring av TTL.

For kritiske endringer bør en annen person kontrollere domenenavn, posttype, navn og verdi før publisering. En skjermdump er nyttig dokumentasjon, men en strukturert soneeksport eller tekstlig liste er enklere å sammenligne og gjenopprette fra.

Ikke publiser en gammel soneeksport ukritisk. Den kan inneholde utgåtte leverandørverifiseringer, gamle IP-adresser eller e-postposter som ikke lenger skal autoriseres.

7. Overvåk det som avslører skade

Overvåk både DNS-data og tjenesten bak dem:

Et varsel må ha en mottaker, alvorlighetsgrad og handling. Ti daglige e-poster som ingen leser er ikke overvåking. Send kritiske domenevarsler til minst én kanal som fortsatt virker hvis domenets egen e-post er nede.

Sammenlign mot en definert normaltilstand, ikke bare mot gårsdagens verdi. En angriper eller feilendring som har stått lenge, skal ikke bli godkjent fordi den ikke lenger er ny.

8. Forbered gjenoppretting før hendelsen

Skriv en kort plan som kan brukes uten tilgang til domenets e-post:

Internt ansvarlig og stedfortreder:
Domeneforhandler og verifisert nødkanal:
DNS-leverandør og verifisert nødkanal:
Forventede navnetjenere og kritiske poster:
Plassering av kontrollert soneoversikt:
Fremgangsmåte ved kompromittert administrator:
Beslutningstaker for tilbakeføring:
Ekstern kommunikasjonskanal:

Ved mistanke om kapring eller uautorisert DNS-endring:

1. Bruk en kjent, ren enhet og en verifisert leverandøradresse.
2. Sperr eller tilbakestill kompromitterte kontoer og aktive sesjoner.
3. Ta vare på logger, varsler, tidspunkt og nåværende DNS-svar.
4. Kontakt domeneforhandler og DNS-leverandør gjennom avtalte kanaler.
5. Gjenopprett delegering og sone fra kontrollert normaltilstand.
6. Kontroller DS, DNSKEY, MX og webpekere før tjenestene friskmeldes.
7. Roter relevante passord, API-nøkler og gjenopprettingskoder.
8. Vurder hvem som må varsles om falsk nettside eller omdirigert e-post.

Den komplette beredskapsplanen for domene, DNS og e-post dekker roller, bevis, kommunikasjon og tjenestegjenoppretting i mer detalj.

En minimumsplan for en liten bedrift

Hvis dere ikke har en egen IT-avdeling, start med disse åtte kontrollene:

• riktig virksomhet og kontaktdata hos domeneforhandleren
• to navngitte ansvarlige med separat tilgang
• flerfaktor på registrar- og DNS-konto der det støttes
• register over aktive administratorer og leverandører
• dokumentert normaltilstand for NS, DS, A/AAAA, MX og e-post-TXT
• godkjenning og ekstern test ved endringer
• varsel på kritiske DNS- og fornyelsesendringer
• en gjenopprettingskanal som ikke avhenger av eget domene

Test planen minst ved leverandørbytte, endring av ansvarlig og når en administrator slutter. Sikkerhet er ikke at ingen endringer skjer; det er at riktige endringer kan gjennomføres, feil oppdages raskt og kontrollen kan tas tilbake.