Схема фильтрации шифрованного трафика без раскрытия ключей шифрования.
Часто в дискуссиях мы слышим, что услуга нейтрализации распределённых атак на отказ в обслуживании базирующаяся на постоянной фильтрации трафика, является менее эффективной и более дорогостоящей по-сравнению с фильтрацией по-требованию.
Аргументы использующиеся в подобных диалогах практически не меняются со временем, когда начинается обсуждение: высокая стоимость постоянной фильтрации против задержки во времени, необходимой на включение специалиста, или оборудования в процесс нейтрализации атаки по требованию.
Qrator Labs хотели бы разъяснить собственную позицию, вынеся на всеобщее обсуждение некоторые аргументы о том, каким образом постоянная фильтрация отличается от фильтрации по запросу и почему первая опция является на самом деле единственной работоспособной.
Одна из ключевых причин заключается в том, что современные атаки развиваются очень быстро — эволюционируют и усложняются в реальном времени. Эволюционирует и сам сервис — сайт и приложение развиваются, поэтому может оказаться, что «нормальное» поведение пользователей во время предыдущей атаки уже не является актуальным.
Техническим специалистам провайдера услуг нейтрализации атак на отказ в обслуживании, в случае ручной фильтрации, в большинстве случаев требуется не только время на осознание происходящего для выработки правильной стратегии поведения и последовательности совершения конкретных действий. Помимо этого, такому специалисту также необходимо точно знать, когда и как меняется вектор атаки, для того чтобы эффективно осуществить её нейтрализацию по запросу клиента.
Подключение под атакой — отдельная сложность, в основном из-за ухудшения доступности для всех пользователей, пытающихся достичь сервис. Если атака прошла успешно и пользователи не получили запрошенный ресурс — они пытаются получить его еще раз, просто обновляя страницу или перезагружая приложение. Это ухудшает сценарий атаки, потому что становится труднее отличить мусорный трафик от легитимного.
Фактическое размещение сервиса нейтрализации атак — в облаке или физически на площадке клиента, в дата-центре партнёра, часто является ключевым требованием к его внедрению. Так как любой из вариантов размещения позволяет осуществлять постоянную автоматическую, либо ручную фильтрацию, а соответственно — детектирование и нейтрализацию атак. Но наличие возможности автоматической фильтрации является ключевым требованиям.
Чаще всего облачные сервисы нейтрализации атак фильтруют весь входящий трафик — он становится полностью доступен для анализа. Физическое оборудование, установленное на границе сети, или получающее клонированный трафик, даёт почти такие же возможности мониторинга и нейтрализации атак в реальном времени.
Часть вендоров рекомендует использовать метрику NetFlow для анализа трафика, либо другие метрики, что само по себе уже является компромиссом в худшую сторону с точки зрения результата, так как сторонние либо производные метрики отдают лишь часть информации о данных, заужая, таким образом, возможности для обнаружения и нейтрализации атаки. И наоборот — облачные сервисы не обязаны анализировать 100% входящего трафика, однако чаще всего они это делают по причине того, что подобный подход позволяет наилучшим образом выстраивать модели и обучать алгоритмы.
Ещё одним недостатком использования протокола NetFlow в качестве основного инструмента анализа заключается в том, что он даёт лишь некоторую характеристику потоков данных — их описание, но не сами потоки. Поэтому, конечно, вы заметите атаку основываясь на параметрах, которые отражает NetFlow, но более сложные виды атак, которые должны обнаруживаться с помощью анализа содержимого потока, видны не будут. Поэтому атаки на прикладной уровень (L7) сложно отражать используя только NetFlow метрику, за исключением случаев стопроцентной очевидности атаки внутри транспорта (потому что выше L4 NetFlow откровенно бесполезен).
Общая схема подключения к фильтрационной сети.
1. Почему облачные провайдеры услуг нейтрализации DDoS предлагают «постоянную фильтрацию» даже в том случае, если в настоящий момент атаки не происходит?
Ответ прост: постоянная фильтрация является наиболее эффективным способом нейтрализации атак. Здесь также необходимо добавить, что физическое оборудование размещённое у клиента, не сильно отличается от облачной фильтрации, за тем лишь исключением, что коробка включается и выключается физически где-то в дата-центре. Однако выбор есть в любом случае (работать — то есть включать устройство, всегда либо лишь в случае необходимости) и его придётся сделать.
Теоретически, ухудшение сетевой задержки вследствие фильтрации, действительно, возможно — особенно если ближайший узел находится географически далеко, а клиенту необходим локальный ресурс и трафик. Но, что мы видим в большинстве случаев — это снижение общей задержки благодаря ускорению HTTPS/TCP-рукопожатий (handshakes) на основе грамотно выстроенной сети фильтрации с логичным размещением узлов. Никто, наверное, не станет спорить с тем, что правильная сеть нейтрализации обладает лучшей топологией (быстрее и надёжнее), нежели та сеть, которая требуется защиты.
Говоря, что обратное проксирование сужает возможности фильтрации только до протоколов HTTP и HTTPS (SSL), вы озвучиваете лишь половину правды. HTTP-трафик является неотъемлемой и одной из критически важных частей сложных систем фильтрации, а обратное проксирование — один из самых эффективных способов осуществлять его сбор и анализ.
2. Как мы знаем, распределённые атаки на отказ в обслуживании могут принимать многие формы и модифироваться, сдвигаясь от HTTP-протокола. Почему облако в данном случае лучше, чем отдельно стоящее оборудование на стороне у клиента?
Перегружение отдельных узлов фильтрационной сети возможно настолько же, насколько это реально совершить и с оборудованием, размещённым в стойке. Не существует железной коробки мощной настолько, чтобы справится с любыми атаками в одиночку — требуется сложная и многосоставная система.
Тем не менее, даже крупнейшие производители оборудования рекомендуют переключаться на облачную фильтрацию в случае наиболее серьёзных атак. Потому что их облака состоят из того же самого оборудования, организованного в кластеры, каждый из которых по-умолчанию мощнее отдельного решения, размещённого в дата-центре. К тому же ваша коробка работает лишь для вас, но большая сеть фильтрации обслуживает десятки и сотни клиентов — дизайн такой сети изначально рассчитан на обработку на порядок больших объёмов данных для успешной нейтрализации атаки.
До атаки невозможно сказать наверняка, что будет проще: вывести из строя отдельно стоящее оборудование (CPE) или узел сети фильтрации. Но подумайте вот о чём — отказ точки всегда является проблемой вашего вендора, а вот кусок оборудования, отказывающийся работать как заявлено, уже после покупки, является только вашей проблемой.
3. Узел сети, выступающий в роли прокси-сервера, должен быть в состоянии получить от ресурса контент и данные. Значит ли это, что любой может обойти облачное решение по нейтрализации атак?
Если между вами и провайдером услуг безопасности не существует выделенной физической линии — да.
Это правда, что без выделенного канала от клиента до провайдера услуг нейтрализации атак на отказ в обслуживании, атакующие могут атаковать нативный IP-адрес сервиса. Далеко не все провайдеры таких услуг в принципе предлагают услуги выделенных линий от себя до клиента.
В общем, переключение на облачную фильтрацию значит объявление соответствующих анонсов с помощью протокола BGP. В таком случае отдельные IP-адреса сервиса, находящегося под атакой, оказываются сокрыты и недоступны для атаки.
4. Порой в качестве аргумента против облачной фильтрации используется соотношение стоимости услуги и затрат на неё со стороны поставщика. Как выглядит эта ситуация в сравнении с оборудованием размещённым на стороне клиента?
Можно с уверенностью утверждать, что насколько бы мала ни была атака на отказ в обслуживании, облачный провайдер услуг по их нейтрализации должен будет обработать их все, даже несмотря на то, что внутренний расход при построении подобных сетей всегда формируется на базе утверждения того, что каждая атака является интенсивной, большой, долгой и умной. С другой стороны, это совсем не значит, что провайдер такой услуги теряет деньги, продавая клиентам защиту от всего, но на деле вынужденный справляться в основном с мелкими и средними атаками. Да, сеть фильтрации может затратить ресурсов чуть больше, чем в «идеальном состоянии», но в случае успешно нейтрализованной атаки никто не будет задавать вопросов. И клиент, и провайдер останутся довольны таким партнёрством и продолжат его с высокой степенью вероятности.
Представьте себе ту же самую ситуацию с оборудованием на месте — единоразово оно стоит на порядки больше, требует квалифицированных рук для обслуживания и… всё так же оно будет вынуждено отрабатывать мелкие и редкие атаки. Когда вы планировали покупку такого оборудования, которое нигде не стоит дёшево, вы задумывались об этом?
Тезис о том, что отдельная коробка, вместе с контрактом на установку, техническую поддержку и оплату работы высококвалифицированных инженеров в конечном счёте будет дешевле в сравнении с покупкой подходящего тарифа в облаке, просто неверен. Конечная стоимость оборудования и часа его работы очень высока — и это основная причина, по которой защита и нейтрализация распределённых атак на отказ в обслуживании стала самостоятельным бизнесом и сформировала индустрию — иначе в каждой IT-компании мы бы видели подразделение по защите от атак.
Исходя из предпосылки, что атака — явление редкое, решение по её нейтрализации должно быть построено соответствующе и быть в состоянии отражать эти редкие атаки успешно. Но, помимо этого, ещё и стоить адекватных средств, ведь все понимают что большую часть времени ничего страшного не происходит.
Облачные провайдеры проектируют и строят собственные сети в эффективной манере, для того чтобы консолидировать собственные риски и справляться с атаками распределяя трафик между точками фильтрации, являющимися и оборудованием, и программным обеспечением — двух частей системы, созданной с одной целью.
Здесь мы говорим о «Законе больших чисел», знакомом из теории вероятностей. Это причина, по которой провайдеры интернет-услуг продают большую ёмкость каналов, чем та, которой они фактически обладают. Все клиенты страховой компании, гипотетически, могут попасть в неприятную ситуацию единовременно — но на практике этого никогда не происходило. И даже несмотря на то, что отдельные страховые компенсации могут быть огромны, это не приводит к банкротству страхового бизнеса каждый раз, когда кто-то попадает в аварию.
Люди, профессионально занимающиеся нейтрализацией атак на отказ в обслуживании знают, что самые дешёвые, а потому наиболее распространённые атаки связаны с амплификаторами, и никак не могут быть характеризованы как «маленькие».
В то же время, соглашаясь, что единоразовый платёж за оборудование установленное на физической площадке останется там навсегда — способы атак будут эволюционировать. Нет никакой гарантии, что вчерашнее оборудование справится с завтрашней атакой — это лишь допущение. Поэтому объёмная инвестиция, сделанная в такое оборудование, начинает терять свою ценность ровно с момента установки, не говоря о необходимости его постоянного обслуживания и обновления.
В деле нейтрализации DDoS важно иметь хорошо масштабируемое решение, обладающие высокой связностью, чего очень сложно достичь покупая отдельную коробку оборудования.
Когда происходит серьёзная атака, любое отдельно стоящее оборудование будет пытаться сигнализировать в облако о факте её начала и пытаться распределять трафик по фильтрующим точкам. Однако, никто не говорит о том, что когда канал забит мусором нет никакой гарантии, что он сможет доставить данное сообщение до собственного облака. И снова — потребуется время на переключение потока данных.
Поэтому, единственной реальной ценой, которую клиент может заплатить, помимо денежных средств, за защиту собственной инфраструктуры от атак на отказ в обслуживании, является задержка и ничего кроме неё. Но, как мы уже сказали, правильно построенные облака улучшают задержки.
Подумайте об этом в следующий раз, пытаясь сделать выбор между железной коробкой и облаком фильтрации.
Автор: Qrator Labs
