elitemadzone.org - Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

Milan Kragujevic
Direktor IT sektora u državnoj firmi
Firma 1989
Klenovnik

Član broj: 231903
Poruke: 2238
*.dynamic.sbb.rs.

Jabber: Milan Kragujevic
Sajt: https://milankragujevic.c..

+205 Profil

Re: Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

^{04.10.2021. u 20:39 - pre 40 meseci}

@Nebojsa

Citat:

As many of you know, DNS for FB services has been affected and this is likely a symptom of the actual issue, and that's that BGP peering with Facebook peering routers has gone down, very likely due to a configuration change that went into effect shortly before the outages happened (started roughly 1540 UTC). There are people now trying to gain access to the peering routers to implement fixes, but the people with physical access is separate from the people with knowledge of how to actually authenticate to the systems and people who know what to actually do, so there is now a logistical challenge with getting all that knowledge unified. Part of this is also due to lower staffing in data centers due to pandemic measures.

https://archive.is/QvdmH

A posebno je zabavno kako je nestanak fejsbukovih ruta izazvao preopterećenje mnogih javnih dns servisa

npr cloudflare

https://twitter.com/jgrahamc/status/1445066136547217413

Nemam ti ništa više reć
Ali ima ti nešto za reći moj tetejac

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16751
2a02:8071:31e1:dd00:e1bb:218..

+7202 Profil

Re: Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

^{05.10.2021. u 00:07 - pre 40 meseci}

@Nebojsa Milanovic,

TL;DR - Aplicirali su neku promenu na sopstvenoj mrezi. BGP update je momentalno ucinio Facebook i ostale FB servise nedostupnim, ali ocigledno niko nije racunao na to da procedure za oporavak zahtevaju funkcionalni DNS. To je izazvalo haos (plus navodno neki ljudi nisu mogli da udju na odredjene lokacije zato sto kljucevi-kartice nisu radili) i verovatno je najvise vremena otislo na uspostavljanje pouzdanog metoda komunikacije izmedju tehnickih lica sa pristupom core ruterima i mreznih inzenjera sa znanjem kako da rese problem.

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16751
2a02:8071:31e1:dd00:e1bb:218..

+7202 Profil

Re: Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

^{05.10.2021. u 00:23 - pre 40 meseci}

Odgovor na temu

Nebojsa Milanovic
Pančevo

SuperModerator
Član broj: 16
Poruke: 8646
*.dynamic.sbb.rs.

+1399 Profil

Re: Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

^{05.10.2021. u 02:40 - pre 40 meseci}

Pre neki dan sam čitao veliku analizu da su u poslednje vreme uložili 15 milijardi dolara samo u cybersecurity, teško je zamisliti koliko su investirali u sve drugo...i da im uprkos svemu se ovo desi...još se tačno ne znaju posledice, videće se narednih dana.

Sa moje strane predlog da sada razmotrite akcije FB, ako ništa imaćete puno bolji ulaz od mene.

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16751
2a02:8071:31e1:dd00:e1bb:218..

+7202 Profil

Re: Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

^{05.10.2021. u 08:08 - pre 40 meseci}

Mislim da ova dva dogadjaja nemaju veze jedan sa drugim.

Ovo sa konfiguracijom mreze deluje kao klasican corporate "oops". Fakat da im je SOS mreza, takodje, zavisila od istih resursa nije lep, ali nije nista sto vec nije vidjeno. Steta samo za WhatsApp koji inace ima odlicnu infrastrukturu ali su morali ocigledno da pocnu da koriste FB servise.

Curenje podataka je druga prica... mada opet, dosadasnje slicne epizode su se zavrsavale brzim zaboravom.

Odgovor na temu

B3R1
Berislav Todorovic
NL

B3R1
Član broj: 224915
Poruke: 843

+675 Profil

Re: Preminuo Fejsbuk nakon procurelih ličnih podataka korisnika

^{05.10.2021. u 09:53 - pre 40 meseci}

Ne znam tacno sta se desilo, ali na osnovu svega ovoga kockice se polako sklapaju.

Kao i sve ogromne mreze, konfiguracija uredjaja u FB mrezi se ne azurira rucno, vec se svaka izmena radi uz pomoc automatizovanih alata (u zargonu i dalje zvani "scripts" ... mada je softver koji se danas koristi za to mnooogo odmakao od skriptica). Drugacije i ne moze, jer azurirati 10,000++ rutera rucno je nemoguce. Znate vec - Ansible/Puppet/Chef, mada sam ubedjen da su u FB napravili takve alate sami. Medjutim, ti alati su isto tako mocno sredstvo da u jednom potezu napravis totalni karambol. I to se ovog puta i dogodilo.

