Domenenavnkapring, DNS-forgiftning og registrar lockout¶

Å miste kontrollen over organisasjonens primære domenenavn eller autoritative DNS-sone er en av de mest ødeleggende digitale nødsituasjonene en bedrift, sykehus, kommunale etater eller nettpublikasjoner kan lide. Fordi domenenavnet ditt er roten til tillit for alle systemer på internett, vil en angriper som kaprer domeneregistratorkontoen din eller forgifter DNS-postene dine, ikke bare ødelegge nettstedet ditt. Innen minutter etter å ha endret din NS (navneserver), A/AAAA (Web IP), eller MX (Mail Exchange) poster, kan angriperen stille avskjære hver innkommende bedrifts- og kunde-e-post, passere automatisert Let's Encrypt Domain Validation (DV) sjekker for å lage gyldige TLS/SSL-krypteringssertifikater i navnet ditt, registrere ansattes Single Sign-On-passord (SSO) og utløse e-poster for tilbakestilling av passord for skyinfrastrukturen, bankportalene og finanskontoene dine. Selv en ikke-ondsinnet feil, for eksempel et utløpt domene som faller inn AutoRenewGracePeriod eller RedemptionPeriod (clientHold), bringer nettrafikk, API mobile backends og bedriftens e-post til en umiddelbar stans over hele verden.

Hvis en domenekapring eller DNS-avbrudd kompromitterer sykehuspasientruting, nødutsendelseskommunikasjon, offentlig telemetri eller et aktivt livsikkerhetssystem, ring ditt lokale nødnummer (911 i USA og Canada, 112 over hele EU, 999 i Storbritannia) eller se vår katalog over internasjonale nødnummer og varsle det nasjonale responsteamet for cyberhendelser (som CISA i USA på 1-844-SAY-CISA eller NCSC i Storbritannia) umiddelbart. For alle kommersielle, ideelle og personlige domenekriser, utfør triage-trinnene nedenfor i nøyaktig rekkefølge.

Gjør dette nå¶

1. Finn ut i løpet av 30 sekunder om domenet ditt utløp, DNS-postene dine ble endret eller domenet ble overført til en utenlandsk registrar: Kjør en live RDAP eller WHOIS spørring og en autoritativ DNS-spørring fra en terminal (rdap yourdomain.com eller whois yourdomain.com, og dig +trace yourdomain.com). Sjekk registratornavnet, EPP-statuskodene (som f.eks clientHold for fakturering/verifisering vs. ok med ukjente navneservere), og de autoritative navneserverne (NS).
2. Frys alle utgående passordtilbakestillinger og lås identitetsleverandøren din (Okta, Microsoft Entra ID, Google Workspace) umiddelbart: Hvis en angriper kontrollerer domenets MX poster eller NS servere, mottar de hver eneste e-post som sendes til *@yourdomain.com. Instruer IT-administratorene dine umiddelbart om å deaktivere "Glemt passord via e-post" selvbetjent tilbakestilling på tvers av alle bedriftsverktøy, tilbakekalle aktive økter for brukere hvis e-postadresser kan brukes til å tilbakestille eksterne leverandørkontoer, og bytte administrative pålogginger til maskinvare FIDO2-sikkerhetsnøkler eller interne .onmicrosoft.com reservedomener.
3. Bevar fullstendige rettsmedisinske øyeblikksbilder av RDAP/WHOIS, DNS-soner og sertifikatgjennomsiktighet (CT) logger før noe endres: Lagre utdataene til dig ANY yourdomain.com @8.8.8.8, whois yourdomain.com, og sjekk crt.sh/?q=%25.yourdomain.com umiddelbart. Søker crt.sh avslører alle uautoriserte SSL/TLS-sertifikater angriperen nettopp har laget for underdomenene dine (mail., vpn., login., api.) slik at du vet nøyaktig hvilke interne tjenester de aktivt etterligner seg via Adversary-in-the-Middle (AitM) proxyer.
4. Kontakt den tapende registratorens dedikerte nødmisbruks-/sikkerhetsoperasjonsteam (ikke Tier-1 chat-støtte) for å utløse en ICANN-tvist om uautorisert overføring (IRTP) eller reversering av registerlås: Hvis domenet ditt ble overført til en annen konto hos samme registrar eller overført via en stjålet Auth-Info (EPP) koden til en utenlandsk registrar, kontakt den opprinnelige registrarens Domenemisbruk / High-Risk Security Escalation Desk og be om en umiddelbar Registrar Angre / Emergency Transfer Dispute under ICANNs retningslinjer for overføring (Section I.A og Transfer Dispute Resolution Policy), med henvisning til uautorisert kompromiss med legitimasjon.
5. Eskaler direkte til registeroperatøren for toppnivådomene (TLD) hvis registraren ikke svarer: Husk hierarkiet: Registrarer (som GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) er ganske enkelt detaljforhandlere; Registeroperatøren (som Verisign for .com/.net, Public Interest Registry (PIR) for .org, Nominert for .uk, CIRA for .ca, DENIC for .de, eller auDA for .au) kjører hovedrotsonedatabasen. Landskode (ccTLD) registre og flere gTLD-registre kan plassere en nødsituasjon serverHold eller serverUpdateProhibited låses direkte på rotnivå under verifiserte cyberkriminalitetshendelser.
6. ** Advar kunder, leverandører og bankpartnere gjennom kanaler utenfor båndet @yourdomain.com e-post er kompromittert**: Hvis angriperen kapret din MX poster, vil de umiddelbart svare på åpne regnskapstråder med falske bankoverføringsinstruksjoner. Varsle klienter via telefon, SMS, LinkedIn, statusside på et eget sikkerhetskopidomene eller offisielle sosiale medier-kontoer om ikke å stole på noen e-post eller påloggingsportal på det berørte domenet før gjenoppretting er bekreftet.

