Názory k článku Výpadek Facebooku způsobila chyba v interním nástroji při rutinním zásahu

Když chcete něco rozbít tak, aby to pocítila podstatná část internetu, zaměřte se na BGP nebo DNS. Fajnšmekři to zkombinují dohromady ;-)

A to by mi pak nefungoval ani Microsoft 365 nebo Google Docs? Naštěstí jsou to velké zaběhnuté značky, takže pravděpodobnost takového problému je téměř nulová... :-)

Někomu to nefungovalo, protože byl zahlcený DNS resolver, který používá. Pravděpodobnost je téměř nulová, ale zase se to násobí tím téměř nekonečným počtem uživatelů :-)

To bylo z mé strany jen takové poťouchlé rýpnutí proti trendu provozovat všechno v externích cloudech, třebaže ty externí cloudy mají jinak celou řadu výhod. Myslím, že takové incidenty jsou prospěšné k tomu, aby si koncoví uživatelé uvědomili, jestli je skutečně nutné všechno "outsourcovat".

No jo, záložní postupy jsou dobrá věc, ale jestli opravdu fungují, poznáte až při skutečné havárii.
Tak aspoň našli chybu ve svých kontrolních mechanismech a můžou ji opravit.

Pochopili jste to s tim pristupem do budov? To bylo kvuli BGP?

Pochopili jste to s tim pristupem do budov? To bylo kvuli BGP?
Nepochopil, ale představuji si to tak, že nějaký terminál u vstupu do budovy chtěl verifikovat uživatele služby Facebook a tak se jako vždycky dotázal nějakého Facebookového serveru, jenže na něj se ztratil kontakt.

Zrušili si všechny spoje ve vnitřní síti a DNS. Stačí, aby ten přístupový systém jenom někde přes IP síť (a možná i na základě DNS názvu) ověřoval, zda je dotyčný ještě zaměstnancem nebo má práva k přístupu do dané místnosti. Nejspíš to bude odolné proti výpadku části interní sítě, ale ne když tu interní síť zrušíte celou.

nevím jak to mají přesně v FB, ale mohu říct zkušenost z našich DC v TIER III/IV.

Přístup do sálu a do technické části je chráněn velkými protižárními ocelovými dveřmi, pro jejich otevřením se musím prokázat vstupní kartičkou a případně nějakou biometrií, to se kontroluje po IP síti s IDM provozovatele (pokud jim spadla celá interní síť, nemohli vůbec otevřít dveře). Samotný sál a ani technická část nemá žádná okna, žádné jiné cesty dovnitř, nouzové otevření je možné pouze zevnitř (násilně jen s těžkou technikou, autogenem a sbíječkou - máte někdo zkušenosti jak se to řeší?)

Druhý problém může být zabezpečení samotných serverů/routerů, bez karty (opět ověřena online přes IP síť) se nedostanu do klece/uličky, kde jsou fyzicky umístěny (to se dá vyřešit nůžkami a kladivem). Jakmile jsem fyzicky u serverů, potřebuji se na terminálu přihlásit, tady opět probíhá ověření proti lokálnímu KMS/IDM serveru (nemám běžně žádné heslo na papírku, spojení mohlo být také rozpadlé kvůli zhrození BGP tras).

