ИТ-портал компании «Инфосистемы Джет»

Анатомия DDoS: нападение и защита

Анатомия DDoS: нападение и защита

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

При этом важно помнить, что DDoS — многоступенчатая атака: начинаясь с довольно простых методов воздействия на корпоративные ресурсы, она постепенно становится все более изощренной. Засечь первый «симптом» и даже «вылечить» его может оказаться относительно просто, но надо быть готовым к тому, что за ним последуют «симптомы» более тяжелые, снимать которые и устранять последствия будет все сложнее и сложнее. Существующий спектр средств защиты от DDoS- атак разного уровня достаточно широк, но, так же как и медицинские средства, они должны применяться в свое время, на своем месте, с учетом особенностей организма, индивидуальных реакций и взаимовлияния препаратов. Иными словами, меры и средства защиты от DDoS должны составлять единую, внутренне согласованную, устойчивую архитектуру. Вопрос «Какое средство лучше всего защищает от DDoS?» не имеет смысла. Любое средство защиты, которое правильно установлено и настроено, делает атаку более сложной и дорогой для злоумышленника. Суть защиты от DDoS в том, чтобы цели злоумышленников перестали оправдывать вложенные средства.

Цена вопроса

Не секрет, что выполнение DDoS — это бизнес, причем хорошо развитый и высококонкурентный. К услугам злоумышленников имеется масса криминальных сервисов с проработанной тарифной политикой и даже программами лояльности. Они упрощают подготовку и проведение атак, а конкуренция позволяет снизить стоимость атак до десяти долл. в час и даже ниже. На данный момент проведение массированных инфраструктурных DDoS-атак (Volumetric L3/L4 DDoS), и SSL DDoS-атак не требует большого «интеллектуального ресурса» и доступно начинающим.

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

Защита от Volumetric L3/L4 и SSL DDoS — это минимум того, что должно быть у компании. Защита от кастомизированных атак потребует гораздо больше ресурсов. Практически любые средства защиты на стороне компании увеличивают стоимость атаки для злоумышленников. Использование же специализированного DDoS-фильтра с репутационными базами делают атаки дороже на один-два порядка, поскольку, во-первых, «положить» ресурс становится намного сложнее, а во-вторых, под угрозу ставится «ударная мощность» самих бот-сетей. Бот-сеть — ресурс не безграничный, она состоит из определенного количества зараженных устройств. Во время атаки трафик от этих устройств идентифицируется DDoS-фильтром как злонамеренный и блокируется, IP-адрес устройства заносится в глобальные репутационные базы (которые оперативно распространяются по устройствам защиты по всему миру). Использование этого скомпрометированного устройства в будущих атаках становится невозможным, бот-сеть теряет свой ресурс и становится менее эффективной.

Динамика DDoS

Начальный этап: исследование объекта атаки

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

На этом этапе ключевое значение имеет не столько защита от атаки, сколько детектирование. Обнаружение попыток несанкционированного исследования инфраструктуры важно потому, что обычно они являются предвестниками последующих массированных атак.

Обнаружить первые попытки атаки способны не только специализированные средства защиты от DDoS, но и всевозможные анализаторы трафика. Подозрение на DDoS — повод принять дополнительные меры защиты, например, подключить дополнительное защитное устройство или обратиться к провайдеру security-сервисов.

Кейс 1. Архитектурная ошибка

Ошибки при построении архитектуры системы защиты иногда приводят к тому, что сами защитные средства становятся узким местом и объектом DDoS- атаки. Например, у одного из заказчиков таким узким местом стала система предотвращения вторжений (IPS), интегрированная с межсетевым экраном. Вследствие активации избыточного количества IPS-сигнатур, а также двойной проверки одного и того же трафика, подсистема IPS даже при DDoS-атаке небольшого объема (правда, специально сконструированной) начинала загружать CPU устройства защиты настолько, что то вообще переставало пропускать трафик.

Инфраструктурные DDoS-атаки (Volumetric L3/L4 DDoS)

