У Facebook назвали причину масштабного збою всіх сервісів

Американська компанія Facebook через кілька годин після відновлення доступу до своїх сервісів оголосила причину глобального збою. Інцидент із недоступністю Facebook, Instagram і WhatsApp по всьому світу тривав близько 6 годин.

Що насправді сталося

Як пояснили в компанії Марка Цукерберга, аварія сталася через зміну конфігурації магістральних маршрутизаторів, які координують мережевий трафік між центрами обробки даних Facebook. Їхнє переналаштування спричинило проблеми, які перервали зв’язок.

Повідомляється, що порушення мережевого трафіку також здійснило каскадний вплив на способи зв’язку з центрами обробки даних, у результаті чого зовнішні і внутрішні мережеві послуги були зупинені.

Водночас у Facebook не пояснили, хто був ініціатором змін конфігурації маршрутизаторів і чому вони були зроблені.

Чому так довго відновлювали

Компанія розповіла, що через збій перестали працювати багато внутрішніх інструментів і систем, які інженери Facebook використовують у повсякденній роботі, що серйозно ускладнило спроби швидко діагностувати і вирішити проблему.

Також відомо, що співробітники Facebook не могли зайти в офіс (частина центрів пускали тільки за перепустками, які прив’язані до інтернет-авторизації), втрачені були майже будь-які звичні способи комунікації. На додаток до всього, більшу частину проблем можна було вирішити тільки при фізичному доступі до серверів, який істотно ускладнений при віддаленій роботі.

Саме через це, як повідомляється, перші ознаки відновлення систем можна було помітити вже після 00:00 за Києвом, тобто аж через 3 години глухого мовчання.

Хто ще постраждав від збою

Міцно дісталося всьому інтернету. «Лежали» майже всі великі соцмережі, які неочікувано отримали трафік «неживого» Facebook і всіх його сервісів.

«Користувачі, не знайшовши звичного Instagram і WhatsApp, пішли шукати порятунку в Twitter, Telegram і TikTok. Ті, хто отримав новий трафік спочатку раділи, але потім почали стогнати під отриманого несподіваного навантаження», — пишуть у The Cloudflare Blog.

За даними блогу, сильно постраждали всі публічні DNS сервери. Зокрема мобільні клієнти Facebook та всі сайти, де була авторизація через цю соцмережу або кнопка like, безупинно DDoS-или свої DNS запитами до неіснуючого Facebook.

При цьому, як наголошується, трафік деяких мобільних додатків виріс у 30-50 разів.

Чи був витік даних

Тим часом на популярному хакерському торговому майданчику в даркнеті виклали на продаж дані понад 1,5 млрд користувачів. За оцінками фахівців, це найбільша кількість крадених конфіденційних даних Facebook.

Відомо, що восени 2021 року анонімний користувач даркнету заявив про володіння великою кількістю персональної інформації користувачів Facebook. Нині ж дані опинилися на торговому майданчику. При цьому потенційним покупцям доступне придбання відразу всього масиву даних або певної його частини. Один із покупців стверджує, що за 1 млн облікових записів призначили ціну в $5000.

Якщо вірити оголошенню на форумі, виставлені на продаж дані містять: справжні імена користувачів, номери телефонів, електронні адреси, місце розташування, адреси проживання, стать і ID на платформі.

Причому перевірка показала, що опубліковані дані не дублюються з раніше злитими, тобто вони можуть бути унікальними. Продавець стверджує, що є представником групи веб-скраперів й отримав дані завдяки парсингу, а не вдавався до злому.

Таким чином, витоку даних у FB наразі не було. Як відомо, популярний спосіб отримання персональних даних на платформі Facebook — онлайн-вікторини, створювані зловмисниками. Користувачі, які беруть участь в опитуваннях, автоматично дають згоду на збір даних, що відкриває можливість їх творцям формувати бази даних на основі отриманої інформації.

Водночас, незважаючи на те, що профілі користувачів не були зламані, загроза для користувачів усе ще залишається. Зловмисники можуть використовувати дані для соціального інжинірингу та неетичного маркетингу. Особливу увагу фахівці звертають на той факт, що у вільному доступі виявилися електронні адреси та номери телефонів користувачів.

Як «падав» і ремонтувався Facebook

