Как GitHub пережил DDoS на 1,35 Тбит/с: цифры до и после

28 февраля 2018 года GitHub пережил DDoS-атаку с пиковым трафиком 1,35 Тбит/с и скоростью 126,9 млн пакетов в секунду. Сервис не стал чинить приложение или срочно добавлять серверы: команда перенаправила трафик через инфраструктуру Akamai, где вредные запросы отфильтровали до попадания в сеть GitHub. Этот случай важен не только рекордным числом, но и тем, какие метрики опубликованы после атаки, а какие разработчикам приходится измерять самостоятельно.

Что произошло с GitHub

Атака использовала отражение через плохо настроенные серверы Memcached. Злоумышленнику не требовалось отправлять к GitHub поток сопоставимого размера: небольшой запрос к открытым серверам мог вызвать значительно более крупный ответ в адрес жертвы.

По отчёту GitHub, пик составил 1,35 Тбит/с. В другой метрике атака достигла 126,9 млн пакетов в секунду. Это разные характеристики одной нагрузки: первая показывает объём данных, вторая — количество отдельных сетевых пакетов и давление на маршрутизаторы, балансировщики и межсетевые экраны.

Команда быстро связалась с Akamai и перенаправила трафик через её систему защиты от DDoS. После этого запросы проходили через внешний слой очистки, а до инфраструктуры GitHub доходил уже отфильтрованный поток.

Главный вывод инцидента: при атаке такого масштаба приложение не может быть первым рубежом защиты. Фильтрация должна происходить раньше, чем трафик займёт канал и ресурсы балансировщика.

Пакеты в секунду (PPS) — количество сетевых пакетов, поступающих за одну секунду. Высокий PPS может перегрузить оборудование даже при сравнительно небольшом объёме данных, потому что каждый пакет требует отдельной обработки.

Цифры до и после переключения

В публичном отчёте GitHub есть данные о мощности атаки и порядке действий, но нет полного набора эксплуатационных метрик. Компания не публикует в этом документе исходные значения задержки, долю ошибок HTTP, загрузку CPU и пропускную способность каждого внутреннего сервиса.

Здесь важно не подменять факт оценкой. Нельзя честно написать, что задержка снизилась на конкретное число миллисекунд или что нагрузка на серверы упала на определённый процент: GitHub таких замеров не раскрыл. Реальный измеримый результат — трафик ушёл на внешний слой защиты, а атака была смягчена без публикации признаков длительной недоступности сервиса.

Почему масштабирование приложения не решило бы проблему

Серверы приложения не были главным ограничением

Если поток достигает сети компании до фильтрации, дополнительные экземпляры приложения не решают проблему. Они могут принять больше валидных HTTP-запросов, но не увеличат пропускную способность интернет-канала и не отменят расходы на обработку миллионов пакетов.

При отражённой атаке источник трафика распределён по сторонним серверам. Блокировка одного IP-адреса почти ничего не даёт, а список адресов быстро меняется. Поэтому защита должна использовать признаки протокола, аномальные объёмы, поведение источников и сетевую фильтрацию на стороне провайдера защиты.

Автоматическое переключение важнее ручного правила

GitHub не стал поддерживать атаку только локальными правилами. Сценарий с Akamai позволил перенаправить поток во внешнюю инфраструктуру, рассчитанную на поглощение и фильтрацию больших объёмов.

Это не означает, что внешний DDoS-сервис автоматически решает все проблемы. До атаки нужно проверить, как меняются DNS или маршруты, кто имеет право включить защиту, сколько занимает переключение и как вернуть обычную схему. Ошибка в этих процедурах может добавить простой к уже работающему инциденту.

Что в этой оптимизации действительно сработало

1. Раннее обнаружение. Команда быстро заметила аномальный трафик и не стала тратить время на изменение бизнес-логики приложения. Проверка результата — поток перестаёт напрямую давить на пограничную инфраструктуру сервиса.
2. Вынос фильтрации за пределы сети GitHub. Akamai приняла на себя обработку атаки. Проверка результата — на origin-серверах остаётся только разрешённый трафик, а не весь входящий объём.
3. Маршрутизация, а не масштабирование вслепую. Добавление серверов не использовалось как универсальная реакция на сетевую атаку. Проверка результата — показатели канала и сетевого оборудования возвращаются в рабочий диапазон.
4. Обновление архитектуры после инцидента. GitHub описал переход к более устойчивой схеме защиты, чтобы повторная атака не требовала такого же ручного согласования. Проверка результата — команда может включить защитный маршрут по заранее проверенному сценарию.

Где такой подход ломается

Внешняя очистка трафика не спасёт сервис, если origin остаётся доступным напрямую. Атакующий обойдёт защитный слой, найдя реальный IP-адрес серверов. После настройки проксирования нужно закрыть вход к origin для всех источников, кроме разрешённых адресов и сетей защитного провайдера.

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

Третий риск — зависимость от DNS и сертификатов. Если схема защиты работает как обратный прокси, сертификаты, записи DNS, заголовки клиента и списки разрешённых адресов должны быть подготовлены заранее. Иначе переключение произойдёт, но приложение начнёт отвечать ошибками конфигурации.

Четвёртый риск — атака на приложение после сетевой фильтрации. DDoS на уровне HTTP может выглядеть как обычные запросы к поиску, авторизации или тяжёлому отчёту. Для него нужны отдельные лимиты, кэширование, защита дорогих операций и наблюдаемость по маршрутам, а не только график входящего трафика.

Какие цифры нужно собирать в собственном сервисе

Публичный отчёт GitHub показывает мощность атаки, но почти не показывает пользовательский опыт. Для своей системы полезно иметь базовую линию минимум за несколько недель до инцидента и сравнивать её с периодом защиты.

• входящий трафик в битах и пакетах в секунду;
• долю ответов 4xx и 5xx отдельно по маршрутам;
• p50, p95 и p99 задержки для главных API-методов;
• загрузку CPU, памяти, соединений и очередей на балансировщиках;
• число запросов к origin после включения фильтрации;
• время от обнаружения атаки до переключения и время возврата в штатную схему.

Сравнение «до и после» имеет смысл только при одинаковых условиях. Если после включения защиты одновременно изменились кэш, тариф, код приложения и размер серверного пула, нельзя приписать весь эффект одному переключению.

Что делать дальше

Начните не с выбора поставщика, а с контрольного сценария. Зафиксируйте допустимый объём трафика, время обнаружения, владельца решения и порядок переключения. Проверьте, что origin недоступен в обход защитного слоя, а мониторинг отдельно показывает входящий поток, очищенный поток и ошибки приложения.

Затем проведите безопасное учение на тестовом домене или с согласованным провайдером. Измерьте время переключения, влияние на задержку, сохранность IP-адреса клиента и работу сертификатов. После этого добавьте в дежурный регламент не только кнопку включения защиты, но и критерии отключения: иначе временный аварийный маршрут может остаться незамеченным в проде.