Hirdetés

A TLS, mint OSINT (nyílt hírszerző) eszköz

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ó

The most pointless sign I've ever seen : r/funny

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. :B

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.

  • Mr Dini

    addikt

    LOGOUT blog (1)

    válasz Pikari #9 üzenetére

    Ez pl a Hetzner volt. Redditen írták, hogy ritka eset (általában nem tartom kredibilisnek a redditet, de ez most egy repr. komment): [link]

    Velem viszont sajnos megtörtént. Azóta lehet fejlődtek, nem tudom. Ez még COVID előtt volt. Sajnos túl jó konfigokat adnak ár/érték arányban, hogy váltsak és a szimmetrikus gigabit uplink is pozitív (ha épp nincs nullrouteolva).

    Egyébként elfelejtettem megköszönni a gondolatokat, köszi a véleménykifejtést/fejtágítast! :R

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Pikari

    addikt

    válasz Mr Dini #8 üzenetére

    Sok szervertermi szolgáltatónak annyi a szolgáltatás, hogy bedug egy kábelt valahova, és akkor ő a szolgáltató, meg valami gagyi szaros 30 éve elavult amcsi varázsfelületen betanították őket, hova kattintsanak a dolgokért, és ennyi, nincs meg a mögöttes kútfő. Így aztán te hiába is állítanád be jól a dolgokat, ha maga a szolgáltató már nem állít be semmit a hálózati eszközein, így a szolálgtató főbb eszközeit úgy tudják terhelni, hogy mire hozzád megérkezne az adatcsomag, addigra az irányodba jövö link már általánosságban eltömődik. (eleve nevetséges, mert ha nullrouteolni tudják, akkor tudniuk kellett volna szűrni is source alapján). Tudni lehet, hogy melyikek voltak ezek a gagyi lovagok, hogy biztosan elkerüljem őket?

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Mr Dini

    addikt

    LOGOUT blog (1)

    válasz Pikari #7 üzenetére

    Engem egyszer térdeltek le úgy, hogy a hosztingnál gigabites portot fizettem, amit teljesen elszaturáltak, aztán a szolgáltató küldött egy emailt, hogy akkor most egy ideig nullrouteolják az összes forgalmat, ami a szerverem felé irányul, mert nem tudnak ennyi adattal mit kezdeni. Akkor volt az, hogy kerestem alternatívát. Hamar rájöttem, hogy nem vagyok szolgáltató ahhoz, hogy anycast címeim legyenek, nem akarok /24-et venni minimum, hogy egyáltalán legyen, DNS szervert sem akarok üzemeltetni, a BGP-hez se értek (és egyedül nem is biztos, hogy kéne erőltetni), szóval marad az, hogy keserűen ugyan, de bekötöttem CF mögé mindent. Azóta nem igazán kapok semmi támadást. A JS challenget élből tiltom, csak kínára szoktam rakni. Szomorú, de ez van. És sokan vannak hasonlóan, mint én. One man projekt, ami nem feltétlen termel hatalmas hasznot, aztán marad az, hogy az ember vagy megtanul mindent és mélyen a zsebébe nyúl, vagy megy egy AWS-hez, ahol megoldják neki talán olcsóbban a skálázást, vagy megy Cloudflarehez, ami meg megoldja ki tudja miért cserébe...

    Ha egyébként tud bárki jobb alternatívát, ami kifizethető kisebb projekteknek is, szívesen veszem a javaslatokat!

    [ Szerkesztve ]

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Pikari

    addikt

    válasz Mr Dini #6 üzenetére

    Nekem évtizedek óta lóg ez-az a neten. De a legdurvább támadás, amit folyamatosan 4 éve kapok 24/7, az az ftp szerverem ellen irányul, ami eleve nem is hostol semmit, hanem azon keresztül szoktak nekem ügyfelek anyagokat feltölteni, ezért van mindig online, és konkrétan üres. Ez tehát nem ddos támadás, hanem egy szótáras jelszótörés, 2 próbálkozás egy ip címről (2 másodperc alatt), aztán ip cím csere egy látszólag teljesen random ip címre. Főleg kínai és amerikai ip címekről. De ez nem célzott támadás, hiszen nincs semmi, amit ezzel elérhetnének. De már négy éve megy, és na az iptables ez ellen tényleg nem jó.

    Ha ddos kölyköt haragítasz magadra, az általában favágó egyszerűségű támadásokkal tolja, valami vérpistike szintű szkripttel, amin nem módosít semmit, pl megpróbálja a tcp protokollt támadni valamivel (iptables rate limit megoldja), esetleg valami faék egyszerűségű szkript betölt egy-egy generált oldalt, hogy elzabálja a cpudat és ramodat (iptables rate limit ezt is megoldja).

    Az ICMP-t már régóta tiltom minden eszközömben, hogy legalább azon keresztül ne tudjanak semmit megtámadni.

    De lehet, hogy csak én vagyok szerencsés, hogy botnet kaliberű szereplő még sose támadott meg, de ha esetleg megtámadna, akkor se hiszem, hogy a cloudflarehez futnék könnyes szemmel, hanem inkább valami nálam okosabb emberrel konzultálnék, akivel át tudom szakmailag akkurátus módon beszélni a támadás formátumát a megfelelő védekező stratégia kialakítása érdekében.

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Mr Dini

    addikt

    LOGOUT blog (1)

    válasz Pikari #5 üzenetére

    Mondanám, hogy igazad van, de én is csak félinformatikus vagyok, nem lenne hiteles. :DDD

    Cloudflarenek pont a JS alapú challengét utálom nagyon én is, amiről te is írsz. Szerintem a legnagyobb probléma vele, hogy konkrétan úgy lett megírva benne a böngésző ellenőrzés, hogy fogták az ismertebb böngészőket, kerestek bennük egyedi működési mintákat és ezekkel detektálják, hogy valóban az a böngésző van-e használva, ami a User-Agentben kimegy a szerver felé. Elvileg ez GDPR kompatibilis, szóval sok adatot nem visznek ki, aztán persze ki tudja. Viszont új böngészőnek így esélye sincs belépni a piacra... Nomeg nem kellemes egy JS-ben implementált virtuális gépet futtatni, ami ki tudja miket csinál ahhoz, hogy hozzáférj a kedvenc hírportálodhoz pl.

    Azzal a kevés tapasztalattal, amit hobbi OSS projektek hosztolása alatt felszedtem, nekem is az volt a tapasztalatom, hogy megfelelően üzemeltetni nehéz. Hibákat keresni sokkal egyszerűbb, mint jól csinálni valamit (erről szól a cikk is). Viszont egy hobbi usernek is lehetnek pl olyan igényei, hogy csinál egy blogot, vagy kirakja az otthoni homeassistantot az internetre, aztán nem feltétlen lesz kapacítása saját CDN-t építeni, meg máshova routolni a forgalmat, ha épp DDoS-olnak. Iptables szépen megvéd egy vérpistike ellen, aki elkezd DoS-olni, de amint betalál egy botnet/VPN/proxy halom és elszaturálják a linked, nem tudsz mit csinálni. Én se találtam eddig jobb megoldást, ezért maradt a Cloudflare. Nem örülök neki, hogy egy monopólium kezében van az oldal sorsa és adatai, de saját zsebből és tapasztalattal nem tudnám ugyanazt hozni.

    Én úgy látom egyébként, hogy sajnos ha akarjuk, ha nem, egyre többen térnek át cf-re. Telex is azt használ pl. Amerikában a szavazásokat CF-en át nyomták... Egyszerűen annyi bandwidth van a kezükben, amivel egyszerű ember álmodni sem mer.

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • Pikari

    addikt

    tanulság:

    1. nem kell mindenféle szellemileg toprongyos, leépült, iptablest beállítani képtelen félinformatikusnak szervert hostolnia, aztán nem kell cloudflare

    2. ne egy szociális kapcsolatokra és kommunikációra képtelen trollkodó autista remegő oposszumtetem legyen az, aki hostolni akar, aztán akkor nem kell cloudflare

    én lábon kihordott agyhalált kapok attól, amikor meg akarok nyitni egy weboldalat, aztán elkezd pörögni a cloudflare ddos protection fél percig, hogy ellenőrizni kezdje, hogy nem -e esetleg túlterhelni akarom -e az oldalát -e, annyi idő alatt, ami alatt el is tudtam volna intézni ott, amit akartam.

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • philoxenia

    MODERÁTOR

    válasz UnA #1 üzenetére

    Már a kannás borok is netre vannak kötve? :Y
    Mondjuk azokat nemigen lehet hekkelni, mert megölik a vírust... ;]

    Menczer érvelési stílusához nekem is jogom van...

  • Mr Dini

    addikt

    LOGOUT blog (1)

    válasz UnA #1 üzenetére

    Hmm, hát sokféle következtetésre számítottam itt a komment szekcióban, de erre pont nem. :DDD

    Viszont el kell ismernem, hogy teljesen jogos. Azt hiszem ezzel senki se tudna boldogulni.

    Minden egér szereti a sajtot... Kivéve a Logitech G305.

  • UnA

    Korrektor

    Ezek szerint továbbra is a legjobb megoldás a hajléktalanok alkalmazása egy kannás borral.

Még van hozzászólás! Tovább