Нагадаємо, інцидент із недоступністю Facebook, Instagram і WhatsApp по всьому світу тривав близько 6 годин. Фахівці компанії займалися усуненням збою, але не могли його вирішити оперативно. Виявилося, що для цього потрібна фізична присутність мережевих інженерів для усунення проблеми на маршрутизаторах у дата-центрах Facebook.

Компанія терміново направила групу фахівців у дата-центр у Санта-Кларі (США), щоб спробувати вручну перезапустити сервери і розібратися з конфігурацією маршрутизаторів.

Водночас стало відомо, що внутрішня мережа компанії також стала недоступна, включаючи корпоративні сегменти, сервери DNS, сервіси й інструменти. Через це фахівці не могли проникнути всередину периметру дата-центрів — у них не спрацьовували пропуски.

Попередня причина інциденту, про яку заявляли багато експертів — віддалене оновлення конфігурації маршрутизаторів всередині мережі компанії, що відповідають за BGP-сесії і їх анонси, а також автономної системи Facebook, пішло не за планом. Після цього перестали бути доступні NS-сервери компанії і зникли DNS-записи.

👍НравитсяПонравилось4
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Куда бы в следующий раз поехать Зеленскому...

І ось сенс усих отих інтерв’ю, онлайн-кодингу, розв’язанням логічних задач і «вот ето вот всьо» для того щоб працювати в фейсбук якщо по висновку трапляється от таке от лайно?

Ще один доказ що є скілл проходити всі оті інтерв’ю а є інший скілл бути раціональним інженером.

если это не диверсия, а они сами сознательно вносят изменения одновременно на всех своих датацентрах, без валидации, удаленно, не имея альтернативного канала доступа, то это — просто «вершина» ченджменеджмента

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

в новостях прочитал что оно сегодня ночью опять падало, неужели fb самоликвидируется?

Мне чота грустно от того, что 6-часовой сбой в соцсетях вообще заметен глазу. Люди уже и 6 часов не могут без них прожить, что ли? :(

А без гугла 6 часов?)

Легко без stackoverflow 6 часов апщета о_О

причем тут гугл? И гугл не единственный поисковик в мире

жил на duckduckgo пару недель, часто приходилось возвращаться к google, забил

Ну вот видите — вы пару недель пользовались duckduckgo. Ну а 6-то часов уж точно можно перебиться.

я был на одном гугловом тренинге, там спикер говорил, что SLA google.com — 100%. то есть даже если весь интернет упадет, поисковик будет работать

Ось підраховують скільки там фейсбук шатдаун збитків приніс. І я думаю — якщо це г*вно один день не працювало, це вже величезний вклад в психічне здоров’я планети. Не все грішми лише міряти.

www.youtube.com/watch?v=c4TCKz-6H-s
тут вице президент гильдии все пояснил за сбой, только вот канал прокремлевский но то такое.

Вот уже хоть какие-то детали: engineering.fb.com/...​g-traffic/outage-details
аффтар жжот:

> During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally. Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command.

Измерение, которое убивает (tm)

Потом тестер доступности внутренней сети сказал „ах, сети нет — складываем DNS”. Что DNS нужен и внутрь — пофиг.

И вишенка на торте:

> We’ve done extensive work hardening our systems to prevent unauthorized access, and it was interesting to see how that hardening slowed us down as we tried to recover from an outage caused not by malicious activity, but an error of our own making.

Так то из инсайдерских каналов твиттера ответ тут
twitter.com/...​/1445186388270452740?s=20

Вкратце:
Обновили конфиги и бот сделал автомерж этого ПРа

Удаленно настраивать BGP/OSPF это примерно как сидя в SSH менять IP адрес хосту.
Вершина тупости.

Удаленно настраивать BGP/OSPF это примерно как сидя в SSH менять IP адрес хосту.

