Защита от DDoS приложений (уровень 7)

Применимо к: ✔️ Application Gateway V2 ✔️ Front Door Premium

Брандмауэр веб-приложений Azure (WAF) включает несколько защитных механизмов, которые помогают предотвращать распределённые атаки отказа в обслуживании (DDoS). Атаки DDoS могут нацелены как на сетевой слой (L3/L4), так и на уровень приложений (L7). Azure DDoS Protection защищает от крупных объемных атак на сетевом уровне. Azure WAF, работающий на уровне 7, защищает веб-приложения от атак DDoS L7, таких как наводнения HTTP. Вместе эти средства защиты не позволяют злоумышленникам добраться до вашего приложения и повлиять на его доступность и производительность.

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

Выбирайте свои защитные уровни

При планировании защиты от DDoS L7 используйте следующую модель. Каждый слой захватывает трафик, который верхний слой не ловит.

Чек-лист базовой конфигурации

Выполните эти шаги до того, как вас атакуют. Подстраивайте их под требования вашей заявки.

1. Развернуть Azure WAF с помощью Azure Front Door Premium или Application Gateway WAF v2 для защиты от атак на уровне приложений L7.
2. Переключите политику WAF на режим предотвращения. Политика в режиме обнаружения ведёт только и не блокирует трафик. Сначала проверьте и настройте политику на уровень производственного трафика, чтобы снизить количество ложных срабатываний, а затем включите профилактику.
3. Назначьте набор правил HTTP DDoS (доступен как в Azure Front Door Premium, так и в Application Gateway WAF v2), чтобы автоматизированное устранение проблем изучало ваш базовый уровень трафика до того, как он вам понадобится.
4. Включите управляемый набор правил Bot Manager для выявления и реагирования на известных неисправных ботов.
5. Настройте хотя бы одно универсальное правило лимита скорости (см. Ограничение скорости).
6. Увеличьте количество исходных экземпляров, чтобы было достаточно свободной ёмкости, и настройте Application Gateway на автомасштабирование без ограничения минимального максимального количества экземпляров.
7. Включите кэширование на Azure Front Door, чтобы внезапный пиковый трафик поглощался на краю, а не на исходе.
8. Покройте экспозицию L3/L4, которая зависит от платформы. См. Защита от DDoS платформы различается в зависимости от платформы. Заблокируйте исходный источник так, чтобы он принимал трафик только с Azure Front Door или Application Gateway.
9. Включите диагностическое логирование в Log Analytics и создайте запросы в Analyze WAF и логи доступадо инцидента.

Защита от DDoS платформы различается в зависимости от платформы

Защита уровня 7 важна только если публичные IP-адреса переживают объёмную атаку, а две платформы Azure WAF начинаются не с одного и того же места.

Azure Front Door по умолчанию имеет защиту от DDoS платформы. Azure Front Door — это глобально распределённый edge-сервис, и его край защищён инфраструктурой Azure DDoS без дополнительных затрат и без настройки. Трафик заканчивается на границе Front Door, а не на вашем IP-адресе, поэтому у вас нет публичного IP, который злоумышленник мог бы нацелиться на L3/L4. Эта защита является неотъемлемой частью платформы, поэтому вы не покупаете и не включаете что-либо для её получения.

Application Gateway needs Azure DDoS Network Protection. Шлюз приложения — это региональный ресурс с публичным IP-адресом в вашей собственной виртуальной сети. Стандартная защита Azure на уровне инфраструктуры защищает саму платформу Azure, но не предоставляет наладённых данных по отделу ресурсов, телеметрии или отчётности об атаках для этого IP. Чтобы защитить публичный IP шлюза от объемных атак L3/L4, включите защиту сети Azure DDoS в виртуальной сети, в которой он содержится. Это платная, отдельно приобретаемая услуга.

Практические последствия при выборе или проектировании развертывания:

• Если вы за Azure Front Door, рассмотрите бюджет на управление L7; защита краев L3/L4 уже есть.
• Если вы используете Application Gateway и не включили DDoS Network Protection, ваши правила WAF можно идеально настроить и всё равно обойти их объёмной атакой на публичный IP шлюза. Включите его.
• В любом случае, публичные IP-адреса исходных источников всё равно требуют защиты сети Azure DDoS, плюс блокировки, так что только сервис WAF может к ним связаться. Защищённая передняя часть перед незащищённой, публично доступной точкой не защищена.