Beslutningstre: diagnostisere og inneholde et domene- eller DNS-brudd¶

Følg dette raske diagnostiske flytskjemaet for å finne det nøyaktige laget av domenenavnsystemet som har feilet eller blitt kapret:

flowchart TD
    A["Nettsted nede, TLS-sertifikatadvarsel eller bedrifts-e-post stoppet"] --> B["Kjør RDAP/WHOIS og grav +spor fra eksternt nettverk"]
    B --> C{"Hva viser RDAP-status og registrarfelt?"}
    C -->|"Status: clientHold, autoRenewPeriod eller redemptionPeriod"| D["Utilsiktet utløp eller suspendering av ICANN Whois Verification"]
    D --> E["Logg på registrator umiddelbart: Betal fornyelses-/innløsningsgebyr eller klikk på RAA-verifiseringslenke; Be om nødspyling med TTL"]
    C -->|"Registratornavn eller registrantkonto endret uten autorisasjon"| F["Full registrarkontokapring eller uautorisert EPP-overføring"]
    F --> G["Lås identitetsleverandør (Entra/Google), misbruksbillett for filnødregistrator + ICANN-overføringstvist, sjekk crt.sh for falske sertifikater"]
    C -->|"Registrar & NS Uendret, men A/CNAME/MX-poster peker på ukjente IP-er"| H["Kompromiss med administrert DNS-leverandør (Cloudflare / Route53 / NS1 API-nøkkel eller kontobrudd)"]
    H --> I["Oppheve kompromitterte DNS API-tokens, gjenopprett kjent-god sonefil, tilbakekall Rogue TLS-sertifiseringer, roter utsatt legitimasjon"]
    C -->|"Registrar, NS og Zone Records ser normale ut, men nettstedet mislykkes med SERVFAIL"| J["Brudd DNSSEC Chain of Trust (DS Record Mismatch eller Expired RRSIG)"]
    J --> K["Kjør DNSViz.net Check: Remove Stale DS Record hos Registrar eller Re-Sign Zone på DNS Host"]

Fase 1: Teknisk etterforskning for å identifisere den eksakte angrepsvektoren¶

Når et domene plutselig slutter å løse seg eller begynner å vise en phishing-side eller svindel med kryptovaluta, sløser hvert minutt brukt på å gjette dyrebar gjenopprettingstid. Det er fire helt forskjellige scenarier som ser identiske ut som en sluttbruker i en nettleser, og hver krever en helt annen løsning.

Hvordan lese RDAP, WHOIS, og dig Sender ut som en hendelsessvar¶

Åpne en kommandoterminal på Linux, macOS eller Windows (ved hjelp av WSL eller nslookup) og kjør følgende tre diagnostiske kontroller ved å bruke en nøytral offentlig rekursiv resolver (8.8.8.8 eller 1.1.1.1):