Facebook díky své globálnosti měl očividně shodnou síť pro interní systémy, pro správu a pro lidi a oddělené to měl pouze SW, jakmile se mu rozpadla IP L2 síť, byl slepý, hluchý a bez rukou. Běžně se tohle řeší přes tzv. OOB (https://en.wikipedia.org/wiki/Out-of-band_management), kdy mám síť pro správu plně oddělenou.

K článku, podle toho co psali na Cloudflare a co jsem viděl na stat.ripe.net, odstranili přes BGP veškeré trasy a ne jen ty pro DNS.

Facebook pise
"Our primary and out-of-band network access was down"
takze asi maju nejaky nefunkcny out-of-band.

Mam skusenosti s velkou firmou a vsade bolo aj nudzove otvaranie zvonka. Chcelo to pristupovy kod ktory malo par ludi a pustilo by to alarm (pri dverach stale strazila ochranka), ale islo by to. Firma hostuje u seba iba svoje servery, takze fyzicky pristup zo salu nepotrebuje nic viac. U tej firmy bolo mozne aj offline prihlasenie a to rovno na roota. Druha vec je, ze by tam musel prist aj niekto, kto by to vedel opravit.

"Jdu roubovat jabloně. Vylezu na strom, podám si štěpy, ale než začnu s tím roubováním, ještě uříznu tuhle suchou větev, na které sedím."

A proč to vypnulo část Vodafone, nebo přesněji exUPC? Navíc nejen v ČR.

Mluví se o přetížených DNS. Náš domácí router od exUPC bohužel prošel restartem, než jsem se pořádně rozkoukal a pak mu trvalo cca 40 minut, než na něm naběhlo webové rozhraní dostupné z LANu a pak cca dalších 20 minut, než dostal adresu z DHCP na WANu. To mi připadá trošku moc na nefunkční DNS.

I Vodafone.

Klasicky, DNS dotazy na facebook (a jiné služby) nekončily v cache, ale resolver je okamžitě dotazoval do internetu přes upstream zahraniční linku, tam nedostal žádnou odpověď (protože trasa na IP adresu neexistovala), výsledný SERVFAIL stav necachoval a vrátil klientovi. Klienti byli neodbytní a ptali se pořád znovu a znovu.

Výsledkem bylo vytížení DNS resolverů, obrovský provoz na vnitřní síti a zahlcení upstreamu, to vedlo postupně k různým náhodným komplikací napříč celou infrastrukturou, protože vše bylo přetížené, začaly se spouštět náhodně failover procesy atd.

Problémem byla tedy nevhodná konfigurace a nedostatečná nadimenzovanost infrastruktury.

Se mi nějak nezdá, že by dotazy na domény FB udělaly takový provoz, aby to vyřadilo z provozu síť, která je dimenzovaná na koncové klienty v rychlostech v řádů stovek MB až 1GB. Kdyby byl problém jen v té DNS, tak beru, že prostě padla. Ok, to se stane, ale já nedostával ani adresu z DHCP.

já nedostával ani adresu z DHCP.
což by znamenalo, že by Vám nefungovala ani komunikace s ostatními zařízeními v domácí síti, například tisk na síťové tiskárně (pokud nemá pevnou IP nebo jiný mechanismus nalezení). Z takové závislosti na někom cizím bych asi nebyl nadšen a správu domácího routeru takovým poskytovatelem bych považoval za slabinu.

Nikoli. Nedostal DHCP adresu od ISP (Vodafone ex-UPC). To je něco jiného než přidělování IP adres zařízením v domácí síti z DHCP serveru na domácím routeru.

Vtip a spinave tejemstvi je, ze sit neni zarizena "koncové klienty v rychlostech v řádů stovek MB až 1GB"
Vemte klidne 100mbps, vynasobte poctem klientu a porovnejte s pripojenim operatora do vnejsiho sveta.
Bezne se predpoklada pouze castecne vyuziti pripojek, ktere navic budou castecne obslouzeny uvnitr site (napriklad O2TV v O2 siti a podobne).
Pokud se vyskytne nejak koordinovany pozadavek velkeho poctu klientu mimo sit operatora, ma problem.

To není žádné špinavé tajemství, je to veřejně známá, logická a samozřejmá věc. Takhle fungují všechny sítě – elektřina, plyn, voda, kanalizace, telefonní síť, silnice…

ISP vám velice rád dodá garantovanou kapacitu v tranzitu. Akorát vás ten humor přejde, až vám přijde faktura.

Jinak kdyby zkusili všichni klienti operátora využít v jednom okamžiku rychlost na maximum, narazí to už mnohem dřív na limity přístupové sítě a na limity sítě samotného ISP.

Mohu odkázat na oficiální tweet Vodafonu https://twitter.com/Vodafone_CZ/status/1445080972232466432

Sice VF nabízí lidem rychlosti v takových řádek, ale podívej se kolik má linek do NIXu a kolik jich má do zahraničí, to není vůbec moc a to se dá rychle přetížit, zejména, když chybějícím BGP routám na lokální cache servery facebooku to najednou končí vše v upstreamu.

Pokud jsou DNS servery pod masivním provozem a stejné používáš i interně, začne ti to celé tak trochu zlobit, někde je timeout 3s, někde je 10s. Začne se vše samo přepínat, překonfigurovávat (nezapomeň, že máš stovky tisíc koncových stanic, které mají autokonfiguraci). Holt je to varianta, na kterou se nemyslelo, neprojektovala se a nikdo nečekal subjektivně (stejně jako ty), že to prostě může celé neudržet.

Já si to představoval tak, že když spoustě lidem přestal fungovat FB a možná teda i některé další stránky, restartovali si modem/router. (ostaně to je první, co vždy poradí, restartujte si modem). No a když si router restartuje třetina sítě, nezvládne to ani přidělovat adresy. :)

