Як захистити сайт від брутфорсу і ботів: WAF, rate-limit, CAPTCHA

Брутфорс і шкідливі боти — це не лише проблема великих сайтів. Для малого та середнього бізнесу навіть простий потік спроб входу, спаму у форми, парсингу контенту або навантаження на /wp-login.php може означати втрату лідів, збої в роботі сайту, зайві витрати на хостинг і ризик компрометації адмін-доступу. Хороша новина в тому, що для базового, але сильного захисту не потрібна складна enterprise-архітектура. У більшості випадків достатньо правильно поєднати три шари: WAF, rate-limit і CAPTCHA або turnstile-перевірки.

У цій статті розберемо, як працює кожен із цих механізмів, де саме їх ставити, що варто захищати в першу чергу на WordPress і сайтах SMB, а також які помилки найчастіше зводять захист нанівець.

Зміст

• Чому брутфорс і боти — реальна проблема для SMB
• Що роблять WAF, rate-limit і CAPTCHA
• Порівняння підходів
• Базова схема захисту для сайту SMB
• Що захищати насамперед на сайті
• Як налаштувати захист без перевантаження сайту
• Типові помилки
• Практичний чеклист
• Висновок
• FAQ

Чому брутфорс і боти — реальна проблема для SMB

Коли говорять про атаки на сайт, багато власників бізнесу уявляють складні злами. На практиці набагато частіше шкодять прості автоматизовані сценарії. Боти масово перевіряють логіни й паролі, надсилають спам у форми, тестують вразливі URL, сканують адміністративні сторінки, створюють фейкові заявки або просто створюють шум, який ускладнює аналітику та роботу відділу продажу.

Для SMB ризик особливо високий, тому що на невеликих проєктах часто немає окремої security-команди. Якщо захист не налаштований, навіть дешевий бот-трафік може створити відчутні проблеми: сайт гальмує, пошта засмічується, CRM отримує сміттєві ліди, а облікові записи адміністраторів стають ціллю для підбору паролів.

Ще одна проблема — боти не завжди виглядають як класична атака. Частина з них поводиться “тихо”: робить небагато запитів, але регулярно, обходить прості блокування, використовує різні IP та імітує поведінку реальних користувачів. Саме тому один плагін “від брутфорсу” рідко дає повний результат. Потрібен багатошаровий підхід.

Що роблять WAF, rate-limit і CAPTCHA

WAF — це веб-аплікаційний фаєрвол. Він стоїть між відвідувачем і сайтом та аналізує HTTP-запити. Його завдання — відсікати підозрілий або явно шкідливий трафік ще до того, як він дійде до WordPress, форми чи бекенду. Для SMB це часто найвигідніший перший шар захисту, особливо якщо WAF працює на рівні CDN або хостингу.

Rate-limit обмежує частоту запитів. Простою мовою: один IP, сесія, країна або інший критерій не може нескінченно часто бити по логіну, формі відновлення пароля, пошуку, API чи кошику. Це критично проти brute force, password spraying, флуда форм і частини бот-сканерів.

CAPTCHA або сучасніші перевірки на кшталт turnstile — це бар’єр між людиною і ботом на найбільш ризикових діях. Їх краще ставити не “всюди підряд”, а на конкретні точки: логін, реєстрацію, скидання пароля, форму заявки, коментарі, інколи checkout або API-ендпоінти з високим ризиком зловживань.

Ключова ідея проста: WAF відсікає частину сміття ще на вході, rate-limit знижує швидкість атак, а CAPTCHA/turnstile додає перевірку там, де потрібна дія саме людини. Разом ці шари дають набагато кращий результат, ніж будь-який окремо.

Порівняння підходів

Інструмент	Що блокує найкраще	Де працює	Сильні сторони	Обмеження
WAF	Відомі шкідливі патерни, сканери, частину ботів, підозрілі запити	На рівні CDN, хостингу або сервера	Блокує трафік до навантаження на сайт, дає централізовані правила	Не замінює захист логіну, 2FA та локальні правила
Rate-limit	Брутфорс, flood-атаки, надто часті запити до форм, API, пошуку	Edge, сервер, застосунок	Простий і дуже ефективний проти масових спроб	Погано налаштований ліміт може зачепити реальних користувачів
CAPTCHA / Turnstile	Автоматичні відправки форм, бот-логіни, фейкові заявки	На конкретних сторінках і діях	Додає перевірку “людина чи бот” там, де це критично	Якщо ставити всюди, псує UX і знижує конверсію