Для получения дополнительной информации смотрите обзор Azure DDoS Protection и раздел «Защитить шлюз приложения с помощью Azure DDoS Network Protection».

Автоматизированная защита с помощью набора правил HTTP DDoS (предварительный просмотр)

Статические элементы управления, такие как IP-фильтры, геофильтры и фиксированные лимиты скорости, часто не успевают за распределенными ботнетами: пороги — это догадки, они всегда включены, и их нужно перестраивать по мере изменения трафика. Набор правил HTTP DDoS — это первая автоматизированная модель защиты уровня 7 в Azure WAF, которая обучает, обнаруживает и защищает с минимальными настройками пользователя. Он доступен в предварительном просмотре как на Azure Front Door Premium, так и на Application Gateway WAF v2. После назначения он непрерывно базирует обычный трафик и, когда всплески указывают на атаку, избирательно блокирует нарушающих клиентов без необходимости экстренной настройки.

Дизайн одинаков на обеих платформах в наиболее важных аспектах:

• Два порога, оцениваемых вместе. Набор правил изучает как глобальный порог (для каждого профиля Front Door или для каждого приложения), так и индивидуальные пороги, основанные на IP. Пороги, основанные на IP, применяются только после превышения глобального порога. Эта конструкция не позволяет набору правил действовать на скачки от нескольких IP-адресов, если только они не превышают общий трафик за пределы нормы.
• Область обзора по ресурсам. Пороги изучаются на уровне глобальных ресурсов. Если назначить одну WAF-политику с набором правил для нескольких профилей Front Door или нескольких шлюзов, сервис вычислит пороги отдельно для каждого из них.
• Чувствительность. Каждое правило предлагает три уровня чувствительности. Более высокая чувствительность применяет более низкий порог; Более высокая чувствительность приводит к более высокому порогу. Medium — это стандартная и рекомендуемая настройка.
• Порядок по оценке. WAF сначала оценивает набор правил HTTP DDoS, даже до появления пользовательских правил. Пользовательское правило с действием «Разрешить » обходит все остальные проверки WAF, но не обходит набор правил HTTP DDoS.
• Обход правил для доверенного трафика. Пользовательское правило с действием Разрешить здесь не помогает — оно обходит все остальные правила, но не HTTP-набор правил DDoS. Используйте исключения WAF , которые можно ограничить конкретным правилом, группой правил или целым управляемым набором правил, включая набор правил HTTP DDoS. См. Освобождённый доверенный трафик с исключениями.
• Требуется постоянное движение. Набор правил может действовать только после того, как освоит надёжные базовые линии. Если ресурс не получает достаточного трафика на этапе обучения, набор правил не обнаружит и не защитит, пока это не случится. Смотрите таблицу платформы для конкретного требования.

Различия платформ

Набор правил

В настоящее время набор правил содержит два правила. Каждое правило поддерживает свои базовые линии трафика и может настраиваться с учетом собственной чувствительности и действий:

Штрафная зона

Обе платформы компенсируются штрафной боксом. Когда трафик от клиента превышает порог одного из правил набора правил, этот IP-адрес клиента помещается в штрафную коробку и блокируется WAF на длительность штрафного бокса, которая составляет 15 минут на Application Gateway. Когда период заканчивается, IP-адрес возвращается к доступу, если только не нарушит порог, что возвращает его в штрафную коробку.

Этот дизайн важен для того, как вы читаете телеметрию: фиксируется только первоначальное попадание по правилу. Дополнительные заблокированные запросы, когда IP-адрес уже находится в штрафной коробке, не регистрируются на Front Door, поэтому подсчёты по логам занижают количество заблокированных запросов. В Application Gateway используйте метрику штрафных блоков для истинного количества блоков и размер штрафной коробки для того, сколько IP-адресов сейчас наказано.

Мониторинг во время предварительного просмотра

Когда IP-адрес превышает порог, запись в журнале записывается с помощью действия Block для набора правил HTTP DDoS и шагов метрики WAF Managed Rule Match.

