Любые опубликованные в интернете сервисы, службы и приложения (сайты, файловые хранилища, API, шлюзы) подвержены DDoS-атакам. Не важно, размещены они на вашем сервере или в облаке, их надо защищать. 

Я Руслан Корнев — эксперт по сервисам информационной безопасности в Cloud.ru. Многие компании размещают свои веб-приложения в нашем облаке. А мы предоставляем вычислительные ресурсы, хранилище данных и защищаем инфраструктуру, чтобы усилить безопасность облачных сервисов и доступность пользовательских ресурсов. В статье расскажу про зоны ответственности по защите ресурсов со стороны клиента и провайдера, а также варианты защиты от DDoS-атак в облаке на примере Cloud.ru.

Когда мы обсуждаем с клиентами тему кибербезопасности, иногда слышим такие мнения: 

1. Наш ресурс вряд ли нужно защищать от DDoS-атак. 

2. Приложению в облаке достаточно инфраструктурной защиты облачного провайдера.

3. Подключить защиту от DDoS можно и в момент атаки.

Согласно аналитическому отчету компании StormWall, по итогам первого квартала 2024 года количество DDoS-атак в России увеличилось на 73% по сравнению с первым кварталом 2023 года. Кроме того, в пять раз выросло среднее количество устройств в ботнетах — с 4 000 до 20 000 устройств. Ботнеты являются одним из ключевых инструментов злоумышленников, запускающих DDoS-атаки, поэтому можно смело прогнозировать, что количество и мощность атак по итогам текущего года также вырастет. Наиболее уязвимыми отраслями в первом квартале стали госсектор (34%), онлайн-игры (21%) и телеком (14%). А самая мощная остановленная атака в первом квартале 2024 года достигала 1,4 Тбит/с.

Реальные истории доказывают, что целью хакеров может стать кто угодно: онлайн-магазин, игровой сервис, авиакомпания, больница, вуз. И цель атаки не всегда деньги. Ее могут использовать, например, как отвлекающий маневр для кражи данных, чтобы испортить репутацию конкурента или просто ради развлечения. 

По истории DDoS-атак видно, что меняются тактика и внимание к отраслям, а число и мощность атак неизменно растет.

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

У облачного провайдера нет доступа к ресурсам, размещенным клиентами в облаке. Так что за защиту своих виртуальных машин, арендованных публичных IP-адресов, приложений и данных отвечает сам заказчик. 

Отразить DDoS-атаку в интересах облачного провайдера независимо от того, есть у клиента защита или нет. Но зона его ответственности — облачная инфраструктура, а не конкретное приложение клиента, развернутое на виртуальной машине. 

Лучше относиться к защите от DDoS как страховке КАСКО, которая не факт, что пригодится, но, если случится ДТП, сильно поможет. Нельзя купить страховку после аварии, а без полиса ущерб не возместят. Аналогично с защитой от DDoS: если ресурс попадет под атаку и будет недоступен какое-то время, вернуть ушедших клиентов будет сложно.

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

Виды DDoS-атак по механизму действия

Единой классификации DDoS-атак нет: можно сгруппировать атаки в зависимости от уровня модели OSI или протоколу, с использованием которого совершается атака, или механизму воздействия. Для более легкого восприятия ниже разделим атаки на две группы исходя из объекта атаки. 

Атаки на исчерпание канала доступа в интернете

Для них характерен очень большой поток трафика, часто это сотни или даже тысячи Гбит/с. Цель таких атак — заполнить канал доступа и не позволить легитимным пользователям достучаться до приложения. Сюда же можно отнести атаки на промежуточные сетевые узлы, например, исчерпание ресурса межсетевого экрана TCP-флудом.

Есть техники, которые генерируют огромные объемы трафика без существенных затрат для атакующего, например, амплификация трафика через уязвимые протоколы. 

Эффективно защититься от этого вида атаки возможно только с помощью специальных сервисов защиты:

