Обмеження швидкості * un * -аутентифіковані запити

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

Однак що робити з користувачами, які не ввійшли в систему (неаутентифіковані)? Ми точно не знаємо, хто саме або звідки надходить запит, тому не можемо легко обмежити ці запити або ..?

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

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

Однак що робити з користувачами, які не ввійшли в систему (неаутентифіковані)? Ми точно не знаємо, хто саме або звідки надходить запит, тому не можемо легко обмежити ці запити або ..?

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

Інший підхід до обмеження ставок, який ви можете скористатися, - це вимагати підтвердження роботи для будь-яких несанкціонованих запитів. Ваш сервер видає код виклику, згідно з яким будь-які клієнти, які подають неавторизований запит (наприклад, запити на вхід), повинні обчислити ресурсоємну відповідь перед тим, як запит буде оброблений. Загальна реалізація цієї ідеї вимагає від клієнтів розрахунку часткової реверсії хешу.

Щоб знати, чи запит від автентифікованого користувача або від анонімного користувача, вам потрібно обов'язково обробити запит (хоча і швидко). Це все ще означає, що ваша програма вразлива для атаки на відмову в обслуговуванні.

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

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

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

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

Ви можете надати окремі обмеження швидкості для анонімних та зареєстрованих користувачів, спрямовуючи зареєстрованих користувачів на різні URL-адреси. Наприклад, ви можете просто встановити префікс усіх анонімно доступних URL-адрес шляхом "/ u", щоб створити кінцеву точку, яка завжди вимагає автентифікації та має інший ліміт швидкості.

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

У 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-адреси - хороший початок. Але якщо вам потрібен більш сильний захист, ваш найкращий вибір буде залежати від вашої моделі потоку (який тип атак ви хочете запобігти).