[Серверное администрирование, Сетевое оборудование, Сетевые технологии] Что стало причиной сбоя 30 августа, в ходе которого мировой трафик упал на 3,5%
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Глобальный сбой работоспособности интернета произошел по вине американского провайдера CenturyLink. Из-за некорректной настройки межсетевого экрана, у пользователей по всему миру наблюдались проблемы с доступом к Google, службам Microsoft, облачным сервисам Amazon, сервису микроблогов Twitter, Discord, сервисам Electronic Arts, Blizzard, Steam, веб-сайту Reddit и многим другим.
Причиной сбоя стало то, что CenturyLink, являясь Level3-провайдером, некорректно сформулировал правило BGP Flowspec в протоколе безопасности. BGP Flowspec используется для перенаправления трафика, так что эта ошибка привела к серьезным проблемам с маршрутизацией внутри сети провайдера, что сказалось и на стабильности глобального интернета. Конечно, сильнее всего пострадали пользователи в США, но отголоски проблем ощущались по всему миру.
Важно отметить, что CenturyLink является третьей про размерам телекоммуникационной компанией Америки, сразу после AT&T и Verizon.
BGP Flowspec по IETF имеет код спецификации RFC 5575 и описан как многопротокольное расширение BGP MP-BGP, которое содержит информацию о доступности сетевого уровня Network Layer Reachability Information (NLRI). BGP FlowSpec — это альтернативный метод сброса атакующего DDoS-трафика с маршрута, который считается более тонким способом уклониться от атаки, нежели RTBH (Remote Triggered Black Hole Filtering), когда блокируется весь трафик с адреса атаки, либо трафик до адреса назначения. Вообще, RTBH, по сути — «оружие судного дня» и является крайним средством для прекращения атаки, так как его применение зачастую позволяет атакующему добиться желаемого, то есть изоляции одного из адресов.
BGP FlowSpec действует более тонко и по сути, является фильтром межсетевого экрана, который который вводится в BGP для фильтрации определенных портов и протоколов и определяет, какой трафик по какому маршруту пропускать. Таким образом, «белый» трафик проходит до адреса назначения, а определенный, как DDoS — сбрасывается с маршрута. Трафик анализируется минимум по 12 параметрам NLRI:
- Destination Prefix. Определяет префикс назначения для соответствия.
- Source Prefix. Определяет исходный префикс.
- Протокол IP. Содержит набор пар {оператор, значение}, которые используются для сопоставления байта значения протокола IP в IP-пакетах.
- Порт. Определяет, будут ли пакеты обрабатываться TCP, UDP или оба.
- Порт назначения. Определяет порт назначения, на который будет влиять FlowSpec.
- Исходный порт. Определяет исходный порт, на который будет влиять FlowSpec.
- Тип ICMP.
- Код ICMP.
- Флаги TCP.
- Длина пакета. Соответствие общей длине IP-пакета (исключая уровень 2, но включая IP-заголовок).
- DSCP. Соответствие по параметру Class Of Service flag.
- Fragment Encoding
Каких-то полноценных отчетов о сбое от самих CenturyLink нет, они только упоминают свой дата-центр недалеко от Онтарио. Однако сбой маршрутизации был достаточно серьезным, чтобы на него обратили внимание не только рядовые пользователи, но и инженеры CloudFlare, которые тоже пользуются услугами CenturyLink как крупного провайдера.
Согласно отчету CloudFlare о произошедшем сбое, все началось с резкого роста 522 ошибки в 10:03 по Гринвичу, 30 августа.
Так, автоматической системе ре-машрутизации на случай сбоев удалось сократить количество ошибок и снизить их до 25% от пикового значения, но проблемы со связностью сети и доступностью ресурсов все еще сохранялись и имели глобальный характер. Все это было сделано в окне между 10:03 на начало сбоя и до 10:11 по UTC. За эти восемь минут автоматика и инженеры отключили свою инфраструктуру в 48 (!) городах Северной Америки от CenturyLink и перебросили трафик на резервные каналы других провайдеров.
Очевидно, что так поступали не только в CloudFlare. Однако это не позволило полностью решить проблему. Для наглядности, какое влияние проблемный провайдер имеет на телеком-рынок США и Канады, инженеры компании привели официальную карту доступности услуг CenturyLink:
В США провайдером пользуется 49 миллионов человек, а это означает, что для некоторых клиентов, если говорить об отчете CloudFlare, и даже целых дата-центров, CenturyLink является единственным доступным провайдером.
В итоге, из-за почти полного падения CenturyLink, специалисты CloudFlare зафиксировали сокращение мирового интернет-трафика на 3,5%. Вот как это выглядело на графике по шести основным провайдерам, с которыми работает компания. CenturyLink на нем — красный.
О том, что сбой был глобальный, а не просто «проблемы в дата-центре под Онтарио», как заявил сам провайдер, свидетельствует и размер обновлений правил Flowspec. Обычно размер обновления конфигураций BGP Flowspec составляет около 2 мегабайт, но специалисты CloudFlare зафиксировали обновления конфигураций BGP размером до 26 Мб (!).
Эти обновления, которые распространяются раз в 15 минут, делятся с узлами сети информацией об изменениях в работоспособности маршрутов. Это позволяет гибко реагировать на какие-то локальные проблемы. Обновления размером в 10-15 раз выше обычных говорят о том, что практически вся сеть провайдера легла или наблюдались крайне серьезные проблемы со связностью.
В CloudFlare считают, что причиной сбоя стало некорректное глобальное правило BGP Flowspec, которое получило подавляющее большинство маршрутизаторов, которые потом ушли в реверсивную перезагрузку в попытках восстановить соединение. Это укладывается в картину сбоя, который продолжался более 4 часов. Именно при перегрузке памяти и ЦП маршрутизаторов инженеры могли потерять удаленный доступ к ряду узлов и управляющих интерфейсов.
К слову, подобная история — далеко не уникальна. Чуть более года назад интернет по всему миру «прилег» по вине самих CloudFlare и сбоя в работе их DNS, плюс эта же компания честно упоминаето похожих проблемах с Flowspec еще семь лет назад, после которых они отказались от его использования.
===========
Источник:
habr.com
===========
Похожие новости:
- [Big Data, DevOps, IT-инфраструктура, Информационная безопасность, Серверное администрирование] ELK, SIEM из OpenSource, Open Distro: Case management (перевод)
- [Google App Engine, Разработка мобильных приложений, Разработка под Android] Google начала публичный альфа-тест Jetpack Compose
- [Информационная безопасность, Сетевые технологии, Сотовая связь] Как попасть в IPVPN Билайн через IPSec. Часть 2
- [Системное администрирование, Сетевые технологии] Как подключить Zimbra OSE к Outlook при помощи Zextras Suite Pro
- [Информационная безопасность, Системное администрирование, Сетевые технологии] 6. Check Point SandBlast Agent Management Platform. FAQ. Бесплатное тестирование
- [Сетевые технологии] Разбираемся на практике: DMVPN и Per-Tunnel QoS (перевод)
- [Информационная безопасность, Серверное администрирование, Облачные сервисы] Zoom так и не понял GDPR (перевод)
- [Системное администрирование, Сетевые технологии, Беспроводные технологии, Сетевое оборудование] Особенности защиты беспроводных и проводных сетей. Часть 2 — Косвенные меры защиты
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Облачные сервисы] 5. NGFW для малого бизнеса. Облачное управление SMP
- [Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Мониторинг кластера Kubernetes: общий обзор и знакомство с Prometheus
Теги для поиска: #_servernoe_administrirovanie (Серверное администрирование), #_setevoe_oborudovanie (Сетевое оборудование), #_setevye_tehnologii (Сетевые технологии), #_itsumma, #_sboj (Сбой), #_centurylink, #_bgp_flowspec, #_setevye_tehnologii (сетевые технологии), #_marshrutizatsija (маршрутизация), #_svjaznost_interneta (связность интернета), #_antiddos (анти-ддос), #_ddos, #_mezhsetevye_ekrany (межсетевые экраны), #_cloudflare, #_blog_kompanii_itsumma (
Блог компании ITSumma
), #_servernoe_administrirovanie (
Серверное администрирование
), #_setevoe_oborudovanie (
Сетевое оборудование
), #_setevye_tehnologii (
Сетевые технологии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:49
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Глобальный сбой работоспособности интернета произошел по вине американского провайдера CenturyLink. Из-за некорректной настройки межсетевого экрана, у пользователей по всему миру наблюдались проблемы с доступом к Google, службам Microsoft, облачным сервисам Amazon, сервису микроблогов Twitter, Discord, сервисам Electronic Arts, Blizzard, Steam, веб-сайту Reddit и многим другим.  Причиной сбоя стало то, что CenturyLink, являясь Level3-провайдером, некорректно сформулировал правило BGP Flowspec в протоколе безопасности. BGP Flowspec используется для перенаправления трафика, так что эта ошибка привела к серьезным проблемам с маршрутизацией внутри сети провайдера, что сказалось и на стабильности глобального интернета. Конечно, сильнее всего пострадали пользователи в США, но отголоски проблем ощущались по всему миру. Важно отметить, что CenturyLink является третьей про размерам телекоммуникационной компанией Америки, сразу после AT&T и Verizon. BGP Flowspec по IETF имеет код спецификации RFC 5575 и описан как многопротокольное расширение BGP MP-BGP, которое содержит информацию о доступности сетевого уровня Network Layer Reachability Information (NLRI). BGP FlowSpec — это альтернативный метод сброса атакующего DDoS-трафика с маршрута, который считается более тонким способом уклониться от атаки, нежели RTBH (Remote Triggered Black Hole Filtering), когда блокируется весь трафик с адреса атаки, либо трафик до адреса назначения. Вообще, RTBH, по сути — «оружие судного дня» и является крайним средством для прекращения атаки, так как его применение зачастую позволяет атакующему добиться желаемого, то есть изоляции одного из адресов. BGP FlowSpec действует более тонко и по сути, является фильтром межсетевого экрана, который который вводится в BGP для фильтрации определенных портов и протоколов и определяет, какой трафик по какому маршруту пропускать. Таким образом, «белый» трафик проходит до адреса назначения, а определенный, как DDoS — сбрасывается с маршрута. Трафик анализируется минимум по 12 параметрам NLRI:
Каких-то полноценных отчетов о сбое от самих CenturyLink нет, они только упоминают свой дата-центр недалеко от Онтарио. Однако сбой маршрутизации был достаточно серьезным, чтобы на него обратили внимание не только рядовые пользователи, но и инженеры CloudFlare, которые тоже пользуются услугами CenturyLink как крупного провайдера. Согласно отчету CloudFlare о произошедшем сбое, все началось с резкого роста 522 ошибки в 10:03 по Гринвичу, 30 августа.  Так, автоматической системе ре-машрутизации на случай сбоев удалось сократить количество ошибок и снизить их до 25% от пикового значения, но проблемы со связностью сети и доступностью ресурсов все еще сохранялись и имели глобальный характер. Все это было сделано в окне между 10:03 на начало сбоя и до 10:11 по UTC. За эти восемь минут автоматика и инженеры отключили свою инфраструктуру в 48 (!) городах Северной Америки от CenturyLink и перебросили трафик на резервные каналы других провайдеров. Очевидно, что так поступали не только в CloudFlare. Однако это не позволило полностью решить проблему. Для наглядности, какое влияние проблемный провайдер имеет на телеком-рынок США и Канады, инженеры компании привели официальную карту доступности услуг CenturyLink:  В США провайдером пользуется 49 миллионов человек, а это означает, что для некоторых клиентов, если говорить об отчете CloudFlare, и даже целых дата-центров, CenturyLink является единственным доступным провайдером. В итоге, из-за почти полного падения CenturyLink, специалисты CloudFlare зафиксировали сокращение мирового интернет-трафика на 3,5%. Вот как это выглядело на графике по шести основным провайдерам, с которыми работает компания. CenturyLink на нем — красный.  О том, что сбой был глобальный, а не просто «проблемы в дата-центре под Онтарио», как заявил сам провайдер, свидетельствует и размер обновлений правил Flowspec. Обычно размер обновления конфигураций BGP Flowspec составляет около 2 мегабайт, но специалисты CloudFlare зафиксировали обновления конфигураций BGP размером до 26 Мб (!).  Эти обновления, которые распространяются раз в 15 минут, делятся с узлами сети информацией об изменениях в работоспособности маршрутов. Это позволяет гибко реагировать на какие-то локальные проблемы. Обновления размером в 10-15 раз выше обычных говорят о том, что практически вся сеть провайдера легла или наблюдались крайне серьезные проблемы со связностью. В CloudFlare считают, что причиной сбоя стало некорректное глобальное правило BGP Flowspec, которое получило подавляющее большинство маршрутизаторов, которые потом ушли в реверсивную перезагрузку в попытках восстановить соединение. Это укладывается в картину сбоя, который продолжался более 4 часов. Именно при перегрузке памяти и ЦП маршрутизаторов инженеры могли потерять удаленный доступ к ряду узлов и управляющих интерфейсов. К слову, подобная история — далеко не уникальна. Чуть более года назад интернет по всему миру «прилег» по вине самих CloudFlare и сбоя в работе их DNS, плюс эта же компания честно упоминаето похожих проблемах с Flowspec еще семь лет назад, после которых они отказались от его использования. =========== Источник: habr.com =========== Похожие новости:
Блог компании ITSumma ), #_servernoe_administrirovanie ( Серверное администрирование ), #_setevoe_oborudovanie ( Сетевое оборудование ), #_setevye_tehnologii ( Сетевые технологии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:49
Часовой пояс: UTC + 5