Вообще нет, при наличии достаточного количества подпорок, например:
— Менять то, на что скорее всего не окажет влияния (eBGP внешний, а админ в пределах той же AS; OSPF — строить другую область; и т.п.
— Прописать раутинг от раутера до своей консоли и назад — статиком по всей цепи.
— Сделать подпорку в виде назначенного отложенного ребута или роллбэка конфигурации.

Но это, да, надо озаботиться и подумать.

В SSH можно менять адрес, если поставить его рядом на тот же интерфейс, не удаляя старый до релогина. Не всегда можно, естественно, но бывает.

Ну все эти подпорки рано или поздно заканчиваются Oops, что собственно и демонстрирует subj.
Я лично давно уже перестал доверять даже самому себе в создании подпорок, настолько часто бывало что ошибался в мелочах, которые приводили к жопе в мыле.
Потому такие операции должны выполняться либо онсайт, либо должен быть железобетонный резервный маршрут.
Например, сеть на продакшен хосте я настраиваю удаленно только из подключенного IP-KVM, и все кто просят делать по-другому т.к. им лень искать этот квм, идут нах.

А если например надо менять адрес на eth1, а управление идёт через eth0 — недостаточно?
(Я знаю стандартные проблемы и могу себе представить, как сломать и в этом случае. Вопрос более административно-психологического плана.)
А если всегда есть кто нажмёт Power в течение минуты?

А если например надо менять адрес на eth1, а управление идёт через eth0 — недостаточно?

Лично для меня — недостаточно.
Я откажусь делать любые настройки с сетью на боевом сервере без квм.

А если всегда есть кто нажмёт Power в течение минуты?

Это не проблема, если есть квм.
Даже если кто-то выключит power во всем ДЦ, то проблема будет вызвана не моим действием и никто не будет меня дрючить в отличие если что-то пойдет не так с «А если например надо менять адрес на eth1, а управление идёт через eth0».

А если сервер/роутер не один, а 10к+ разбросанных по разным дата центрам и континентам?

Вопрос более административно-психологического плана.

админская карма, как правило, несет позитивный эффект, и при наличии свитера, бороды, пива и др. психологических аттрибутов заставляет любую железяку нормально работать на расстояних до 20 тыс. км.
но никто не отменял Single-event upset

пива и др.

под пивом вместо eth1 напишешь eth0, а потом будет как тут — www.youtube.com/watch?v=SeW4gq9JGMM

А что не так со сменой IP-адреса? Тебе что, больше сконнектиться не дадут?

Можешь запросто попасть в промежуточную позу — старый адрес удалён, новый не добавлен. Тогда да, нидадуд.

Я правильно понимаю, проблема в том что IP меняется в 2 местах? Или там сам скрипт, который меняет, может отстрелиться недоработав, только потому, что отлетела SSH сессия в силу потери коннекта?

Я правильно понимаю, проблема в том что IP меняется в 2 местах? Или там сам скрипт, который меняет, может отстрелиться недоработав, только потому, что отлетела SSH сессия в силу потери коннекта?

Проблема в обоих пунктах. Смена IP это больше одного действия. Каждое из действий может пойти «не так». Разрыв может пройти между командами, или команда настройки нового IP не выполнится. Если ты вспоминаешь про screen/tmux, то и они тут не всегда помогают, потому что если новый адрес не назначился, то ты не доберёшься даже вернуть старое. Скрипт скорее всего мгновенно не откинет от смены IP, это будет только если скрипт начнёт выводить что-то в объёме многих килобайт, но ошибка в команде не поставит новый адрес.

Иногда, да, неизбежно что-то делать без подпорок в виде IKVM. Тогда я обычно обеспечивал себе подпорку в следующем виде:
1) Сервер предварительно ребутится, чтобы убедиться, что он успешно встаёт сам. (А то мало ли что там сбилось.)
2) На нём под screenʼом запускается минимум два терминала, в первом что-то вроде sleep 600 && reboot (Ctrl+C во время ожидания отменит вторую команду), во втором собственно команды смены IP в виде скрипта, который проверен с точностью до адресов в какой-то песочнице (сейчас годится виртуалка).
3) Если смена прошла успешно, и доступ через новые адреса работает (а то мало ли что настроено на свичах и раутерах), то новый адрес прибивается в конфигах — и снова перезагрузка, чтобы убедиться, что оно корректно встаёт с новым конфигом.

Во многих случаях можно было упрощать — например, если реально раздельные интерфейсы для менеджмента и клиентов, а меняется на одном из них (если не совсем криворукий, второй не затронет). И то, всегда вначале проверяется, что если что — есть альтернативные каналы (IKVM, компорт, умный админ рядом...)

Ну и если гермозона под боком, то, естественно, 90% этого не нужно — в LN основное хозяйство было именно в таком режиме, до любого можно дотянуть дисплей и клаву.

