Domainnév-eltérítés, DNS-mérgezés és a regisztrátor kizárása¶

A szervezet elsődleges domain neve vagy a hiteles DNS-zóna feletti ellenőrzés elvesztése az egyik legpusztítóbb digitális vészhelyzet, amelyet egy üzleti vállalkozás, kórház, önkormányzati ügynökség vagy online kiadvány elszenvedhet. Mivel az Ön domain neve a bizalom gyökere az interneten található összes rendszerben, egy támadó, aki eltéríti az Ön domainregisztrátori fiókját vagy megmérgezi DNS-rekordjait, nem pusztán elrontja webhelyét. Perceken belül, miután megváltoztatta NS (névszerver), A/AAAA (Web IP), ill MX (Mail Exchange) rekordokat, a támadó csendben elfoghat minden bejövő vállalati és ügyfél e-mailt, átadhatja az automatikus Let's Encrypt Domain Validation (DV) ellenőrzi, hogy érvényes TLS/SSL titkosítási tanúsítványokat helyezzen-e az Ön nevére, rögzíti-e az alkalmazottak egyszeri bejelentkezési (SSO) jelszavait, és jelszó-visszaállítási e-maileket indít el felhőinfrastruktúrája, banki portáljai és pénzügyi számlái számára. Még egy nem rosszindulatú hiba is, például egy lejárt domain beesése AutoRenewGracePeriod vagy RedemptionPeriod (clientHold), azonnal leállítja a webes forgalmat, az API mobil háttérrendszereket és a vállalati e-maileket világszerte.

Ha egy tartomány-eltérítés vagy DNS-kimaradás veszélyezteti a kórházi betegek útválasztását, a segélyhívó kommunikációt, a közüzemi telemetriát vagy egy aktív életvédelmi rendszert, hívja a helyi segélyhívó számot (911 az Egyesült Államokban és Kanadában, 112 az Európai Unió egész területén, 999 az Egyesült Királyságban), vagy tekintse meg nemzetközi jegyzékünket segélyhívó számok és értesítse nemzeti kiberincidens-elhárítási csapatát (például a CISA-t az Egyesült Államokban a címen 1-844-SAY-CISA vagy NCSC az Egyesült Királyságban) azonnal. Minden kereskedelmi, nonprofit és személyes domain krízis esetén hajtsa végre az alábbi osztályozási lépéseket pontos sorrendben.

Tedd ezt most¶

1. Határozza meg 30 másodpercen belül, hogy lejárt-e a domainje, megváltoztak-e a DNS-rekordjai, vagy a domain átkerült-e egy külföldi regisztrátorhoz: Futtasson élőben RDAP vagy WHOIS lekérdezés és egy mérvadó DNS-lekérdezés egy terminálról (rdap yourdomain.com vagy whois yourdomain.com, és dig +trace yourdomain.com). Ellenőrizze a Regisztrátor nevét, az EPP állapotkódokat (pl clientHold számlázáshoz/ellenőrzéshez vs. ok ismeretlen névszerverekkel), és a Authoritative Nameservers (NS).
2. Azonnal fagyasszon le minden kimenő jelszó-visszaállítást, és zárolja le identitásszolgáltatóját (Okta, Microsoft Entra ID, Google Workspace): Ha egy támadó irányítja a domainjét MX rekordok ill NS szerverekre, minden egyes e-mailt megkapnak, amelyre küldött *@yourdomain.com. Azonnal utasítsa az informatikai rendszergazdákat, hogy tiltsák le az „Elfelejtett jelszó e-mailben” önkiszolgáló visszaállítását az összes vállalati eszközben, vonják vissza az aktív munkameneteket azon felhasználók számára, akiknek az e-mail címét külső szállítói fiókok visszaállítására használhatják, és váltsák át az adminisztrátori bejelentkezéseket hardveres FIDO2 biztonsági kulcsokra vagy belső .onmicrosoft.com tartalék domainek.
3. Megőrzi az RDAP/WHOIS, a DNS-zónák és a tanúsítványok átláthatóságának teljes igazságügyi pillanatfelvételeit (CT) naplózza, mielőtt bármi megváltozna: Mentse a kimenetét dig ANY yourdomain.com @8.8.8.8, whois yourdomain.com, és ellenőrizze crt.sh/?q=%25.yourdomain.com azonnal. Keresés crt.sh felfed minden jogosulatlan SSL/TLS-tanúsítványt, amelyet a támadó az Ön aldomainje számára készített (mail., vpn., login., api.), így pontosan tudja, mely belső szolgáltatásokat személyesítik meg aktívan az Adversary-in-the-Middle (AitM) proxykon keresztül.
4. Vegye fel a kapcsolatot a vesztes regisztrátor dedikált vészhelyzeti visszaélés/biztonsági műveleti csapatával (nem az 1. szintű csevegési támogatással), hogy az ICANN jogosulatlan átutalásával kapcsolatos vitát kezdeményezzen (IRTP) vagy a Registry Lock visszavonása: Ha a domainjét egy másik fiókba küldték át ugyanannál a regisztrátornál, vagy egy ellopott fiókon keresztül Auth-Info (EPP).Section I.A és Transfer Dispute Resolution Policy), jogosulatlan hitelesítő kompromisszumra hivatkozva.
5. Eszkaláljon közvetlenül a legfelső szintű tartományi (TLD) regisztrációs kezelőhöz, ha a regisztrátor nem válaszol: Ne feledje a hierarchiát: Regisztrátorok (mint például a GoDaddy, Namecheap, Cloudflare, MarkMonitor, Network Solutions, Gandi, Porkbun) egyszerűen kiskereskedelmi viszonteladók; a Registry Operator (például a Verisign for .com/.net, Public Interest Registry (PIR) for .org, Nominet for .uk, CIRA for .ca, DENIC for .de, vagy auDA .au) futtatja a fő gyökérzóna adatbázist. Országkód (ccTLD) nyilvántartások és számos gTLD-nyilvántartás vészhelyzetet hozhat létre serverHold vagy serverUpdateProhibited zárolás közvetlenül a gyökér szinten az ellenőrzött kiberbűnözés során.
6. ** Figyelmeztesse az ügyfeleket, szállítókat és banki partnereket sávon kívüli csatornákon keresztül, hogy @yourdomain.com az e-mail feltört**: Ha a támadó eltérítette az Ön MX rekordokat, azonnal válaszolnak a nyitott könyvelési szálakra hamis átutalási utasításokkal. Tájékoztassa az ügyfeleket telefonon, SMS-ben, LinkedIn-en, egy külön biztonsági tartományon lévő állapotoldalon vagy hivatalos közösségimédia-fiókokon keresztül, hogy a visszaállítás megerősítéséig ne bízzanak az érintett domain egyetlen e-mailjében vagy bejelentkezési portáljában sem.

Döntési fa: tartomány- vagy DNS-kimaradás diagnosztizálása és tárolása¶

Kövesse ezt a gyors diagnosztikai folyamatábrát a meghibásodott vagy eltérített tartománynévrendszer pontos rétegének meghatározásához:

flowchart TD
    A["A webhely leállt, a TLS-tanúsítványra vonatkozó figyelmeztetés vagy a vállalati e-mail leállt"] --> B["Futtassa az RDAP/WHOIS-t és dig +nyomkövetést a külső hálózatról"]
    B --> C{"Mit mutatnak az RDAP állapota és nyilvántartó mezői?"}
    C -->|"Állapot: clientHold, autoRenewPeriod vagy redemptionPeriod"| D["Véletlen lejárat vagy az ICANN Whois ellenőrzés felfüggesztése"]
    D --> E["Azonnal jelentkezzen be a Regisztrátorba: Fizessen megújítási / beváltási díjat, vagy kattintson a RAA ellenőrzési hivatkozásra; Vészhelyzeti TTL-öblítés kérése"]
    C -->|"Az anyakönyvvezető neve vagy a regisztráló fiókja engedély nélkül megváltozott"| F["Teljes Regisztrátor-fiók eltérítése vagy jogosulatlan EPP-átvitel"]
    F --> G["Lock Identity Provider (Entra/Google), File Emergency Registrar Abuse Ticket + ICANN Transfer Dispute, Rogue Certs keresése a crt.sh oldalon"]
    C -->|"Regisztrátor és NS változatlan, de az A / CNAME / MX rekordok ismeretlen IP-címekre mutatnak"| H["Felügyelt DNS-szolgáltató kompromittálása (Cloudflare / Route53 / NS1 API kulcs vagy fiók megsértése)"]
    H --> I["Kompromittált DNS API-tokenek visszavonása, jól ismert zónafájl visszaállítása, Rogue TLS-tanúsítványok visszavonása, felfedett hitelesítő adatok elforgatása"]
    C -->|"A Registrar, NS és Zone Records normálisan néz ki, de a webhely meghiúsul a SERVFAIL segítségével"| J["Megszakadt DNSSEC bizalmi lánc (DS-rekord eltérés vagy lejárt RRSIG)"]
    J --> K["Futtassa a DNSViz.net ellenőrzést: Távolítsa el az elavult DS-rekordot a regisztrátornál vagy írja be újra a zónát a DNS-állomáson"]

1. fázis: Technikai kriminalisztika a pontos támadási vektor azonosítására¶

Amikor egy domain hirtelen leáll, vagy adathalász oldalt vagy kriptovaluta-átverést kezd kiszolgálni, minden találgatással töltött perc értékes helyreállítási időt veszít el. Négy teljesen eltérő forgatókönyv létezik, amelyek a webböngészőben egy végfelhasználóhoz hasonlítanak, és mindegyik teljesen más javítást igényel.

Hogyan kell olvasni RDAP, WHOIS, és dig Kimenetek, mint egy incidensre reagáló¶