• Front Door: используйте метрику Брандмауэр веб-приложений Request count, фильтрованную по имени правил, для подсчёта блоков, а также метрику Брандмауэр веб-приложений HTTPDDoSRuleset Is Active, которая отчитывается 1 после завершения обучения и готовности набора правил к работе с трафиком, превышающим изученные пороги.
• Application Gateway: каждый следующий заблокированный запрос с наказанного IP-адреса увеличивает метрику Managed Rule Match, а метрики размера штрафной коробки и блоков штрафных блоков отслеживают штрафную коробку напрямую.

Освобождение от доверенного трафика с исключениями

Зонды здоровья, синтетический мониторинг, тесты нагрузки, интеграции с партнёрами и внутренние пакетные задания — всё это создаёт трафик, который выглядит как поток, но на самом деле не такой. Исторически нельзя было освободить их от DDoS-набора правил, потому что пользовательское правило Разрешения обходит Default Rule Set, Core Rules Set и Bot Protection правила, но намеренно не обходит HTTP DDoS.

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

Исключения совпадают:

• Удалённый IP-адрес (Equals или IP Match) — это обычный выбор для исключения известных диапазонов мониторинга, нагрузочного тестирования или партнёрских источников из набора правил DDoS
• URI запроса
• Имя и значение заголовка запроса, сопоставлено с Equals, Starts s, Ends with или Contains

Руководство по использованию исключений в правилах DDoS:

• Охватайте как можно узже. Предпочитаю исключение для каждого правила, а не освобождение от всего набора правил. Широкое исключение даёт злоумышленнику задокументированный путь обхода вашей автоматической защиты от последствий. Если генератору нагрузки нужен только освобождение от правила 500100, не освобождайте его от 500110 тоже.
• Освободить источники, а не пути. IP-основанное исключение для известного тестового жгута ограничено. Исключение на основе URI на публичной конечной точке — это открытая дверь для любого, кто его найдёт.
• Проверяйте их по расписанию. Исключения, добавленные для одноразового нагрузочного теста, могут оставаться в силе и через год.
• Следи за пределами. Каждая политика WAF поддерживает до 60 исключений, а каждая Front Door — 60 в общей сложности по всем соответствующим политикам. Одно исключение может содержать до 600 IP-адресов, 10 URI или 10 заголовков запроса.
• Исключения требуют использования движка WAF следующего поколения и управляемого набора правил DRS 2.1 или новее.

Используйте правильный инструмент для работы: исключения пропускают проверку одного элемента запроса (шумного куки или заголовка), при этом проверяя остальное; Исключения пропускают определённые правила или наборы правил для запросов на сопоставление; пользовательское правило Allow обходит всё, кроме набора правил HTTP DDoS.

Вызов перед блоком

Блокировка — это грубый инструмент при атаке уровня L7: трафик атаки часто поступает с IP-адресов и географических территорий, где также перевозятся реальные пользователи. Испытания позволяют отделить автоматизацию от людей без сопутствующего ущерба, связанного с полным блоком, и именно они являются самым большим изменением в том, как Azure WAF справляется с флудами L7 по сравнению с ограничением скорости только блоков.

• Вызов JavaScript — это невидимая задача, не требующая человеческого взаимодействия. Если браузер успешно вычисляет задачу, WAF проверяет клиент как небот и продолжает оценивать оставшиеся правила; Запросы, которые не проходят, блокируются. Используйте её как основную задачу для общего веб-трафика. Запросы на конечную точку вызова не пересылаются на ваш бэкенд и не учитываются при ограничении скорости.
• CAPTCHA — это интерактивный челлендж, требующий участия пользователей, лучше всего для ценных потоков, таких как вход, регистрация и оформление заказа, где автоматическое нарушение дорогостоящее, а несколько секунд трения с пользователем допустимы. Валидность cookie challenge настраивается в настройках политики от 5 до 1 440 минут, при условии по умолчанию 30 минут. CAPTCHA накладывается на дополнительные расходы, связанные с использованием.

Планируйте ограничения обеих функций перед их внедрением:

