Перерастая reverse proxy — технология удаленной защиты и оптимизации сайтов без изменения А-записей DNS

Вы решили защитить свой растущий проект от DDoS-атак. В основе любой защиты лежит анализ и фильтрация входящего трафика. Но чтобы очистить трафик, его сначала нужно доставить в центр очистки. Далее по тексту под “решением по защите” мы будем иметь в виду совокупность технологий по доставке и очистке трафика.

Скорее всего, первое решение, которое вам попадется, будет основано на технологии reverse proxy со сменой A-записей DNS. Поэтому сначала мы рассмотрим принцип работы технологии, ее возможности (если вы хорошо знакомы с reverse proxy — смело пропускайте эти два подраздела) и ограничения, связанные с доставкой трафика (это пропускать не стоит). Затем мы покажем, как эти ограничения можно обойти на примере реального кейса. В конце мы дадим несколько общих рекомендаций по организации защиты интернет ресурса.

Reverse proxy — принцип работы
Здесь мы рассмотрим reverse proxy, как средство доставки трафика. Схема ее работы всем хорошо знакома, но не упомянуть ее здесь просто нельзя.

• Изменение А-записей DNS — вместо IP адреса веб-сервера указывается IP адрес прокси сервера. Распространение внесенных изменений по миру (DNS propagation).
• ОС посетителя запрашивает IP-адрес, соответствующий доменному имени сайта (DNS resolution).
• DNS сервер отвечает на запрос, сообщая IP-адрес прокси сервера.
• Браузер посетителя открывает HTTP(s) сессию и отправляет запросы прокси серверу, который, переустанавливает соединение с целевым веб-сервером и передает запросы ему.

Reverse proxy — возможности
Какие возможности предоставляют решения работающие через reverse proxy со сменой А-записей?

• Мониторинг запросов и защита сайта от атак на уровне приложений. Технология позволяет обработать каждый запрос уровня приложений, поступающий к целевому серверу.
• Снижение нагрузки на целевой веб-сервер и ускорение сайта. На проксирующих серверах можно сжимать и кэшировать данные — это является основой работы сетей доставки контента CDN (Content Delivery Network).
• Гибкое распределение нагрузки между несколькими целевыми веб-серверами. Технология позволяет распределить нагрузку по обработке запросов между несколькими машинами. Это повышает отказоустойчивость и производительность системы.
• Простота подключения. Чтобы подключить защиту достаточно поменять А-записи DNS и дождаться, когда изменения вступят в силу. Переезд, новое оборудование и ПО — не требуются.
• Сокрытие реального IP-адреса целевого веб-сервера. Посетитель используют IP-адрес проксирующего сервера для обращения, и с него же получают ответы, что обеспечивает анонимность целевого веб-ресурса.

Reverse proxy — ограничения
У данной технологии есть ряд подводных камней, о которых не очень-то принято говорить. К ее ограничениям можно отнести:

• Отсутствие защиты от прямых DDoS-атак для самого веб-сервера и инфраструктуры. Если известен IP-адрес целевого веб-сервера, злоумышленники могут провести атаку напрямую, не обращаясь к DNS-серверу. Настройка файрвола на защищаемом сервере не спасает от пакетных DDoS-атак и атак на переполнение каналов.
• Изменение IP-адресов, используемых для доступа к веб сайтам. Если одних интересует анонимность, то для других сохранение собственных IP-адресов является принципиально важным. Например если компания обладает собственными IP-адресами или целой автономной системой и не хочет ассоциировать себя с компанией, которой принадлежат IP адреса проксирующих серверов.
• Ощутимые задержки при включении/отключении защиты. Задержки связаны со скоростью обновления информации на DNS серверах по всему миру (DNS propagation). При лучшем сценарии это занимает несколько часов, но может затянутся и на несколько суток. Длительность DNS propagation зависит от времени жизни TTL (Time to Live) DNS-записей, которое определяет через какое время сервер обновит кэш записей.
• Нельзя защитить сайты и веб-приложения, использующие TCP-порты, отличные от стандартных 80 и 443. Если веб-приложение использует, например, UDP-порт, защитить его не получится. Запросы не будут проксироваться и легитимные пользователи просто не смогут воспользоваться приложением.

Недостатки решений по защите от DDoS-атак на базе “классической” Reverse Proxy начинают ощущаться, по мере того как растущий проект упирается во все большее число ограничений технологии. Какие технические решения способны нивелировать или значительно снизить риски недоступности сайта из-за перечисленных недостатков? — читайте ниже.

Перерастая reverse proxy
Давайте рассмотрим проблему на реальном примере из нашей практики. В прошлом году к нам обратился крупный клиент, с конкретным списком требований к услугам по защите. Мы не можем раскрыть название компании по понятным причинам, а вот потребности клиента — пожалуйста:

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

Решения на основе “классической” reverse proxy с изменением А-записей DNS позволяют закрыть первые два пункта из спиcка.

Услуги вроде защищенного хостинга, виртуальных и выделенных серверов позволяют защититься от атак на уровнях L3-L7 OSI, но требуют переезда и означают использование единственного провайдера защиты. Что делать?

