Rate limiting проти credential stuffing і брутфорсу
Чому «5 невдалих спроб — блокування» вже не працює
Класична порада — блокувати акаунт після кількох невдалих входів — розрахована на зловмисника, який довбає один логін з одного IP. Сучасна атака виглядає інакше. При credential stuffing нападник бере базу вкрадених пар «логін-пароль» з чужого витоку й перевіряє їх на вашому сайті — по одній спробі на акаунт, з тисяч різних IP-адрес, розтягнуто в часі. Ліміт «5 спроб на акаунт» тут безсилий: кожен окремий акаунт бачить лише одну спробу.
Гірше, наївний ліміт на акаунт стає зброєю проти вас: зловмиснику достатньо навмисно провалити входи в чужі акаунти, щоб масово їх позаблокувати. Тобто механізм захисту перетворюється на інструмент відмови в обслуговуванні.
Обмежувати треба за кількома вимірами одразу
Ефективний rate limiting дивиться не на один ключ, а на кілька зрізів трафіку водночас:
- За джерелом. Скільки запитів іде з однієї IP-адреси чи підмережі за вікно часу. Ловить грубий брутфорс з однієї точки.
- За ціллю. Скільки різних акаунтів пробує один клієнт. Один IP, що перебирає сотні логінів, викриває себе, навіть якщо на кожен акаунт припадає одна спроба.
- За кінцевою точкою. Логін, скидання пароля, OTP — чутливі маршрути отримують жорсткіші ліміти, ніж звичайне читання контенту.
- За поведінкою. Різкий сплеск невдалих входів по всьому сайту — сигнал розподіленої кампанії, навіть якщо жодне окреме джерело не перевищує свій ліміт.
Саме поєднання цих зрізів відрізняє розподілену атаку від живого напливу користувачів у години пік.
Швидкий шлях: памʼять вузла, потім спільне сховище
Обмеження частоти має сенс лише тоді, коли воно саме не стає вузьким місцем. Тому лічильники працюють ярусами, від найшвидшого до повільнішого:
- Памʼять вузла. Перший ярус — лічильники в локальній памʼяті edge-вузла, з наносекундним доступом. Переважну більшість рішень ухвалюють тут, без жодного мережевого виклику.
- Спільне сховище між вузлами. Коли важлива координація між нодами — щоб розподілена атака не «розмазалася» по вузлах і не пройшла повз ліміт, — у гру вступає спільний лічильник у швидкому сховищі.
- Ізоляція за тенантами. Кожен лічильник прив’язаний до тенанта й сайту — трафік одного клієнта ніколи не впливає на ліміти іншого.
Цей порядок — памʼять перед мережею — тримає накладні витрати в межах проєктного бюджету затримки; як ми його вимірюємо, розписано в методології.
Ліміт — не бан. Це драбина
Головна помилка — перетворювати перевищення ліміту на жорстке блокування. Легітимний користувач, що забув пароль і кілька разів помилився, не заслуговує на бан. Тому перевищення ліміту веде не в стіну, а на драбину challenge: спершу proof-of-work, далі CAPTCHA. Людина проходить майже непомітно; автоматизований клієнт застрягає, бо кожна сходинка коштує йому обчислень, помножених на масштаб атаки.
Для API-трафіку, де немає інтерфейсу для CAPTCHA, логіка та сама, але акцент на джерелі й поведінці — детальніше в статті про безпеку API на edge.
Чого ми не обіцяємо
Rate limiting не «зупиняє credential stuffing назавжди» — він робить його економічно невигідним і повільним, а ще дає вам видимість: кожне спрацювання осідає в незмінному аудит-логу з прив’язкою до тенанта. Ми не називаємо магічних чисел «витримуємо X запитів», бо реальна межа залежить від вашого трафіку й обладнання. Ми даємо механізм, який масштабується разом із вами, і чесний журнал того, що він зробив.
Хочете закрити свої форми входу від масового перебору? Напишіть нам.