• Вызовы AJAX и API не поддерживаются. Не ставьте вызовы перед маршрутами API. Используйте там ограничения скорости и правила матча.
• Испытания предназначены для HTML-ресурсов, а не для встроенных изображений, CSS или JavaScript-файлов.
• При первом запросе, вызывающем вызов, корпус POST ограничен 64 КБ на Azure Front Door и 128 КБ на Application Gateway.
• Ни одна из функций не поддерживает Internet Explorer; обе поддерживают актуальные версии Microsoft Edge, Chrome, Firefox и Safari.
• Вызов JavaScript переиздавается при изменении IP-адреса клиента и для запросов между источниками (CORS).
• В Application Gateway JavaScript Challenge находится в предварительном просмотре и не поддерживается для пользовательских правил с ограничением скорости. Application Gateway for Containers WAF этого не поддерживает.

Ограничение скорости

Минимум создайте правило ограничения скорости, которое блокирует высокий уровень запросов от одного клиента. Установите это правило как правило наименьшего приоритета (с наибольшим числовым значением), чтобы сначала оценивались более конкретные лимиты или правила совпадения.

Azure Front Door – сервис Microsoft

• Ограничения по скорости действуют на IP-адрес сокета, который является адресом клиента, открывающего TCP-соединение с Azure Front Door, и может быть прокси, а не конечным пользователем.
• Пороги оцениваются в течение фиксированного окна в одну или пять минут. После нарушения порога Azure Front Door блокирует весь трафик, соответствующий правилу, на оставшуюся часть окна. Используйте пятиминутное окно для предотвращения HTTP-флуд: злоумышленник, заблокированный в первую минуту, остаётся заблокированным в оставшиеся четыре.
• Более крупные окна с минимальным приемлемым порогом — самая эффективная анти-DDoS-конфигурация. Большие окна и большие пороговые значения также обеспечивают приближение к заданному порогу. При очень низких порогах (примерно до 200 запросов в минуту) некоторые запросы выше порога могут пройти, потому что запросы от одного клиента могут поступать на серверы Front Door, чьи счётчики ещё не обновлены.
• Правила ограничения скорости поддерживают только действия Log и Block ; Разрешение не поддерживается.
• Примените правило ко всему трафику, сопоставив на Host заголовке длиной больше 0, потому что каждый действительный запрос к Azure Front Door имеет такую функцию.

Шлюз приложений WAF версии 2

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

• Правила требуют GroupByUserSession, который контролирует подсчёт запросов. Эта функция позволяет ограничивать рейтинг не по IP клиента:

  GroupByVariable	Используйте его, когда
  ClientAddr (по умолчанию)	Обычный случай с независимыми счётчиками на IP источника
  ClientAddrXFFHeader	Ваш шлюз находится за CDN или прокси, а настоящий IP клиента находится в системе X-Forwarded-For
  GeoLocation	Вы хотите ограничить трафик по стране/регионам во время географически концентрированного наводнения
  GeoLocationXFFHeader	То же самое, что и выше, используя IP-адрес в X-Forwarded-For
  None	Один общий счётчик узко совпадающего шаблона, например, страницы входа или списка подозрительных пользовательских агентов

• Правила ограничения скорости требуют последнего двигателя WAF (выберите CRS 3.2 или более позднее для стандартного набора правил) и не поддерживаются в облаках с воздушным разрывом.

• Application Gateway подсчитывает пороги независимо для каждой конечной точки , к которой прикреплена политика. Одна политика для пяти слушателей поддерживает пять комплектов счетчиков.

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

Установка географически ориентированных порогов

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

Начните с измерения распределения в мирное время как минимум за полную неделю, чтобы были представлены эффекты по будням, выходным и часовым поясам:

• В Azure Front Door разделите метрику количества запросов на измерение ClientCountry.

• В Log Analytics определите страну из IP-адреса клиента в журнале доступа:

  AzureDiagnostics
  | where Category == "FrontdoorAccessLog"
  | where TimeGenerated > ago(7d)
  | extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
  | summarize Requests = count(), Clients = dcount(clientIp_s) by Country
  | extend ShareOfTraffic = round(100.0 * Requests / toscalar(
        AzureDiagnostics
        | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
        | count), 2)
  | order by Requests desc
  

Затем сгруппируйте результаты по уровням и установите порог для каждого:

То, как вы реализуете уровни, зависит от платформы:

• Application Gateway WAF v2 — используйте GroupByVariable: GeoLocation (или GeoLocationXFFHeader за CDN или прокси) так, чтобы весь трафик из одной географии имел общий счётчик, и создайте одно правило ограничения скорости на каждый уровень с собственным порогом. Поскольку утечка действует против каждого клиента в этой географии, осторожно размерьте эти пороги и сначала проверьте их в Log Action: неправильно настроенное правило о широком совпадении географии может привести к частым коротким сбоям для легального трафика.
• Azure Front Door — счётчики рассчитаны на IP-адрес сокета, поэтому строите уровни с учетом условий гео-совпадения: одно правило лимита тарифов на каждый уровень, сопоставленное по соответствующим странам, у каждого свой порог. Каждый клиент в регионе с длинным хвостом получает гораздо более низкий потолок, чем клиенты на ваших основных рынках, при этом поведение одного клиента не влияет на других.

Несколько практик, которые позволяют поддерживать это:

• Упорядочивайте правила от самых конкретных к наименьшим: правила первичного рынка с более высоким приоритетом (ниже числового значения), затем вторичными, затем длиннохвостыми, с глобальным общим правилом как правилом минимального приоритетного лимита ставок.
• Предпочитайте испытательное действие вместо блока для географии с длинным хвостом. Трафик из страны с небольшим легальным объёмом подозрителен в совокупности, но всё равно содержит реальных пользователей — путешественников, пользователей VPN и удалённых сотрудников.
• Переоценивайте после запуска маркетинга, региональных расширений и крупных продуктовых мероприятий. Конфигурация, ориентированная на географию, хороша ровно настолько, насколько хороша базовая линия её размера.
• Обратите внимание на обратный сигнал во время инцидента: страна, которая обычно вносит 1% трафика, внезапно вносит 40% — один из самых быстрых способов убедиться, что вы видите атаку, а не органический рост.

Выберите порог из собственного трафика

Используйте следующий запрос Log Analytics для размера универсального правила. Для Application Gateway замените FrontdoorAccessLog на ApplicationGatewayAccessLog.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

Чтобы определить пороговые значения по географии, описанные выше, добавьте страну к тому же запросу:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

Установите порог выше 99-го процентиля мирного трафика, а не максимальный. Максимум обычно — это краулер или неправильно настроенный клиент, и при таком размере правило становится слишком изысканным, чтобы помочь во время атаки.

Пользовательские правила для целенаправленного смягчения последствий

Создайте пользовательские правила WAF для блокировки или ограничения рейтинга HTTP- и HTTPS-атак с идентифицируемыми сигнатурами, такими как конкретный пользовательский агент, заголовок, куки, шаблон строк запроса, URI или их комбинация. Помимо сопоставления строк, пользовательские правила Azure Front Door WAF могут соответствовать следующим параметрам:

• Геолокация: Заблокируйте трафик из-за пределов вашего региона обслуживания или перенаправьте его на статическую страницу.
• Списки IP-адресов клиента (CIDR ) и IP-ограничений для адресов и диапазонов, которые вы определили как вредоносные.
• Номер AS (ASN): Минимизировать потоки, исходящие от хостинг-провайдера или транзитной сети, откуда ваши легитимные пользователи не исходят, без перечисления IP-диапазонов.
• Отпечаток клиента (JA4): Совпадение по отпечатку JA4, хэшу, полученному из характеристик TLS handshake и HTTP клиента. Поскольку инструменты для атаки и клиенты ботнетов создают единый отпечаток вне зависимости от IP-адреса, с которого они отправляют, JA4 — одна из самых надёжных сигнатур при распределённой атаке: ротация тысяч IP-адресов источника не меняет отпечаток, а блокировка или ограничение скорости уничтожает весь ботнет по одному правилу. Проверьте отпечаток пальца по вашим журналам мирного времени, прежде чем применять его. Популярные браузеры и распространённые SDK имеют общие отпечатки у огромного числа легитимных пользователей, поэтому невалидированный блок JA4 может быть чрезвычайно широким. Сначала развернуть действие Log , убедиться, что отпечаток появляется только в трафике атаки, затем переключитесь на Block или правило ограничения скорости.
• Комбинируйте JA4 с другими состояниями для хирургического смягчения во время инцидента. Например, ограничение скорости вместо блокировки конкретного отпечатка JA4 и ASN, с которого вы не обслуживаете пользователей, или отпечатка JA4 и URI запроса.
• Ограничения на сервисный тег и размер компонентов запроса.