1. Sjekk delegasjonen på registernivå (dig +trace og RDAP):

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Se på trinnet rett etter TLD-rotserverne (f.eks. a.gtld-servers.net. for .com). Hvilken NS (Nameserver) vertsnavn returneres av TLD-registeret selv?
   • Hvis TLD-registeret returnerer dine vanlige navneservere (ns1.yourdnsprovider.com) med status NOERROR, skjer kapringen inne i DNS-vertsleverandøren din (eller det er et DNSSEC-brudd).
   • Hvis TLD-registeret returnerer helt ukjente navneservere (eller hvis whois yourdomain.com viser en ny Registrar: navn og en Updated Date: i løpet av de siste timene eller dagene), skjedde kapringen på domeneregistratornivå.
2. Dekode ICANN EPP-domenestatuskodene: Se på Domain Status: linjer i din WHOIS eller RDAP utgang. Disse standardiserte EPP-kodene (Extensible Provisioning Protocol) forteller deg hvorfor et domene svikter eller er låst:

Fase 2: Gjenoppretting fra en ondsinnet domenekapring eller uautorisert registraroverføring¶

Angripere kaprer bedrifts-, Web3/DeFi-, finans- og mediadomener med høy verdi ved å bruke tre primære teknikker: 1. Registrar Account Overtakelse (Credential Stuffing, Infostealer Malware eller SIM Swap): Angriperen logger på GoDaddy, Namecheap, Google Domains/Squarespace eller Network Solutions-dashbordet, slår seg av clientTransferProhibited, endrer NS poster for å peke på en angriperkontrollert Cloudflare-konto, eller genererer en Auth-Info (EPP) kode for å overføre domenet ut. 2. Social Engineering of Registrar Support: Angriperen sender forfalskede inkorporeringsdokumenter, falske myndighets-IDer eller falske brevpapir til en registrars kontogjenopprettingsskranke og hevder at den opprinnelige IT-administratoren døde eller forlot selskapet. 3. ** Overtakelse av underdomene (Dangling CNAME / Dangling NS)**: Hoveddomenet ditt er urørt, men et gammelt underdomene (promo.yourdomain.com eller status.yourdomain.com) har fortsatt en CNAME post som peker på en utrangert AWS S3-bøtte, Azure App Service, GitHub Pages repo, Heroku-app eller Zendesk-forekomst som du slettet for måneder siden. Angriperen registrerer det forlatte skyressursnavnet på AWS/Azure/GitHub og serverer umiddelbart skadelig innhold fra det offisielle underdomenet ditt.

Trinn 1: Kast ut angriperen fra Cloud Identity-leverandøren og e-postsystemet¶

Før du i det hele tatt er ferdig med å fylle ut registrarens gjenopprettingsskjema, anta at angriperen aktivt leser hver e-post som sendes til domenet ditt og prøver å pivotere inn i din interne skyinfrastruktur:

1. Bytt Microsoft 365 / Google Workspace til reservedomener og maskinvare MFA:
   • I Microsoft Entra ID (tidligere Azure AD) har hver leietaker et permanent reservedomene som ikke kan kapres (yourcompany.onmicrosoft.com). Administratorer kan logge på via admin@yourcompany.onmicrosoft.com selv om yourdomain.com DNS er fullstendig kapret.
   • Deaktiver alle metoder for tilbakestilling av passord for SMS, taleanrop og alternativ e-post i Entra ID / Okta / Google Workspace (Authentication Methods Policy). Krev FIDO2/WebAuthn maskinvaresikkerhetsnøkler eller nummermatchende Authenticator-push-varsler.
2. Revisjon utgående og inngående e-postlogger for eksakt kompromissvinduet:
   • Hvis din MX postene ble endret kl. 02:14 UTC, null legitime eksterne e-poster har nådd dine ekte e-postservere siden 02:14 UTC; hver eneste eksterne e-post som ble sendt til de ansatte i løpet av det vinduet ble fanget opp i full klartekst av angriperens useriøse e-postserver (Postfix/Exim-lytter).
   • Trekk umiddelbart en liste over alle tredjeparts SaaS-plattformer, banker, AWS/GCP-rotkontoer, GitHub-organisasjoner og leverandørportaler knyttet til @yourdomain.com e-postadresser, og sjekk om angriperen utløste tilbakestilling av passord på de eksterne plattformene under kapringsvinduet.

Trinn 2: Utfør protokollen for registrar og Registry Emergency Recovery¶

