Особенности защиты от 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.
Схема без раскрытия сертификата с отправкой лог-файлов в сторону провайдера DDoS:
Защита с помощью организации прямого стыка 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
Это внутренние адреса платформы, используемые при работе многих сервисов.
Преимущества схемы:
злоумышленники не смогут воспользоваться приватным адресом балансировщика для атаки извне;
выделенный стык с оператором DDoS, гарантирующий определенные полосы пропускания очищенного трафика.
Защита TCP/UDP трафика
Особенность реализации: клиент сам договаривается с оператором DDoS-защиты о параметрах защиты публикуемых ресурсов без участия Cloud.ru.
Внимание
В режиме работы TCP-прокси анализ заголовков происходит на уровне 4, поэтому использование WAF здесь не применимо.
В зависимости от схемы реализации на стороне клиента в облаке потребуется либо терминация GRE-туннелей (StormWall), либо поддержка Proxy Protocol (Qrator). Средства разворачиваются на виртуальных машинах облака силами клиента.
Схема описана в разделе Защита TCP/UDP трафика. Основное отличие — наличие дополнительного публичного стыка между Cloud.ru и оператором защиты от DDoS.
для Dev & Test