Базова схема захисту для сайту SMB

Для більшості сайтів малого й середнього бізнесу достатньо такої логіки:

• увімкнути WAF на рівні CDN, хостингу або окремого security-рішення;
• поставити rate-limit на логін, скидання пароля, реєстрацію, форми заявок, пошук і чутливі API;
• додати CAPTCHA або turnstile на точки з високим ризиком;
• закрити або обмежити xmlrpc.php, якщо він не потрібен;
• увімкнути 2FA для всіх адміністраторів і редакторів з підвищеними правами;
• стежити за логами невдалих входів, сплесками трафіку та підозрілими країнами / IP.

Це вже значно краще, ніж встановити один “security plugin” і вважати, що питання закрите. Важливо, щоб захист працював на кількох рівнях: до WordPress, на сервері та в самій точці дії користувача.

Чому edge-захист зазвичай вигідніший

Коли шкідливий трафік відсікається до потрапляння на сайт, ваш сервер і WordPress не витрачають ресурси на обробку сміття. Це означає менше навантаження, стабільнішу швидкість і менше шансів, що під час атаки “ляже” не тільки логін, а й увесь сайт. Тому для SMB часто правильний порядок такий: спочатку edge WAF і rate-limit, потім локальні правила в WordPress або на сервері.

Чому тільки CAPTCHA недостатньо

Помилка багатьох сайтів — поставити CAPTCHA на логін і заспокоїтись. Але боти можуть атакувати не тільки логін. Вони б’ють у пошук, коментарі, форми зворотного зв’язку, REST API, XML-RPC, сторінки відновлення пароля. Якщо немає rate-limit і правил WAF, частина трафіку все одно дійде до сайту, створить навантаження або знайде інший вхід.

Що захищати насамперед на сайті

Якщо у вас WordPress або інший типовий SMB-сайт, починайте з цих точок:

• Сторінка логіну — /wp-login.php або власний URL входу.
• Адмінка — доступ до /wp-admin/, особливо якщо ним користується вузьке коло співробітників.
• Скидання пароля — один із найулюбленіших ендпоінтів для abuse.
• Реєстрація — якщо вона відкрита, тут часто з’являються боти.
• Форми лідів і контакту — спам, фейкові ліди, сміття в CRM.
• Пошук і фільтри — їх часто використовують для високочастотних запитів.
• XML-RPC — якщо не використовуєте, краще вимкнути або жорстко обмежити.
• API та webhook-ендпоінти — особливо якщо вони публічні.

Дуже корисно мислити не сторінками, а діями. Запитайте себе: де бот може зайти, спробувати пароль, надіслати форму, створити навантаження або витягувати дані? Саме на ці дії і ставляться захисти.

Як налаштувати захист без перевантаження сайту

1. Почніть із аудиту того, що вже є

На багатьох сайтах частина захисту вже доступна через CDN, хостинг або security-плагін, але вимкнена або налаштована формально. Перевірте: чи є WAF, чи увімкнений rate-limit, чи фільтруються бот-краулери, чи є лог невдалих входів, чи працює 2FA, чи відкритий XML-RPC.

2. Виносьте перший бар’єр ближче до edge

Найкраще, коли основний сміттєвий трафік блокується ще до PHP і WordPress. Це може бути cloud WAF, захист від провайдера хостингу або правила на рівні reverse proxy. Для NGINX часто використовують rate-limit на конкретні location, а для WordPress-сценаріїв — окремі правила для логіну, XML-RPC і чутливих URL.

3. Налаштовуйте ліміти по точках, а не “одним числом на весь сайт”

Логін, форма заявки і сторінка пошуку мають різний профіль навантаження. Якщо поставити один жорсткий ліміт на весь сайт, можна зламати нормальний UX. Краще встановлювати окремі правила: м’якші для перегляду сторінок, жорсткіші для логіну, відновлення пароля, API або форм, які часто атакують.

4. Використовуйте CAPTCHA розумно

Сучасний підхід — не змушувати кожного користувача розв’язувати складні задачки. Краще використовувати менш фрикційні перевірки або ризик-орієнтовані механізми там, де дійсно є зловживання. Для SMB це зазвичай означає: логін, реєстрація, форма заявки, інколи checkout або форма коментарів.