Ikke åpne en generisk "Min nettside fungerer ikke"-støtteprat. Du må bruke den nøyaktige regulatoriske og juridiske terminologien som utløser eskalering til Registrar Tier-3 Security / General Counsel / ICANN Compliance Team:

1. Tilfelle A: Domenet er fortsatt hos den opprinnelige registratoren din (kontoovertakelse eller intern "kontopush"):
   • Mange angripere venter ikke 5 dager på en EPP-overføring mellom registrarer; i stedet bruker de registrarens umiddelbare funksjon "Push Domain to Another Account" for å flytte domenet ditt til en brennerkonto hos den samme registraren på 3 sekunder.
   • Ring og send e-post til registrarens Svindel / Kontokapring / Misbruksavdeling umiddelbart. Oppgi tydelig: "HASTERENDE SIKKERHETSHENDELSE: Uautorisert kontotilgang og intern domene-push / DNS-endring av [dittdomene.com]. Ber om umiddelbar frysing av domenet under serverHold/clientUpdateProhibited og tilbakeføring av uautoriserte DNS/kontoendringer."
   • Sett sammen pakken med bevis på historisk eierskap med en gang: Registratorsikkerhetsteam krever uomtvistelige bevis på at du er den legitime tidligere registranten før de vil trekke et domene tilbake fra en annen konto. Samle disse 5 dokumentene til én enkelt PDF umiddelbart:
     1. Historiske registrarfakturaer og betalingsbevis: PDF-kvitteringer og kredittkort-/bankoverførselsutskrifter som viser at organisasjonen din betaler for registrering og fornyelse av yourdomain.com i løpet av de siste 1 til 10 årene (inkludert de siste 4 sifrene i betalingskortet eller bankreferansen).
     2. Offisielt utstedt bedriftsregistrerings- og offisers-ID: Offisielt selskapsbevis / organisasjonsvedtekter som samsvarer med den historiske WHOIS-en Registrant Organization, pluss en offentlig legitimasjon med bilde av bedriftssjefen som signerer erklæringen.
     3. Bevis for historisk DNS-sonefil og servereierskap: Kopier av din tidligere DNS-sonefil, historiske WHOIS-øyeblikksbilder eller bevis på at organisasjonen din eier det autonome systemet (ASN) eller IP-blokker (A poster) som domenet pekte på i flere år før dagens endring.
     4. E-post for oppretting av original konto / billetthistorikk: Overskrifter på e-poster mottatt fra registraren på det tidspunktet domenet opprinnelig ble registrert eller fornyet.
     5. Offisielt rettshåndhevelsesrapportnummer: En innlevert FBI IC3 (ic3.gov) klagenummer (USA), Action Fraud referansenummer (Storbritannia) eller nasjonal politirapport om nettkriminalitet. Registrarer handler dramatisk raskere når de får utlevert et formelt saksnummer for rettshåndhevelse som bekrefter en kriminell datamaskininntrenging under 18 U.S.C. § 1030 (CFAA) eller UK Computer Misuse Act 1990.
2. Tilfelle B: Domenet ble overført til en annen registrator (interregistratorkapring):
   • Under ICANN Transfer Policy (tidligere IRTP) krever en overføring mellom registrarer en Auth-Info (EPP) kode og må blokkeres i 60 dager etter visse registrantendringer med mindre de fravikes. Hvis en angriper hacket kontoen din hos Registrar A ("den tapende registratoren") og overførte domenet til Registrar B ("Gaining Registrar"):
   • Kontakt BÅDE den tapende registratoren og den vinnende registratoren umiddelbart, men prioriter tvisten om tapende registrars overføring/sikkerhetsteam. Under ICANNs Transfer Dispute Resolution Policy (TDRP), er den tapende registratoren enheten som har dine historiske faktureringsoppføringer og påloggingslogger som beviser at overføringen var uautorisert. Den tapende registratoren kan formelt kontakte registratorens overholdelsesansvarlig for å gjennomføre en samarbeidende Registrar Transfer Undo, eller inngi en formell TDRP-prosedyre.
   • Send samtidig din eierskapsbevispakke og politirapport til Gaining Registrar's Abuse Desk og krever at de legger inn en umiddelbar clientTransferProhibited og clientUpdateProhibited lås på domenet slik at angriperen ikke kan hoppe domenet gjennom en kjede med ytterligere tre offshore-registratorer ("registrar hopping").
