все новости по филиалам
Поиск
We added new capacity in Francfort, DE. Ready to add new 100G
164.132.0.0/16
Черная пятница, скидки до 50% на облачные решения!
Публичное облако / Хранилище / Блок / Высокопроизводительный
Наш новый бэкэнд на основе NVMe-oF для блочного хранилища теперь доступен бесплатно в бета-версии только в наших центрах обработки данных GRA 11 и SBG 7, и мы ищем бета-тестеров, которые помогут его усовершенствовать! Это распределенное блочное хранилище на основе технологии Exten.
Классические тома:
Высокоскоростные объемы:
Что нового?
Почему бета-тест?
Как принять участие?
Классические тома:
- Размеры: от 100 ГБ до 12 ТиБ
- 500 IOPS на том
- До 64 МБ/с на том
Высокоскоростные объемы:
- Размеры: от 10 ГБ до 12 ТиБ
- 3000 IOPS на том
- До 128 МБ/с на том
Что нового?
- Повышение производительности: классические тома улучшены с 250 до 500 IOPS
- Увеличенная емкость: до 12 ТиБ на том
- Оптимизирован для масштабирования: улучшен для управления большими объемами
- Повышенная устойчивость: внедрение стирающего кодирования для более надежной и надежной модели хранения
Почему бета-тест?
- Производительность бэкэнда NVMe-oF: посмотрите, как он интегрируется с различными средами
- Функциональность API: тестирование с помощью API OpenStack Cinder
- Крупномасштабное управление: оценка производительности и управления расширенными мощностями
- Максимальная емкость: протестируйте новый лимит в 12 ТиБ в реальных сценариях
Как принять участие?
- Доступ к бета-версии через панель управления OVHcloud
- Поделитесь отзывами на GitHub или Discord
- Более подробную информацию можно найти на странице «Лаборатории».
Менеджер / IPv4 IPv6
Дополнительного заказа IP для парковки (т.е. теперь клиент может заказать несколько IPv4 для парковки, чтобы позже подключить их к своим услугам, предвидя потребности в масштабировании инфраструктуры)
В процессе заказа дополнительного IP-адреса просто выберите парковку IP-адресов в качестве целевой услуги и целевой регион, в котором такой дополнительный IP-адрес будет доступен для использования (а также для перемещения).
Дополнительный заказ IP напрямую с подключением к сети vRack (т.е. заказ IPv4 напрямую в сети vRack для гибкого управления дополнительными общедоступными IP-адресами таким образом)
Это было возможно для Additinoal IPv6, но не для IPv4. Теперь мы унифицируем опыт.
В процессе заказа дополнительного IP-адреса просто выберите целевую сетевую службу vRack и целевой регион, в котором будет настроен такой дополнительный IP-адрес (который также можно перемещать).
Отличные поля поиска для IP-сервисов и IP-менеджмента также доступны некоторое время! (небольшое напоминание). Теперь вы можете вводить данные для поиска в полях «Сервис» или «Все сервисы»
на странице списка IP-адресов для быстрого поиска интересующих вас IP-адресов (по имени сервиса, идентификатору сервиса, имени или идентификатору сети vRack, имени или идентификатору проекта PCI и т.д.!)
В процессе заказа дополнительного IP-адреса просто выберите парковку IP-адресов в качестве целевой услуги и целевой регион, в котором такой дополнительный IP-адрес будет доступен для использования (а также для перемещения).
Дополнительный заказ IP напрямую с подключением к сети vRack (т.е. заказ IPv4 напрямую в сети vRack для гибкого управления дополнительными общедоступными IP-адресами таким образом)
Это было возможно для Additinoal IPv6, но не для IPv4. Теперь мы унифицируем опыт.
В процессе заказа дополнительного IP-адреса просто выберите целевую сетевую службу vRack и целевой регион, в котором будет настроен такой дополнительный IP-адрес (который также можно перемещать).
Отличные поля поиска для IP-сервисов и IP-менеджмента также доступны некоторое время! (небольшое напоминание). Теперь вы можете вводить данные для поиска в полях «Сервис» или «Все сервисы»
на странице списка IP-адресов для быстрого поиска интересующих вас IP-адресов (по имени сервиса, идентификатору сервиса, имени или идентификатору сети vRack, имени или идентификатору проекта PCI и т.д.!)
Рост числа атак на скорость пакетов: когда основные маршрутизаторы становятся злом
Атаки типа «распределенный отказ в обслуживании» (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, чтобы сообщить им о проблеме.
OVHcloud не уходит с фондового рынка
Я получаю сообщения с поздравлениями и разочарованием по поводу предполагаемого ухода OVHcloud с фондового рынка!? Но, но… OVHcloud не уходит с фондового рынка!
Мы объявили об OPRA, что означает публичное предложение о выкупе акций, а не об OPA, которое является публичным предложением о покупке. Конкретно это означает, что OVHcloud выкупит собственные акции у акционеров, желающих их продать, но без каких-либо обязательств: каждый волен продавать или нет. В отличие от предложения о поглощении, за которым может последовать выкуп, никто не принуждается продавать свои акции.
Бюджет этого OPRA установлен в размере 350 миллионов евро. Это означает, что:
- Если количество выставленных на продажу акций меньше этой суммы, OVHcloud потратит меньше средств на выкуп.
- Если больше акционеров захотят продать, чем бюджет в 350 миллионов евро, OVHcloud не выйдет за рамки этой суммы. В этом случае акции будут выкуплены пропорционально доле каждого акционера. Правила пропорционального распределения могут показаться нелогичными, поэтому не стесняйтесь узнать о конкретном принципе пропорционального распределения в OPRA и, в более общем плане, прочитать проект информационной записки, опубликованный на нашем сайте, который содержит всю информацию, касающуюся OPRA, и который остается предметом проверки со стороны Управления по финансовым рынкам (AMF).
Наконец, если АИФ даст свое согласие на эту операцию, часть акций останется в обращении на Парижской фондовой бирже для акционеров, которые решили сохранить свои акции.
А OVHcloud? Где мы? Вот где мы находимся, по моему мнению.
Я основал OVH без денег, потому что у меня их не было. За 15 лет я руководил тремя пятилетними стратегическими планами, всегда с положительным свободным денежным потоком, не привлекая средств, просто реинвестируя заработанное. Старая школа. Хорошая школа.
Затем я решил реализовать 10-летний или два пятилетних стратегических плана с отрицательным свободным денежным потоком. Мы компенсировали большие вложения благодаря капиталу, предоставленному инвесторами: 250 М € + 350 М €, или 600 М €.
Эти 10 лет были необходимы для ускорения развития OVHcloud. С 2016 по 2020 год мы смогли инвестировать в многочисленные новые центры обработки данных и укрепить свое глобальное присутствие. С 2021 по 2025 год мы инвестировали в программное обеспечение для создания 40 продуктов публичного облака.
Всего за несколько лет мы увеличились вдвое – спасибо, Мишель! – и сейчас мы приближаемся к концу этого периода отрицательного свободного денежного потока. Я хочу, чтобы мы вернулись к роли «хорошего отца»: инвестируем то, что зарабатываем, не более того. Да, я немного старомоден, я знаю.
Несколько слов о публичном облаке: мы думали отказаться от всей дорожной карты в период с 2021 по 2024 год. Короче говоря, идите быстрее. Имея +300 разработчиков за 18 месяцев, приобретенных 5 стартапов, мы все равно двигались быстро, но после 3 лет работы, надо признать, нам еще осталось немного поработать, чтобы закончить все разработки. Я бы сказал, около 12-24 месяцев.
Поэтому мы продолжаем усердно работать над тем, чтобы завершить и предложить нашим клиентам эти 40 продуктов Public Cloud в 7 регионах, каждый регион в форме 3 AZ (3 DC) в версии ISO27000 (гражданская) и версии SecNumCloud (военная).
Кроме того, присоединяйтесь к нам на Саммите 28 ноября, чтобы узнать больше!
summit.ovhcloud.com/en-ie/
Несмотря на более длительные, чем ожидалось, сроки, наши инвестиции в публичное облако продолжаются, поскольку наши клиенты просят нас об этих 40 продуктах, и поэтому мы приложим все усилия, чтобы их доставить.
В то же время мы сохраняем четкую видимость роста частного облака и извлекаем из него выгоду благодаря инновациям, строгому управлению и экономии за счет масштаба.
Другими словами, теперь мы можем финансировать все эти инвестиции в публичное облако благодаря доходам от частного облака и даже снова получить положительный денежный поток с 26 финансового года, если все пойдет хорошо. Это безумие, но это правда!
В 26 финансовом году мы будем, как и в начале OVH, в течение первых 15 лет, снова свободными от любой зависимости от внешнего капитала, но на этот раз оставаясь публичной компанией, котирующейся на фондовой бирже, со строгой обязанностью хорошо инвестировать каждый евро. Я очень хочу! Спасибо всем нашим клиентам, которые поддерживают нас и всегда за нас!
С начала сентября мы с Бенджамином, новым генеральным директором OVHcloud, решили развивать мой вклад в течение следующих 18 месяцев. Мне понадобится 3 x 6 месяцев, чтобы повторно просканировать всю коробку: сначала отрасль, затем продукт и, наконец, торговлю. Цель состоит в том, чтобы дать совет Бенджамину и предложить изменения, которые устранят наши опасения и еще больше ускорят работу, все, что можно ускорить.
Мы должны поставить эти темы в центр: цифровой опыт клиентов, менеджер, выставление счетов, мы также должны улучшить поддержку, снизить цены, быстрее внедрять инновации, ускорить реализацию планов, развернуть все наши продукты во всех центрах обработки данных, чтобы предложить их всем. клиенты… Я сделаю предложения по этим вопросам Бенджамину, чтобы он и команды могли их выполнить, чтобы это приобрело форму в ближайшие кварталы :)
Все это говорит о том, что мне очень приятно, что мы запускаем эту OPRA, продолжая делать все, что уже делаем. OVHcloud в конечном итоге станет европейской альтернативой облаку с реальным каталогом продуктов публичного облака и размещенного частного облака, продолжая при этом инвестировать в Baremetal Cloud и Web Cloud.
29 ноября на саммите мы сделаем множество анонсов по нашим 4 продуктам для гражданского и военного использования.
Я не говорю этого достаточно: Спасибо! Спасибо всем нашим клиентам за их доверие, их требования, их способность всегда подталкивать нас вперед и помогать нам расти. OVHcloud каждый день борется вместе с крупнейшими компаниями мира. Это нормально, что некоторые люди сомневаются или не понимают, как мы этого добиваемся, но главное, что мы, команда OVHcloud, знаем, как этого добиться, и что наши клиенты поддерживают нас в этом невероятном приключении! Это единственные условия успеха – и они у нас есть :)
СПАСИБО! Мы знаем, что осталось сделать: приступить к работе ;)
OVHcloud теперь в Италии! Скоро будет пинг