Nyisson meg egy parancsterminált Linux, macOS vagy Windows rendszeren (WSL vagy nslookup), és futtassa a következő három diagnosztikai ellenőrzést egy semleges nyilvános rekurzív feloldóval (8.8.8.8 vagy 1.1.1.1):

1. Ellenőrizze a regisztrációs szintű delegációt (dig +trace és RDAP):

   dig +trace yourdomain.com NS @1.1.1.1
   

   • Nézze meg a lépést közvetlenül a TLD gyökérkiszolgálók után (például a.gtld-servers.net. számára .com). Melyik NS A (névszerver) gazdagépneveket maga a TLD Registry adja vissza?
   • Ha a TLD Registry visszaadja a normál névszervereit (ns1.yourdnsprovider.com) állapottal NOERROR, az eltérítés a DNS-tárhelyszolgáltatón belül történik (vagy DNSSEC-törésről van szó).
   • Ha a TLD Registry teljesen ismeretlen névszervereket ad vissza (vagy ha whois yourdomain.com újat mutat Registrar: név és egy Updated Date: az elmúlt órákban vagy napokban), a feltörés a domain regisztrátor szintjén történt.
2. Dekódolja meg az ICANN EPP domain állapotkódjait: Nézd meg a Domain Status: sorok a te WHOIS vagy RDAP kimenet. Ezek a szabványos Extensible Provisioning Protocol (EPP) kódok megmondják, hogy egy tartomány miért nem működik vagy zárolva van:

2. fázis: Helyreállítás rosszindulatú domain-eltérítésből vagy jogosulatlan regisztrátor-átvitelből¶

A támadók három elsődleges technikával eltérítik a nagy értékű vállalati, Web3/DeFi, pénzügyi és médiatartományokat: 1. Regisztrátor-fiók átvétele (hitelesítő adatok kitöltése, Infostealer rosszindulatú program vagy SIM-csere): A támadó bejelentkezik a GoDaddy, a Namecheap, a Google Domains/Squarespace vagy a Network Solutions irányítópultjába, és kikapcsol clientTransferProhibited, megváltoztatja a NS rekordokat, hogy egy támadó által vezérelt Cloudflare-fiókra mutasson, vagy létrehoz egy Auth-Info (EPP) kódot a domain átviteléhez. 2. Regisztrátortámogatás szociális tervezése: A támadó hamis alapító okiratokat, hamis állami igazolványokat vagy hamisított levélpapírt nyújt be a regisztrátor fiók-helyreállítási részlegének, azt állítva, hogy az eredeti rendszergazda meghalt vagy elhagyta a céget. 3. Aldomain átvétel (Dangling CNAME / Dangling NS): Fő domainje érintetlen, de egy régi aldomain (promo.yourdomain.com vagy status.yourdomain.com) még mindig a CNAME rekord, amely egy leállított AWS S3 tárolóra, Azure App Service-re, GitHub Pages repóra, Heroku alkalmazásra vagy hónapokkal ezelőtt törölt Zendesk-példányra mutat. A támadó regisztrálja ezt az elhagyott felhő-erőforrásnevet az AWS/Azure/GitHubon, és azonnal kiszolgálja a rosszindulatú tartalmat a hivatalos aldomainről.

1. lépés: Lépje ki a támadót a Cloud Identity szolgáltatójából és az e-mail rendszeréből¶

Mielőtt még befejezné a regisztrátor helyreállítási űrlapjának kitöltését, feltételezze, hogy a támadó aktívan elolvas minden, a domainbe küldött e-mailt, és megpróbál bekapcsolódni a belső felhő-infrastruktúrába:

1. A Microsoft 365 / Google Workspace váltása tartalék tartományokra és hardveres MFA-ra:
   • A Microsoft Entra ID-ben (korábban Azure AD) minden bérlőnek van egy állandó, fel nem törhető tartalék tartománya (yourcompany.onmicrosoft.com). A rendszergazdák a következőn keresztül tudnak bejelentkezni admin@yourcompany.onmicrosoft.com még ha yourdomain.com A DNS teljesen feltört.
   • Az összes SMS, hanghívás és alternatív e-mail jelszó-visszaállítási módszer letiltása az Entra ID / Okta / Google Workspace szolgáltatásban (Authentication Methods Policy). FIDO2/WebAuthn hardveres biztonsági kulcsok vagy számegyeztető Authenticator push értesítések szükségesek.
2. A kimenő és bejövő e-mail naplók ellenőrzése a pontos kompromisszum ablakhoz:
   • Ha a te MX a rekordokat 02:14 UTC-kor módosították, 02:14 UTC óta nulla legitim külső e-mail érkezett a valódi levelezőszerverekhez; Minden egyes külső e-mailt, amelyet a személyzetnek küldött az adott ablakban, teljes sima szövegben rögzítette a támadó csaló levelezőszervere (Postfix/Exim figyelő).
   • Azonnal készítsen listát minden harmadik féltől származó SaaS-platformról, bankról, AWS/GCP gyökérfiókról, GitHub-szervezetről és szállítói portálról @yourdomain.com e-mail címeket, és ellenőrizze, hogy a támadó elindította-e a jelszó-visszaállítást ezeken a külső platformokon a feltörési ablak során.