1. Сервисы оператора связи, которые фильтруют входящий трафик по портам атаки на пограничных маршрутизаторах, настраивая ACL вручную или распространяя их по сети через BGP Flowspec. Такой метод эффективен при атаках, созданных путем амплификации трафика, но практически бесполезен при более сложных атаках на уровне L7.

2. Сервисы провайдеров защиты, которые специализируются на фильтрации трафика на всех уровнях модели OSI с использованием распределенными по миру центрами очистки.

Атаки на исчерпание серверных ресурсов

Речь про CPU, оперативную память, дисковое пространство, TCP-порты сетевого стека. Например, атака SSL/TLS Exhaustion направлена на веб-ресурсы с шифрованием и эксплуатирует процесс установки SSL, являющийся крайне CPU-ресурсоемким; атака Low and Slow эмулирует поток низкоскоростных клиентов, занимая и удерживая ресурсы веб-сервера.

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

Как защитить от DDoS веб-ресурс в облаке: варианты 

Защиту от DDoS-атак в облаке можно построить несколькими способами:

• на сервисах операторов связи,

• на сервисах провайдеров защиты,

• с помощью ПО или ПАК в собственном центре очистки трафика (on-premise). 

Можно подключить один сервис, а можно организовать многоуровневую защиту. Любой вариант поможет защитить канал доступа в интернет, сетевую инфраструктуру и веб-ресурсы. Но необходимо понимать, что даст каждый из способов защиты.

Сервис оператора связи — базовая защита от DDoS-атак, которая нужна любому приложению. Максимальная емкость фильтруемой атаки у операторов связи ограничена производительностью пограничных маршрутизаторов. У крупнейшего российского оператора связи это тысячи Гбит/с грубой очистки (на L3-L4 OSI) и сотни Гбит/с тонкой очистки (до L7 уровня). У других операторов возможности послабее. Центры очистки трафика у операторов связи находятся внутри нашей страны: если источник атаки будет за границей, очистка трафика начнется только когда атака уже прилетит и сконцентрирует свою силу в России: 

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

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

Источники DDoS-атак распределены по всему миру. Именно поэтому атаки называются DDoS (Distributed DoS). Архитектура провайдеров защиты учитывает это: точек очистки трафика большое количество и они распределены по всему миру, чтобы гибко фильтровать трафик ближе к источнику атаки. Это значит, что каналы связи будут меньше перегружены атакой и защита будет эффективнее. 

Можно выделить несколько отличий провайдеров защиты от операторов связи: 

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

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

3. Провайдер защиты, кроме входящего трафика, анализирует еще и исходящий от приложения трафик, что позволяет получить более качественную очистку на уровне L4 OSI.

Облачные провайдеры сами не разрабатывают сервисы защиты от DDoS, но работают в партнерстве с известными поставщиками и предлагают их защиту как облачный сервис. Для работы с облаком и сервисом защиты у клиента будет два личных кабинета. Некоторые облачные провайдеры предлагают опцию single sign on, чтобы входить в оба ЛК с одной учетной записью.

Купить защиту через облачного провайдера удобно еще тем, что не придется заключать отдельный договор и всю ответственность за доставку трафика от входящего порта в центр очистки трафика до тенанта клиента будет нести облачный провайдер. 

Клиент может купить сервис и напрямую у провайдера защиты, которого нет в списке партнеров облачного провайдера. С точки зрения пользования облаком это ничего не меняет. Но тогда ответственность облачного провайдера начнется у порта выхода в интернет конкретного ЦОД и со всем, что происходит дальше в интернете, придется разбираться самостоятельно. Когда зона ответственности делится между несколькими участниками процесса доставки трафика, будет сложнее найти причину потери трафика.