Самый ад — это уже не я делал, просто наблюдал — коллега взял халтурку обновить фряху с 2.2.чего-то на 4.x удалённо, а машина была аж в Иране. Он подобрал похожее железо и потренировался на ней несколько раз (а процесс нетривиальный, с промежуточными этапами, сменами загрузчика...)

Еще раз поясню свою теорию.
РЕАЛЬНЫЕ киевские гении давно работают в Фэйсбуках на з/п, начиная от 250 000 в год и не допускают, что бы —

аварія сталася через зміну конфігурації магістральних маршрутизаторів

А всякие ****, которых выгнали с 3го курса КПИ, получают замыленные биткоины от ФСБ и льют тронянов со своих IP.
Хотя это все теория, и возможно реально сработал «человеческий фактор».

И ГОВОРЯТ, что не допускают... пока не случится. Но остальные будут и дальше верить, что с ними такого не может быть никогда.

Гении — это миф. Реальность — это жёсткая система субординации, и только она может что-то противопоставить человеческому фактору. И даже её строят не гении, а скорее умные копипастеры.

Чуваки, я вот не особо спец в кибератаках, но мне здается что вся это история от Фэ
йсбука на счет —

зміну конфігурації магістральних маршрутизаторів,

, это для замыливания глаз.
На самом деле работала команда профессионалов, но крайними как всегда /*привет Гуантаномо*/ окажутся малолетник Киевские или КНДРовские гении /*дибилы*/.

Ну сейчас местные эксперты расскажут как нужно было правильно делать и в чём проблема.

На додаток до всього, більшу частину проблем можна було вирішити тільки при фізичному доступі до серверів, який істотно ускладнений при віддаленій роботі.

Хз, что там произошло на самом деле, в отличие от официальной инфы... но этот аргумент точно будет использоваться конторами любого рода для попыток загона удаленщиков обратно в стойло :)

Так наче на галерах є якесь обладнення. Всі сервера в клауді!

Так наче на галерах є якесь обладнення. Всі сервера в клауді!

Это вообще не важно. Главное — формальный повод есть. Это как политики тоталитарных (и не очень) стран любят использовать ковид для введения любой дичи.

Главное — формальный повод есть.

«мне не нужна твоя работа, абы ты мучился»
Отличная лакмусовая бумажка для определениях оленей на постах Chief *

и чем поможет офис ? там что — оборудование какое стоит ?
Вся и-ра проектов или с public cloud или свои, но за рубежом и так далее.
а кто предоставляет услуги outsourcing network engineers — там свои правила и порядки, таких у нас практически нет

и чем поможет офис ? там что — оборудование какое стоит ?

С точки зрения здравого смысла — конечно, ничем. Как повод, пусть и оторванный от здравого смысла — сгодится вполне. Как с тем же ковидом, в чем смысл комендантского часа, который ввели некоторые страны? Ночь — время дьявола и вирус лучше передается?

Вночі бухарики по ларькам ходять.

І ось сенс усих отих інтерв’ю, онлайн-кодингу, розв’язанням логічних задач і «вот ето вот всьо» для того щоб працювати в фейсбук якщо по висновку трапляється от таке от лайно?

Ще один доказ що є скілл проходити всі оті інтерв’ю а є інший скілл бути раціональним інженером.

Це лише показник, що факаплять всі. Ідеальних людей не існує.

это периодически делается для того, чтобы уволенным работникам fb было что ответить на вопрос «tell me about your biggest failure»

Напевне сенс в тому, що фейсбук впав через проблеми в маршрутизаторах, а не в продукті роботи тих, хто проходив онлайн-кодинг і логічні задачі.

Тобто ви, написавши, налаштувавши і викотивши на прод код, вважаєте себе відповідальним за роботу техніки, які відповідає за маршрутизацію трафіку на сервери, на яких лежить ваш код?

Я колись проходив інтерв’ю на FB як сисадмін і так, там також був кодінг і логічні задачи коли тобі зазирають у екран і таймер тікає.