2. lépés: Hajtsa végre a Registrar and Registry Emergency Recovery Protocol protokollt¶

Ne nyisson meg általános „A webhelyem nem működik” támogatási csevegést. Pontos szabályozási és jogi terminológiát kell használnia, amely a Regisztrátor Tier-3 Security / General Counsel / ICANN Compliance Team felé történő eszkalációt váltja ki:

1. A eset: A domain még mindig az eredeti regisztrátornál van (fiókátvétel vagy belső "fiókleküldés"):
   • Sok támadó nem vár 5 napot a regisztrátorok közötti EPP-átvitelre; ehelyett a regisztrátor azonnali „Domain átküldése másik fiókba” funkcióját használják, hogy 3 másodpercen belül áthelyezzék a domainjét az ugyanazon regisztrátornál lévő írófiókba.
   • Azonnal hívja és küldjön e-mailt a regisztrátor Csalások / Fiókeltérítés / Visszaélések Osztályának. Világosan fogalmazza meg: "SÜRGŐS BIZTONSÁGI ESEMÉNY: Jogosulatlan fiókhozzáférés és a [sajatdomain.com] belső domain leküldése/DNS-módosítása. A domain azonnali lefagyasztásának kérése serverHold/clientUpdateProhibited és a jogosulatlan DNS-/fiókmódosítások visszaállítása."
   • Azonnal állítsa össze a történelmi tulajdonjogot igazoló csomagot: A regisztrátor biztonsági csapatai megdönthetetlen bizonyítékot kérnek arról, hogy Ön a jogos korábbi regisztráló, mielőtt visszavonnák a domaint egy másik fiókból. Azonnal gyűjtse össze ezt az 5 dokumentumot egyetlen PDF-be:
     1. Korábbi hivatalvezetői számlák és fizetési bizonylatok: PDF nyugták és hitelkártya-/banki átutalási kivonatok, amelyek azt mutatják, hogy a szervezet fizet a regisztrációért és a megújításért. yourdomain.com az elmúlt 1-10 év során (beleértve a fizetési kártya vagy az átutalás utolsó 4 számjegyét).
     2. Állami által kibocsátott vállalati regisztráció és tisztségviselői azonosító: hivatalos cégbírósági okirat / a korábbi WHOIS-nak megfelelő alapszabály Registrant Organization, valamint az eskü alatti nyilatkozatot aláíró vállalati tisztviselő fényképes igazolványa.
     3. Előzményi DNS-zónafájl és -kiszolgáló tulajdonjogának igazolása: A korábbi DNS-zónafájl másolatai, a WHOIS történeti pillanatképei vagy annak bizonyítéka, hogy az Ön szervezete az autonóm rendszer tulajdonosa (ASN) vagy IP blokkok (A rekordok), amelyekre a domain a mai változás előtt évekig mutatott.
     4. Eredeti fióklétrehozási e-mail / jegyelőzmények: A regisztrátortól a domain eredeti regisztrálásakor vagy megújításakor kapott e-mailek fejlécei.
     5. A hivatalos rendészeti jelentés száma: A benyújtott FBI IC3 (ic3.gov) panaszszám (Egyesült Államok), Action Fraud hivatkozási szám (Egyesült Királyság) vagy nemzeti rendőrségi kiberbűnözési jelentés száma. Az anyakönyvvezetők drámaian gyorsabban járnak el, ha átadják a hivatalos bűnüldözési ügyszámot, amely megerősíti, hogy az Egyesült Államok 18. évében történt számítógépes behatolás történt. § 1030 (CFAA) vagy az Egyesült Királyság 1990. évi számítógépes visszaélésről szóló törvénye.
2. B eset: A domaint egy másik regisztrátorhoz adták át (Regisztrátorok közötti eltérítés):
   • Az ICANN átviteli szabályzata (korábban IRTP) értelmében a regisztrátorok közötti átvitelhez egy Auth-Info (EPP). Ha egy támadó feltörte az Ön fiókját az A regisztrátornál (az "elvesző regisztrátor"), és átadta a domaint a B regisztrátornak (a "gyarapodó regisztrátor"):
   • Azonnal vegye fel a kapcsolatot a vesztes iktatóval és a nyerő iktatóval, de előnyben részesítse a elvesztes iktató áthelyezési vitás/biztonsági csapatát. Az ICANN Transfer Dispute Resolution Policy (TDRP) szerint a vesztes regisztrátor az az entitás, amely rendelkezik az Ön korábbi számlázási rekordjaival és bejelentkezési naplóival, amelyek bizonyítják, hogy az átvitel jogosulatlan volt. A vesztes hivatalvezető hivatalosan kapcsolatba léphet a Nyerő Regisztrátor megfelelőségi tisztviselőjével, hogy végrehajtsa a szövetkezeti Regisztrátor átadás visszavonását, vagy hivatalos TDRP-eljárást indítson.
   • Egyidejűleg küldje el a tulajdonjogot igazoló csomagot és a rendőrségi jelentést a Gining Registrar's Abuse Desk-nak, kérve, hogy azonnal tegyenek bejelentést. clientTransferProhibited és clientUpdateProhibited zárolja a domaint, hogy a támadó ne tudja átugrani a domaint három további offshore regisztrátorból álló láncon ("regisztrátor ugrás").