5. Закрийте слабкі місця WordPress

Якщо ви не використовуєте мобільний застосунок WordPress, Jetpack або інші інструменти, яким потрібен XML-RPC, його варто вимкнути або хоча б жорстко обмежити. Окремо перевірте, чи немає зайвих плагінів, які відкривають публічні форми, AJAX-ендпоінти або API без нормальних обмежень.

6. Не забувайте про акаунти

WAF і CAPTCHA не компенсують слабкий пароль адміністратора. Для всіх привілейованих користувачів мають бути унікальні паролі, менеджер паролів і 2FA. Якщо є зовнішні підрядники або тимчасові редактори, перегляньте їхні права доступу та відключайте непотрібні облікові записи.

7. Відстежуйте сигнали, а не лише “успіх атак”

Якщо чекати, доки сайт уже зламають, захист запізниться. Моніторте: різке зростання невдалих логінів, аномалії по країнах, стрибки POST-запитів у форми, навантаження на wp-login.php, сплески звернень до xmlrpc.php або повторювані патерни user-agent.

Типові помилки

• Ставити CAPTCHA на все підряд і погіршувати конверсію.
• Взагалі не мати rate-limit на логін, форми та API.
• Сподіватися лише на плагін усередині WordPress, без edge-захисту.
• Забути про xmlrpc.php, відновлення пароля та технічні ендпоінти.
• Не вмикати 2FA для адміністраторів.
• Не тестувати правила після ввімкнення, через що блокуються реальні користувачі.
• Не вести логи та не мати базового моніторингу.

Головна практична порада: захист має бути не “максимально жорстким”, а збалансованим. Вам потрібно зменшити ризик без зламу реального користувацького сценарію: вхід, заявка, покупка, зв’язок із менеджером.

Практичний чеклист

• WAF увімкнений на рівні CDN, хостингу або сервера.
• Логін, скидання пароля, реєстрація та форми мають окремі rate-limit правила.
• На високоризикових діях є CAPTCHA або turnstile.
• xmlrpc.php вимкнений або обмежений.
• Усі адміни мають 2FA та унікальні паролі.
• Є журнал невдалих входів і сповіщення про аномалії.
• Перевірено, що правила не шкодять реальним користувачам і не ріжуть нормальні форми.
• Ядро, теми, плагіни та серверні компоненти оновлюються регулярно.

Висновок

Захист сайту від брутфорсу і ботів — це не одна кнопка і не один плагін. Для більшості SMB найкраще працює комбінація з трьох шарів: WAF на вході, rate-limit на чутливих точках і CAPTCHA або turnstile там, де потрібно підтвердити, що дію виконує людина. Додайте до цього 2FA, контроль XML-RPC, моніторинг і дисципліну оновлень — і ви закриєте більшість реальних сценаріїв атак без надмірної складності.

Якщо починати з нуля, не намагайтеся впровадити все за один день. Спершу закрийте логін, форми та XML-RPC, потім винесіть фільтрацію ближче до edge і лише після цього допрацьовуйте деталізацію правил. Такий підхід дає швидкий практичний результат і не ламає бізнес-процеси.

FAQ

Чи достатньо лише CAPTCHA на логіні?

Ні. CAPTCHA допомагає, але не замінює WAF, rate-limit, 2FA та захист інших точок, таких як форми, XML-RPC, скидання пароля й API.

Що краще для SMB: WAF чи rate-limit?

Не “або-або”, а разом. WAF відсікає частину шкідливих запитів загалом, а rate-limit дуже ефективний саме проти повторюваних спроб входу, флуда і бот-скриптів.

Чи потрібно захищати XML-RPC?

Так. Якщо він вам не потрібен, його краще вимкнути. Якщо потрібен — обмежити доступ і поставити захист від надто частих звернень.

Чи псує CAPTCHA конверсію?

Може псувати, якщо поставити її на кожен крок. Саме тому краще використовувати її точково або обирати сучасні менш нав’язливі перевірки.

З чого почати, якщо захисту майже немає?

Почніть із трьох речей: увімкніть WAF або edge-захист, поставте rate-limit на логін і форми, додайте CAPTCHA або turnstile на найризиковіші дії. Потім підключіть 2FA та перегляньте XML-RPC.