Volumetric-атаки создают большой поток нелегитимного сетевого трафика, превышающий пропускную способность канала связи и/или сетеобразующих устройств. Такие атаки способны не только привести к недоступности публичных сервисов жертвы, но и полностью изолировать организацию от сети Интернет. Иногда volumetric- атака — не самоцель, а прикрытие для более изощренных атак. Злоумышленники добиваются снятия некоторых ограничений на пропуск трафика и запускают в его составе специально подготовленный вредонос.

Защита от Volumetric DDoS с помощью локально установленных средств защиты ограничена тем, что такие средства эффективны только в рамках ширины входящего канала — когда поток трафика превышает пропускную способность канала, они становятся бесполезными.

Можно не устанавливать локального анти-DDoS решения и пользоваться облачным сервисом security- провайдера — либо на постоянной основе, либо подключаясь к нему при подозрении на атаку. Но препятствием к использованию такого варианта зачастую являются нежелание организаций отдавать «на сторону» свой трафик (особенно бизнес-критичный), а также регуляторные требования. Кроме того, облачный сервис рассчитан на множество клиентов, и его сложно (или даже невозможно) кастомизировать, чтобы отбивать «тонкие» виды атак, направленные лично на вас.

Поэтому наиболее правильный подход — использование локального устройства в комбинации со средствами защиты, расположенными на стороне специализированного провайдера. В таком случае собственное средство защиты может быть тонко настроено, а когда объем входящего трафика превышает определенный предел, трафик автоматически перенаправляется на более мощное внешнее средство очистки. Единственное ограничение такого способа защиты — время переключения. Оно невелико от 2 до 15 минут в зависимости от технологии подключения к площадке провайдера и, как правило, не критично. И все же не надо забывать, что переключение на средства провайдера не происходит мгновенно.

Простая Application DDoS (SSL DDoS)

В отличие от Volumetric-атак атака на уровне приложений (Application DDoS) нацелена не на всю инфраструктуру, а на конкретные публичные ресурсы.

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

Решением является перенос терминации SSL на выделенное устройство, которое обрабатывает входящий и исходящий трафик web-сервера (SSL offloading). Есть разные способы реализации этой функции, начиная от самых простых, например, с использованием дополнительного Apache-сервера, до продвинутых, с применением специализированных устройств со встроенными аппаратными SSL-акселераторами — ADС (Application Delivery Controller), WAF (Web Application Firewall), балансировщиков и пр.

Ряд специализированных security-провайдеров помимо защиты от Volumetric DDoS предоставляют сервисы защиты от SSL DDoS и атак на уровне приложений. Облачный сервис защиты от SSL DDoS в некоторых случаях может экономически быть более оправдан, чем защита на локальном уровне, однако его подключение требует очень высокого уровня доверия клиента к провайдеру. Прецеденты такие есть, но многие компании не готовы предоставлять третьей стороне сертификаты шифрования — ввиду требований собственной политики безопасности или требований регуляторов. Поэтому выбор собственного решения для SSL offloading, его локальная установка и настройка остаются актуальными.

Кейс 2. DDoS в развитии

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

На второй день поток запросов к сайту усилился (атаки типа SYN Flood и ICMP Flood). Понимая, что атака нарастает, банк подключается к облаку security- провайдера.

На третий день DDoS-трафик превысил ширину входящего канала. Однако облако провайдера позволило ее отразить.

На четвертый день началась атака с использованием SSL. Сервер приложения не смог справится с потоком SSL-трафика. Сайт оказался неработоспособным в течение примерно 4-х часов. После переноса терминации SSL на выделенные серверы, мощность которых в несколько раз превосходила прежние, работа сайта восстановилась.

SSL-атака оказалась удачной из-за архитектурной ошибки. Обработка SSL-трафика требует больших вычислительных мощностей. В данном случае она выполнялась на том же самом сервере приложения, который был объектом атаки. Это создавало архитектурную брешь, которой воспользовались злоумышленники — сервер не справился с нагрузкой. Вынос функции обработки SSL-трафика на отдельное решение позволяет исключить такую брешь и повысить общую эффективность противодействия DDoS.