3. Vészhelyzeti eszkaláció benyújtása az ICANN-hoz (például gTLD-k esetén .com, .net, .org, .io ha gTLD) vagy a ccTLD nyilvántartó:
   • Ha egy regisztrátor megtagadja a jogosulatlan átvitel kivizsgálását, vagy nem válaszol egy aktív eltérítés során, nyújtson be sürgős jogosulatlan átviteli/domain-eltérítési panaszt az ICANN szerződés-megfelelőségi portálon (icann.org/compliance/complaint).
   • Ha domainje Országkódú legfelső szintű domaint használ (ccTLD), mint pl .uk, .ca, .au, .de, .fr, .nl, .ch, vagy .jp, akkor még gyorsabb lehetősége van: a ccTLD-nyilvántartásokat az ICANN helyett a nemzeti felügyeleti hatóságok irányítják, és szinte mindig közvetlen Registry Emergency Security Teams tart fenn (például Nominet az Egyesült Királyságban a következő címen: 0330 236 9470, CIRA Kanadában, DENIC Németországban, AFNIC Franciaországban), amelyek a vállalati azonosság ellenőrzése után órákon belül lefagyaszthatják a feltört domaint közvetlenül a nemzeti nyilvántartás szintjén.

3. fázis: Lejárt domain mentése (clientHold, RedemptionPeriod, és PendingDelete)¶

Nem minden hirtelen globális kiesés számít kibertámadásnak. A nagyvállalatok, az induló SaaS-vállalkozások és az állami vállalkozók minden egyes nap teljesen elsötétülnek, mert a domainregisztrátoruknál lejárt hitelkártya lejárt, és a megújítási emlékeztető e-maileket a címre küldték. former-founder@company.com aki három éve hagyta el a céget.

Az ICANN lejárt domain életciklus idővonalának megértése¶

Általános legfelső szintű domainekhez (.com, .net, .org, .biz, .info), az ICANN lejárt regisztráció helyreállítási szabályzata (ERRP) szigorú, többlépcsős életciklust érvényesít a lejárati dátum lejárta után:

1. 1. szakasz: Automatikus megújítási türelmi időszak (1. naptól ~30/45-ig a lejárat után):
   • Közvetlenül a lejárat után (gyakran 24-72 órán belül) a regisztrátor megváltoztatja a domain NS rögzít egy parkolt/lejárt megújítási kezdőlapra, vagy elhelyezi a domaint clientHold.
   • Hatás: Webhelye és vállalati e-mailjei azonnal leállnak (DNS_PROBE_FINISHED_NXDOMAIN vagy parkolási hirdetések).
   • Helyreállítás: Jelentkezzen be a regisztrátor fiókjába, és fizesse ki a szokásos 1 éves megújítási díjat (10-30 USD). A regisztrátor azonnal visszaállítja az eredetit NS rekordokat.
2. 2. szakasz: Megváltási türelmi időszak (redemptionPeriod, 30 napos időtartam):
   • Ha senki sem újítja meg a domaint az 1. szakaszban (általában a regisztrátor Általános Szerződési Feltételeitől függően a 30-42. nap után), a regisztrátor törli a domaint a Regisztrációban, és a Nyilvántartó a kötelező 30 napba helyezi.redemptionPeriod (hacsak a regisztrátor nem aukcióra bocsátotta a lejárt domaint egy belső lejárt domain aukciós platformon, például a GoDaddy Auctions vagy a NameJet segítségével, azonnal ellenőrizze regisztrátora 30. napos aukciós határidejét).
   • Helyreállítás: Továbbra is 100 százalékos biztonsággal megmentheti a domaint közben redemptionPeriod, csak az eredeti vesztes hivatalvezetőn keresztül. Fel kell vennie a kapcsolatot a számlázási/támogatási részlegükkel, és ki kell fizetnie a Registry Redemption Restore Fee (általában 80-250 USD) díjat, valamint az 1 éves megújítást.