On-premise центр очистки трафика — дорогостоящее и сложное решение, которое могут себе позволить только очень крупные компании. Они строят многоуровневую систему защиты сразу из нескольких сервисов и ПО. Например, используют on-premise защиту и держат в резерве сервисы оператора связи и провайдера защиты на случай мощной атаки, с которой не справится on-premise защита от DDoS-атак. Такая защита имеет как правило самые скромные показатели емкости фильтрации из-за высокой стоимости «широкого» канала связи. Это десятки Гбит/с. Также on-premise вариант используется, если компания не готова отправлять логи веб-сервера поставщику защиты или раскрывать SSL/TLS сертификаты для защиты на L7 OSI.

Как защищается от DDoS облачный провайдер

Облачные провайдеры защищают свою инфраструктуру теми же сервисами операторов связи и провайдеров защиты, которые предлагают своим клиентам. 

Также облачный провайдер следит за чистотой пула IP-адресов: если он узнает, что какой-то из его IP скомпрометирован, то обязан провести расследование и выяснить, кто находится за этим адресом — этим обычно занимается центр киберзащиты.

Очищенный трафик от центра фильтрации провайдера защиты передается в облако через физические стыки. Трафик очищается от DDoS-атак на уровнях L3 и L4 OSI и, если тип трафика http и https, то дополнительно до уровня L7 OSI. Очищенный трафик через интернет направляется в тенант на публичный IP в облаке:

Как защититься от DDoS клиенту: варианты подключения сервисов в облаке Cloud.ru 

Разберем две типовые схемы подключения сервисов защиты облачных веб-ресурсов от DDoS-атак.  

Защита по схеме с раскрытием сертификатов

В этом случае предполагается раскрытие сертификатов SSL/TLS, чтобы сервис защиты мог проверять запросы внутри HTTPS-сессии. В схеме сервис защиты работает как Reverse Proxy: принимает на себя весь трафик, проверяет его и перенаправляет на защищаемый сайт или приложение уже очищенный трафик. Настроить защиту этим способ можно по инструкции.

Защита по схеме без раскрытия сертификатов

В этом случае пользователь не загружает сертификаты SSL/TLS в систему защиты. Сервис защиты подключается по одному из трех вариантов:

1. Как TCP Proxy, принимая на себя все входящие соединения и перенаправляя их на защищаемый сайт или приложение;

2. С использованием GRE/IPIP-туннеля от точки очистки трафика провайдера защиты до защищаемого сайта или приложения;

3. Физический стык. 

Трафик фильтруется только до уровня L4 OSI. Дополнительно клиент может настроить веб-сервер или балансировщик нагрузки для своего веб-сайта, чтобы направить access log в сторону сервиса защиты (как на схеме ниже). Это позволит реализовать более глубокую очистку, но все равно менее эффективную, чем в схеме с раскрытием сертификатов. В инструкции описаны шаги настройки для защиты этим способом.

Выводы

Резюмирую все то, о чем рассказал в статье:

• Облачный провайдер отвечает за защиту своей облачной инфраструктуры, а за безопасность и доступность самого веб-приложения, развернутого на виртуальной машине, отвечает уже клиент.

• Защиту от DDoS можно собрать одним из трех способов: из сервиса оператора связи, сервиса провайдера защиты или решением on-premise.

• Если веб-ресурс развернут в облаке, эффективнее защищаться от DDoS  специализированным провайдером защиты.

• Чтобы облачный провайдер отвечал не только за доступность вычислительных ресурсов, СХД, сети, но и за доступность вашего приложения, удобнее использовать сервисы безопасности облачного провайдера, который предоставляет их в партнерстве с провайдером защиты от DDoS-атак.

А еще вы можете бесплатно попробовать облако Cloud.ru и если всё понравится, рекомендовать наши сервисы коллегам или партнерам в рамках реферальной программы и получать вознаграждение 15% с каждого оплаченного счета.

Полезные материалы в блоге:

• Уменьшаем неопределенность в проектной деятельности: эволюционная модель команды проекта

• Стадии запуска продукта на примере Cloud.ru Evolution: почему ввели новый процесс и что это дает нам и нашим клиентам

• Что такое free tier и какие облачные ресурсы вы можете бесплатно использовать прямо сейчас