Да, я не зовсім точно виразився. Я мав на увазі, що на ДОУ здебільшого говорять про співбесіди для програмістів, вся взаємодія яких з серверами — системи автоматичного деплою. Їх (людей) я і мав на увазі. Навіть якщо вони займаються розгортанням і оркестрацією, всеодно це не маршрутизатори і не системне адміністрування. Тому, на мій погляд, коли падає система, близька до заліза і маршрутизації — пинаємо ногами сисадмінів. Коли падає чи тече даними прикладна частина з беком і фронтом — пинаємо ногами програмістів. Не змішуючи сфери відповідальності.

Там майже нема сисадмінів у звичайному сенсі. Є SRE інженери. І вони мають бути відповідно треновані, щоб керувати мережею сервіса такого масштабу, щоб вимагати достатнього рівню систем нештатного керування...

Оновлення конфігурації робили інженери а на само по собі воно так трапилось.

Напевне сенс в тому, що фейсбук впав через проблеми в маршрутизаторах, а не в продукті роботи тих, хто проходив онлайн-кодинг і логічні задачі.

Читаємо офіційний коментар:

> Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command.

При онлайн-кодингу не перевіряють здатність писати тести?

> a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally.

Як можна було так задізайнити, щоб якась команда в результаті простої описки перетворилась на відключення всіх зʼєднань? Про UX навіть в commandline інтерфейсі вони не чули?

> the total loss of DNS broke many of the internal tools we’d normally use to investigate and resolve outages like this.

Про якісь правила SRE ці сортувальники гномів не чули? Чому наприклад у Гугла є окрема 1e100.net, а FB не стурбувався про це? Чи якщо умні люди пишуть, що треба резервувати і відокремлювати керування, то не треба так робити?

Навіть за офіціальним коментарем проблема не в маршрутизаторах, а в вухастих прокладках (між клавіатурою і стільцем).

Чому наприклад у Гугла є окрема 1e100.net

Гугль довше за всих утримувався від працевлаштування дебілів

Ще один доказ що є скілл проходити всі оті інтерв’ю а є інший скілл бути раціональним інженером.

Т.е. если набрать рандомных челиков с Доу без собеседований (или с галерными собесами) то падений не будет никогда?

Проблеми могли початись з закінченням строку дії DST Root CA X3 30 вересня. Який потягнув за собою купу обновлень одне з яких закінчилось падінням фб letsencrypt.org/...​xpiration-september-2021

Навіщо раутерам список корневих сертифікатів?

там один кореневий сертифікат через який в мене відвалилось половина інтернету.

Раутери зазвичай його не використовують.
Ну і чому у вас openssl застаріла?

там не все так просто, наприклад той же chef-client з собою таскає cа-сertificate, та що там шеф, та ж mac os 11.6 мала проблеми поки не запушили фікс від айосу з апдейтом.

Але зверніть увагу — в вашому списку нема пристроїв від Cisco/Juniper/ExtremeNetworks/Arista/etc. :))

я не мережевий експерт але в моєму розумінні це говорить тільки про регулярні апдейти пристроїв коли на них можуть інсталитись сертифікати. Сертифікат може бути або заінсталений на залізяку або приходити з мережі. В другому випадку його можна перехопити і хакнути. Кожен апдейт це також ризик регрешенів. Тобто тягати з собою сертифікат це абсолютно нормальна ідея якщо вчасно обновляти фірмвейр.

але в моєму розумінні це говорить тільки про регулярні апдейти пристроїв коли на них можуть інсталитись сертифікати.

Насправді, це говорить, по більшости, що у них немає проблем з X.509 сертифікатами тому, що сертифікати не використовуються.
Основна взаємодія з крупними раутерами (рівня core/edge/distribution) йде через: telnet, ssh (часто і без перевірки хоста — оскільки це роблять адміни, у них зазвичай немає проблеми чужого MITM), SNMP зі своєю системою паролей (або community для v1-v2), а для первісних налаштувань взагалі послідовний порт...
Навіть HTTP (відкритий, без TLS) це вже нетипове.

Так, це дуже дивно для тих, в кого 99% взаємодії це якийсь REST over HTTPS, але в цьому світі інші технології.

Ваша гіпотеза мала б якийсь сенс, якби розглядали не самі по собі раутери, а якийсь допоміжний шар кастомного керування. Але і в цьому випадку навряд чи хтось ходив до letsencrypt авторизувати кожний проміжний (умовно) control-edge9.dc11.net.fb.com, зробили б свій корінь або купили б ’*’ (всі піддомени) у когось з тих, хто дає таке (від ~200$/рік — дрібниця). Свій корінь імовірніше і корисніше (бо внутрішня мережа, в ідеалі, не має прямого доступу до Internet).

