Как мощная DDoS-атака не стала для нас форс-мажором. Ну почти

Привет, Хабр. 19 июня мы в Т1 Облако отражали первую массированную DDoS-атаку одновременно на множество IP-адресов, зарегистрированных на нас. Ботнет атаковал наш транспортный, сетевой и прикладной уровень. На пике мы зафиксировали более 50 Гбит/с входящего трафика. Длилось это не самое приятное событие почти 3 часа.

В этом посте расскажем, как прошла атака, какие инструменты помогли нам её отразить, насколько эффективными они оказались и какие выводы мы сделали после. Добро пожаловать под кат.

Подробности атаки

19 июня, в среду, наступило солнечное утро, которое не предвещало ничего необычного. Но это было затишье перед бурей. В 9:30 на множество IP-адресов, зарегистрированных на Т1 Облако, посыпалась массированная DDoS-атака.

Атака повлияла на все сетевые ресурсы пользователей нашего облака, имеющие публичные сетевые адреса, а также корпоративные сервисы VPN. Каналы связи с интернетом были перегружены. Это вызвало потерю трафика для всех клиентов, за исключением тех, кто защищается с помощью нашего сервиса Anti‑DDoS, так как у них есть выделенные каналы связи с провайдерами защиты. Вредоносный трафик переполнил каналы к вышестоящим провайдерам и привёл к перегрузке программных эджей VMware, что послужило вторичным фактором отказа для ВМ на этой платформе.

Судя по множеству целей, атаковали всю нашу компанию, а не какого‑то конкретного клиента, как это бывало ранее.

Немного предыстории

Мы постоянно наблюдали и наблюдаем за различными киберугрозами. Операторы связи и банки отбиваются от DDoS‑атак ежегодно. Можно вспомнить, как в октябре 2023 года хакеры совершили самую массированную за всю историю атаку на сайт крупного банка.

Очевидно, что облачные провайдеры, которые обеспечивают функционирование десятков тысяч систем и сервисов у сотен разных заказчиков, являются лакомой целью. Мы об этом задумались, начали готовиться и всё ждали, когда к этой мысли придут «киберзлодеи». И в конце 2023 года они до этого додумались. Атаки на облачных провайдеров участились примерно полгода назад.

Полагаем, дело было так. Хакеры составили список облачных провайдеров и по каждому собрали перечень IP‑адресов, зарегистрированных на эти компании. Такие данные есть в открытых источниках, например, в RIPE. Там можно получить полный список всех сетей и адресов, которые выделены тому или иному провайдеру. Этим пользуются инженеры, технари и, к сожалению, всякие злоумышленники. Допускаем, что хакеры использовали либо RIPE, либо аналог, и начали по очереди атаковать облачных провайдеров. И мы тоже попали в эту очередь.

В общем, у нас не было иллюзий, что DDoS‑ы обойдут нас стороной.

Как мы готовились и какой опыт у нас был

• Мы заранее определили наиболее критичные объекты в инфраструктуре нашего облака. В частности, это был наш единый интерфейс для управления облачными сервисами. Поставили его под защиту с помощью сервиса Anti‑DDoS.

• Наши архитекторы придумали, как соединить сервис WAF c Anti‑DDoS по тёмной оптике, чтобы WAF не становился точкой отказа.

• С точки зрения защиты сети мы, как и любой провайдер, могли «блэкхолить» атакуемые адреса (black hole routing). Кстати, этой возможностью мы уже пользовались прошлой весной, когда атаковали одного из наших заказчиков. На его IP‑адрес «лились» 7–8 Гбит/с, что могло повлиять на других наших заказчиков, использовавших те же самые программные эджи, что и жертва. На уровне операторов мы отключили отправку трафика на этот адрес и защитили наши внешние каналы. Правда, у этого механизма есть побочный эффект: недоступность IP‑адреса жертвы и, соответственно, сервиса у клиента. Но всё же это наименьшее из зол, потому что такая блокировка предотвратила недоступность всех остальных заказчиков. Юридически мы этот механизм отработали на уровне договоров на облачные услуги.

• Научились обнаруживать атакуемый адрес, так как в момент атаки виден только огромный входящий трафик. С помощью GeoIP определяем, какие автономные системы (AS) или страны являются источниками трафика.

• В системе мониторинга настроили оповещения на резкое превышение среднего уровня трафика. Выбрали в качестве порога средний уровень, потому что в течение суток нагрузка меняется: днём она в 5–6 раз больше, чем ночью.

