Настройка rate limit¶

Неограниченное потребление ресурсов включено в список OWASP WAF Top 10 2023 – наиболее серьезных угроз безопасности API. Без надлежащих мер по ограничению скорости API уязвимы для таких атак, как отказ в обслуживании (DoS) и перегрузка серверов API. В этой статье объясняется, как защитить ваш API и пользователей с помощью правила Вебмониторэкс для регулирования лимита подключений.

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

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

Создание и применение правила¶

Чтобы настроить и применить лимит подключений:

1. Перейдите в Консоль Вебмониторэкс → Правила и нажмите Добавить правило.

2. В поле Если в запросе опишите область применения правила – запросы, которые следует ограничить.

3. В поле Тогда выберите Установить rate limit и укажите желаемый лимит для подключений к вашей области:

   • Максимальное количество описанных запросов в секунду или минуту.
   • Всплеск пакетов - максимальное количество избыточных запросов, которые будут помещены в буфер после превышения указанного значения RPS/RPM и обработаны, как только скорость вернется к нормальному значению. По умолчанию 0.

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

   • Код ответа - код, который будет возвращен в ответ на отклоненные запросы.

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

   • Remote_addr для ограничения подключений по исходному IP-адресу.
   • json → json_doc → hash → api_key для ограничения подключений с помощью api_key параметра тела JSON.

5. Дождитесь завершения компиляции правил.

Примеры правил¶

Ограничение подключений по IP для обеспечения высокой доступности API¶

Предположим, что REST API медицинской компании позволяет врачам отправлять информацию о пациентах через запрос POST на эндпоинт /patients хоста https://example-host.com. Этот эндпоинт содержит конфиденциальную личную медицинскую информацию, и важно гарантировать, что она не будет использована неправильно или перегружена большим количеством запросов.

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

Например, можно установить ограничение на 5 POST-запросов в минуту для каждого IP-адреса следующим образом:patients

Ограничение подключений по сессиям для предотвращения атак методом перебора параметров аутентификации¶

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

Предположим, ваше приложение присваивает каждой пользовательской сессии уникальный идентификатор и отражает его в заголовке X-SESSION-ID. Эндпоинт API по URL-адресу https://example.com/api/login принимает запросы POST, которые включают JWT носителя в заголовке Authorization. Для этого сценария правило, ограничивающее подключения по сессиям, будет выглядеть следующим образом:

Регулярное выражение, используемое для значения Authorization:

^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$

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

Ограничение подключений на основе пользовательского агента для предотвращения атак на эндпоинты API¶

Допустим, у вас есть старая версия вашего приложения с некоторыми известными уязвимостями безопасности, позволяющими злоумышленникам перебрать конечную точку API https://example.com/login, используя уязвимую версию приложения. Обычно заголовок User-Agent используется для передачи версий браузера/приложения. Чтобы предотвратить грубую атаку через старую версию приложения, вы можете реализовать ограничение подключений на основе User-Agent.

Например, вы можете установить лимит в 10 запросов в минуту для каждого User-Agent. Если конкретный User-Agent делает более 10 запросов, равномерно распределенных в минуту, дальнейшие запросы от этого User-Agent отклоняются до начала нового периода.

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

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

Например, правило, ограничивающее каждого клиента 10 POST-запросами в минуту к https://example.com/orders, может выглядеть так, как показано ниже. В этом примере рассматривается, что идентификатор клиента передается в объекте тела JSON data.customer_id.

Ограничения и особенности¶

Функционал ограничения скорости имеет следующие ограничения и особенности:

• Правило ограничения скорости поддерживается всеми формами развертывания Вебмониторэкс.

• Максимально допустимая длина значений параметров, по которым измеряются пределы, составляет 8000 символов.

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

• Если к входящим запросам применяются несколько правил ограничения скорости, для ограничения запросов используется правило с наименьшим ограничением скорости.

• Если для входящего запроса нет точки, указанной в разделе В этой части запроса, то это правило не применяется в качестве ограничения для этого запроса.

• Если ваш веб-сервер настроен на ограничение подключений (например, с помощью модуля NGINX
  ngx_http_limit_req_module), и вы также применяете правило Вебмониторэкс, веб-сервер отклоняет запросы по настроенным правилам, а Вебмониторэкс — нет.

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