Защита от DDoS внутри сети с защищаемыми сервисами
Установка фильтрующего оборудования в своей сети позволяет защитить сервисы на уровнях L3-L7 OSI и свободно управлять правилами фильтрации. Вы несете существенные капитальные (CaPex) и операционные расходы (OpEx), выбирая такое решение. Это расходы на:

• оборудование для фильтрации трафика + лицензии на ПО (CapEx);
• продление лицензий на ПО (OpEx);
• штатные специалисты для настройки оборудования и контроля его работы (OpEx);
• каналы доступа в сеть Интернет, достаточные для приема атак (CapEx + OpEx);
• оплата входящего «мусорного» трафика (OpEx).

В результате эффективная цена за мегабит неочищенного трафика становится неоправданно высокой. Возможности по фильтрации трафика у такого решения в любом случае будут ниже, чем у специализированных провайдеров. Более того, чтобы повысить скорость работы сайта, так или иначе придется прибегнуть к услугам CDN провайдеров. Из достоинств решения стоит отметить, что расшифрованный трафик не покидает периметра защищаемой сети. Этот вопрос мы обсудим подробнее чуть позже.

Даже для крупных компаний, такое решение часто является экономически нецелесообразным, не говоря о среднем и малом бизнесе. Нашему клиенту оно также не подошло.

Проксирование без смены А-записей.
Чтобы удовлетворить потребности таких клиентов, мы разработали технологию перехвата веб-трафика и реализовали ее в рамках услуги удаленной защиты без смены А-записей. В основе решения лежит принцип: Все соединения между АС клиента и публичными сетями должны быть защищены. Клиент передает нам анонсы своих IP адресов/сетей по BGP, а мы анонсируем их в Интернет.


Весь трафик, предназначенный защищаемым ресурсам, проходит через нашу сеть. Клиент может оставить несколько резервных подключений и использовать их в случае непредвиденных обстоятельств, сняв анонсы с сети DDoS-GUARD. В штатном режиме мы советуем использовать только наши подключения для выхода в сеть Интренет, чтобы мы могли гарантировать защиту клиентских сервисов.

На схеме ниже показано, как организована обработка трафика в нашей сети на примере веб-трафика.

• Клиент указывает IP-адреса, подсети и домены, которые он хочет защитить на уровне L7. Это можно сделать для анонсируемых сетей в личном кабинете или при помощи API
• В сеть провайдера услуги из сети Интернет попадает клиентский трафик. В первую очередь он проходит базовый анализ и очистку от «мусора» на уровнях L3-4 модели OSI.
• Система перехвата сепарирует и обрабатывает трафик на основании используемых протоколов уровня приложений. В данном случае TCP пакеты на 80 и 443 порты, содержащие HTTP заголовки, направляются на анализ веб-трафика, остальной трафик доставляется в сеть клиента как легитимный.
• Веб-трафик проверяется на принадлежность защищаемой подсети. Пакеты с адресом назначения отличным от указанных клиентом проходят дополнительную проверку по имени домена.
• Весь трафик указанных клиентом IP адресов/доменов проходит обработку на уровне L7. На проксирующих серверах осуществляется фильтрация трафика, оптимизация контента и его кеширование.

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

Заключение
Теперь давайте проверим удовлетворяет ли разработанное DDoS-GUARD решение списку требований из раздела «Перерастая reverse proxy».

• Клиент получает защиту от атак на уровнях L3-L7 OSI.
• Контент сжимается и кэшируется на узлах нашей CDN, что уменьшает нагрузку на целевые веб-серверы.
• Управление защитой происходит в реальном времени. Клиент управляет правилами фильтрации трафика для подсетей, IP-адресов и отдельных доменов через личный кабинет или API. Изменения вступают в силу пределах 1 минуты. В экстренной ситуации клиент может перенаправить весь трафик в обход сети DDoS-GUARD, просто сняв анонсы по BGP.
• IP-адреса, принадлежащие компании, остались неизменными. Клиенту не нужно закупать новое оборудование, программное обеспечение, нанимать дополнительный персонал и платить за неочищенный трафик.

В добавок появляется возможность защитить сервисы и приложения, работающие на нестандартных портах.

P.S.
Общие рекомендации по организации защиты вашего проекта:

• Избегайте туннелей, в т.ч. при доставке очищенного трафика через сеть провайдера — это снижает MTU (Maximum Transmission Unit). Чем ниже MTU, тем больше пакетов приходится фрагментировать, т.е. разбивать, понижая тем самым скорость передачи данных) и ставит ваш сервис в зависимость от политик по приоритезации трафика транзитных операторов.
• Обращайте внимание на связность сети поставщика услуг — нерационально строить маршрут Красная площадь — ВДНХ, через Рязань или Франкфурт.
• Резервируйте все подключения (каналы), операторов, оборудование, персонал. В случае с защитой от DDoS предусмотрите «стоп-кран», который позволит экстренно отключать влияние на трафик.
• Вне зависимости от особенностей используемой схемы защиты веб-сайта, сервис должен предоставлять возможность управлять защитой в реальном времени. Учитывая, что 100% точность фильтрации недостижима, система должна быть управляемой для снижения ошибок I и II рода.

https://ddos-guard.net