U takvim kompanijama svaka izmena u mrezi prolazi strogi Change Management proces, gde svaki predlog izmene konfiguracije prodje kroz 2-3 peer review ciklusa. Znaci, ako jedan inzenjer/arhitekt predlozi da se npr. izmeni nesto u BGP konfiguraciji, on mora da napise detaljan MOP (Method of Procedure, prim.prev.) dokument za to, sve to pregleda njegov kolega, to aminuje neki senior koji takodje treba da pregleda sve to, procenjuje impakt te izmene na ostatak mreze, dobro proceslja svaku komandu u dokumentu itd. Pogotovo kada je rec o slozenim CDN-ovima kakav imaju FAANG. Ovo pisem jer radim bas na takvim poslovima vec skoro 30 godina, pri cemu su ti change management procesi usli u "modu" tek pre nekih 10-15 godina. Mi se cesto zalimo na te CM procese, kazemo kako oni ubijaju kreativnu energiju ljudi, kako su dosadni, naporni ... Tacno. Ali izgleda da ce tek sada CM postati strog!

Medjutim, u svim velikim IT firmama ljude angazuju da rade na vise projekata u isto vreme, koga god vide da ima znanja i vestine natovare mu gomilu gluposti na ledja, jer gazde zaposljavaju minimum radne snage za sve to. Bas kao i u Srbiji, samo na vecoj skali. Uz sve to, rokovi su ludacki tesni, sve mora da bude gotovo juce itd. Znate vec ... Plus, kao sto rekoh, niko ne voli CM, jer to jeste posao koji "neko mora da odradi". :->

I sve bi to jos bilo ok da inzenjere dodatno cesto ne maltretiraju da sede po besmislenim sastancima (trenutno su to "conference calls", ali opet sastanak je sastanak) ... plus nekakvi tupavi "treninzi" koji nemaju veze s tekucim poslom, a koje je propisao HR da moras da ih prolazis svakog kvartala. Bolje da vam ne kazem sta je sadrzaj svega toga, povracali biste. Mnogi zato ostaju prekovremeno i rade SVOJ POSAO na kraju radnog vremena, kada zavrse te druge budalastine ... I sve to vodi povrsnom radu, gde nemas ni vremena da se fokusiras samo na jedan problem i temeljno ga odradis. Vec sve radis u isto vreme, povrsno, ofrlje, napamet ... Dodajte tu jos i porodicne i licne probleme na sve to.

A konfiguracije rutera su zeznuta stvar. Jedna greska, makar samo pogresno napisana netmaska (npr. /23 umesto /22) - i eto belaja. U ovom slucaju izgleda da su iz spiska ruta koje se oglasavaju BGP-om izbacili anycast opseg koje koristi njihov autoritativni DNS - kljucna komponenta svakog CDN-a, koja "peca" korisnikovu IP adresu i u zavisnosti od nje optimalno ga prosledjuje ka edge cache serveru najblizem korisniku, odakle mu servira sadrzaj. Dovoljno je da su izostavili tu jednu IP mrezu, jedan /24 i ceo CDN je neupotrebljiv ... a koliko sam citao na NANOG listi, izgleda da su sa liste skinuli nekih stotinak ruta ... :-))) Izmedju ostalog i neke svoje interne rute, pa im je pukao i njihov OSS/NMS sa koga nadziru mrezu. Glasine su bile da im je pukao i sistem za fizicki nadzor objekata, pa radnici (koji trenutno zbog kovida rade od kuce) nisu mogli da udju u svoje kancelarije i u datacentre, jer skeneri propusnica nisu radili. Kazu da se cekalo nekih par sati da se taj sistem deaktivira, kao i da mobilisu dovoljan broj inzenjera i objasne im sta tacno treba da urade da na licu mesta u datacentrima odrade rollback svih konfiguracija. Verovatno rucno, jer Ansible (ili sta vec) nije mogao da radi ... :-)))

Sve u svemu, licno mislim da je ovo sto se desilo odlicna stvar, jer ce - nadam se - iz ovoga industrija izvuci neke pouke!

_{[Ovu poruku je menjao B3R1 dana 05.10.2021. u 11:04 GMT+1]}

Odgovor na temu