3. Send inn en nødeskalering med ICANN (for gTLD-er som .com, .net, .org, .io if gTLD) eller ccTLD-registeret:
   • Hvis en registrar nekter å undersøke en uautorisert overføring eller unnlater å svare under en aktiv kapring, send inn en presserende klage på uautorisert overføring/domenekapring via ICANN Contractual Compliance Portal (icann.org/compliance/complaint).
   • Hvis domenet ditt bruker et Landskode toppnivådomene (ccTLD), som f.eks .uk, .ca, .au, .de, .fr, .nl, .ch, eller .jp, har du et enda raskere alternativ: ccTLD-registre styres av nasjonale tilsynsmyndigheter i stedet for ICANN og opprettholder nesten alltid direkte Registry Emergency Security Teams (for eksempel Nominet i Storbritannia kl. 0330 236 9470, CIRA i Canada, DENIC i Tyskland, AFNIC i Frankrike) som kan fryse et kapret domene direkte på nasjonalt registernivå innen timer etter bekreftelse av bedriftens identitet.

Fase 3: Redde et utløpt domene (clientHold, RedemptionPeriod, og PendingDelete)¶

Ikke alle plutselige globale avbrudd er et nettangrep. Hver eneste dag blir store selskaper, SaaS-startups og offentlige entreprenører helt mørke fordi kredittkortet som er registrert hos domeneregistratoren deres utløp, og e-postene om fornyelsespåminnelse ble sendt til former-founder@company.com som forlot firmaet for tre år siden.

Forstå tidslinjen for ICANN Expired Domain Lifecycle¶

For generiske toppnivådomener (.com, .net, .org, .biz, .info), håndhever ICANN Expired Registration Recovery Policy (ERRP) en streng flertrinns livssyklus etter at utløpsdatoen har passert:

1. Trinn 1: Utsettelsesperiode for automatisk fornyelse (dager 1 til ~30/45 etter utløp):
   • Umiddelbart etter utløp (ofte innen 24 til 72 timer), endrer registraren domenets NS registrerer til en parkert / utløpt fornyelsessplash-side eller plasserer domenet på clientHold.
   • Effekt: Nettstedet ditt og bedriftens e-post slutter å fungere umiddelbart (DNS_PROBE_FINISHED_NXDOMAIN eller parkeringsannonser).
   • Gjenoppretting: Logg på registrarkontoen og betal standard 1-års fornyelsesavgift ($10 til $30 USD). Registraren gjenoppretter umiddelbart originalen NS poster.
2. Trinn 2: Utsettelsesperiode (redemptionPeriod, 30 dagers varighet):
   • Hvis ingen fornyer domenet i løpet av trinn 1 (vanligvis etter dag 30 til 42 avhengig av registrarens vilkår for bruk), sletter registraren domenet i registret, og registret plasserer det i de obligatoriske 30-dagers redemptionPeriod (med mindre registraren auksjonerte det utløpte domenet via en intern auksjonsplattform for utløpt domene som GoDaddy Auctions eller NameJet, sjekk registrarens eksakte dag-30 auksjonsavbrudd umiddelbart).
   • Gjenoppretting: Du kan fortsatt redde domenet med 100 prosent sikkerhet under redemptionPeriod, kun gjennom den originale Losing Registrar. Du må kontakte deres fakturerings-/støttedesk og betale Registry Redemption Restore Fee (vanligvis $80 til $250 USD) pluss en 1-års fornyelse.
3. Trinn 3: Venter på sletting (pendingDelete, siste 5 kalenderdager):
   • En gang på 30 dager redemptionPeriod utløper, kommer domenet inn pendingDelete i nøyaktig 5 dager (120 timer).
   • Påvirkning: Under pendingDelete, avviser registeret all standard EPP restore kommandoer fra registraren. På slutten av dag 5 (for .com/.net Verisign faller, mellom 18:00 og 19:15 UTC), blir domenet frigitt til offentligheten og snappet i løpet av 10 millisekunder av automatiserte drop-catching-nettverk.
   • Nødtiltak hvis du blir fanget inn pendingDelete eller registrator utløpt auksjon:
     • Hvis domenet ble solgt via registrarens dag-30 utløpte auksjon før det kom inn i registret redemptionPeriod, sjekk om registraren din tilbyr et kort innløsningsvindu etter auksjonen eller kontakt den vinnende budgiveren/megleren umiddelbart.
     • Hvis domenet virkelig er i 5-dagers registeret pendingDelete fase, plasser samtidig høytliggende restordrer på tvers av alle de tre store drop-catching-nettverkene (DropCatch.com, SnapNames.com, og NameJet.com) slik at hvis domenet faller til den offentlige poolen på dag 5, vil restordren din fange det eller legge deg inn i den lukkede budauksjonen for å kjøpe tilbake domenet ditt.

