A napokban beszélgettem egy weboldal tulajdonossal, akinek rengeteg különböző célra van domainje regisztrálva. Büszkén mesélte, hogy az átlag felhasználó (pl nem büntetés-végrehajtási szerv) számára szinte lehetetlen felfedezni, hogy ki üzemelteti ténylegesen a domainjeit, amióta van whois protection és az oldalai kivétel nélkül mind Cloudflare mögött vannak. Alapvetően ebben lehet igazság, de minden konfiguráció és elővigyázatosság kérdése. Kíváncsi voltam, hogy az állításai ellenére sikerül-e megtalálnom Őt valahogyan mégiscsak...
A feladat tehát egyszerű volt. Adott egy domain, ami Cloudflare mögé van rejtve. Ez alapján kellene megtalálni a tulajdonos szerver IP címét/adatait.
Old-school trükkök
- Whois
A whois protokollt sokan csak a domaintulajdonosok telefonkönyvének emlegetik. Én leginkább rémálomnak, mert nem igazán standardizált, és mindenki úgy formázza, ahogy szeretné. A legtöbb népszerű domainvégződés támogatja valamilyen formában és segítségével általában lekérdezhető az adott domain (/IP) tulajdonosa, az ő adatai, a domain lejárati ideje, névszerverek, DNSSEC állapot stb.
Pl.:
[steve@todo ~]$ whois google.com
Domain Name: GOOGLE.COM
Registry Domain ID: 2138514_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2019-09-09T15:39:04Z
Creation Date: 1997-09-15T04:00:00Z
Registry Expiry Date: 2028-09-14T04:00:00Z
Registrar: MarkMonitor Inc.
Registrar IANA ID: 292
Registrar Abuse Contact Email: abusecomplaints@markmonitor.com
Registrar Abuse Contact Phone: +1.2086851750
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited
Name Server: NS1.GOOGLE.COM
Name Server: NS2.GOOGLE.COM
Name Server: NS3.GOOGLE.COM
Name Server: NS4.GOOGLE.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
Logikus első lépés lehet, ha adott egy domain, és szeretnénk megtudni a gazdája elérhetőségeit, hogy lekérjük a whois rekordját, hátha szerepel valami érdekes benne. Azonban az utóbbi időben hála a jó égnek a legtöbb regisztrátor elkezdte szorgalmazni a whois privacyt. Ez a gyakorlatban azt szokta jelenteni, hogy bár a domain vásárlásakor továbbra is el szokták kérni a vásárló minden adatát, a whois rekordban maszkolt értékek szerepelnek csak és azokat csak alapos indokkal adják ki (pl bírói végzés). Érdekesség, hogy a .hu esetében lényegesen kevés infó érkezik vissza:
[steve@todo ~]$ whois sztaki.hu
% Whois server 3.0 serving the hu ccTLD
domain: sztaki.hu
record created: 1991-10-07 02:00:00
Tovabbi adatokert ld.:
https://www.domain.hu/domain-kereses/
For further data see:
https://www.domain.hu/domain-search/
Viszont a linkelt weboldalon sokkal több adat elérhető a domainről: [link]. Feltételezem, hogy a captcha miatt van, gondolom nem szeretnék, ha valaki automatizáltan gyűjtené az infókat. Cégek esetében egész sok infó látszik, viszont természetes személyek esetében már a .hu sem mutat sok személyes infót. Ne kövezzetek meg, de az első közszereplő, aki eszembe jutott OV volt, így az ő oldalával tudom demonstrálni: [link]
Nem volt ez mindig így, emlékszem, hogy 2017 környékén még simán le tudtam kérdezni bármely .hu domainről, hogy ki birtokolja és a név minden esetben szerepelt itt.
No de, vissza a történethez. Esetünkben a kapott domain .hu
végződés,. Illetve természetes személy nevére lett regisztrálva, bírói végzésem pedig sajnos nincsen, hogy kiderítsem, ki lehet a tulaj.
- IP alapú keresés
Ha már van egy domain, általában IP címek is tartoznak hozzá. Ha pedig böngészőben megnyitjuk és betöltődik valami, akkor szinte biztosak lehetünk abban, hogy IP is van a dolog mögött. Márpedig esetemben ez volt tapasztalható. Szerezzük hát meg ezeket:
[steve@todo ~]$ dig telex.hu a +short
172.67.71.160
104.26.2.85
104.26.3.85
Ha ezek egy direkt a tulajdonos által üzemeltetett szerverre mutatnának, nyert ügyünk lenne. Régen pont ez volt a bevett szokás. Viszont esetünkben ezek sajnos mind Cloudflare IP címek. Már egy whois kérés is elárulja:
[steve@todo ~]$ whois 104.26.2.85
NetRange: 104.16.0.0 - 104.31.255.255
CIDR: 104.16.0.0/12
NetName: CLOUDFLARENET
NetHandle: NET-104-16-0-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)
RegDate: 2014-03-28
Updated: 2024-09-04
Comment: All Cloudflare abuse reporting can be done via https://www.cloudflare.com/abuse
Comment: Geofeed: https://api.cloudflare.com/local-ip-ranges.csv
Ref: https://rdap.arin.net/registry/ip/104.16.0.0
Ami azért probléma, mert valószínűleg nem innen van hosztolva a tényleges weboldal. A Cloudflare csak betüremkedik a kliens és a szerver közé átjátszva a forgalmat a hálózatán. Egy IP cím rengeteg domain forrását szolgálhatja ki és számunkra ismeretlen marad a tényleges kiszolgáló elérhetősége. Más megoldás után kell néznünk tehát!
Domain történelem
Még ha az oldal Cloudflare által is van "védve", simán előfordulhat, hogy a múltban véletlenül, vagy szándékosan direktben volt kirakva az oldal az internetre. Számos, általában fizetős tool létezik, ami folyamatosan szkenneli az internetet és letárolja bizonyos időközönként többek között a domainekhez tartozó IP címeket. Nem kívánom egyiket sem reklámozni, de Googleben tucatjával találni. Néha elég egyszer véletlenül átkattintani, hogy ne menjen proxyzva a forgalom, aztán örökre ott lesz a domain történetében, hogy mégis milyen IP címről volt annak idején hosztolva.
Esetünkben sajnos erre is figyelt a domain tulajdonosa, látszólag a regisztráció pillanatától kezdve cloudflare volt a DNS szerver és egyik ilyen log adatbázisban sem találtam más IP címeket.
Aldomain evaluáció
Hát igen, eddig nem valami fényes a helyzetünk. Van viszont egy olyan eshetőség, amit szintén egész gyakran elkövetnek az oldalak tulajdonosai. Mégpedig, hogy nem minden aldomain van Cloudflare mögül proxyzva. Ennek több oka lehet, pl van, hogy kifejezetten szükség van rá, mert mondjuk nem HTTP(S)-en szeretnénk elérni a szervert, hanem valami más protokollt akarunk bekötni, legyen az játékszerver, VoIP, SSH stb. Ezeket a Cloudflare nem fogja proxyzni (egy két protokoll megoldható, de általában borsos ára lenne). Érdemes tehát körülnézni, hogy van-e bármilyen aldomain, ami elárulhatna nekünk egy szerver IP-t.
Igen ám, viszont valahonnan ki kéne deríteni, hogy milyen aldomainek léteznek egyáltalán. Erre az egyik megoldás régen az any
kérés volt:
[steve@todo ~]$ dig telex.hu any
; <<>> DiG 9.20.4 <<>> telex.hu any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20329
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;telex.hu. IN ANY
;; ANSWER SECTION:
telex.hu. 92 IN AAAA 2606:4700:20::681a:255
telex.hu. 27614 IN NS hank.ns.cloudflare.com.
telex.hu. 211 IN A 104.26.2.85
telex.hu. 92 IN AAAA 2606:4700:20::ac43:47a0
telex.hu. 211 IN A 172.67.71.160
telex.hu. 211 IN A 104.26.3.85
telex.hu. 92 IN AAAA 2606:4700:20::681a:355
telex.hu. 27614 IN NS poppy.ns.cloudflare.com.
Ezzel gyakorlatilag az összes létező rekord lekérdezhető volt a névszerverektől adott zónához, azonban ezt a legtöbb modern DNS szerver már rég nem követi, vagy máshogy implementálja, mint ahogyan az a régi RFC-ben le volt írva. Többek közt a Cloudflare sem.
Marad tehát az, hogy Google keresésekben, illetve erre specializált aldomain keresőkben nézünk utána, hogy milyen aldomainek vannak. A legtöbb ilyen kereső egy meghatározott szólistából dolgozik és végignézi, hogy van-e pl play, kubernetes, admin, webmail stb subdomain. Nem fog tehát mindent megtalálni, csak az ismertebb szavakat.
Plusz kis spoiler, de arra is lehet építeni, ha valaki adott aldomainre kért tanúsítványt. Ezek ugyanis látszanak crt.sh-n rákeresve: [link] Ezt elkerülvén érdemes mindig wildcard (*) certeket kérni.
Viszont azt fontos megjegyezni, hogy az ilyen módon megszerzett infókhoz hozzáférést elvileg a Btk. már bűnteti (egyszer legalábbis ezt álllította egy nálam okosabb személy), szóval csak olyan domaint érdemes evaluálni, amihez van jogunk. Abból biztosan nem lesz baj.
No, hát így sem találtam értelmes infót. Lehetett volna nyilván az oldalon turkálni, esetleg kint maradt git mappát keresni, CMS esetén létező usereket nézni, stb, de ezek nagyrésze szürkezónás, oldal specifikus és nem sok esély van rá, hogy be fognak jönni.
A Cloudflare paradoxon
Bár sokan pont arra használják a szolgáltatást, hogy elfedjék a tényleges szerverük, esetlegesen a saját maguk mivoltát, amit teljesen megértek, mert sajnos olyan monopóliumot alakítottak ki, hogy nincs alternatívája a dolognak és egy kicsi blog üzemeltetésénél előny, ha nem közvetlen DoS-ra kárhoztatva van kint a neten a szolgáltatás... Itt is van pár dolog, amit el lehet szúrni.
A rossz tűzfal konfiguráció
Tegyük fel, hogy valaki berakta a domaint valamelyik CDN óriás mögé, mint a Cloudflare, ddos-guard stb. Viszont amikor ezek továbbítják a klienstől a hozzájuk érkezett forgalmat a tényleges célpontnak, ami a mi szerverünk, azt is biztosítani kell, hogy ezek elérhetőek legyenek az adott szolgáltató számára. A legegyszerűbb nyilván, ha a webszerverünk figyel valamilyen támogatott porton és válaszol a beérkező kérésekre. Igen ám, de ha ez nincs megfelelően tűzfalazva, hogy csak az adott szolgáltató IP címeit engedje (Cloudflare esetén pl, ddos-guard esetén pl), akkor mi akadályozza meg a támadót abban, hogy végigscannelje az internetet, a te szolgáltatásod után kutatva? Egy misconfig és a webszervered direkt IP-vel és porttal címezve ugyanazt a tartalmat mutatja, mint proxy mögött, tehát korrelálható. Sőt, ha használsz HTTPS tanúsítványt, abban is szerepelhet a domain, így a tartalom sem szükséges a korrelációhoz, csupán egy olyan HTTPS szerver, ami elárulja a szolgáltatáshoz használt TLS certet.
Van egy pár kereső, ami egész jól specializálódott erre a felhasználásra és jól kereshető vele az ilyen. Pl: Shodan, Censys Search és Zoomeye. Néha érdemes egyébként a szervered IP címére rákeresni akár elővigyázatosságból is, biztos, ami biztos.
A szomszéd fűje mindig zöldebb
Tartja a mondás. Feltételezhetjük, hogy aki mindezen lépések egyikében sem hibázott eddig, az vagy született zseni, vagy jó leírást követett, vagy nem ez az első domainje. Amikor regisztrálunk egy fiókot Cloudflare-re, majd felveszünk egy domaint, akkor kapunk egy névszerver párost, pl bob.ns.cloudflare.com
és lola.ns.cloudflare.com
, amikre át kell állítanunk a domaint, hogy aktiválódjanak a Cloudflare szolgáltatásai. Hogy ez miért van így, arról bővebben konkrétan ők írnak. Bár minden névszerver ugyanarra a fizikai anycast IP címre mutat, tehát elérésben nem lesz különbség, mégis egy piszok nagy listából kapsz 2 névszervert. Állításuk szerint azért csinálják, hogy ne tudja bárki beregisztrálni ugyanazt a domaint Cloudflaren és elvenni a jogát a jogos tulajdonosától. Hiszen a domainhez tartozó névszervereket csak a tulajdonos tudja állítani, Cloudflare fiókban domaint regisztrálni pedig bárki tud.
Azt azonban kevesen tudják, hogy ez a páros nagyon ritkán változik. Sokáig azt hittem, hogy per fiók örökre szól. Ezen hibajegy alapján azonban ez sem fix, de a gyakorlat nálam azt mutatta, hogy esetemben pl sosem változott.
Remek, mivel a névszervereket pedig simán le tudjuk kérdezni minden élő domain esetében (ha tartozik hozzá):
[steve@todo ~]$ dig telex.hu ns +short
poppy.ns.cloudflare.com.
hank.ns.cloudflare.com.
Ha tehát végig tudnánk scannelni az összes létező Cloudflare mögötti oldalt, akkor jó eséllyel lenne egy egészen pontos listánk arról, hogy milyen más domainjei lehetnek az illetőnek ugyanazon Cloudflare fiókhoz kötve. Ugyan nem feltétlen egyedi a pár, tehát lehet még X user ugyanazzal a névszerver párossal, így is eléggé leszűkítettük a kört sokszor akár száz alatti domain mennyiségre.
És lehet, hogy az általunk eredetileg birtokolt domain jól be van védve, simán lehet, hogy ugyanazon a fiókon van egy kevesebb odafigyeléssel telepített darab is. Anno volt egy érdekes tool, a Crimeflare, ami valószínűleg ezt a trükköt használhatta ki domain korrelációra. Akkor le voltam nyűgözve, hogy ez hogy lehetséges, de nem esett le, pontosan hogy csinálják. Beírtam a domaint és kidobta az összes másik domaint, ami szerinte ugyanazon fiók által lehet hosztolva. Sajnos azóta le lett véve az oldal, illetve a hasonló kezdeményezéseket is lelőtték jogi problémák miatt: [link].
Ezen a ponton csak az a kérdés, hogy honnan szerezzük meg a világon létező összes domain listáját. Mivel nem vagyok se TLD tulajdonos, se nagy DNS szerver operátor, se ki tudja milyen állami szerv, akinek valahogy kiadják a domainek listáját, marad az, hogy publikusan elérhető infó morzsákból próbálok használható infókat kinyerni. Iterálhatnék keresőmotorokat, domain adatbázisokat stb. De semmi nem garantálná, hogy az összes aktív Cloudflare mögötti domain ott legyen, ami engem érdekel. Mi lehet hát a megoldás?
A Certificate Transparency Log
Minden Cloudflare domain automatikusan kap egy TLS certet, amit a Cloudflare készségesen kiállít számunkra azonnal, a hozzáadást követően. Ha akarjuk, ha nem. Talán Enterprise konfigurációban ki lehet kapcsolni, ezt sajnos nem tudom. Free/pro csomagban én nem jöttem rá hogy lehetséges. És tök érdekes, hogy egyre több decentralizált trust (megbízhatóság) alapú megoldás létezik, a TLS viszont a mai napig centralizált. Bízunk egy tucat cert authorityben, hogy jól végzik a dolgukat, nem törik fel/zsarolják meg őket és ezáltal nem fog tudni illetéktelen a nevünkben olyan tanúsítványt kiállítani, amiben aztán az egész világ összes eszköze vakon megbízik.
A történelem során azonban már történt hasonló incidens, 2011-ben a DigiNotart törték fel például és állítottak ki többek közt Google szolgáltatásokra saját tanúsítványokat, hogy aztán le tudják hallgatni az irániak böngészését. Nyilván ezeket a kulcsokat utána visszavonták, azonban akkor még nem létezett rendszer, ami ezt jelezte volna, így a támadóknak bőven volt ideje garázdálkodni.
A Google erre válaszul kidolgozta a certificate transparency log megoldást, ami azt hivatott jelezni a weboldalak jogos tulajdonosai számára, hogyha valakik egy tanúsítványt állítottak ki az oldalukra. Pár nagyobb szolgáltató üzemeltet saját logot, ahova elvileg kötelezően bekerül az összes általuk ismert, kiállított cert. A protokoll támogat lekéréseket és hozzáadásokat is egyaránt.
Mivel maga a Cloudflare is üzemeltet egy ilyen logot, úgy éreztem megtaláltam a jackpotot. Ebben ugyanis benne lesz az összes éppen aktív Cloudflare által/közvetve rajta keresztül kiállított, még érvényes cert.
Igen ám, de sosem csináltam még hasonlót, azt se tudtam hogy működik a dolog. Korábban már használtam pl a crt.sh oldalt, ami egy piszok profi erőforrás és gyakorlatilag pont ezekből a logokból épít kereshető adatbázist. Tökéletes cucc egyszerű keresésre, de nekem kicsit komplexebb keresésre volt szükségem és elég instabil az oldal bonyolultabb lekérdezéseknél, ami nem csoda, mert rengeteg adatban kell keresnie.
Elkezdtem tehát értelmezni a log formátumot és hamar rájöttem, hogy az API nem bonyolult, egy sima HTTP REST API van kirakva, amit lehet kérdezgetni. Tök jól el van magyarázva a legtöbb oldalon egyébként, hogy Merkle treekkel van megoldva az adatok tárolása, ami gyakorlatilag olyan szempontból lényeges nekünk, hogy az amúgy egymástól független certeket nem csak belehányja az adatbázisba a szerver amikor beérkeznek, hanem számol egy hasht és ezáltal minden adat egymásra fog épülni. Ha kitörölnek/módosítanak egy régebbi cert logot, akkor a fa szétesik és tudjuk, hogy manipulálták az adathalmazt. Hacsak nem törik meg a matekot, a hozzáadáson kívül nem tudja még a szolgáltató sem manipulálni azt az adatot, ami egyszer már bekerült.
Ez tök jól el volt magyarázva tényleg mindenhol, csak olyan egyszerű kérdésekre nem kaptam választ pl, hogy hogy értelmezzem ezt a táblázatot az oldalukon:
Az a rész érthető, hogy shardolva tárolják az adatokat évekre bontva, de elsőre egyáltalán nem volt világos, hogy miért van 2025-höz szinte ugyanannyi cert rendelve, mint 2024-ben összesen, amikor csak januárt írunk. Ha arról lenne szó, hogy betöltik a korábbi adatokat is a friss shardba, akkor érteném a dolgot, de akkor meg mit keres 2026 alatt már egy csomó cert. Aztán szépen lassan leesett, hogy valószínűleg arról lehet szó, hogy minden certet annak lejárati éve szerint rendeznek. Tehát ha én generálok egy Let's Encrypt certet 3 hónapra, akkor az a 2025-ös shardhoz fog kerülni. Viszont mivel a max elfogadható certek élettartama a DigiCert szerint 398 nap, így világos, hogy miért van jó pár cert már a 2026-os shardban. Az is világos, hogy miért így tárolják, hiszen elsősorban a domain tulajdonosokat a még érvényes certek fogják érdekelni. Ez megmagyarázza azt is, hogy miért tárolják mindig csak az utolsó pár év adatait. A lejárt certek nem igazán érdekei senkinek.
Amit még nem teljesen értek, az az, hogy 2024-nél miért írja még mindig azt, hogy 30 cert/óra van még mindig generálva átlagosan itt:
Meg mi lehet vajon ez az unsubmitted érték...? Ha esetleg valaki ezekre tudja a választ, azt nagyon szívesen olvasnám kommentben!
De igen, az ötlet jó, hogy bárki megnézheti, milyen certek lettek kiállítva adott domainre, sőt vannak szolgáltatások, amik ezeket 0-24 monitorozzák és alertet küldenek, ha valaki kiállít a nevedben egy certet.
Viszont így magával hordoz egy olyan hátrányt is, hogy minden domain, amire lett cert kiállítva, az publikus lesz. Hiszen amúgy hacsak valaki nem botlik bele egy domainbe keresés útján, nincs mód protokoll szinten tudtommal lekérdezni bárkinek a frissen regisztrált domainjeit.
Ahogy így kutatgattam, belebotlottam a leírásukba, ami említi, hogy egy golang nyelven írt eszköz, a Trillian van használva általuk az API kiszolgálására. Innen eljutottam a cert transparency go projekthez, ami még egy klienst is tartalmazott. Így nem kellett azzal se foglalkozzak, hogy a leaf certeket kézzel dolgozzam fel, vagy foglalkozzak a rate limittel.
Egyébként az API is elég egyszerű, az URL formátum: https://ct.cloudflare.com/logs/nimbus2024/ct/v1/get-entries?start=0&end=1000
A válasz pedig JSON, csomó bináris adattal Base64 enkódolva. Aki esetleg kézzel szeretné feldolgozni ezt, vagy érdekli részletesen a mikéntje, az ebben az RFC-ben megtalálja mindenre a választ.
Nekem viszont tökéletesen megfelelt a library, így azt kezdtem el használni.
A terv az volt, hogy végigiterálok az összes rekordon, hiszen ezt sajnos nem tudom elkerülni. Viszont mielőtt minden egyes domainre küldenék egy DNS kérést, előtte előszűröm, hogy csak .hu címekkel kelljen foglalkozni, mivel a keresett többi domain is .hu
végű lesz. Ezen kívül megnéztem, milyen tanúsítványkibocsátókkal dolgozik együtt a Cloudflare (forrás) és arra jutottam, hogy elég a Let's Encrypt, Google Trust Services, SSL Corp és Sectigo organizációtól kiállított certeket figyelembe venni.
A toolt először nem párhuzamosra írtam meg, tehát ezresével szedte a certeket. Ez lassúnak bizonyult, ezért megírtam többszálasra, viszont így meg rate limitekbe futottam bele viszonylag hamar. A végleges tapasztalat viszont az, hogy 5 workerrel és átlagban 10 kéréssel per másodperc stabilan fut. Így átlagban 140 Mbit/s adatforgalmat visz el folyamatosan, amíg nem nézte végig az egész adathalmazt.
Aztán belefutottam abba, hogy a tradicionális DNS kérések UDP 53-as porton nem voltak elég megbízhatóak, timeoutoltak és párszor voltak érdekes elveszett csomagok is. Nomeg a DNS kiszolgálóm is elszenvedett egy nagyobb kimaradást pont a scraping közepette, ezért jött az ötlet, hogy a Cloudflare DNS over HTTPS szolgáltatását fogom erre a célra használni. Egyelőre stabil és mivel HTTP-t használ TCP-n keresztül, mindig kapok valami értelmes választ (vagy ha nem, akkor nagyobb eséllyel tudom mi a gond), illetve akár a keepaliveot is meg lehetne oldani, hogy egy kapcsolattal menjen az összes kérés és ne kelljen minden kéréshez újranyitni az egész TCP sessiont.
A kész tákolmányt pedig Githubon publikáltam.
Az eredmény pedig magáért beszél. Sikerült megtalálni a kolléga összes másik domainjét, ahol az egyik konkrétan a privát portfóliójához vezetett, illetve találtam olyan domaint is, amely direktben a szerver IP címéhez vezetett. Kicsit lefagyott szegény.
Mi a tanulság?
A magam részéről bizton állíthatom, hogy a nulláról rengeteget tanultam a projekt kapcsán a CT logokról és kicsit sikerült talán emészteni, hogy mennyire összetett folyamat egy megbízható tanúsítványkibocsátót működtetni. A Cloudflare pedig messze nem mindenható és a sok termékével, meg absztrakció mögé rejtésével simán kelthet hamis biztonságérzetet.
Ha mindenképp CF-et használsz és nem szeretnéd, hogy kitett legyél ennek a jelenségnek, akkor jelenleg kb az a megoldás létezik, hogy minden domainhez új fiókot csinálsz... Más megoldást sajnos nem tudok.
Hátha egyszer implementálnak egy NS rotálást.