← Документация WAF / rate-limiting-rules

Лучшие практики rate limiting

В следующих разделах описаны типовые конфигурации rate limiting для распространённых сценариев. Вы можете комбинировать приведённые примеры правил и адаптировать их под свой сценарий.

Основные сценарии применения rate limiting:

• Гранулярный контроль доступа к ресурсам. Включает управление доступом по таким критериям, как user agent, IP-адрес, referrer, хост, страна и регион мира.
• Защита от credential stuffing и атак с захватом учётных записей.
• Ограничьте число операций , выполняемых отдельными клиентами. Сюда входит предотвращение скрейпинга ботами, доступа к чувствительным данным, массового создания новых аккаунтов и программных покупок на платформах электронной коммерции.
• Защита REST API от исчерпания ресурсов (целевых DDoS-атак), а ресурсы — от злоупотреблений в целом.
• Защита GraphQL API — предотвращая перегрузку сервера и ограничивая количество операций.

Типичный сценарий — ограничение частоты запросов от отдельных user agent. Следующее правило-пример позволяет мобильному приложению выполнять максимум 100 запросов за 10 минут. Можно также создать отдельное правило, ограничивающее частоту для десктопных браузеров.

После того как посетитель успешно проходит Managed Challenge, Cloudflare выдаёт cf_clearance (cookie), помечающий их как проверенных. Однако злоумышленники могут пытаться переиспользовать или передавать один действительный cf_clearance значение между несколькими запросами или устройствами для обхода дополнительных челленджей.

Это правило rate limiting помогает смягчить такое злоупотребление, ограничивая количество запросов с одним и тем же cf_clearance (значение) за заданный период. Легитимные пользователи-люди не пострадают, а автоматизированные или повторно воспроизводимые запросы с одним clearance-токеном будут блокироваться после превышения порога.

Ещё один сценарий управления доступом к ресурсам — исключение или включение IP-адресов либо номеров автономных систем (ASN) в правило rate limiting.

Следующий пример правила разрешает до 10 запросов в минуту с одного IP-адреса, выполняющего GET запрос к /status, при условии что IP-адрес посетителя не входит в partner_ips IP-список.

Некоторые приложения получают запросы, порождённые другими источниками (например, рекламой со ссылками на сторонние страницы). Возможно, вы захотите ограничить число запросов от отдельных страниц-реферреров, чтобы управлять квотами или избежать непрямых DDoS-атак.

Для этого примера правила требуется Advanced Rate Limiting.

SaaS-приложения или клиенты, использующие Cloudflare SSL for SaaS могут иметь тысячи хостов в одной зоне, из-за чего создавать отдельные правила для каждого хоста непрактично. Чтобы решить эту задачу, можно создать правило rate limiting, использующее хост в качестве характеристики подсчёта.

Следующее правило-пример будет отслеживать частоту запросов к /login для каждого хоста:

Для этого примера правила требуется Advanced Rate Limiting.

Типичный сценарий использования rate limiting — защита эндпоинта входа от таких атак, как credential stuffing ↗. Следующий пример содержит три разных правила rate limiting с нарастающими санкциями для клиентов, выполняющих слишком много запросов.

Правило #1

Правило №2

Правило №3

Эти примеры правил требуют тарифа Business или выше.

Правило #1 разрешает до четырёх запросов в минуту, после чего срабатывает Managed Challenge. Такая конфигурация даёт легитимным клиентам несколько попыток вспомнить пароль. Если несколько запросов делает автоматизированный субъект, этот клиент, скорее всего, будет остановлен нерешённым Managed Challenge. С другой стороны, если человек получает и проходит челлендж при достижении лимита правила #1, правило #2 обеспечит следующий уровень защиты, разрешая до 10 запросов в течение следующих 10 минут. Для клиентов, превысивших этот второй порог, сработает правило #3 (самое строгое), блокируя клиента на один день.

У этих трёх правил выражение подсчёта отделено от выражения правила (также известного как выражение блокировки). Когда вы настраиваете отдельное выражение подсчёта, критерии совпадения используются только при срабатывании действия. В выражение подсчёта можно включать условия на основе кода состояния HTTP-ответа и заголовков HTTP-ответа, интегрируя тем самым rate limiting с логикой вашего бэкенда.

Можно также использовать два разных выражения — выражение подсчёта и выражение правила/митигации, — чтобы задать:

1. Запросы, используемые для вычисления частоты.
2. Запросы, к которым фактически было применено действие.

Например, правило № 3 вычисляет частоту с учётом POST запросов к /login , вернувшие 401 или 403 код состояния HTTP. Однако при превышении лимита частоты Cloudflare блокирует каждый запрос к example.com , сгенерированных одним и тем же IP-адресом. Подробнее о выражениях подсчёта см. в Расчёт частоты запросов.

Эндпоинты одноразовых паролей (OTP) и верификации (например, /api/otp/validate или /account/verify) — частые цели атак перебором. Эти конечные точки особенно чувствительны, потому что атакующие отправляют большие объёмы запросов с разными кодами, пытаясь угадать действительный OTP.

