Рост числа атак на скорость пакетов: когда основные маршрутизаторы становятся злом
Атаки типа «распределенный отказ в обслуживании» (DDoS) — это постоянная угроза, которая продолжает оставаться эффективным способом воздействия на доступность онлайн-сервисов. За последнее десятилетие несколько злоумышленников продемонстрировали, как легко они могут создать армию зомби-устройств с помощью своего ботнета, используя широкий спектр методов: от фишинга до установки вредоносного ПО на настольный хост и использования различных уязвимостей, влияющих на устройства IoT, системы видеонаблюдения или домашние маршрутизаторы.
Эти ботнеты в основном использовались для запуска DDoS-атак, используя десятки тысяч скомпрометированных устройств по всему миру. Стратегия атаки часто одна и та же — генерировать как можно больше пакетов, чтобы максимизировать битрейт или скорость пакетов, перегружая сеть цели. Так было с ботнетом Mirai в 2016 году, который первым сгенерировал более 1 Тбит/с трафика. С тех пор другие ботнеты превзошли Mirai, и трафик достиг 3,47 Тбит/с в 2021 году. Однако атаки, превышающие 1 Тбит/с, были относительно редки — до недавнего времени.
С начала 2023 года наши команды в OVHcloud заметили резкое увеличение DDoS-атак, как по частоте, так и по интенсивности. Более того, начиная с ноября того же года, наблюдалось значительное ускорение тенденции. За последние 18 месяцев мы перешли от атак мощностью 1+ Тбит/с, которые были довольно редкими, к еженедельным, а затем к почти ежедневным (в среднем за одну неделю). Самая высокая скорость передачи данных, которую мы наблюдали в этот период, составила ~2,5 Тбит/с.
Интересно, что недавнее объявление о ликвидации ботнета 911 S5 в период с 25 по 30 мая 2024 года примерно совпадает со значительным снижением DDoS-атак, начавшимся в середине мая. Однако мы не можем с уверенностью утверждать, что эти события связаны между собой.
Хотя частота атак, по-видимому, вернулась к норме, мы по-прежнему наблюдаем большое количество DDoS-атак со скоростью передачи пакетов свыше 100 миллионов пакетов в секунду (Mpps).
Интересно, что недавняя ликвидация ботнета 911 S5 между 25 и 30 мая 2024 года совпала с заметным снижением DDoS-атак, начавшимся в середине мая. Однако мы не можем однозначно сказать, что эти события связаны. Хотя частота атак вернулась к норме, мы все еще наблюдаем значительное количество DDoS-атак с пакетной скоростью, превышающей 100Mpps.
А как насчет атак на скорость пакетов?
Обычно большинство DDoS-атак основаны на отправке большого количества мусорных данных для переполнения полосы пропускания (атаки на сетевом уровне) или отправке большого количества запросов приложений для чрезмерного использования ЦП или памяти (атаки на уровне приложений). Конечно, есть и другие методы, такие как атаки на основе скорости пакетов или атаки на основе пакетов в секунду.
Целью атак на скорость пакетов является перегрузка процессоров обработки пакетов сетевых устройств, расположенных близко к месту назначения, вместо того, чтобы истощать доступную полосу пропускания. Общая идея заключается в том, чтобы парализовать инфраструктуры перед целевой службой (например, балансировщики нагрузки, системы защиты от DDoS и т. д.), таким образом, возможно, повлияв на большую инфраструктуру в качестве сопутствующего ущерба. Проще говоря, вместо того, чтобы пытаться найти дыры в системах защиты от DDoS, просто выведите их из строя!
Атаки на скорость пакетов довольно эффективны, поскольку работа с большим количеством маленьких пакетов обычно сложнее, чем работа с большими, но менее многочисленными пакетами. Это связано с тем, что стоимость вычислений обычно выше. Например, если вы используете программное обеспечение для обработки пакетов, каждый пакет означает как минимум один доступ к памяти (исключая возможное копирование, доступ к сохраненным данным, таким как таблицы соединений и т.д.), вместо простого перебора большего количества байтов.
Если вы используете оборудование, то, хотя производительность обработки пакетов не обязательно зависит от скорости пакетов, конвейер обработки, вероятно, зависит от других компонентов, таких как память (опять же!), которая может быть значительно нагружена высокой скоростью пакетов. В этих условиях вы можете достичь некоторых пределов из-за очень высокой скорости или просто потому, что у вас недостаточно буферов для хранения всего этого, что, вероятно, вызовет задержку или потерю производительности. Мы можем обобщить эту проблему в одном предложении — если ваша работа заключается в том, чтобы иметь дело в основном с полезными нагрузками, пропускная способность может быть жестким ограничением; но если ваша работа заключается в том, чтобы иметь дело в основном с заголовками пакетов, скорость пакетов является жестким ограничением.
Вот почему в большинстве случаев работать с маленькими пакетами сложнее, чем с большими. В двух словах, DDoS-атака 10 Гбит/с с большими пакетами (1480 байт) дает ~0,85Mpps. Для сравнения, 10 Гбит/с с самыми маленькими пакетами (84 байта на проводе для Ethernet) дает колоссальные ~14,88Mpps.
В контексте стандартного интернет-MTU (1500) вы можете разместить в 17 раз больше пакетов на проводе, генерируя только самые маленькие возможные пакеты по сравнению с большими пакетами. Чтобы дать представление о вычислительных возможностях, необходимых в контексте смягчения DDoS, рассмотрим канал 100 Гбит/с, который будет соответствовать скорости линии ~149Mpps. Это позволяет до 6 наносекунд времени обработки на пакет или 18 циклов для одного вычислительного конвейера, работающего на тактовой частоте 3 ГГц. Другими словами, даже с десятками параллельных конвейеров у вас не будет много доступных циклов, особенно если вам нужно получить доступ к некоторой памяти.
Рост числа атак с (большой) скоростью передачи пакетов
DDoS-атаки, основанные на высокой скорости передачи пакетов, не являются чем-то новым, и сетевым операторам по всему миру приходилось сталкиваться с такими атаками по крайней мере один раз. Например, самая высокая публично известная атака с пакетной скоростью была зарегистрирована Akamai в 2020 году и достигла 809Mpps. Несмотря на эту большую цифру, подавляющее большинство атак с пакетной скоростью значительно ниже 100Mpps. Вероятно, это связано с тем, что генерировать несколько небольших пакетов сложнее, чем генерировать большие — вам нужно гораздо больше вычислительной мощности (аналогично обработке) и ее сложнее скрыть от систем мониторинга сети и противодействия злоупотреблениям.
Атаки на скорость пакетов начали привлекать серьезное внимание в OVHcloud два года назад после того, как мы подверглись — но были успешно нейтрализованы — гигантскому потоку UDP, длившемуся более шести часов, достигавшему в среднем ~700 млн пакетов в секунду в течение примерно четырех часов.
За последние 18 месяцев, и особенно за последние шесть месяцев, мы заметили резкое увеличение DDoS-атак, использующих скорость пакетов более 100Mpps. Мы перешли от нейтрализации нескольких из них каждую неделю к десяткам или даже сотням в неделю. Нашим инфраструктурам пришлось нейтрализовать несколько атак 500+Mpps в начале 2024 года, включая одну с пиком в 620Mpps. В апреле 2024 года мы даже нейтрализовали рекордную DDoS-атаку, достигшую ~840Mpps, что немного выше предыдущего рекорда, о котором сообщила Akamai.
Эта атака на 99% состояла из TCP ACK, исходящих примерно из 5000 исходных IP-адресов. Интересно, что оставшийся 1% был атакой отражения DNS, использующей ~15000 DNS-серверов для усиления трафика, что не очень эффективно при попытке достичь атак с высокой скоростью пакетов.
Хотя атака была распространена по всему миру, 2/3 от общего числа пакетов поступило всего из четырех точек присутствия (PoP), все из которых расположены в США, и три из них на Западном побережье. Это подчеркивает способность противника отправлять огромную скорость пакетов всего через несколько пирингов, что может оказаться очень проблематичным. Как правило, команды реагирования на DDoS предполагают, что довольно сложно отправлять массивные DDoS-атаки только из нескольких географических точек. Исходя из этого предположения, наши инфраструктуры масштабируются горизонтально и распространяются по всему миру, поэтому они легче поглощают нагрузку. Однако распределение трафика атаки 840Mpps серьезно поставило это предположение под сомнение. Хотя у нас есть локальные возможности для смягчения этой атаки, мы рассмотрим корректировку общей модели масштабирования и распределения наших инфраструктур против DDoS, чтобы гарантировать, что они справятся с будущими (и, вероятно, более крупными) атаками, как мы делаем это сегодня.
В конце концов, значительный рост атак с высокой скоростью пакетов заставил нас глубоко погрузиться в тему. Как всемирный поставщик облачных услуг, OVHcloud ежедневно отбивает множество DDoS-атак, что дает нам исключительную точку зрения по этой теме. Мы хотели понять, как эти атаки были сгенерированы, откуда они взялись, и, возможно, определить, что мы можем сделать, чтобы лучше защитить наши инфраструктуры и клиентов от такого рода огневой мощи.
Раскрытие вредоносных маршрутизаторов ядра
В ходе нашего анализа мы вручную проверили около сотни атак с пакетной скоростью от 100 до 500Mpps. Мы заметили, что значительная часть трафика исходила из относительно небольшого числа источников. Мы определили список известных IP-адресов, способных генерировать не менее 1Mpps каждый, и решили провести дальнейшее расследование.
Мы проанализировали 70 лучших IP-адресов, выдающих самые высокие скорости пакетов, до 14,8Mpps на IP-адрес. Эти IP-адреса в основном принадлежат автономным системам (AS) в Азии, но также представлены Европа, Ближний Восток, Северная Америка и Южная Америка. Выявленные AS, по-видимому, в основном принадлежат интернет-провайдерам или поставщикам облачных подключений.
Чтобы определить типы устройств, задействованных в этих DDoS-атаках, мы использовали Onyphe для проверки того, были ли IP-адреса уже известны. Многие из этих IP-адресов действительно были распознаны как маршрутизаторы MikroTik, которые, по крайней мере, были открыты для Интернета через свои веб-страницы конфигурации.
На данный момент остается возможность, что этот трафик генерируется серверами, расположенными за маршрутизатором, настроенным с помощью трансляции сетевых адресов (NAT), с использованием поддельных IP-адресов или с использованием какого-то странного отражения TCP. Однако мы быстро отклонили эти гипотезы из-за маловероятности обнаружения столь значительного количества идентифицированных маршрутизаторов MikroTik, учитывая, что MikroTik не занимает пропорционально большую долю мирового рынка.
Кроме того, раскрытие интерфейса администрирования отражает плохие методы управления. Это увеличивает поверхность атаки устройства и может облегчить его взлом злоумышленником. Более того, RouterOS — операционная система MikroTik — пострадала от нескольких критических CVE за последние годы. Даже если был выпущен патч, эти устройства могли еще не быть исправлены.
Поскольку интерфейс HTTP открыт на большинстве устройств, его можно использовать для восстановления версии RouterOS, работающей на этих устройствах. Половина из них работает под управлением версии RouterOS до 6.49.8, выпущенной 23 мая 2023 года, а другая половина — под управлением более поздней версии. Например, были идентифицированы устройства под управлением RouterOS 6.49.14, выпущенной 4 апреля 2024 года.
Мы были удивлены, обнаружив, что устройства с последней прошивкой потенциально скомпрометированы. Насколько нам известно, до сих пор не было опубликовано ни одной уязвимости, влияющей на RouterOS 6.49.14 и более поздние версии. Возможным объяснением может быть то, что эти устройства могли быть исправлены после того, как были скомпрометированы.
Мы пока не можем сказать, почему эти устройства участвуют в скоординированных DDoS-атаках, но одной из возможных гипотез может быть функция проверки пропускной способности в RouterOS. Она позволяет администратору проверить реальную пропускную способность маршрутизатора, создавая пакеты и выполняя стресс-тесты. По совпадению, в документации указано: «До версии RouterOS 6.44beta39 проверка пропускной способности использовала только одно ядро ЦП и достигала своих пределов, когда ядро было загружено на 100%. Проверка пропускной способности [теперь] использует всю доступную пропускную способность (по умолчанию) и может повлиять на удобство использования сети». Это довольно интересно, поскольку среди IP-адресов-нарушителей мы в основном идентифицировали RouterOS v6.44 или выше.
99 382 устройств доступны в Интернете
Используя Simple Network Management Protocol (SNMP) на устройствах, которые его раскрывают, мы смогли определить, какие устройства способны выдавать такую высокую скорость передачи пакетов. Как и ожидалось, это не домашние маршрутизаторы, а скорее основные сетевые устройства.
Используя Simple Network Management Protocol (SNMP) на устройствах, которые его раскрыли, мы смогли определить типы устройств, способных генерировать такие высокие скорости передачи пакетов. Как и ожидалось, это были не домашние маршрутизаторы, а основные сетевые устройства.
Рисунок 6 показывает серию MikroTik Cloud Core Router (CCR). Действительно, SNMP вернул несколько CCR1036-8G-2S+ и CCR1072-1G-8S+
Чтобы получить представление о том, сколько устройств может быть скомпрометировано и использовано в таких массированных DDoS-атаках с пакетной скоростью, мы снова использовали Onyphe для поиска устройств CCR, широко распространенных в Интернете. Было идентифицировано 99 382 устройства CCR.
Наш анализ показывает, что две модели устройств, задействованные в атаках на скорость пакетов, CCR1036-8G-2S+ и CCR1072-1G-8S+, составляют не менее 40 000 устройств, открытых в Интернете. CCR1036-8G-2S+ является наиболее распространенной, с 30 976 обнаруженными случаями, в то время как CCR1072-1G-8S+ занимает четвертое место с 9 353 случаями. Хотя мы пока не знаем конкретную уязвимость, использованную для взлома этих моделей, неясно, могут ли быть затронуты и другие модели CCR. Однако открытие административной панели в Интернете остается значительным риском безопасности.
Еще больше злых моделей?
Благодаря внутреннему обмену данными и обсуждениям мы вспомнили об атаке уровня 7 (L7), которая произошла в ноябре 2023 года. Хотя маршрутизаторы MikroTik были идентифицированы в то время, это не вызвало опасений. Эта атака достигла 1,2 миллиона HTTPS-запросов в секунду и включала около 3000 исходных IP-адресов. Учитывая наши последние выводы, мы решили пересмотреть инцидент.
Чтобы определить, какие типы маршрутизаторов были задействованы, мы извлекли 3000 IP-адресов, связанных с атакой. Предыдущие расследования показали, что около 700 из этих IP-адресов были идентифицированы как маршрутизаторы MikroTik с открытым портом TCP 8291. Однако в то время мы не исследовали конкретные устройства, задействованные в атаке.
Как и прежде, мы провели быстрый поиск с помощью Onyphe, сначала вручную, и нашли похожие результаты: CCR также были вовлечены в эту атаку. Среди IP-адресов, идентифицированных как устройства CCR, более 10% имели публично раскрытый SNMP. И снова мы обнаружили, что основными сетевыми устройствами были целевые устройства — 16% раскрытых устройств были CCR1009-7G-1C-1S+, еще одна похожая модель. Эта модель является второй по степени раскрытия в Интернете, как было отмечено в наших предыдущих выводах.
Определение версии RouterOS, работающей на идентифицированных устройствах восемь месяцев назад, вероятно, не имеет значения, поскольку мы не можем сказать, какая версия была запущена на устройстве в то время. Однако анализ показывает, что 22% устройств работают под управлением RouterOS, выпущенной между 1 июля 2023 года и 1 июля 2024 года. Самая последняя версия — v6.49.15 (24/05/2024), а самая старая — v5.20 (15/08/2012).
К сожалению, у нас больше нет достаточного количества данных, чтобы оценить частоту запросов для каждой модели устройства.
Как упоминалось ранее, до сих пор неясно, как эти устройства были скомпрометированы. Аналогично, сложно определить, связаны ли атаки с высокой скоростью пакетов и атаки L7 или в них был задействован один и тот же ботнет. Тем не менее, идентификация основных сетевых устройств в атаках L7 имеет важное значение, поскольку подчеркивает потенциальную угрозу, которую представляют эти устройства.
Давайте займемся математикой.
Чтобы оценить возможную мощность ботнета, использующего эти устройства, мы решили сосредоточиться на хорошо идентифицируемых атаках на скорость передачи пакетов.
Беглый взгляд на заявленные возможности идентифицированных устройств показывает, что они могут обрабатывать до 28 Гбит/с для CCR1036-8G-2S+ и 80 Гбит/с для CCR1072-1G-8S+. С точки зрения скорости передачи пакетов эти устройства, как утверждается, обрабатывают около теоретической скорости пакетной линии на основе их пропускной способности. Для ясности, соединение 1 Гбит/с может обрабатывать максимум около 1,5 млн пакетов в секунду.
Однако количество пакетов в секунду, которые может генерировать устройство, зависит от того, создает ли оно пакеты (обычно это обрабатывается ЦП) или просто пересылает их (обычно это делают ASIC). Это означает, что фактическая скорость пакетов может быть намного ниже заявленной производительности обработки. Кроме того, генерация трафика с использованием оборудования скомпрометированного устройства сложна, и злоумышленник, скорее всего, будет полагаться на возможности ЦП или повторно использовать встроенные функции для непреднамеренных целей.
В контексте этого мысленного упражнения мы предполагаем, что сетевые устройства способны создавать пакеты со скоростью, равной 10% от их максимальной емкости, что приводит к следующим предположениям:
На этом этапе любой может провести математические расчеты, чтобы построить наивную масштабную модель ботнета, использующего эти устройства. Принимая во внимание показатель в 1% (произвольное консервативное значение) скомпрометированных устройств и сосредоточившись только на первых двух моделях, которые мы определили как скомпрометированные:
С точки зрения пропускной способности запросов в секунду для атак L7 у нас недостаточно данных, чтобы сформировать достаточно сильную гипотезу. Мы можем только утверждать, что эти устройства, по-видимому, способны выполнять атаки L7 и атаки с высокой скоростью пакетов. Попытка оценить возможную пропускную способность L7 остается в качестве упражнения для читателя.
Заключение
Доказательства, представленные в этой статье, указывают на новую тенденцию использования скомпрометированных сетевых основных устройств для запуска мощных атак. Хотя устройства MikroTik и раньше были замешаны в DDoS-атаках, не было никаких предварительных указаний на то, что ботнеты специально полагались на основные сетевые устройства для проведения этих атак.
Хотя любой высокопроизводительный сервер вполне способен генерировать пакетные скорости в таком масштабе, они, вероятно, будут ограничены фактическим объемом доступной общедоступной полосы пропускания. Из-за своего расположения в сети основные устройства гораздо меньше подвержены этому утверждению. Они, как правило, подключены к еще более крупным устройствам с использованием высокопроизводительных сетевых соединений. Более того, меры по смягчению последствий, реализованные сетевыми администраторами для выявления ненормального поведения в сети, например, серверов, инициирующих DDoS-атаки, в этом случае можно обойти, поскольку маршрутизаторы, как правило, не подлежат этим мерам.
В зависимости от количества скомпрометированных устройств и их реальных возможностей это может стать новой эрой для атак с пакетной скоростью. С ботнетами, которые, возможно, способны выдавать миллиарды пакетов в секунду, это может серьезно оспорить то, как строятся и масштабируются инфраструктуры анти-DDoS. Мы обязательно учтем эту новую угрозу, когда будем думать о том, как мы строим и масштабируем наши собственные инфраструктуры анти-DDoS, чтобы быть уверенными, что мы остаемся вне любого возможного воздействия.
Безопасность сетевых устройств является как насущной проблемой, так и актуальной проблемой. С 1 января 2024 года было выпущено более 10 критических CVE, затрагивающих различные сетевые устройства от разных поставщиков (таких как Ivanti, Cisco, Fortinet, Palo Alto и т. д.). Некоторые из них даже эксплуатировались в дикой природе до публичного выпуска CVE. Однако это первый случай, когда мы сталкиваемся с устройствами ядра сети, участвующими в скоординированных DDoS-атаках. Это несколько тревожно, поскольку идентифицированные устройства предназначены для малых и средних сетевых ядер, а сегодня доступно гораздо более мощное оборудование.
Заключительное замечание: Мы обратились к MikroTik по нескольким каналам связи, чтобы рассказать им о ситуации. MikroTik связался с нами 04.07.2024 и расследует возможные причины проблемы.
В настоящее время мы также связываемся с различными AS, чтобы сообщить им о проблеме.
Эти ботнеты в основном использовались для запуска DDoS-атак, используя десятки тысяч скомпрометированных устройств по всему миру. Стратегия атаки часто одна и та же — генерировать как можно больше пакетов, чтобы максимизировать битрейт или скорость пакетов, перегружая сеть цели. Так было с ботнетом Mirai в 2016 году, который первым сгенерировал более 1 Тбит/с трафика. С тех пор другие ботнеты превзошли Mirai, и трафик достиг 3,47 Тбит/с в 2021 году. Однако атаки, превышающие 1 Тбит/с, были относительно редки — до недавнего времени.
С начала 2023 года наши команды в OVHcloud заметили резкое увеличение DDoS-атак, как по частоте, так и по интенсивности. Более того, начиная с ноября того же года, наблюдалось значительное ускорение тенденции. За последние 18 месяцев мы перешли от атак мощностью 1+ Тбит/с, которые были довольно редкими, к еженедельным, а затем к почти ежедневным (в среднем за одну неделю). Самая высокая скорость передачи данных, которую мы наблюдали в этот период, составила ~2,5 Тбит/с.
Интересно, что недавнее объявление о ликвидации ботнета 911 S5 в период с 25 по 30 мая 2024 года примерно совпадает со значительным снижением DDoS-атак, начавшимся в середине мая. Однако мы не можем с уверенностью утверждать, что эти события связаны между собой.
Хотя частота атак, по-видимому, вернулась к норме, мы по-прежнему наблюдаем большое количество DDoS-атак со скоростью передачи пакетов свыше 100 миллионов пакетов в секунду (Mpps).
Интересно, что недавняя ликвидация ботнета 911 S5 между 25 и 30 мая 2024 года совпала с заметным снижением DDoS-атак, начавшимся в середине мая. Однако мы не можем однозначно сказать, что эти события связаны. Хотя частота атак вернулась к норме, мы все еще наблюдаем значительное количество DDoS-атак с пакетной скоростью, превышающей 100Mpps.
А как насчет атак на скорость пакетов?
Обычно большинство DDoS-атак основаны на отправке большого количества мусорных данных для переполнения полосы пропускания (атаки на сетевом уровне) или отправке большого количества запросов приложений для чрезмерного использования ЦП или памяти (атаки на уровне приложений). Конечно, есть и другие методы, такие как атаки на основе скорости пакетов или атаки на основе пакетов в секунду.
Целью атак на скорость пакетов является перегрузка процессоров обработки пакетов сетевых устройств, расположенных близко к месту назначения, вместо того, чтобы истощать доступную полосу пропускания. Общая идея заключается в том, чтобы парализовать инфраструктуры перед целевой службой (например, балансировщики нагрузки, системы защиты от DDoS и т. д.), таким образом, возможно, повлияв на большую инфраструктуру в качестве сопутствующего ущерба. Проще говоря, вместо того, чтобы пытаться найти дыры в системах защиты от DDoS, просто выведите их из строя!
Атаки на скорость пакетов довольно эффективны, поскольку работа с большим количеством маленьких пакетов обычно сложнее, чем работа с большими, но менее многочисленными пакетами. Это связано с тем, что стоимость вычислений обычно выше. Например, если вы используете программное обеспечение для обработки пакетов, каждый пакет означает как минимум один доступ к памяти (исключая возможное копирование, доступ к сохраненным данным, таким как таблицы соединений и т.д.), вместо простого перебора большего количества байтов.
Если вы используете оборудование, то, хотя производительность обработки пакетов не обязательно зависит от скорости пакетов, конвейер обработки, вероятно, зависит от других компонентов, таких как память (опять же!), которая может быть значительно нагружена высокой скоростью пакетов. В этих условиях вы можете достичь некоторых пределов из-за очень высокой скорости или просто потому, что у вас недостаточно буферов для хранения всего этого, что, вероятно, вызовет задержку или потерю производительности. Мы можем обобщить эту проблему в одном предложении — если ваша работа заключается в том, чтобы иметь дело в основном с полезными нагрузками, пропускная способность может быть жестким ограничением; но если ваша работа заключается в том, чтобы иметь дело в основном с заголовками пакетов, скорость пакетов является жестким ограничением.
Вот почему в большинстве случаев работать с маленькими пакетами сложнее, чем с большими. В двух словах, DDoS-атака 10 Гбит/с с большими пакетами (1480 байт) дает ~0,85Mpps. Для сравнения, 10 Гбит/с с самыми маленькими пакетами (84 байта на проводе для Ethernet) дает колоссальные ~14,88Mpps.
В контексте стандартного интернет-MTU (1500) вы можете разместить в 17 раз больше пакетов на проводе, генерируя только самые маленькие возможные пакеты по сравнению с большими пакетами. Чтобы дать представление о вычислительных возможностях, необходимых в контексте смягчения DDoS, рассмотрим канал 100 Гбит/с, который будет соответствовать скорости линии ~149Mpps. Это позволяет до 6 наносекунд времени обработки на пакет или 18 циклов для одного вычислительного конвейера, работающего на тактовой частоте 3 ГГц. Другими словами, даже с десятками параллельных конвейеров у вас не будет много доступных циклов, особенно если вам нужно получить доступ к некоторой памяти.
Рост числа атак с (большой) скоростью передачи пакетов
DDoS-атаки, основанные на высокой скорости передачи пакетов, не являются чем-то новым, и сетевым операторам по всему миру приходилось сталкиваться с такими атаками по крайней мере один раз. Например, самая высокая публично известная атака с пакетной скоростью была зарегистрирована Akamai в 2020 году и достигла 809Mpps. Несмотря на эту большую цифру, подавляющее большинство атак с пакетной скоростью значительно ниже 100Mpps. Вероятно, это связано с тем, что генерировать несколько небольших пакетов сложнее, чем генерировать большие — вам нужно гораздо больше вычислительной мощности (аналогично обработке) и ее сложнее скрыть от систем мониторинга сети и противодействия злоупотреблениям.
Атаки на скорость пакетов начали привлекать серьезное внимание в OVHcloud два года назад после того, как мы подверглись — но были успешно нейтрализованы — гигантскому потоку UDP, длившемуся более шести часов, достигавшему в среднем ~700 млн пакетов в секунду в течение примерно четырех часов.
За последние 18 месяцев, и особенно за последние шесть месяцев, мы заметили резкое увеличение DDoS-атак, использующих скорость пакетов более 100Mpps. Мы перешли от нейтрализации нескольких из них каждую неделю к десяткам или даже сотням в неделю. Нашим инфраструктурам пришлось нейтрализовать несколько атак 500+Mpps в начале 2024 года, включая одну с пиком в 620Mpps. В апреле 2024 года мы даже нейтрализовали рекордную DDoS-атаку, достигшую ~840Mpps, что немного выше предыдущего рекорда, о котором сообщила Akamai.
Эта атака на 99% состояла из TCP ACK, исходящих примерно из 5000 исходных IP-адресов. Интересно, что оставшийся 1% был атакой отражения DNS, использующей ~15000 DNS-серверов для усиления трафика, что не очень эффективно при попытке достичь атак с высокой скоростью пакетов.
Хотя атака была распространена по всему миру, 2/3 от общего числа пакетов поступило всего из четырех точек присутствия (PoP), все из которых расположены в США, и три из них на Западном побережье. Это подчеркивает способность противника отправлять огромную скорость пакетов всего через несколько пирингов, что может оказаться очень проблематичным. Как правило, команды реагирования на DDoS предполагают, что довольно сложно отправлять массивные DDoS-атаки только из нескольких географических точек. Исходя из этого предположения, наши инфраструктуры масштабируются горизонтально и распространяются по всему миру, поэтому они легче поглощают нагрузку. Однако распределение трафика атаки 840Mpps серьезно поставило это предположение под сомнение. Хотя у нас есть локальные возможности для смягчения этой атаки, мы рассмотрим корректировку общей модели масштабирования и распределения наших инфраструктур против DDoS, чтобы гарантировать, что они справятся с будущими (и, вероятно, более крупными) атаками, как мы делаем это сегодня.
В конце концов, значительный рост атак с высокой скоростью пакетов заставил нас глубоко погрузиться в тему. Как всемирный поставщик облачных услуг, OVHcloud ежедневно отбивает множество DDoS-атак, что дает нам исключительную точку зрения по этой теме. Мы хотели понять, как эти атаки были сгенерированы, откуда они взялись, и, возможно, определить, что мы можем сделать, чтобы лучше защитить наши инфраструктуры и клиентов от такого рода огневой мощи.
Раскрытие вредоносных маршрутизаторов ядра
В ходе нашего анализа мы вручную проверили около сотни атак с пакетной скоростью от 100 до 500Mpps. Мы заметили, что значительная часть трафика исходила из относительно небольшого числа источников. Мы определили список известных IP-адресов, способных генерировать не менее 1Mpps каждый, и решили провести дальнейшее расследование.
Мы проанализировали 70 лучших IP-адресов, выдающих самые высокие скорости пакетов, до 14,8Mpps на IP-адрес. Эти IP-адреса в основном принадлежат автономным системам (AS) в Азии, но также представлены Европа, Ближний Восток, Северная Америка и Южная Америка. Выявленные AS, по-видимому, в основном принадлежат интернет-провайдерам или поставщикам облачных подключений.
Чтобы определить типы устройств, задействованных в этих DDoS-атаках, мы использовали Onyphe для проверки того, были ли IP-адреса уже известны. Многие из этих IP-адресов действительно были распознаны как маршрутизаторы MikroTik, которые, по крайней мере, были открыты для Интернета через свои веб-страницы конфигурации.
На данный момент остается возможность, что этот трафик генерируется серверами, расположенными за маршрутизатором, настроенным с помощью трансляции сетевых адресов (NAT), с использованием поддельных IP-адресов или с использованием какого-то странного отражения TCP. Однако мы быстро отклонили эти гипотезы из-за маловероятности обнаружения столь значительного количества идентифицированных маршрутизаторов MikroTik, учитывая, что MikroTik не занимает пропорционально большую долю мирового рынка.
Кроме того, раскрытие интерфейса администрирования отражает плохие методы управления. Это увеличивает поверхность атаки устройства и может облегчить его взлом злоумышленником. Более того, RouterOS — операционная система MikroTik — пострадала от нескольких критических CVE за последние годы. Даже если был выпущен патч, эти устройства могли еще не быть исправлены.
Поскольку интерфейс HTTP открыт на большинстве устройств, его можно использовать для восстановления версии RouterOS, работающей на этих устройствах. Половина из них работает под управлением версии RouterOS до 6.49.8, выпущенной 23 мая 2023 года, а другая половина — под управлением более поздней версии. Например, были идентифицированы устройства под управлением RouterOS 6.49.14, выпущенной 4 апреля 2024 года.
Мы были удивлены, обнаружив, что устройства с последней прошивкой потенциально скомпрометированы. Насколько нам известно, до сих пор не было опубликовано ни одной уязвимости, влияющей на RouterOS 6.49.14 и более поздние версии. Возможным объяснением может быть то, что эти устройства могли быть исправлены после того, как были скомпрометированы.
Мы пока не можем сказать, почему эти устройства участвуют в скоординированных DDoS-атаках, но одной из возможных гипотез может быть функция проверки пропускной способности в RouterOS. Она позволяет администратору проверить реальную пропускную способность маршрутизатора, создавая пакеты и выполняя стресс-тесты. По совпадению, в документации указано: «До версии RouterOS 6.44beta39 проверка пропускной способности использовала только одно ядро ЦП и достигала своих пределов, когда ядро было загружено на 100%. Проверка пропускной способности [теперь] использует всю доступную пропускную способность (по умолчанию) и может повлиять на удобство использования сети». Это довольно интересно, поскольку среди IP-адресов-нарушителей мы в основном идентифицировали RouterOS v6.44 или выше.
99 382 устройств доступны в Интернете
Используя Simple Network Management Protocol (SNMP) на устройствах, которые его раскрывают, мы смогли определить, какие устройства способны выдавать такую высокую скорость передачи пакетов. Как и ожидалось, это не домашние маршрутизаторы, а скорее основные сетевые устройства.
Используя Simple Network Management Protocol (SNMP) на устройствах, которые его раскрыли, мы смогли определить типы устройств, способных генерировать такие высокие скорости передачи пакетов. Как и ожидалось, это были не домашние маршрутизаторы, а основные сетевые устройства.
Рисунок 6 показывает серию MikroTik Cloud Core Router (CCR). Действительно, SNMP вернул несколько CCR1036-8G-2S+ и CCR1072-1G-8S+
Чтобы получить представление о том, сколько устройств может быть скомпрометировано и использовано в таких массированных DDoS-атаках с пакетной скоростью, мы снова использовали Onyphe для поиска устройств CCR, широко распространенных в Интернете. Было идентифицировано 99 382 устройства CCR.
Наш анализ показывает, что две модели устройств, задействованные в атаках на скорость пакетов, CCR1036-8G-2S+ и CCR1072-1G-8S+, составляют не менее 40 000 устройств, открытых в Интернете. CCR1036-8G-2S+ является наиболее распространенной, с 30 976 обнаруженными случаями, в то время как CCR1072-1G-8S+ занимает четвертое место с 9 353 случаями. Хотя мы пока не знаем конкретную уязвимость, использованную для взлома этих моделей, неясно, могут ли быть затронуты и другие модели CCR. Однако открытие административной панели в Интернете остается значительным риском безопасности.
Еще больше злых моделей?
Благодаря внутреннему обмену данными и обсуждениям мы вспомнили об атаке уровня 7 (L7), которая произошла в ноябре 2023 года. Хотя маршрутизаторы MikroTik были идентифицированы в то время, это не вызвало опасений. Эта атака достигла 1,2 миллиона HTTPS-запросов в секунду и включала около 3000 исходных IP-адресов. Учитывая наши последние выводы, мы решили пересмотреть инцидент.
Чтобы определить, какие типы маршрутизаторов были задействованы, мы извлекли 3000 IP-адресов, связанных с атакой. Предыдущие расследования показали, что около 700 из этих IP-адресов были идентифицированы как маршрутизаторы MikroTik с открытым портом TCP 8291. Однако в то время мы не исследовали конкретные устройства, задействованные в атаке.
Как и прежде, мы провели быстрый поиск с помощью Onyphe, сначала вручную, и нашли похожие результаты: CCR также были вовлечены в эту атаку. Среди IP-адресов, идентифицированных как устройства CCR, более 10% имели публично раскрытый SNMP. И снова мы обнаружили, что основными сетевыми устройствами были целевые устройства — 16% раскрытых устройств были CCR1009-7G-1C-1S+, еще одна похожая модель. Эта модель является второй по степени раскрытия в Интернете, как было отмечено в наших предыдущих выводах.
Определение версии RouterOS, работающей на идентифицированных устройствах восемь месяцев назад, вероятно, не имеет значения, поскольку мы не можем сказать, какая версия была запущена на устройстве в то время. Однако анализ показывает, что 22% устройств работают под управлением RouterOS, выпущенной между 1 июля 2023 года и 1 июля 2024 года. Самая последняя версия — v6.49.15 (24/05/2024), а самая старая — v5.20 (15/08/2012).
К сожалению, у нас больше нет достаточного количества данных, чтобы оценить частоту запросов для каждой модели устройства.
Как упоминалось ранее, до сих пор неясно, как эти устройства были скомпрометированы. Аналогично, сложно определить, связаны ли атаки с высокой скоростью пакетов и атаки L7 или в них был задействован один и тот же ботнет. Тем не менее, идентификация основных сетевых устройств в атаках L7 имеет важное значение, поскольку подчеркивает потенциальную угрозу, которую представляют эти устройства.
Давайте займемся математикой.
Чтобы оценить возможную мощность ботнета, использующего эти устройства, мы решили сосредоточиться на хорошо идентифицируемых атаках на скорость передачи пакетов.
Беглый взгляд на заявленные возможности идентифицированных устройств показывает, что они могут обрабатывать до 28 Гбит/с для CCR1036-8G-2S+ и 80 Гбит/с для CCR1072-1G-8S+. С точки зрения скорости передачи пакетов эти устройства, как утверждается, обрабатывают около теоретической скорости пакетной линии на основе их пропускной способности. Для ясности, соединение 1 Гбит/с может обрабатывать максимум около 1,5 млн пакетов в секунду.
Однако количество пакетов в секунду, которые может генерировать устройство, зависит от того, создает ли оно пакеты (обычно это обрабатывается ЦП) или просто пересылает их (обычно это делают ASIC). Это означает, что фактическая скорость пакетов может быть намного ниже заявленной производительности обработки. Кроме того, генерация трафика с использованием оборудования скомпрометированного устройства сложна, и злоумышленник, скорее всего, будет полагаться на возможности ЦП или повторно использовать встроенные функции для непреднамеренных целей.
В контексте этого мысленного упражнения мы предполагаем, что сетевые устройства способны создавать пакеты со скоростью, равной 10% от их максимальной емкости, что приводит к следующим предположениям:
- CCR1036-8G-2S+ должен иметь возможность генерировать 4Mpps каждый
- CCR1072-1G-8S+ должен иметь возможность генерировать 12Mpps каждый
На этом этапе любой может провести математические расчеты, чтобы построить наивную масштабную модель ботнета, использующего эти устройства. Принимая во внимание показатель в 1% (произвольное консервативное значение) скомпрометированных устройств и сосредоточившись только на первых двух моделях, которые мы определили как скомпрометированные:
- ~ 300x CCR1036-8G-2S+ / 4Mpps каждый
- ~ 90x CCR1072-1G-8S+ / 12Mpps каждый
С точки зрения пропускной способности запросов в секунду для атак L7 у нас недостаточно данных, чтобы сформировать достаточно сильную гипотезу. Мы можем только утверждать, что эти устройства, по-видимому, способны выполнять атаки L7 и атаки с высокой скоростью пакетов. Попытка оценить возможную пропускную способность L7 остается в качестве упражнения для читателя.
Заключение
Доказательства, представленные в этой статье, указывают на новую тенденцию использования скомпрометированных сетевых основных устройств для запуска мощных атак. Хотя устройства MikroTik и раньше были замешаны в DDoS-атаках, не было никаких предварительных указаний на то, что ботнеты специально полагались на основные сетевые устройства для проведения этих атак.
Хотя любой высокопроизводительный сервер вполне способен генерировать пакетные скорости в таком масштабе, они, вероятно, будут ограничены фактическим объемом доступной общедоступной полосы пропускания. Из-за своего расположения в сети основные устройства гораздо меньше подвержены этому утверждению. Они, как правило, подключены к еще более крупным устройствам с использованием высокопроизводительных сетевых соединений. Более того, меры по смягчению последствий, реализованные сетевыми администраторами для выявления ненормального поведения в сети, например, серверов, инициирующих DDoS-атаки, в этом случае можно обойти, поскольку маршрутизаторы, как правило, не подлежат этим мерам.
В зависимости от количества скомпрометированных устройств и их реальных возможностей это может стать новой эрой для атак с пакетной скоростью. С ботнетами, которые, возможно, способны выдавать миллиарды пакетов в секунду, это может серьезно оспорить то, как строятся и масштабируются инфраструктуры анти-DDoS. Мы обязательно учтем эту новую угрозу, когда будем думать о том, как мы строим и масштабируем наши собственные инфраструктуры анти-DDoS, чтобы быть уверенными, что мы остаемся вне любого возможного воздействия.
Безопасность сетевых устройств является как насущной проблемой, так и актуальной проблемой. С 1 января 2024 года было выпущено более 10 критических CVE, затрагивающих различные сетевые устройства от разных поставщиков (таких как Ivanti, Cisco, Fortinet, Palo Alto и т. д.). Некоторые из них даже эксплуатировались в дикой природе до публичного выпуска CVE. Однако это первый случай, когда мы сталкиваемся с устройствами ядра сети, участвующими в скоординированных DDoS-атаках. Это несколько тревожно, поскольку идентифицированные устройства предназначены для малых и средних сетевых ядер, а сегодня доступно гораздо более мощное оборудование.
Заключительное замечание: Мы обратились к MikroTik по нескольким каналам связи, чтобы рассказать им о ситуации. MikroTik связался с нами 04.07.2024 и расследует возможные причины проблемы.
В настоящее время мы также связываемся с различными AS, чтобы сообщить им о проблеме.
