tocdepth

2

Особенности защиты от DDoS-aтак для Cloud.ru Advanced и Cloud.ru Evolution

Существуют особенности защиты клиентов для Cloud.ru Advanced и Cloud.ru Evolution.

Платформы предполагают полностью динамическое выделение публичных IP-адресов. Средствами платформы нет возможности выдать определенный публичный адрес или блок адресов со стороны транспортной сети и закрепить его за определенным клиентом/тенантом. Поэтому вариант предоставления услуги через выделенные публичные блоки Cloud.ru, как в Облако VMware, не применим в этом случае.

Схемы, описанные в этом разделе, при необходимости можно использовать и с платформой Cloud.ru Облако VMware.

Предлагаются следующие варианты предоставления услуги:

  • защита приложений, развернутых за определенными публичными адресами EIP на платформе;

  • защита ресурсов в облаке с помощью организации прямого стыка с Qrator/StormWall с платформой посредством DirectConnect;

  • отдельно также можно рассмотреть защиту TCP/UDP. В этом случае клиенту своими силами необходимо разворачивать машину, способную терминировать GRE-туннели, либо имеющую поддержку Proxy Protocol в облаке.

Защита приложений с публичными адресами

Особенность реализации: клиент сам договаривается с оператором DDoS-защиты о параметрах защиты публикуемых сервисов без участия Cloud.ru.

В этом случае схемы мало отличаются от приведенных в разделах Защита веб-сайта по схеме Reverse Proxy и Защита веб-сайта без раскрытия сертификатов.

Основное отличие, которое необходимо учитывать в этой схеме, — клиент заказывает услугу у оператора StormWall/Qrator самостоятельно без участия Cloud.ru, поскольку нет возможности выделения и закрепления защищаемых публичных адресов, выделенных на коммунальных стыках Cloud.ru с Qrator/StormWall.

Другой важный момент: на используемый на платформе публичный адрес необходимо назначать группу безопасности (security group), разрешающую трафик из интернета только с подменного Source IP адреса для Qrator. Если злоумышленникам становится известен публичный адрес сервера, его необходимо заменить на другой, выбрав другой публичный адрес средствами платформы, поменяв его также в кабинете провайдера DDoS для предотвращения атак напрямую без знания доменного имени.

Схема с раскрытием сертификата приведена ниже. Основное отличие — в наличии дополнительного публичного стыка между Cloud.ru и оператором защиты от DDoS.

../../_images/schm__public-ip-certificate.svg

Схема без раскрытия сертификата с отправкой лог-файлов в сторону провайдера DDoS:

../../_images/schm__public_ip-no-certificate.svg

Защита с помощью организации прямого стыка DirectConnect

Область применения: индивидуальная защита ресурсов клиента; канал защиты организован не через общий для всех заказчиков пиринг между Cloud.ru и сервисом защиты, а создан специально для заказчика.

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

Использование согласованного под систему защиты блока IP адресов (protected_private_ip) обеспечивает передачу трафика между сервисом защиты и Cloud.ru по выделенному каналу DirectConnect.

Для работы этой схемы необходимо:

  • организовать услугу DirectConnect, первой точкой стыка является платформа, второй точкой стыка должен быть оператор Qrator/StormWall.

  • согласовать с оператором DDoS приватные адреса используемые на платформе Advanced/Evolution со стороны балансировщика, приватные блоки адресов используемые со стороны оператора DDoS, а также публичные адреса выделенные под защищаемые ресурсы заказчика.

  • опубликовать приложение в приватный блок IP адресов через балансировщик, согласованный с оператором DDoS для защиты

  • изменить DNS A-записи таким образом, чтобы они указывали на публичные адреса сервиса защиты

Внимание

Диапазоны IP-адресов, которые не могут использоваться при организации этого стыка для платформы Advanced:

  • 100.64.0.0/10

  • 127.0.0.0/8

  • 169.254.0.0/16

  • 198.19.128.0/20

Это внутренние адреса платформы, используемые при работе многих сервисов.

../../_images/schm__direct-connect.svg

Преимущества схемы:

  • злоумышленники не смогут воспользоваться приватным адресом балансировщика для атаки извне;

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

Защита TCP/UDP трафика

Особенность реализации: клиент сам договаривается с оператором DDoS-защиты о параметрах защиты публикуемых ресурсов без участия Cloud.ru.

Внимание

В режиме работы TCP-прокси анализ заголовков происходит на уровне 4, поэтому использование WAF здесь не применимо.

В зависимости от схемы реализации на стороне клиента в облаке потребуется либо терминация GRE-туннелей (StormWall), либо поддержка Proxy Protocol (Qrator). Средства разворачиваются на виртуальных машинах облака силами клиента.

Схема описана в разделе Защита TCP/UDP трафика. Основное отличие — наличие дополнительного публичного стыка между Cloud.ru и оператором защиты от DDoS.

../../_images/schm__tcp-udp-traffic.svg
Запустили Evolution free tier
для Dev & Test
Получить