При настройке rate limiting для этих конечных точек следуйте этим рекомендациям:

• Совпадение с точным путём URI: выражение правила должно соответствовать пути, на который приходит атакующий трафик. Проверьте путь в аналитике перед созданием правила. Правило, нацеленное на /validate/otp не будет соответствовать запросам к /api/otp/validate.
• Использование подсчёта по ответам: учитывать только запросы, возвращающие ответы с ошибками (например, 401 или 403), чтобы не применять rate limiting к легитимным пользователям, отправляющим действительные коды.
• Правильно ограничивайте географию: если вы ограничиваете по странам, убедитесь, что атакующий трафик исходит из всех стран, которые вы видите в аналитике, а не только из одной.

Следующее правило-пример защищает эндпоинт проверки OTP, подсчитывая только неудачные попытки:

Приведённое выше правило требует плана Business или выше.

Если ваш OTP-эндпоинт возвращает 200 и для корректных, и для некорректных кодов (с результатом в теле ответа), используйте вместо этого подсчёт по запросам с более низким порогом:

С помощью rate limiting можно ограничить количество операций, выполняемых клиентом. Конкретное правило для такой защиты зависит от вашего приложения. Следующие примеры охватывают скрейпинг контента ↗ через параметры строки запроса или JSON-тело.

В этом примере клиенты выполняют операции (например, просмотр цен и добавление в корзину) на сайте электронной коммерции с разными параметрами строки запроса. Типичный запрос клиента может выглядеть так:

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

Ваша команда безопасности может рассмотреть настройку лимита на число просмотров цен клиентом, чтобы боты — которые могли ускользнуть от Cloudflare Bot Management — не выгрузили весь каталог магазина.

Правило #1

Правило №2

Эти два правила rate limiting сопоставляют запросы, выполняющие выбранное действие (в этом примере — просмотр цены), и используют IP как характеристику подсчёта. Аналогично предыдущие /login (пример), эти два правила помогут снизить число ложных срабатываний в случае настойчивых (но легитимных) посетителей.

Чтобы ограничить поиск определённого product_id через параметр строки запроса, вы можете добавить именно этот параметр как характеристику подсчёта, чтобы частота рассчитывалась по всем запросам независимо от клиента. Следующее правило-пример ограничивает количество обращений для каждого product_id до 50 запросов за 10 секунд.

Для этого примера правила требуется Advanced Rate Limiting.

По той же схеме правил rate limiting можно защищать приложения, обрабатывающие резервирования и бронирования.

Рассмотрим приложение, которое обрабатывает операцию и её параметры через тело запроса в формате JSON. Например, lookup_price может выглядеть следующим образом:

POST https://api.store.com/merchant
Cookie: session_id=12345

Body:
{
  "action": "lookup_price",
  "product_id": 215
}

В этом сценарии можно написать правило, ограничивающее число действий из отдельных сессий:

Для этого примера правила требуются Advanced Rate Limiting и инспекция payload.

Вы также можете ограничить число обращений к каждому product_id независимо от клиента, выполняющего запросы, развернув правило наподобие следующего:

Для этого примера правила требуются Advanced Rate Limiting и инспекция payload.

Общий подход к выявлению трафика ботов — применять rate limiting к запросам, которые вызывают большой объём 403 или 404 кодов состояния ответа от исходного сервера. Обычно это указывает на автоматизированную активность приложений-скрейперов.

В этой ситуации можно настроить правило, подобное следующему:

Это правило-пример требует плана Business или выше.

Чтобы контролировать частоту действий, выполняемых автоматизированными источниками, рассмотрите использование правил rate limiting вместе с Bot Management. С Bot Management вы можете использовать оценка ботов (bot score) в критериях сопоставления, чтобы применять правило только к автоматизированному или вероятно автоматизированному трафику. Например, можно использовать максимальную оценку (порог) 30 для вероятно автоматизированного трафика и 10 для автоматизированного трафика.

Если ваше приложение отслеживает сессии с помощью cookie, вы можете использовать cookie для задания контекста rate limiting (то есть как характеристику подсчёта). Если задать характеристикой rate limiting значение Cookie, правило будет группировать запросы с разных IP-адресов, но принадлежащие одной сессии, — типичный сценарий при работе с ботнетом, выполняющим распределённую атаку.

Правило #1

Правило №2

Эти примеры правил требуют Advanced Rate Limiting и Bot Management.

Если приложение не использует сессионный cookie, вы можете использовать JA3-отпечатки для идентификации отдельных клиентов. JA3-отпечаток — это уникальный идентификатор, доступный клиентам с Bot Management, который позволяет Cloudflare определять запросы, приходящие от одного клиента. Отпечаток есть у всех клиентов — как автоматизированных, так и нет.

Этот пример правила требует Advanced Rate Limiting и Bot Management.

API могут создавать значительную нагрузку на бэкенд приложения, поскольку API-запросы могут быть дорогими в вычислении и обслуживании. Такие запросы могут также требовать сложных операций (например, обработки данных и объёмных выборок), которые при злоупотреблении способны в итоге вывести исходный сервер из строя.