в мене OSx 10.11 і там це кореневий сертифікат, мабуть найважливіший з усіх — це кореневий сертифікат для letsencrypt. stackoverflow.com і пів інтернету ним були підписані. Можливо роутери фб або якісь залежності цих роутерів.

Раутерам (великим, а не SOHO) TLS зазвичай ні до чого.
Повторюсь: Основна взаємодія з крупними раутерами (рівня core/distribution) йде через: telnet, ssh (часто і без перевірки хоста — оскільки це роблять адміни, у них зазвичай немає проблеми чужого MITM), SNMP зі своєю системою паролей (або community для v1-v2), а для первісних налаштувань взагалі послідовний порт...
Навіть HTTP (відкритий, без TLS) це вже нетипове.
Відкрийте типову книгу по налаштуванні наприклад Cisco (IOS based, не плутати з Apple iOS) і побачите інструкції типу: знайти послідовний порт. Підключитись до console порта (треба спец. шнурок, звичайно є в комплекті, але губиться на третій день). Сказати enable. Сказати масу заклинань у дусі
conf term
int gi 0/0
ip address 192.168.2.1 255.255.255.0
no shutdown
exit
line vty 0 4
enable secret ababagalamaga
exit
sh run (перевірити що все як треба)
copy run sta

І вони — при нормальному сетапі (а не відкритому всім вітрам) на сірих адресах і DNS іменах типу edge1.mysite.local (в ідеалі через окремі DNS сервери — схоже, це в FB не зробили).

TLS через ієрархію X.509 (як для HTTPS) тут вже може робити тільки через свої сертифікати, бо жоден letsencrypt/verison/thawte/etc. не видасть вам сертифікат для *.mysite.local. І навіщо тоді він такий потрібен?

а логи і бекапи з цих девайсів як збирати сек"юрно? теж через console?

telnet, ssh (часто і без перевірки хоста)

якщо це правда — то це одна з можливих причин чому FB впав :)
Для мереж такого масштабу придумали TACACS(+) і в великих мережах він є обов"язковим стандартом.

Для мереж такого масштабу придумали TACACS(+) і в великих мережах він є обов«язковим стандартом.

Здається, ви не в курсі, «від слова „зовсім“» (tm).
По-перше, TACACS+ через політику Cisco, можна вважати, не вижив. Ще в кінці 1900-х інші вендори обʼєднались і створили свій аналог — RADIUS. Він був кривий, косячний, але вільний — без юридичних обмежень. (TACACS без плюсу не був корисним.) Cisco звільнила TACACS+ через 20 років (RFC вже від 2020), коли він нікому нафіг не був потрібний (після RADIUS був ще Diameter, який, наприклад, в 4G мережі).
До речі, голосові рішення Cisco базувались на RADIUS! Загугліть, наприклад, атрибути h323-ivr-out. З ~2005 Cisco дозволила RADIUS всюди де був TACACS+, тому мультивендорські мережі базуються на RADIUS чи Diameter.

По-друге — що важливіше — використання TACACS+/RADIUS/etc. ортогональне до вказаних речей. telnet/ssh/etc. воно між клієнтом та сервером доступу, а вже сервер доступу йде до AAA-серверу з питаннями про аутентифікацію і авторизацію. І от як саме буде перевірятись пароль та віддаватись права доступу — ортогональне до того, чим прийшли (telnet, SSH, SIP, RS-232...), хоча може і мати правила «це не можна через telnet, а оце навіть через ssh».

а логи і бекапи з цих девайсів як збирати сек«юрно? теж через console?

З того, що я бачив — IPSec. А ось він вже може бути зконфігурований різними шляхами, в тому числі «ентерпрайзним» X.509, але для таких мереж — через власні CA чи «великі» дорогі центри сертифікації. Letsencrypt не видає сертифікати для такого використання.

(Так, пишучи це подумав — чи могли в FB зробити IPSec по сертифікатам? Але це все одно не дало б падіння через _той самий_ корінь.)

PS: чи ви побачили про «перевірку хоста» і не зрозуміли? Я мав на увазі, що server host key ігнорується (як роблять 99% тих хто ходить по ssh), мов, мережа захищена тому що окрема. І це теж ортогональне до TACACS+/RADIUS/etc.