Hvorfor svikter nettstedet mitt i flere timer etter at jeg fornyet et utløpt domene? (Fikser negativ DNS-bufring)¶

Når domenet ditt utløper, erstatter registraren din NS poster med midlertidige parkeringsnavneservere som ofte har en 24-timers til 48-timers TTL (Time-To-Live) (86400 eller 172800 sekunder). Selv etter at du har betalt fornyelsesregningen og registraren din gjenoppretter din ekte NS registrerer i rotsonen innen 5 minutter, offentlige rekursive DNS-løsere over hele verden (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, og ISP-løsere) kan fortsette å betjene den bufrede utløpte parkeringssiden til den 48-timers TTL utløper.

Hvordan tvinge frem en umiddelbar global DNS-bufferskylling på 60 sekunder: Ikke vent 48 timer på at rekursive cacher utløper naturlig. Spyl domenet ditt manuelt fra de tre største globale offentlige DNS-leverandørene akkurat nå ved å bruke deres gratis nettbufferrensingsportaler: 1. Tyll Googles offentlige DNS (8.8.8.8 / 8.8.4.4): Besøk developers.google.com/speed/public-dns/cache, type yourdomain.com, velg posttype NS (og gjenta deretter for A, AAAA, MX, og DS), og klikk på Tyll hurtigbuffer. Dette sletter domenet ditt på tvers av alle Google DNS-datasenter over hele verden på mindre enn 10 sekunder. 2. Skyll Cloudflare Public DNS (1.1.1.1 / 1.0.0.1): Besøk one.one.one.one/purge-cache/, skriv inn yourdomain.com, velg NS, A, AAAA, og MX, og klikk på Tøm buffer. 3. Skyll OpenDNS / Cisco Umbrella (208.67.222.222): Besøk cachecheck.opendns.com, skriv inn yourdomain.com, sjekk resultatene på tvers av globale noder, og klikk på Oppdater hurtigbufferen nederst i tabellen.

Fase 4: Retting av ødelagt DNSSEC (SERVFAIL) etter en migrering eller kapring¶

Domain Name System Security Extensions (DNSSEC) signerer DNS-postene dine kryptografisk (RRSIG poster signert med en sonesigneringsnøkkel ZSK og nøkkelsigneringsnøkkel KSK) og publiserer en matchende delegasjonsunderskriver (DS) hash i den overordnede TLD-sonen hos registraren din.

Mens DNSSEC forhindrer cache-forgiftning, forårsaker en ødelagt DNSSEC-konfigurasjon et øyeblikkelig, totalt globalt avbrudd (SERVFAIL) på hver validerende resolver (inkludert 8.8.8.8, 1.1.1.1, Comcast og store mobiloperatører). Dette skjer oftest under en nødmigrering: en administrator flytter yourdomain.comsine navneservere fra Cloudflare til AWS Route 53 (eller omvendt) uten først å slette den gamle leverandørens DS registrere hos domeneregistratoren.

Diagnostisere og reparere en DNSSEC SERVFAIL Lockout om 5 minutter¶

1. Bekreft at DNSSEC er den skyldige: Kjør to dig kommandoer rygg-til-rygg: en vanlig spørring og en spørring med +cd (Checking Disabled) flagg, som forteller den rekursive resolveren å ignorere DNSSEC kryptografisk validering:

   dig yourdomain.com @8.8.8.8
   dig yourdomain.com @8.8.8.8 +cd
   

   • Hvis den første kommandoen mislykkes med status: SERVFAIL og null svar, mens den andre kommandoen (+cd) lykkes umiddelbart med status: NOERROR og returnerer din A registrere IP-adresse, 100 prosent av strømbruddet ditt er en ødelagt DNSSEC-tillitskjede.
2. Inspiser det eksakte bruddet med DNSViz.net eller Verisign DNSSEC Debugger:
   • Åpne dnsviz.net eller dnssec-debugger.verisignlabs.com og gå inn yourdomain.com.
   • Den vil tegne et visuelt diagram som viser om DS posten som er publisert hos registraren din samsvarer ikke med DNSKEY servert av din nåværende DNS-vert, eller om sonesignaturene dine (RRSIG) har utløpt.
