Защита от DDoS. Технические критерии

  • 1.

    Наличие у поставщика глобальной геораспределенной сети

    Распределенному нападению – распределенную защиту. Поставщик должен иметь более 1 точки присутствия во всех ключевых регионах распространения Интернета с подключением к поставщикам связи не ниже Regional Tier 1 (т.е. не покупающим трафик в этом регионе). Важно исключить наличие «единой точки отказа» — в том числе, за счет максимального распределения вредоносного трафика по узлам фильтрации.

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

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

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

     

  • 2.

    Инфраструктура поставщика должна быть построена с использованием сетей иерархически не связанных интернет-провайдеров

    Использование одного поставщика – это создание единой точки уязвимости, так же как и базирование в одном регионе.

    Атаки сегодня способны полностью вывести из строя оператора связи и сделать неработоспособной инфраструктуру целого региона, а вместе с ними и зависимый бизнес.

    Примеры:

    Интернет почти полдня был недоступен для пользователей T-Hrvatski Telekom и интернет-провайдеров, использовавших инфраструктуру атакованного оператора, который является крупнейшим в Хорватии. Мобильная сеть, а вместе с ней банковские сервисы, банкоматы, аптеки, экстренные звонки и кассовые терминалы перестали функционировать.

    A DDoS attack crippled Croatia as Internet services, fixed and mobile networks go down

    DDoS-атака на игровой сайт оставила клиентов Telia, крупнейшего интернет-провайдера Швеции, без интернета.

    DDoS of unprecedented scale 'stops Sweden working'. The target? A gaming site

    Количество провайдеров поставщика вы можете проверить по ссылке.

     

  • 3.

    У сетевого префикса должно быть более одного поставщика услуг
    (в данном случае буквально имеется ввиду «не у сети, но у префикса»)

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

    Это можно сделать, например, с использованием инструментов WHOIS, traceroute, сервисов Looking Glass поставщиков связи или сервиса Qrator.Radar.

    Даже в «мирных условиях» (без DDoS-атаки) это может доставить немало хлопот.

    • До атаки:
      появляется единая точка отказа. Все риски сети оператора, к которому подключен поставщик, наследуются поставщиком услуги.
    • В случае массированной атаки:
      полная (в случае отключения) или частичная (в случае использования blackhole) недоступность поставщика услуг.

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

  • 4.

    Наличие у поставщика услуги «Защита DNS»

    DNS – часть инфраструктуры, обеспечивающей работу сайта. При этом атаковать DNS при помощи DDoS-атаки проще, а восстановление может занять более суток.

    В результате атаки на DNS-серверы работа вашего сайта будет прервана на критическое время (даже при хорошей защите основного сервиса).
     

  • 5.

    Сервис поставщика должен работать со всеми протоколами, которые используют защищаемые интернет-приложения (то есть фильтры поставщика должны «уметь» обрабатывать не только Web-протокол, но и остальные ключевые протоколы интернета)

    Современный интернет – это не только HTTP, но и множество других ключевых протоколов, которые могут использовать приложения.

    Сайт будет подвергнут атакам по протоколам, которые он поддерживает, но которые не обрабатываются системой фильтрации вашего поставщика.

  • 6.

    Обеспечение постоянной автоматической фильтрации трафика

    Сегодня время реакции на новый вектор атаки должно составлять минуты или секунды, иначе злоумышленник будет быстрее развивать и модифицировать атаку, чем условная система будет реагировать на нее.

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

  • 7.

    Способность обеспечить фильтрацию до 7-го уровня OSI и интегрироваться для этого с другими решениями (которые были использованы ранее и т.п.)

    Анализируя сегодняшние тренды развития атак и угроз, напрашивается вывод: сайт могут эффективно «положить» с использованием любого уровня (инфраструктуры сети, приложения и т.п. – см. Классификацию атак в Приложении 2) сетевой модели OSI.

    Атаки всё чаще нацеливаются на уровень приложений (L7) – именно в эту сторону сегодня идет эволюция коммерческих атак.
     

  • 8.

    Полноценная (полная) фильтрация шифрованного трафика без использования ключей

    Есть требования регуляторов, касающиеся раскрытия данных третьим лицам;

    Необходимо минимизировать риск утечки коммерчески важных данных.

     

  • 9.

    Обеспечение приемлемых показателей false positive (процент ложных срабатываний системы фильтрации трафика) и соответствующие гарантии в договоре:

    Для DDoS-атак:

    Нулевой показатель срабатывания false positive без атаки;

    Под атакой — показатель не выше 5%.

    Для атак на уязвимости веб-сайта и приложений:

    Нулевой показатель срабатывания в обоих сценариях.

    Сервис защиты от атак не должен мешать бизнесу — даже под широкополосной атакой потери легитимного трафика должны быть минимальны.

  • 10.

    Отсутствие вмешательства в User Experience

    Приложение клиента вне зависимости от применяемого сервиса защиты должно оставаться таким, каким его хочет видеть пользователь.

    Добавление любых изменений в интерфейсе (например, Captcha и т.п.) приводят к раздражению пользователей сайта и повышению количества отказов.

  • 11.

    Открытость поставщика для внешних тестеров системы защиты

    Позволяет заказчику получить независимую экспертную оценку эффективности решений по защите от атак до осуществления угрозы.

  • 12.

    Наличие в пакете услуг Web Application Firewall — защиты несанкционированного доступа к данным и обнаружения уязвимостей

    Более половины случаев DDoS-атаки связаны с попытками «взлома приложения» через его уязвимости (статистика участников Содружества поставщиков услуг кибербезопасности за 2016 год).

    Успешный «взлом» приложения злоумышленниками может напрямую влиять не только на доступность ресурса, но и на конфиденциальность данных. 26% утечек данных в 2015 году произошли через взломанные веб-приложения компаний*

    *По данным Verizon