Ще в кінці 1900-х інші вендори обʼєднались і створили свій аналог — RADIUS.

Cisco seriously evaluated RADIUS as a security protocol before it developed TACACS+. так я знаю що перша ітерація (без плюсика) була розроблена значно раніше, для військових

він нікому нафіг не був потрібний

потрібний хоча б тому що в TACACS+ на відміну від RADIUS реалізовано декілька кіллер фіч:

* TACACS+ uses TCP (while RADIUS operates over UDP)
* All the AAA packets are encrypted in TACACS+ while only the passwords are encrypted in RADIUS
* Provides granular control (command by command authorization)

Для якогось VPN/Wi-Fi вистачить і RADIUS, а щоб керувати магістралями між ДЦ я обрав би TACACS+ (бюджет у FB для цього є)

Cisco seriously evaluated RADIUS as a security protocol before it developed TACACS+. так я знаю що перша ітерація (без плюсика) була розроблена значно раніше, для військових

Ага, і знайшли в нього «фатальний недолік» (tm).

потрібний хоча б тому що в TACACS+ на відміну від RADIUS реалізовано декілька кіллер фіч:

Жодна з них не є дійсно кіллером. TCP — нічого принципового для цеї задачі не дає (ба навіть робить гірше — на кожний запит ще треба підняти зʼєднання, а потім його максимально коректно закрити. Звичайно, як ми бачили, навіть їх рідні NASи не тримали зʼєднання між запитами.) Повне криптування — в довіреній мережі нічого принципово не дає (уж повірте тому чий компонент вже майже 20 років авторизується RADIUSом), а в недовіреній я б і TACACS+ не довіряв повністю. Ви бачили, что навіть в RFC8907 (2020 рік) там тільки MD5? Command authorization — хто забороняє питати на кожну команду? Цисковські боги? Ну це їх справа.

(Якщо я почну згадувать скільки ми наморочились з акаунтінгом по такаксу... дубльовані старти-стопи, сміття замість ідентифікаторів портів... це ще окрема книга.)

От що було дійсно кіллер-фічею _тодішнього_ такаксу це alive accounting. В RADIUS його більш-менш масово завезли на декілька років пізніше, і то Cisco його не вміла.

а щоб керувати магістралями між ДЦ я обрав би TACACS+ (бюджет у FB для цього є)

І знову, це ніяк не стосується того, чи ходити на раутер по ssh, чи перевіряти host key... ну і я б там робив таки тотальний IPSec, навіть якщо на статичних ключах.

втрачені були майже будь-які звичні способи комунікації.

А нічого на роботі в фейсбуках сидіти!

На прошлой работе у нас пробовали facebook for corporations, или как он там точно зовётся. Назначение — ну представим себе аналог slack/teams только в формате FB.

Мы месяц-два попробовали, отплевались и выкинули. Оно было тупо неадекватно. Например: 10 человек постят в общую ленту по котику. Потом у каждого открываем ленту и смотрим, сколько котиков показано в каком порядке. Ни у кого не было больше 7, остальное оно не показывало.
То же самое по хэштегу — не показывает всех, и всё.
Ну и те, что показало, порядок похож на рандомный.
В общем, надёжности нет ни на грош.

Но кто-то может и сейчас использовать.

,— сказав менеджер, і наказав адмінам всім вимкнути фейсбук. Він працював у фейсбуці.

це смішно, але те що Фейсбук та Інста впали я прочитав на Реддіті, десь опівночі по Києву))))

если это не диверсия, а они сами сознательно вносят изменения одновременно на всех своих датацентрах, без валидации, удаленно, не имея альтернативного канала доступа, то это — просто «вершина» ченджменеджмента

Список префіксів FB, з якими зникла глобальна зв’язність: IPv4, IPv6.

Цікаво, що саме було перекладено так невдало :)

Там было с два десятка v4 и столько же v6 префиксов: тут

Отож бо :) «IPv4» та «IPv6» не виглядать, як роут-префікси :)

Куда бы в следующий раз поехать Зеленскому...

Але в Москву транзитом через Ростов.

И там ему и остаться, ну чтобы уже точно и навсегда! :-)

Куда бы в следующий раз поехать Зеленскому...