• Подключили услугу фильтрации трафика от операторов связи. В частности, магистральные операторы легко отражают DDoS‑атаки уровня L3–4.

• Рекомендуем всем нашим заказчикам ставить их критичные сервисы под защиту Anti‑DDoS.

Как мы отбили атаку 19 июня

Мы выбирали те средства защиты от DDoS, которые посчитали самыми действенными в конкретной ситуации.

Сразу после начала атаки сработали настроенные оповещения. Дежурная смена сообщила о DDoS. Мы посмотрели график внешнего трафика и увидели поток свыше 40 Гбит/с. На самом деле о реальном общем объёме атаки мы могли только догадываться, поскольку увидели лишь тот трафик, который шёл к нам через нескольких операторов.

Попытались выявить жертву. Быстро поняли, что нет одной цели, ботнет атакует всю сеть. В такой ситуации нет смысла что-то «блэкхолить», потому что просто выключишь всю сеть, а это только поможет атакующим достичь цели.

Тогда мы попробовали отсекать входящий трафик по GeoIP. Выяснили, что основной поток идёт из автономной системы Google. C помощью BGP community попросили наши аплинки не анонсировать наши сети в AS Google. Тогда мы смогли отсечь довольно большой объём трафика.

Через час-полтора после того как мы перестали анонсировать сети в AS Google, у наших внешних клиентов, которые пользуются Google DNS, перестали резолвиться IP-адреса некоторых ресурсов: Google DNS после истечения времени жизни кеша не мог обратиться к нашим NS, так как в результате мероприятий по отражению атаки мы потеряли связность с сетями Google. У тех, кто пользуется отечественными DNS-серверами, всё работало стабильно. Здесь можем порекомендовать диверсифицировать использование сервиса DNS. Свои серверы DNS есть у любого российского интернет-провайдера.

Параллельно мы пользовались защитой от магистральных операторов связи — услугой фильтрации трафика. Но это защищает от DDoS-атак на уровне L3-4, а на более высоких уровнях метод не сработает. Чем тогда пользоваться? Мы точно знаем, что атака не затронула клиентов, которые подключились к нашим сервисам Anti-DDoS. Когда хакер атакует ресурс, который стоит под защитой, весь его нелегитимный трафик прилетает не к нам в облако, а в провайдера Anti-DDoS. Там он проходит фильтрацию, и по выделенному каналу к клиенту поступает уже очищенный трафик.

Откуда шла атака

Согласно анализу инцидента, который мы получили от нашего партнёра, 90 % трафика шло из-за рубежа и небольшая часть — из России. Кто именно инициировал атаку, мы пока точно не знаем, так как трафик шёл из многих источников, и не от злоумышленников, а от утюгов, пылесосов и других подключённых к интернету устройств посредников-ботнетов. Но определённые паттерны указывают на группу хактивистов, известных своими многочисленными атаками на веб-ресурсы российских банков, бирж и страховых сервисов.

Благодаря слаженным действиям критичных последствий не было, а те сервисы, которые стояли под нашим Anti-DDoS, и вовсе не пострадали от атаки.

Какие выводы мы сделали

Это была первая, но не последняя атака на все ресурсы и внешние сервисы облака и наших клиентов. Печально, но факт: скорее всего, такие DDoS-атаки будут продолжаться с определённой периодичностью.

Перепроверили, что под защитой Anti-DDoS стоят все критически важные ресурсы и внешние сервисы, которые есть в облаке. Рекомендуем всем сделать то же самое.

Продолжили совершенствование внутренних систем защиты, а также расширение внешних каналов связи.

Продолжили создавать резервные VPN с адресами не из наших диапазонов для обеспечения доступа инженерного персонала к инфраструктуре при подобных атаках.

Продолжили регулярно делать пентесты и сканы. Разве что массированную атаку на самих себя ещё не проводили. Хотя, если задуматься, зарубежный ботнет сделал это для нас бесплатно.

Как уже сказали выше, мы будем напоминать пользователям, что не нужно пользоваться только DNS-серверами от Google и других зарубежных провайдеров. Это поможет избежать рисков в случае недоступности зарубежных DNS-ресурсов, в том числе по не зависящим от нас причинам.

Авторы:

• Алексей Кубарев, директор по ИБ

• Игорь Плотников, руководитель направления сервисов ИБ

• Илья Пекшев, архитектор по ИБ

• Михаил Дьяконов, руководитель отдела эксплуатации сети