Две важные практики во время инцидента:

• Создайте , разрешите правила совпадения для известного легитимного трафика, чтобы снизить ложные срабатывания, и придайте им более высокий приоритет (меньшее числовое значение), чем ваши правила блокировки и лимита скорости. Помните, что правило Allow обходит другую проверку WAF, но не обходит набор правил HTTP DDoS.
• Оценка правила останавливается на любом действии, кроме Log, и приоритетные номера должны быть уникальными. Зарезервируйте блок низкоприоритетных номеров для аварийных правил, чтобы можно было вставить один во время атаки без перенумерации.

Управляемые правила не направлены на защиту от DDoS, но защищают от других распространённых атак и должны оставаться активными. См. Управляемые правила (Azure Front Door) или Управляемые правила (Application Gateway).

Защитите происхождение

• Заблокируйте доступ к публичным IP на исходном устройстве и ограничите входящий трафик так, чтобы только Azure Front Door или Application Gateway могли к ним связаться. Следуйте рекомендациям по обеспечению безопасности трафика в origins Azure Front Door.
• Убедитесь, что в виртуальной сети Application Gateway нет публично открытых IP-адресов.
• Включите кэширование на Azure Front Door. Кэшированные ответы поглощают пиковый объём на краю и снижают частоту запросов, достигающих исхода данных, что часто является разницей между ухудшением производительности и сбоем.
• Происхождение масштаба с запасом головы. Автоматические и ручные меры по снижению последствий требуют времени; Запасная вместимость покрывает этот пробел.

Реагировать на активную атаку

1. Убедитесь, что это атака, а не органический рост. Проверьте WAF и логи доступа на предмет резких изменений частоты запросов, количества IP клиентов, географического состава, распределения пользовательских агентов и запрошенных URI.
2. Проверьте, что уже смягчает последствия. Убедитесь, что набор правил HTTP DDoS активен, и проверьте его блоки по названию правил. В Application Gateway также проверьте метрики размера штрафных коробок и блоков штрафных блоков, так как в журналах появляется только первый блок на IP-адрес. Проверьте соответствия правил лимита скорости.
3. Сравните географический состав с вашим базовым уровнем. Страна, которая обычно вносит небольшую долю трафика, внезапно доминирует, — это быстрый, высокодоверённый сигнал атаки. Также он показывает, какой уровень правил по лимиту ставок следует ужесточить в первую очередь.
4. Повышайте чувствительность перед написанием новых правил. Повышение чувствительности набора правил HTTP DDoS или снижение существующего порога скорости быстрее и безопаснее, чем создание нового правила под давлением.
5. Бросай вызов, а не блокируй там, где движение смешанно. Применить JavaScript challenge к затронутым HTML-маршрутам и CAPTCHA к чувствительным потокам.
6. Пишите целевое правило только после того, как определите прочную подпись: ASN, отпечаток клиента, комбинацию заголовка, географию или шаблон URI. Сначала развернуть его в Log action, если паттерн совпадает с реальными пользователями.
7. Держите источник под защитой во время настройки: убедитесь, что кэш включён, подтверждение Origin lockdown и масштабируйтесь.
8. После инцидента переопределите пороговые значения тарифов с новыми данными о трафике и сохраняйте актуальность в режиме журнала, если не хотите, чтобы они продолжались постоянно.

Анализ WAF и логов доступа

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

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Шлюз приложений Azure

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Ведущие говорящие и топовые пользовательские агенты через окно атаки (показан Azure Front Door; замена ApplicationGatewayAccessLog Application Gateway):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

Для получения дополнительной информации см. Azure WAF с Azure Front Door и Azure WAF с Шлюз приложений Azure.

Связанные материалы

• HTTP DDoS ruleset: Azure Front Door WAF | Application Gateway WAF
• WAF exceptions list: Azure Front Door WAF | Application Gateway WAF
• Ограничение скорости: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front DoorApplication | Gateway
• Azure вызов JavaScript WAF
• AZURE FRONT DOOR WAF CAPTCHA
• DDoS-защита на Azure Front Door
• Azure DDoS Protection reference architectures
• Обзор защиты от атак DDoS Azure