3. 3. szakasz: Törlés függőben (pendingDelete, Utolsó 5 naptári nap):
   • Egyszer a 30 nap redemptionPeriod lejár, a domain pendingDelete pontosan 5 napig (120 óráig).
   • Hatás: Közben pendingDelete, a Nyilvántartó minden szabványos EPP-t elutasít restore parancsokat a regisztrátortól. Az 5. nap végén (az .com/.net A Verisign megszűnik, 18:00 és 19:15 UTC között), a domain nyilvánosságra kerül, és 10 ezredmásodpercen belül lefoglalják az automatikus cseppfogó hálózatok.
   • Vészhelyzeti intézkedés, ha elkapják pendingDelete vagy Regisztrátor lejárt aukció:
     • Ha a domaint a regisztrátor 30. napján lejárt aukción keresztül értékesítették a Regisztrációba való belépés előtt redemptionPeriod, ellenőrizze, hogy regisztrátora kínál-e rövid aukció utáni beváltási időszakot, vagy azonnal lépjen kapcsolatba a nyertes licitálóval/brókerrel.
     • Ha a domain valóban benne van az 5 napos nyilvántartóban pendingDelete fázisban egyszerre adjon le magas szintű utólagos rendeléseket mindhárom fő cseppfogó hálózaton (DropCatch.com, SnapNames.com, és NameJet.com), így ha a domain az 5. napon a nyilvános készletbe kerül, az Ön utólagos rendelése rögzíti azt, vagy bevezeti Önt a zárt licitáló aukcióba, hogy visszavásárolja a domaint.

Miért nem működik még órákig a webhelyem, miután megújítottam egy lejárt domaint? (A negatív DNS-gyorsítótárazás javítása)¶

Amikor a domain lejár, a regisztrátor lecseréli a domainjét NS rekordok ideiglenes parkoló névszerverekkel, amelyek gyakran hordoznak egy 24-48 órás TTL-t (Time-To-Live) (86400 vagy 172800 másodperc). Még azután is, hogy kifizette a megújítási számlát, és az anyakönyvvezető visszaállítja a valódit NS rekordok a gyökérzónában 5 percen belül, nyilvános rekurzív DNS-feloldók szerte a világon (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9és az ISP-feloldók) továbbra is kiszolgálhatják a gyorsítótárazott lejárt parkolóoldalt, amíg a 48 órás TTL le nem jár.

Hogyan kényszeríthet ki azonnali globális DNS-gyorsítótár-ürítést 60 másodperc alatt: Ne várjon 48 órát, amíg a rekurzív gyorsítótárak természetes módon lejárnak. Manuálisan ürítse ki domainjét a három legnagyobb globális nyilvános DNS-szolgáltatótól az ingyenes internetes gyorsítótár-tisztító portálok segítségével: 1. ** Öblítse ki a Google nyilvános DNS-t (8.8.8.8 / 8.8.4.4)**: Látogassa meg developers.google.com/speed/public-dns/cache, írja be yourdomain.com, válassza ki a rekord típusát NS (majd ismételje meg A, AAAA, MX és DS), majd kattintson a Gyorsítótár kiürítése lehetőségre. Ezzel kevesebb, mint 10 másodperc alatt törli domainjét világszerte minden Google DNS-adatközpontban. 2. Flush Cloudflare nyilvános DNS (1.1.1.1 / 1.0.0.1): Látogassa meg one.one.one.one/purge-cache/, írja be yourdomain.com, válassza a NS, A, AAAA és MX, majd kattintson a Gyorsítótár törlése lehetőségre. 3. Flush OpenDNS / Cisco Umbrella (208.67.222.222): Látogassa meg cachecheck.opendns.com, írja be yourdomain.com, ellenőrizze a globális csomópontok eredményeit, majd kattintson a Gyorsítótár frissítése lehetőségre a táblázat alján.

4. fázis: A hibás DNSSEC javítása (SERVFAIL) migráció vagy eltérítés után¶

A Domain Name System Security Extensions (DNSSEC) kriptográfiailag aláírja a DNS-rekordokat (RRSIG zóna aláíró kulccsal aláírt rekordok ZSK és Kulcs-aláíró kulcs KSK), és közzétesz egy megfelelő Delegation Signer (DS) hash a szülő TLD zónában a regisztrátornál.

Míg a DNSSEC megakadályozza a gyorsítótár mérgezését, egy hibás DNSSEC-konfiguráció azonnali, teljes globális leállást okoz (SERVFAIL) minden érvényesítő feloldón (beleértve 8.8.8.8, 1.1.1.1, Comcast és nagyobb mobilszolgáltatók). Ez leggyakrabban vészhelyzeti migráció során történik: a rendszergazda elköltözik yourdomain.comnévszervereket a Cloudflare-től az AWS Route 53-ig (vagy fordítva) anélkül, hogy először törölné a régi szolgáltatót. DS rögzítse a domain regisztrátornál.

DNSSEC diagnosztizálása és javítása SERVFAIL Kizárás 5 percen belül¶

1. Erősítse meg, hogy a DNSSEC a tettes: Fuss kettőt dig egymás melletti parancsok: egy normál lekérdezés és egy lekérdezés a +cd (Checking Disabled) jelző, amely arra utasítja a rekurzív feloldót, hogy figyelmen kívül hagyja a DNSSEC kriptográfiai érvényesítését:

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

   • Ha az első parancs sikertelen status: SERVFAIL és nulla választ, míg a második parancs (+cd) azonnal sikerül status: NOERROR és visszaadja az Ön A rögzítse az IP-címet, a kimaradás 100 százaléka megszakadt DNSSEC bizalmi lánc.