Nezapomeňte, že facebook není jen ta stránka kde někdo háže svoje fotky oběda (nebo k čemu se vlastně dnes používá), je tam i verze "intranetu" pro firmy, messenger, a pak různé sledovací prvky, které má v sobě snad 80% stránek, pak různé "like" tlačítka, různé komentáře, spousta webů má deska možnost přihlášení přes facebook, atd. Otevřete si pár webů (bez adblocku a podobných) a nejednou máte tolik trafficu na facebook DNS, že se ani nestačíte divit:)

Kdyz necham zapnuty prohlizec (cca 30-50 zalozek) a nic kompu vubec nedelam. Tak za 24hodin vygeneruju 1GB trafficu na servery facebooku.

Prakticky vsechny stranky s reklamou nepretrzite neco bonzuji neco na servery FB. Taky je dost dobre mozny ze existuji strelci kteri ze svych stranek stahuji JS primo z facebooku.

Což mě přivádí k lákavé myšlence.
Jak bych mohl zakázat veškerou komunikaci mého počítače / domácí sítě, na všechny služby a servery, které vlastní Facebook, Inc.

Řešit to na úrovni DNS / hosts.
Jak blacklistovat všechny jejich domény a IP adresy?

(Zkoušel jsem hledat nějaký užitečný odkaz ale je to zaplevelené neužitečnými odkazy.)

Resenim je nejaky moderni chytry firewall - napr. Fortigate od Fortinetu - naklikate jedno pravidlo - v destination vyberete facebook, date deny a mate vystarano... ale je pravda ze pro domaci pouziti je to drahe (kupujete hw tak k tomu licence obsahujici ruzne databaze - antivirove, antispam, IPS signatury, seznamy IP adres (botnety, ip adresy velkych sluzeb,....)

To už se tu řešilo - pomocí DNS nasazením Pi-hole, pomocí IP skriptem a pravidly v Mikrotiku.

Na DNS nejspíš budou závislé i interní systémy. Pokud ty používají tu veřejnou DNS infrastrukturu… Navíc tím, že nebyly DNS servery vůbec dostupné, mohlo jít víc DNS provozu i do tranzitu. Osobně mi připadá divné, že by to bylo tak významné, že by to takhle viditelně ovlivnilo provoz – ale mohou mít nějakou vyhrazenou kapacitu pro interní provoz, do kterého mohou spadat i dotazy z jejich DNS serverů. A to už by vyčerpat mohli.

Problém skoro jistě nebyl způsobený přímo tím, že byl nedostupný Facebook, ale ty problémy s DNS přetížily nějakou část infrastruktury. Což se pak snadno může kaskádovitě šířit do dalších systémů.

Problém skoro jistě nebyl způsobený přímo tím, že byl nedostupný Facebook, ale ty problémy s DNS přetížily nějakou část infrastruktury. Což se pak snadno může kaskádovitě šířit do dalších systémů.

přesně tak, střelba do vlastní nohy. Ony se pak ty problémy násobí.

A může mi někdo osvětlit, proč kvůli výpadku Facebooku prakticky nejela konektivita českého Vodafone?

Protože zmizely přímé peeringové spoje, poslali operátoři provoz do Facebooku přes zahraničí (upstreamu), které je univerzální, ale také dimenzované na menší provoz. Tím se ucpaly zahraniční linky a popadaly další spoje.

Navíc se zahltila infrastruktura DNS resolverů, které nekešovaly chybu typu SERVFAIL a ptaly se dokola znovu a znovu po neexistujících autoritativních DNS serverech. Všechno je to řešitelné, ale je třeba na to být připravený. Předpokládám, že se z toho incidentu operátoři poučí a příště ho zvládnou lépe.

Diky za zrozumitelne, ale pritom velmi podrobne vysvetleni. Takhle si predstavuji odborne clanky.

Jen trochu stranou, kdyz jsem to cetl, nemohl jsem si nevzpomenout na Sefe, me se asi neco nepovedlo...

Svět se vrátí do normálu a vývojáři budou zase vzácnější než kamioňáci v Británii. :-)