3. Nødsanering:
   • Hvis du nettopp byttet DNS-leverandør: Logg inn på domeneregistratoren, naviger til DNSSEC / DS Records-delen, og slett den gamle foreldede DS ta opp (eller erstatt den med den nye DS post generert av din nye DNS-vert).
   • Skyll DS record cache: Besøk Google Public DNS Cache Flush umiddelbart (developers.google.com/speed/public-dns/cache) og Cloudflare Purge Cache (one.one.one.one/purge-cache/) og tøm DS og DNSKEY posttyper for yourdomain.com så validerende resolvere slutter å sjekke de slettede DS hash umiddelbart.

Fase 5: Opprydding etter gjenoppretting, tilbakekall av TLS-sertifikat og herding¶

Å få din domeneregistrarkonto og DNS-poster tilbake under din kontroll er bare halve kampen. I løpet av timene eller dagene som angriperen kontrollerte domenets DNS, hadde de full autoritet til å bevise "Domenekontrollvalidering" (DCV) til hver sertifiseringsinstans (CA) på planeten.

1. Revisjonssertifikatgjennomsiktighetslogger (crt.sh) og oppheve Rogue TLS-sertifikater¶

Når en angriper peker din A eller NS poster til serveren deres, kjører de umiddelbart certbot (La oss kryptere, ZeroSSL, Google Trust Services eller Sectigo) for å generere gyldige, nettleser-klarerte TLS-sertifikater for yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, og mail.yourdomain.com. Selv etter at du har gjenopprettet DNS-postene dine, har angriperen fortsatt den gyldige Private Key (.key) og signert Offentlig sertifikat (.crt) for domenet ditt, som de kan bruke til å iscenesette captive-portal Wi-Fi-angrep, BGP-kapringer eller intern nettverksspoofing i de neste 90 dagene.

1. Søk sertifikatgjennomsiktighetslogger:
   • Gå til crt.sh/?q=%25.yourdomain.com eller Censys sertifikatsøk (search.censys.io/certificates).
   • Sorter etter Logged At / Not Before dater og inspiser hvert enkelt sertifikat som er utstedt under kapringsvinduet (og innen 24 timer etter gjenoppretting, på grunn av bufrede DCV-autorisasjoner).
