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

Рекомендации по ограничению скорости запросов

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

Основные сценарии использования ограничения скорости следующие:

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

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

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

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

Ещё один сценарий использования при управлении доступом к ресурсам: исключение или включение IP-адресов или номеров автономных систем (ASN) в правило ограничения скорости.

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

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

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

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

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

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

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

Правило №1

Правило №2

Правило №3

Для этих примеров правил требуется тарифный план Business или выше.

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

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

Можно также использовать два отдельных выражения: выражение подсчёта и выражение правила (противодействия), чтобы определить:

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

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

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

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

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

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

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

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

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

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

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

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

Правило №1

Правило №2

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

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

Для этого примера правила требуется Advanced 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.

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

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

Для этого примера правила требуется тарифный план Business или выше.

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

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

Правило №1

Правило №2

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

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

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

API способны создавать серьёзную нагрузку на бэкенд приложения, поскольку обработка и обслуживание таких запросов может обходиться дорого. Кроме того, подобные запросы нередко требуют сложных операций, например обработки данных или поиска в больших массивах, и при злоупотреблении это способно в итоге вывести исходный сервер из строя.

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

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

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

Характеристикой подсчёта может быть любой заголовок, ключ, токен, файл cookie, параметр запроса или даже поле в теле JSON, поскольку некоторые API передают идентификатор сессии или 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 позволяет создавать правила, которые отслеживать сложность с течением времени и блокировать последующие запросы после достижения бюджета сложности или лимита.

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

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

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

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

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

См. Документация API Shield ↗ подробнее о защите от вредоносных GraphQL-запросов.