No coby, začnou se zase víc číst manuály a manuálové stránky :-) (a případně další vyhledaný obsah v článcích různě po netu). A pak samozřejmě taky to, co psal Michal Kubeček.

Zajímavé je, jak podobný je tenhle výpadek loňskému výpadku Google.

Ve Facebooku vznikla chyba v nástroji, který má řídit kapacitu v globální síti Facebooku. V Googlu byl problém s nástrojem, který řídí kapacitu jednotlivých služeb (hlídá počty požadavků). V Googlu omylem pro autentizační službu nastavili limit požadavků na nulu; ve Facebooku chtěli zjistit kapacity globální sítě, místo toho se všechna spojení zrušila (dost možná nastavili jejich kapacity na nulu). V obou případech mají nad těmito nástroji audit nebo testování, to ale v obou případech obsahovalo chybu a chybné nastavení/příkaz propustilo. V Googlu se to přímo týkalo autentizační služby, která měla najednou limit na počet požadavků nastaven na nulu, takže se nešlo nikam autentizovat – tudíž ani systémy Googlu a správci se nemohli autentizovat vůči jiným systémům a provádět změny. Zaměstnanci Facebooku se také nemohli dostat k serverům, protože interní síť nefungovala. V obou případech se tedy podařilo problém vyřešit až když se správci dostali fyzicky do datacentra – Googlu stačilo dostat se do jednoho, kde navýšili kapacitu autentizační služby, Facebook se zřejmě potřeboval dostat do více nebo možná do všech datacenter.

Zdá se, že nástroje na hlídání přetížení systému jsou dobrý sluha, ale zlý pán.

Čím komplexnější systém je, tím komplexnější chyby ho sundají, a tím hůř se tyto chyby dají detekovat dopředu a testovat. Existuje teorie systémů, která jestli si vzpomínám tvrdí, že jediným řešením je dělení systémů na co nejvíc izolované subsystémy s jednoznačně definovaným rozhraním. Což jde proti efektivitě údržby i proti efektivitě vývoje, i proti efektivitě provozu.

Nebo na to jít jinak - jednoduché věci se nerozbíjejí, a pokud ano, tak se dají snadno opravit.

Poleno [pod redakčním dohledem]: On to není „tento scénář“ – těch scénářů, kterými mohlo dojít ke stejným důsledkům, jsou tisíce. A není to „stejné řešení“. Jenom se to prostě shodou okolností týkalo podobných věcí. Nebo pokud jste scénářem myslel „nemůžu se dostat do datacentra“, tak evidentně na to obě společnosti nouzový postup mají a fungoval. A asi nemá moc smysl snažit se ten postup urychlit a tím jej učinit méně bezpečným. Spíš se budete snažit, abyste ten postup používal méně často.

Tohle je vzdy balance mezi efektivitou a jednoduchosti. A nema viteze.

Zdeno Sekerák: No hlavně některé věci se prostě jednoduše dělat nedají.

Já si myslím, že dost věcí se dá dělat jednoduše, jen se včas musí říct, že se vymýšlí pí****, a že je lepší jít na to jinak. Zrovna v IT, kde ta komplexita není na první pohled vidět, a kde každý obchodník umí prodat všechno a každý programátor umí všechno naprogramovat a každý architekt všechno navrhnout je tohle extra průser. Věci, které se nedají jednoduše udělat jsou obvykle blbě vymyšlený nebo nedomyšlený.

Některé věci se třeba ani jednoduše dělat nechtějí.

Naprosto perfektní článek. Díky!

taky dekuju za skvely clanek, Petre