2. Tvinge umiddelbar tilbakekall av sertifikat:
   • Identifiser den utstedende sertifikatmyndigheten (Issuer Name) på hvert uautorisert sertifikat.
   • Enhver offentlig klarert CA er pålagt i henhold til CA/Browser Forum Baseline Requirements (seksjon 4.9.1.1) for å tilbakekalle et uredelig eller uautorisert sertifikat innen 24 timer etter å ha bekreftet at søkeren ikke var autorisert av den sanne domeneeieren.
   • Hvis du allerede har gjenvunnet DNS-kontroll over domenet, kan du tilbakekalle uautoriserte Let's Encrypt- eller ACME-sertifikater selv på 60 sekunder uten engang å trenge angriperens private nøkkel: bare installer certbot på en server du kontrollerer, send en ny DNS-01- eller HTTP-01-utfordring for nøyaktig samme domenenavn ved å bruke en helt ny ACME-kontonøkkel, og kjør:

     certbot revoke --cert-path downloaded_rogue_cert_from_crt_sh.pem --reason keycompromise
     

   • Alternativt kan du sende inn sertifikatets serienumre direkte til CAs nødopphevelsesportal (for eksempel Let's Encrypt sin tilbakekallingsinstruksjonsside, DigiCerts /revoke portal, eller Sectigos rapporteringsskjema for SSL-misbruk).

2. Lås domenet ditt permanent slik at det aldri kan bli kapret igjen¶

Når driften er gjenopprettet, implementerer du disse fem bedriftsdomeneherdende kontrollene:

1. Aktiver registerlås (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited):
   • For virksomhetskritiske produksjonsdomener, oppgrader til en registrar som tilbyr ekte Registry Lock (støttet av Verisign på .com/.net, PIR på .org, og tilbys gjennom bedriftsregistratorer som MarkMonitor, CSC Digital Brand Services, Cloudflare Enterprise, Porkbun/Gandi/Namecheap Registry Lock-nivåer). Med Registry Lock aktiv, selv om en hacker stjeler registrar-påloggingen din og MFA, avviser TLD-registeret alle NS eller overføre endringer med mindre en menneskelig sikkerhetsansvarlig fullfører en kryptografisk/telefonseremoni utenfor båndet.
2. Publiser CAA (Autorisasjon fra sertifiseringsinstans) DNS-poster:
   • Legg til en CAA rekord (RFC 8659) til DNS-sonen din og spesifiserer de nøyaktige sertifiseringsinstansene som har tillatelse til å utstede TLS-sertifikater for domenet ditt (f.eks. 0 issue "letsencrypt.org" eller 0 issue "digicert.com", pluss 0 iodef "mailto:security@yourdomain.com"). Mens en angriper som kontrollerer hele DNS-sonen din kan slette en CAA rekord, a CAA post stopper BGP-kaprere eller kompromitterte CNAME-mål under domene fra å bruke uautoriserte CAer.
3. Skill domeneregistratoren din fra din daglige DNS-vertsleverandør:
   • Hold domeneregistreringen din låst inne i en hvelvregistrarkonto med høy sikkerhet som bare 2 bedriftsledere har tilgang til ved å bruke FIDO2 maskinvaresikkerhetsnøkler (YubiKey), og deleger daglig DNS-postadministrasjon (A, CNAME, TXT) til en separat administrert DNS-tjeneste med granulær rollebasert tilgangskontroll (RBAC) og scoped API-tokens.
4. Revidere og eliminere dinglende underdomene CNAME og NS Rekorder:
   • Kjør en månedlig automatisk skanning av hele DNS-sonefilen din (subzy, nuclei -t takeovers/, eller OWASP Amass) for å identifisere eventuelle CNAME, ALIAS, eller underdomene NS post som peker til en uregistrert ekstern skyressurs eller utløpt domene, og slett DNS-posten før skyserveren tas ut av drift.
5. Konfigurer automatisk ekstern RDAP-, DNS- og CT-loggovervåking:
   • Konfigurer en ekstern skjerm (som f.eks CertSpotter, Cloudflare Sertifikattransparensovervåking, eller en enkel cron script-sjekking hver time dig NS og whois) som varsler en dedikert Slack/PagerDuty-kanal og en SMS/e-postadresse utenfor domenet det nøyaktige minuttet et nytt TLS-sertifikat er logget på Certificate Transparency eller en NS/MX/DS registrere endringer.

Ofte stilte spørsmål¶

Kilder sjekket¶

• Cybersecurity and Infrastructure Security Agency (CISA, USA): Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering (CISA-mandater om Registry Lock, MFA for DNS/Registrars, Certificate Transparency-loggrevisjon og DNSSEC-validering) (cisa.gov/news-events/directives/emergency-directive-19-01).
• Internet Corporation for Assigned Names and Numbers (ICANN, International): Transfer Policy (Inter-Registrar Transfer Policy / IRTP), Transfer Dispute Resolution Policy (TDRP), Utløpt Registration Recovery Policy (ERRP) og EPP Status Codes Reference (icann.org/resources/pages/epp-status-codes-2014-06-16-en).
• National Institute of Standards and Technology (NIST, USA): Spesialpublikasjon 800-81-2, Secure Domain Name System (DNS) Deployment Guide (csrc.nist.gov).
• National Cyber Security Center (NCSC, Storbritannia): Beskyttelse av bulk personlige data og domenesikkerhet: registerlås, CAA-poster og forebygging av underdomeneovertakelse (ncsc.gov.uk).
• CA/nettleserforum (internasjonalt): Basiskrav for utstedelse og administrasjon av offentlig pålitelige TLS-serversertifikater (avsnitt 4.9.1.1: 24-timers obligatorisk tilbakekall for domenekompromittering) (cabforum.org).
• Internet Engineering Task Force (IETF, International): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS Certification Authority Authorization / CAA Resource Record), og RFC 9083 (Registration Data Access Protocol / RDAP) (datatracker.ietf.org).

Relaterte guider¶

• Krise for webhotell, migrering og gjenoppretting av sikkerhetskopier
• Nettfisking og kompromitterte kontoer
• MFA-phishing og motstander-i-midten-omgåelse
• Respons på datainnbrudd og passordlekkasjer
• Bedrifts løsepengevare og serverbrudd
• SIM-bytte