2. Ellenőrizze a pontos törést a DNSViz.net vagy Verisign DNSSEC Debugger:
   • Nyitvadnsviz.net vagy dnssec-debugger.verisignlabs.com és lépjen be yourdomain.com.
   • Vizuális diagramot fog rajzolni, amely megmutatja, hogy a DS a regisztrátornál közzétett rekord nem egyezik a DNSKEY az aktuális DNS-állomás szolgálja ki, vagy hogy a zóna aláírásai (RRSIG) lejártak.
3. Sürgősségi helyreállítás:
   • Ha most váltott DNS-szolgáltatót: Jelentkezzen be a Domain Regisztrátorba, lépjen a DNSSEC / DS Records szakaszhoz, és törölje a régi elavult fájlt. DS rekord (vagy cserélje ki az újra DS az új DNS-gazda által generált rekord).
   • ** Öblítse le a DS gyorsítótár rögzítése**: Azonnal keresse fel a Google nyilvános DNS-gyorsítótár öblítését (developers.google.com/speed/public-dns/cache) és a Cloudflare Purge Cache (one.one.one.one/purge-cache/) és törölje ki a DS és DNSKEY rekordtípusok yourdomain.com így a feloldók érvényesítése leállítja a töröltek ellenőrzését DS azonnal hash.

5. fázis: Helyreállítás utáni tisztítás, TLS-tanúsítvány visszavonása és keményítés¶

Domainregisztrátor-fiókja és DNS-rekordjainak visszaszerzése az irányítása alá csak a siker fele. Azon órákban vagy napokban, amíg a támadó ellenőrizte a domain DNS-ét, teljes jogkörrel rendelkezett a „Domain Control Validation” bizonyítására (DCV) minden tanúsító hatósághoz (CA) a bolygón.

1. Tanúsítványok átláthatósági naplói (crt.sh) és a Rogue TLS tanúsítványok visszavonása¶

Amikor egy támadó rámutat az Önre A vagy NS rekordokat a szerverükre, azonnal lefutnak certbot (Encrypt, ZeroSSL, Google Trust Services vagy Sectigo) érvényes, böngészőben megbízható TLS-tanúsítványok generálásához yourdomain.com, *.yourdomain.com, vpn.yourdomain.com, és mail.yourdomain.com. A DNS-rekordok visszaállítása után is a támadó továbbra is birtokolja az érvényes Privát kulcsot (.key) és aláírt Nyilvános tanúsítvány (.crt) az Ön domainjéhez, amelyet a következő 90 napon keresztül használhatnak Wi-Fi-támadások, BGP-eltérítések vagy belső hálózati hamisítások végrehajtására.

1. Lekérdezési tanúsítvány átláthatósági naplói:
   • Tovább a crt.sh/?q=%25.yourdomain.com vagy Censys tanúsítványkeresés (search.censys.io/certificates).
   • Rendezés Logged At / Not Before dátumozzon és ellenőrizzen minden egyes tanúsítványt, amelyet a feltörési időszak alatt (és a gyorsítótárazott DCV-engedélyek miatt a helyreállítást követő 24 órában) adtak ki.
2. A tanúsítvány azonnali visszavonásának kényszerítése:
   • Azonosítsa a kiállító tanúsítvány hatóságot (Issuer Name) minden jogosulatlan tanúsítványon.
   • A CA/Böngészőfórum alapkövetelményei (4.9.1.1. szakasz) értelmében minden nyilvánosan megbízható CA köteles visszavonni a csalárd vagy jogosulatlan tanúsítványt 24 órán belül azt követően, hogy megerősítette, hogy a kérelmezőt nem a valódi domaintulajdonos engedélyezte.
   • Ha már visszaszerezte a DNS-ellenőrzést a tartomány felett, 60 másodpercen belül visszavonhatja a jogosulatlan Let's Encrypt vagy ACME tanúsítványokat anélkül, hogy a támadó privát kulcsára lenne szüksége: egyszerűen telepítse certbot az Ön által irányított kiszolgálón adjon át egy új DNS-01 vagy HTTP-01 kihívást pontosan ugyanarra a tartománynévre egy vadonatúj ACME-fiókkulccsal, és futtassa:

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

   • Alternatív megoldásként küldje el a tanúsítványok sorozatszámait közvetlenül a CA vészhelyzeti visszavonási portáljára (például a Let's Encrypt visszavonási utasítások oldalára, a DigiCert /revoke portálon vagy a Sectigo SSL-visszaélés bejelentési űrlapján).

2. Zárolja végleg domainjét, hogy soha többé ne lehessen eltéríteni¶

A műveletek visszaállítása után hajtsa végre az alábbi öt vállalati tartomány-megerősítő vezérlőt:

1. A beállításjegyzék zárolásának engedélyezése (serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited):
   • A kritikus fontosságú éles domainek esetében frissítsen olyan regisztrátorra, amely valódi Registry Lock szolgáltatást kínál (a Verisign on támogatásával) .com/.net, PIR bekapcsolva .org, és olyan vállalati regisztrátorokon keresztül kínálják, mint a MarkMonitor, a CSC Digital Brand Services, a Cloudflare Enterprise, a Porkbun/Gandi/Namecheap Registry Lock szintek). Ha a Registry Lock aktív, akkor is a TLD Registry elutasítja az összes NS vagy átadja a változtatásokat, hacsak egy humánbiztonsági tiszt nem hajt végre egy sávon kívüli titkosítási/telefonos ceremóniát.
