Как CDN защищают отказоустойчивые сайты от DDoS-атак?

Я нахожусь в процессе разработки веб-приложения на Java, которое я, вероятно, в конечном итоге разверну в Google App Engine (GAE). Хорошая вещь в GAE заключается в том, что мне действительно не нужно беспокоиться о защите моего приложения от страшной DDoS-атаки - я просто указываю «потолок биллинга», и, если мой трафик достигает пика до этого потолка (DDoS или иным образом), GAE просто закрою мое приложение. Другими словами, GAE будет по существу масштабироваться до любой суммы, пока вы просто не сможете позволить себе продолжать работу приложения.

Поэтому я пытаюсь спланировать непредвиденную ситуацию, при которой, если я достигну этого потолка выставления счетов, и GAE закроет мое приложение, настройки DNS домена моего веб-приложения «переключатся» на другой IP-адрес не-GAE. Некоторые первоначальные исследования показали, что некоторые CDN, такие как CloudFlare, предлагают услуги для этой конкретной ситуации. По сути, я просто сохраняю свои настройки DNS с ними, и они предоставляют API, который я могу использовать для автоматизации процедуры восстановления после отказа. Таким образом, если я обнаружу, что у меня 99% потолка выставления счетов для моего приложения GAE, я могу подключиться к этому API CloudFlare, и CloudFlare динамически изменит мои настройки DNS, чтобы они указывали с серверов GAE на какой-либо другой IP-адрес.

Мое первоначальное непредвиденное обстоятельство состояло бы в переключении на «только для чтения» (только статическое содержимое) версию моего веб-приложения, размещенную где-то еще, возможно, GoDaddy или Rackspace.

Но вдруг меня осенило: если DDoS-атаки нацелены на доменное имя, какая разница, если я перенесу свой IP-адрес GAE на мой (скажем) IP-адрес GoDaddy? По сути, отработка отказа не сделает ничего, кроме того, что позволяет злоумышленникам DDoS уничтожить мой резервный сайт / сайт GoDaddy!

Другими словами, злоумышленники DDoS координируют атаку на мое веб-приложение, размещенное в GAE, по адресу www.blah-whatever.com, который на самом деле является IP-адресом 100.2.3.4 . Они приводят к тому, что мой трафик достигает 98% моего потолка выставления счетов, и мой пользовательский монитор запускает переключение CloudFlare с 100.2.3.4 на 105.2.3.4 . Злоумышленникам DDoS все равно! Они все еще начинают атаку против www.blah-whatever.com! DDoS-атака продолжается!

Поэтому я спрашиваю: какую защиту предлагают CDN, такие как CloudFlare, чтобы - когда вам нужно переключиться на другой DNS - вы не подвергались риску того же самого, продолжая DDoS-атаку? Если такая защита существует, существуют ли какие-либо технические ограничения (например, только для чтения и т. Д.), Которые размещены на сайте аварийного переключения? Если нет, то что они хорошего ?! Заранее спасибо!

— herpylderp
источник

Отличный вопрос! Из этого можно многому научиться :-)

— Мартейн Вербург

Ответы:

Они не защищают от DDoS-атак в этой конфигурации. CDN не «защищает» от DDoS-атаки - они просто смягчают ее последствия, имея много оборудования и пропускную способность, чтобы решить эту проблему. Когда CDN изменяет настройки DNS так, чтобы они указывали непосредственно на ваш сервер, CDN больше не обрабатывает запросы на ваш веб-сайт - клиенты никогда не видят IP-адрес CDN, поэтому CDN больше не может предложить вам защиту.

Что касается «что они хорошего» - DDoS-атаки не имеют смысла использовать CDN. Смысл использования CDN заключается в уменьшении задержки между тем, когда кто-то запрашивает большой кусок данных с одного из ваших веб-серверов, и тем, кто получает данные, путем сокращения географического расстояния между сервером и клиентом. Это идеальная оптимизация, которую вы можете сделать; но он действительно не предназначен для обеспечения безопасности от DDoS.

— Билли ОНил
источник