Продвинутая Application DDoS (L7)

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

Защитить приложения от атак Layer 7 позволяют решения класса Web Application Firewall (WAF). Традиционно WAF воспринимается как средство защиты от взлома, настройки дополнительной идентификации, аналитики и пр. Но не стоит забывать, что это еще и важнейший компонент защиты от DDoS. WAF отлавливает уязвимые URL, некорректные параметры запросов, попытки инъекций и другие возможные источники дополнительной нагрузки на сервер приложения. Практически все WAF имеют в своем составе аппаратный SSL-акселератор. Таким образом, они могут служить средством защиты от SSL DDoS.

В основе работы WAF лежат два ключевых механизма: сигнатурный анализ и создание позитивной модели приложения. Анализ трафика по сигнатурам, а также репутационной базе хостов-источников позволяет отсечь уже известные виды атак и трафик бот-сетей. Настроить этот механизм в WAF довольно просто. Что касается позитивной модели приложения, то WAF способен построить ее автоматически — путем сбора и обработки информации о поступающем к приложению трафике (синтаксисе запросов, дереве URL, процессах идентификации и аутентификации и т.д.). Трафик, который не соответствует сформированной позитивной модели, блокируется. Однако и само приложение, и условия его использования со временем меняются, и, опираясь на автоматически созданную модель WAF, неизбежно генерирует «ложные тревоги» (false positives). Их количество может оказаться столь велико, что их будет проще игнорировать, чем проверять. Поэтому автоматически созданная модель нуждается в тонкой донастройке (тюнинге), причем не одноразовой, а постоянной, основанной на мониторинге изменений. Это задача совсем непростая, она по силам только квалифицированным экспертам. Поэтому все более популярной становится услуга профессионального аутсорсинга эксплуатации WAF.

Некоторые облачные security- провайдеры предоставляют WAF как услугу. Однако тут, опять же, возникают проблемы доверия заказчика (готовности предоставить провайдеру сертификаты шифрования) и тонкой настройки позитивной модели приложения (в облаке такая возможность ограничена). Кроме того, WAF способны выполнять целый ряд дополнительных полезных функций, таких как балансировка нагрузки, модификация трафика (например, для борьбы с фродом), усиленная аутентификация, разграничение доступа внутри приложения и пр. Решения некоторых вендоров позволяют даже программировать сценарии работы с трафиком в зависимости от его свойств и источников (например, использовать geoip). Гибко настроить все эти функции под собственные нужды можно только на локально развернутом решении.

Но даже если вы не сумели, не успели или не имеете возможности произвести тонкую настройку WAF, он все равно будет полезен: как минимум, вы поймете, откуда идет атака и что делать.

Еще один полезный инструмент защиты от атак Layer 7 — анализатор кода. Найденная злоумышленником ошибка/некорректность в коде приложения становится для него открытым входом, поэтому лучше найти ее самостоятельно. Анализаторы кода позволяют в автоматическом режиме проверить код приложения, обнаружить уязвимости и выдать понятные для программистов рекомендации по их устранению. А пока программисты работают над устранением уязвимости, прикрыть ее позволит тот же WAF. WAF умеет напрямую работать с анализатором кода: получив от анализатора информацию об уязвимостях, он будет блокировать активности, которые могут их эксплуатировать, — применит технологию Virtual Patching.

Кейс 3. Неэффективность запросов

В ходе тестирования системы защиты сайта в одном из крупнейших российских банков (выполнения пентестов) была обнаружена проблема при формировании запроса на конвертацию валют. Входящие параметры не фильтровались, а сама функция была реализована неэффективно, чрезмерно нагружая back-end. При нормальной работе это было незаметно, но стоило создать поток запросов с огромными цифрами в качестве параметров, как сайт испытал серьезные проблемы с производительностью. В итоге в рамках теста с одного‒единственного компьютера удалось полностью «положить» сайт одного из крупнейших банков страны. Никаких ботнетов из миллионов устройств не потребовалось. Подстраховать разработчиков сайта, скорее всего, мог бы WAF, но он не был использован.

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

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: