3 ms·
(just a wild theory) Is the downtime (at the time of writing) their way of blocking a known ongoing attack that can't be stopped fast and safely enough by othe
by drclau 5y ago
(just a wild theory)
Is the downtime (at the time of writing) their way of blocking a known ongoing attack that can't be stopped fast and safely enough by other means?
Something like: 1) take everything down, 2) fix the bug, 3) deploy everywhere, 4) start everything up.
And, to stop clients from connecting, take down the DNS too. DNS is also a great scapegoat.
- johntiger1 5y agoAlso thinking that these two events are not independent...
- deleted 5y ago[deleted]
- Seredo 5y agoApparently the data was collected through scraping, so probably just a coincidence.
- toast0 5y agoI worked at WhatsApp until 2019; I don't remember any disaster plans where taking everything down was an option (although I'm sure they exist), but dropping BGP sessions is probably not the best way to do it, because it's hard to reverse and hard to inspect the system without BGP. Over in WA land, we'd probably just kill all the frontend servers if needed. For all of FB infrastructure, killing all the loadbalancers would probably work, and also the outgoing proxy hosts, as appropriate. No need to mess with DNS or BGP.
- y4mi 5y agoI agree that it's highly unlikely to be a deliberate action, but your listed mitigations would only help against security issues that impact the web services. It could be the only way to go in the highly unlikely scenario that attackers are able to compromise the management APIs of various infrastructure devices like routers, baremetal servers etc. These APIs are usually on airgapped networks though, which makes this extremely unlikely