Ограничение скорости * un * -аутентифицированные запросы

11

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

Однако как насчет не вошедших (не прошедших проверку подлинности) пользователей? Мы точно не знаем, кто именно или откуда поступил запрос, поэтому не можем легко ограничить эти запросы или ...?

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

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

load-balancing nginx rate-limiting

2

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

— Роберт Харви,

1

Почему вы хотите использовать ограничение скорости? Чтобы противостоять атакам типа «отказ в обслуживании», чтобы пользователи не превышали свой тарифный план, что-то еще? Вариант использования влияет на методы, которые вы можете эффективно использовать.

— Барт ван Инген Шенау

1

Этот вопрос может больше подойти для security.stackexchange.com , хотя я не говорю, что он не по теме

— Peeyush Kushwaha

@BartvanIngenSchenau все вышеперечисленное?

Почему у вас должно быть два разных ограничения скорости? Вы продаете какие-либо "планы" с различными ограничениями / особенностями?

— Laiv

9

Однако как насчет не вошедших (не прошедших проверку подлинности) пользователей? Мы точно не знаем, кто именно или откуда поступил запрос, поэтому не можем легко ограничить эти запросы или ...?

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

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

— Ли Райан
источник

Я не вижу, как «доказательство работы» может предотвратить атаки DOS? Клиент может игнорировать вызов и продолжать отправлять запросы вплоть до сбоя. Есть 3-й процесс, решающий проблему?

— Laiv

4

@Laiv POW можно надежно выдавать и проверять, распределяя без подключения к центральной базе данных, где большинство других схем ограничения скорости терпят неудачу. Это увеличивает стоимость атаки для атакующего, поскольку масштабирование вашей защиты и увеличение коэффициента загрузки дешевле для вас и законных пользователей, чем масштабирование атаки для атакующего. Это создает экономический сдерживающий фактор для атаки на систему, поскольку также эффективно исключает использование устройств с низким энергопотреблением (например, скомпрометированных принтеров, IOT, маршрутизаторов) в качестве эффективной платформы для атак.

— Ли Райан

6

Чтобы узнать, был ли запрос от аутентифицированного пользователя или от анонимного пользователя, вы должны обязательно обработать запрос (хотя и быстро). Это по-прежнему означает, что ваше приложение уязвимо для атаки типа «отказ в обслуживании».

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

Кроме того, как общее правило, вы, вероятно, не должны предполагать, что атака не будет осуществляться аутентифицированным пользователем, как минимум в отношении атак DOS. Слабый пароль легко позволит кому-то предположить личность старого пользователя. Итак, предположим, что вы могли бы сделать такую проверку, ваши (люди) пользователи никогда не должны выполнять запросы с такой скоростью, даже если у вас много отдельных пользователей.

— Нил
источник

Я полагаю, вы могли бы использовать IP-адреса и установить лимит высокой скорости для каждого из них. Я предполагаю, что хорошо организованная DoS-атака может использовать тысячи IP-адресов? может больше? idk ... Я знаю, что один и тот же IP-адрес может быть использован для нескольких разных клиентов, но я бы сказал, что есть большая вероятность, что это один и тот же пользователь, верно?

— Александр Миллс

@AlexanderMills Хорошо, предположим, вы решили, что алгоритм будет проверять наличие нескольких запросов с одного и того же IP-адреса. Даже если их тысячи, они будут повторяться для более чем 1000 запросов. Ваш сервер регистрирует первый запрос с заданного IP-адреса, и начинается переполнение. Ваш сервер уже загружен запросами. Вы даже не можете обработать достаточно запросов, чтобы получить второе повторение с того же IP-адреса (который все еще может быть законным запросом). Кстати). Это защитит от DoS-атак, когда используется только тот же IP-адрес. Лучше использовать оба, если что-нибудь. : P

— Нил

0

Одним из основных предложений Cloudflare является защита от атак типа «отказ в обслуживании», предоставляя интеллектуальный прокси для вашего API / веб-сервера. Базовый сервис бесплатный; они зарабатывают на других связанных сервисах, таких как услуги CDN и балансировка нагрузки. Они также предоставляют более сложные и контролируемые услуги по ограничению скорости , в настоящее время по цене 0,05 доллара США за 10 000 хороших запросов (плата за отклоненные запросы не взимается), но вам нужно перейти на платные планы, чтобы получить более одного глобального правила.

Вы можете использовать сервис Cloudflare с AWS или любой другой платформой, если у вас есть контроль над серверами имен вашего домена (например, вы можете изменить серверы имен, зарегистрированные для вашего домена).

Вы можете предоставить отдельные ограничения скорости для анонимных и вошедших в систему пользователей, направляя вошедших в систему пользователей по разным URL-адресам. Например, вы можете просто поставить перед всеми анонимно доступными URL-путями префикс «/ u», чтобы создать конечную точку, которая всегда требует аутентификации и имеет другое ограничение скорости.

Обратите внимание, что ограничение скорости Cloudflare (как и все ограничения коммерческих ставок для анонимных пользователей, о которых я знаю) определяет клиента по его IP-адресу. Это может вызвать проблемы у людей, использующих коммерческие VPN или Tor, так как они склонны скрывать большое количество клиентов за 1 IP-адресом для дополнительной конфиденциальности.

— Старый Про
источник

0

В AWS есть связанные сервисы AWS Shield и AWS WAF . Они в первую очередь предназначены для предотвращения DDoS-атак, но также предлагают поддержку ограничения скорости на основе IP-адресов.

В WAF эта концепция называется правилами на основе ставок . Предотвращение попыток входа в систему методом грубой силы упоминается в качестве варианта использования в первоначальном объявлении :

Этот новый тип правил защищает веб-сайты клиентов и API-интерфейсы от таких угроз, как DDoS-атаки веб-уровня, попытки входа в систему методом "грубой силы" и вредоносные боты. Правила на основе тарифов автоматически срабатывают, когда веб-запросы от клиента превышают определенный настраиваемый порог.

Другие облачные провайдеры должны иметь аналогичные предложения. Вот табличное сравнение: Google Cloud Armor против AWS WAF против Cloudflare WAF .

Поскольку вы уже используете Nginx, использование встроенного ограничения скорости на основе IP также может быть простым вариантом. Модуль называется ngx_http_limit_req_module . Этот блог описывает, как его можно использовать.

Обратите внимание, что ограничение скорости на основе IP - это относительно простая концепция, но она не идеальна:

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

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

— Филипп Классен
источник