Advanced Rate Limiting может смягчать многие типы объёмных атак, такие как DDoS-атаки, mass assignment и эксфильтрация данных.

Распространённая задача — ограничить POST действия. Для аутентифицированного трафика вы можете использовать API Discovery, чтобы определить подходящую частоту запросов для каждого эндпоинта, а затем создайте правило rate limiting, подобное следующему:

Для этого примера правила требуется Advanced Rate Limiting. Для API Discovery требуется дополнительная лицензия.

Характеристикой подсчёта может быть любой заголовок, ключ, токен, cookie, параметр запроса и даже поле JSON-тела, поскольку некоторые API передают ID сессии или ID пользователя в JSON-теле. Дополнительную информацию см. в следующих разделах:

• Если ваш уникальный идентификатор находится в пути URI, см. Защита ресурсов.
• Если ваш уникальный идентификатор находится в JSON-теле, см. Предотвращение скрейпинга контента (по телу запроса).

GET запросы также могут создавать чрезмерную нагрузку на приложение или затрагивать дорогостоящие ресурсы, например пропускную способность. Рассмотрим приложение с большим количеством хранимых файлов (например, изображений), где клиенты скачивают файл по его URL:

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

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

Для этого примера правила требуется Advanced Rate Limiting.

Правило задаёт лимит в 10 скачиваний за 10 минут для каждого файла в https://api.store.com/files/*. Используя Path как характеристику правила, вы избавляетесь от необходимости писать новое правило каждый раз, когда появляется новый загруженный файл с другим <FILE_ID>. С этим правилом частота вычисляется по каждому запросу независимо от исходного IP или идентификатора сессии.

Вы также можете сочетать Path с x-api-key (заголовок) — или IP, если ключа или токена нет, — чтобы задать максимальное число скачиваний, которое конкретный клиент, идентифицируемый по x-api-key, может составить о данном файле:

Для этого примера правила требуется Advanced Rate Limiting.

Предотвращение перегрузки сервера для GraphQL API может отличаться от предотвращения перегрузки для RESTful API. Одна из главных трудностей приложений на GraphQL в том, что все запросы к серверу проходят через один путь, и каждый запрос обычно представляет собой POST операции. Это не позволяет задавать разные лимиты частоты для разных сценариев использования API на основе HTTP-метода и пути URI.

Однако, в отличие от RESTful API с его методом и путём, назначение запроса обычно заложено в теле, где указано, какие данные клиент хочет получить или изменить (согласно Терминология GraphQL ↗ для изменения данных на стороне сервера) вместе с любыми дополнительными данными, необходимыми для выполнения действия.

Чтобы предотвратить перегрузку сервера, рассмотрите следующие подходы:

1. Ограничьте число вызовов одной и той же GraphQL-операции конкретным пользователем.
2. Ограничьте суммарную сложность запросов, разрешённую каждому отдельному пользователю.
3. Ограничьте сложность запроса для каждого отдельного запроса.

Следующие примеры основаны на приложении, принимающем отзывы о фильмах. GraphQL-запрос может выглядеть так:

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345

Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

Чтобы ограничить частоту действий, можно использовать следующее правило:

Для этого примера правила требуются Advanced Rate Limiting и инспекция payload.

Сложность обработки GraphQL-запроса может существенно варьироваться. Поскольку API использует единственный эндпоинт, трудно определить сложность каждого запроса до его обслуживания.

Чтобы защитить исходный сервер от исчерпания ресурсов, нужно ограничивать не число запросов, а объём сложности, необходимой для обслуживания одного клиента за период времени. Cloudflare Rate Limiting позволяет создавать правила, которые отслеживание сложности во времени и блокировать последующие запросы после исчерпания бюджета или лимита сложности.

Этот тип rate limiting требует, чтобы сервер оценивал каждый обслуженный запрос по его сложности. Кроме того, сервер должен добавлять эту оценку в ответ в виде HTTP-заголовка. Затем механизм rate limiting использует эту информацию для обновления бюджета конкретного клиента.

Например, следующее правило задаёт суммарный бюджет сложности 1 000 в час:

Для этого примера правила требуются Advanced Rate Limiting и инспекция payload.

Обрабатывая запрос, исходный сервер добавляет score HTTP-заголовок к ответу со значением, отражающим, сколько работы источник затратил на его обработку, — например, 100. В следующий час тот же клиент может выполнять запросы в пределах дополнительного бюджета 900. Как только этот бюджет будет превышен, последующие запросы будут блокироваться до истечения тайм-аута.

Клиенты API Shield могут использовать защиту от вредоносных запросов GraphQL для своих GraphQL API. Эта защита сканирует GraphQL-трафик на запросы, способные перегрузить исходный сервер и привести к отказу в обслуживании. Вы можете создавать правила, ограничивающие глубину и размер входящих GraphQL-запросов, чтобы блокировать подозрительно большие или сложные запросы.

См. Документация API Shield ↗ для получения дополнительной информации о защите от вредоносных запросов GraphQL.