Коли там Динамо з Барселоною грає? Можна в гості на Камп Ноу заїхати

В Донецк пущай едет. Главное обратно не пускайте.

А теперь представьте что в будущем весь интернет — трафик идет через спутники. И вдруг одна команда меняет все IP адреса или чистит таблицы маршрутизации. И все: что бы поменять настройки к спутнику нужно подключиться по сети ... ну или лететь на орбиту и втыкать в него монитор и клавиатуру.
Но самое страшное в другом: невозможно связаться с космонавтами — потому что вся связь уже давно через Интернет, телефонные линии обрезаны, рацией уже никто не помнит как пользоваться ...

я думаю в любом случае с каждым спутником будет автономная связь по радио, независимая от интернета

Будет — пока на смену старому поколению инженеров не придет поколение тиктокеров. Тогда везде связь будет только через тикток — потому что современные дети не знают что такое радиоволны!

При всех возможностях доставить интернет сейчас на самолет, для обмена информацией используют аналоговую радиосвязь. Для навигации, хотя и есть GPS, втч используют всенаправленые и узконаправленые радиомаяки. Угадайте почему. И это только в гражданке. У военных и в космосе все еще более защищено.

При этом для устранения ошибок в конструкции на самолеты ставят программы, которые опускают их носом в землю. Угадайте почему? Потому что самолеты — это летающие гробы!

Что спутник...
один знакомый рассказывал, как они патчили прошивку марсианскому орбитальному аппарату (нет, оно на планету не садилось). Причём в ограниченное время (ошибка в предыдущих планах коррекции, надо было успеть за сутки связаться туда-обратно и залить новую версию, любая ошибка — и потеряли бы). Стрём был жуткий, но всё получилось.
Программа, к слову, была на диалекте LISP.

Тогда проще будет новые спутники запустить. И космонавтов тоже.

пішли шукати порятунку в Twitter і Telegram..., — пишуть у The Cloudflare Blog.

Что за обман, редакция
i.ibb.co/...​021-10-05-at-11-41-31.png

Ви б хоч прочитали заголовочок до діаграми, скрін якої зробили) По картинкам текстовий пошук, на жаль, на працює.

А тепер мають відписатись ІТ-шники у кого ніколи не було даунтаймів в породі.

Колись грохнувся вінт на нашому хостинг-сервері. Здавалося б, нічого страшного, ДЦ Воля дуже швидко поміняла його, бекап свіжий був, ETA простою — не більше 2-х годин. Але коли все вже було встановлено і відновлено, посипались скарги клієнтів на дуже повільну роботу сайтів. Дивимось — а швидкість роботи диска десь в 10 разів менше за звичайну. Проблема не гуглиться, нічого особливого начебто не мінялось, окрім нової серії диска. Пішли читати про нього і виясняється, що це серія із «залізними» 8к-секторами замість 512б. І коли операції читання-запису не вирівнені по цим 8к, диск тормозить, як скажений. А на серваку — CentOS, у який ще старий fdisk із дефолтним 63-м стартовим сектором :) Отакої, тож ВСІ блоки диску перетинали кордон хардварного «сектора».
Довелось влаштувати ще один штучний шатдаун та виправити елайнинг. Ух, нам тоді й дісталось від клиєнтів.

Тільки 4К (8*512), а не 8К. А так — да, у нас було схоже (не для клієнтів, але падіння швидкости було помітне).

Ну блин не до такой же степени:))
Вообще в сети такого размера в любой конкретный момент времени будет что-то не работать. Это норма (tm), и относиться надо соответственно — изолировать, резервировать, контролировать, и прочее -ировать.

В мене не було даунтаймів на 6 мільйардів баксів чистого збитку.

«***к-***к и в продакшен.»
«Да что там может сломаться? я ж просто убираю трейлинг пробел».

Whitespace не бывает trailling space! У нас все пробелы значимые!

десь так я все і уявляв)

Сокращу до смысла: Фейсбук родил официальную версию, а причину решил не называть

Та ладно. Я скажу причину — манагер увидел для новой фиче в дешборде зеленые крыжики и велел ее запушить без QA, потому что там кнопку сдвигали на три пикселя, а это очень важно для юзерстори и профитов.

Виноватым как всегда назначили NOCов.

Подписаться на комментарии