Спасибо @Billy ONeal (+1) - подведем итог: я бы хотел, чтобы мой «DDoS Failover» фактически перенаправлял запросы на серверы CDN, чтобы они могли выделять достаточное количество оборудования / пропускной способности для решения проблемы, чтобы сайт работал и работал; хотя это не основная функция CDN. Это более или менее правильно? Если это так, быстрый вопрос: если бы я пошел по этому пути и перенаправил аварийное переключение на CDN, могло ли мое веб-приложение продолжать функционировать как обычно, или CDN обслуживал бы только статический контент (т. Е. Мое веб-приложение стало бы " только для чтения »и т. д.)? Еще раз спасибо!

— herpylderp

@herpylderp: Ну, это зависит от характера сайта. CDN обрабатывают только статический контент. Если ваш сервер делает «интересные вещи», то CDN вам не поможет. Обычно вы не можете запускать код на серверах CDN. Например, на сайтах обмена стеками изображения для каждого из сайтов размещаются на sstatic.com, CDN, но основной сайт размещается в собственных центрах обработки данных StackExchange.

— Билли ОНил

CDN обычно взимается в зависимости от объема, поэтому вы просто переносите стоимость биллинга с одного поставщика на другого. AFAIK, уменьшение DDoS обычно включает автоматическую временную блокировку диапазонов IP.

— Джори Себрехтс

Спасибо @Joeri Sebrechts (+1) - есть ли разница между «диапазоном IP-адресов» и «IP-подсетью» или они одинаковы? Я спрашиваю, потому что GAE позволяет вам блокировать IP-подсети, и я надеюсь, что это то, о чем вы говорите.

— herpylderp

Я работаю в Incapsula , компании Cloud Security, которая также предоставляет услуги ускорения на основе CDN (например, CF).

Я хочу сказать, что хотя (как правильно заявлено @Billy ONeal) CDN сама по себе не обеспечивает защиту от DDoS, облачная прокси-сеть является ОЧЕНЬ эффективным средством предотвращения DDoS.

И поэтому, в случае DDoS в облаке CDN, не «CDN», а «облако» защищает вас, поглощая весь дополнительный трафик, генерируемый DDoS, и в то же время предоставляя доступ к вашему сайту из разных POP по всему миру.

Кроме того, поскольку это решение с промежуточным прокси-сервером, эту технологию можно использовать для смягчения сетевых DDoS-атак 3-4-го уровня (например, SYN-наводнения), которые используют поддельные IP-адреса для отправки многочисленных запросов SYN на ваши серверы.

В этом случае прокси не установит соединение, пока не будет получен ответ ACK, что предотвратит переполнение SYN.

Есть и другие способы использования Cloud для обеспечения безопасности веб-сайтов (например, блокировка плохих ботов, WAF на основе облака), и некоторые из них также можно использовать для предотвращения или предотвращения DDoS (остановка ботов для сканера - хороший пример для последующего использования), но Главное, чтобы понять, что все это основано не на CDN, а на облачной технологии.

— Игал Зейфман
источник

Ого - спасибо @Igal Zeifman (+1) - отличный ответ! Несколько вопросов для вас: (1) Когда вы говорите « сеть прокси » или « прокси переднего шлюза », я предполагаю, что вы имеете в виду, что облако предоставляет серверы, которые выступают в качестве посредников между клиентами и серверами моих приложений, да? Если нет, не могли бы вы объяснить? И (2) CloudFlare и / или Incapsula предоставляют функциональность для этих других сервисов (остановка / блокировка ботов, WAF и т. Д.)? Еще раз спасибо!

— herpylderp

Кроме того, под « POP » я предполагаю, что вы имеете в виду «Точки присутствия», да?

— herpylderp

Привет спасибо. Очень признателен. Чтобы ответить на ваши вопросы: Front Gate Proxy: термин «прокси» подразумевает промежуточные отношения между указанной сетью и вашим сайтом. Это означает, что сеть будет «сидеть» перед вашим сайтом (следовательно, «передними воротами») в качестве первой линии защиты, в основном получая весь трафик в первую очередь и отфильтровывая все «плохие вещи», в нашем случае с помощью Bad Bot правила блокировки и векторы, WAF и так далее. В случае DDoS эта сеть также поможет сбалансировать дополнительный трафик, тем самым предотвращая проблемы, связанные с DDoS. (т.е. сбой) POP = Точки присутствия. Вы на 100% правы.

— Игал Зейфман