2. Közzététel CAA (Hitelesítési hatóság engedélyezése) DNS rekordok:
   • Add hozzá a CAA rekord (RFC 8659). 0 issue "letsencrypt.org" vagy 0 issue "digicert.com", plusz 0 iodef "mailto:security@yourdomain.com"). Míg a teljes DNS-zónát felügyelő támadó törölheti a CAA rekord, a CAA A rekord megakadályozza, hogy a BGP-eltérítők vagy a feltört aldomain CNAME-célpontjai jogosulatlan hitelesítésszolgáltatókat használjanak.
3. Válassza el domainregisztrátorát napi DNS-tárhelyszolgáltatójától:
   • Tartsa zárva domain regisztrációját egy nagy biztonságú trezor regisztrátori fiókban, amelyhez csak 2 vállalati tiszt fér hozzá a FIDO2 hardver biztonsági kulcsok (YubiKey) használatával, és delegáljon napi DNS-rekordkezelést (A, CNAME, TXT).
4. A lelógó aldomain ellenőrzése és megszüntetése CNAME és NS Rekordok:
   • Futtassa le a teljes DNS-zónafájl havi automatikus vizsgálatát (subzy, nuclei -t takeovers/, vagy OWASP Amass) azonosításához CNAME, ALIAS, vagy aldomain NS egy nem regisztrált külső felhő-erőforrásra vagy lejárt tartományra mutató rekordot, és törölje a DNS-rekordot mielőtt leállítja a felhőkiszolgálót.
5. Automatikus külső RDAP, DNS és CT naplófigyelés beállítása:
   • Konfiguráljon egy külső monitort (pl CertSpotter, Cloudflare Certificate Transparency Monitoring, vagy egy egyszerű óránkénti cron script ellenőrzés dig NS és whois), amely pontosan abban a percben figyelmeztet egy dedikált Slack/PagerDuty csatornára és egy domainen kívüli SMS-re/e-mail címre, amikor egy új TLS-tanúsítványt bejelentkeztetnek a Certificate Transparency-be vagy NS/MX/DS változások rögzítése.

Gyakran ismételt kérdések¶

A források ellenőrizve¶

• Kiberbiztonsági és Infrastruktúra-biztonsági Ügynökség (CISA, Egyesült Államok): Vészhelyzeti irányelv 19-01: A DNS-infrastruktúra szabotázsának enyhítése (CISA-megbízások a rendszerleíró adatbázis zárolására, a DNS/regisztrátorok MFA-jára, a tanúsítványok átláthatóságának naplózása és a DNSSEC érvényesítése) (cisa.gov/news-events/directives/emergency-directive-19-01).
• Internet Corporation for Assigned Names and Numbers (ICANN, International): Átviteli szabályzat (Regisztrátorok közötti átviteli szabályzat / IRTP), Átadási vitarendezési szabályzat (TDRP), Lejárt regisztráció helyreállítási szabályzata (ERRP) és EPP állapotkódok hivatkozása (icann.org/resources/pages/epp-status-codes-2014-06-16-en).
• Nemzeti Szabványügyi és Technológiai Intézet (NIST, Egyesült Államok): Különleges kiadvány 800-81-2, Secure Domain Name System (DNS) telepítési útmutató (csrc.nist.gov).
• Nemzeti Kiberbiztonsági Központ (NCSC, Egyesült Királyság): Tömeges személyes adatok és tartománybiztonság védelme: Registry Lock, CAA-rekordok és aldomain átvétel megelőzése (ncsc.gov.uk).
• CA/Böngészőfórum (nemzetközi): A nyilvánosan megbízható TLS-kiszolgálótanúsítványok kibocsátásának és kezelésének alapkövetelményei (4.9.1.1. szakasz: 24 órás kötelező visszavonás a domain feltörésekor) (cabforum.org).
• Internet Engineering Task Force (IETF, International): RFC 4033/4034/4035 (DNSSEC), RFC 8659 (DNS hitelesítési hatóság engedélyezése / CAA erőforrás rekord), és RFC 9083 (Registration Data Access Protocol / RDAP) (datatracker.ietf.org).

Kapcsolódó útmutatók¶

• Webtárhely-válság, migráció és biztonsági mentés visszaállítása
• Adathalászat és feltört fiókok
• MFA adathalászat és a középső ellenfél megkerülése
• Adatszivárgásra adott válasz és jelszószivárgás
• Üzleti zsarolóvírus és szerver megsértése
• SIM csere