Захист сайту від фаззингу: Вас ламають, поки ви спите

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

У вебі це називається фаззинг (fuzzing).  От прямо зараз тисячі ботів сканують ваш сайт, намагаючись знайти забутий архів site_old.zip, папку .git або файл .env з паролями від бази даних, або намагаються встромити SQL-ін’єкцію в одну з ваших форм. Для зломщика це найдешевший і найефективніший спосіб знайти «вхід з чорного ходу».  Якщо ви адміністратор сайту і у вас немає прав «бога» над сервером, а ваше завдання зробити так, щоб цей робот обламав про ваш сайт свої залізні зуби, то ця стаття для вас.

Фаззинг — що це таке? (Пояснюємо «на пальцях»)

Фаззинг — це метод автоматизованого хаосу. Програма-фаззер (наприклад, ffuf або dirsearch) бере величезний словник (десятки тисяч слів) і починає підставляти їх в адресний рядок вашого сайту, просто до вашого url, або адресу вашої форми.

• «Є  папка /admin?»— Ні.
• «А /backup?»— Ні.
• «А /wp-content/uploads/2023/db.sql?»— Ага, є!

Як тільки фаззер отримує відповідь, відмінну від «404 Not Found», хакер відкриває шампанське. Він знайшов те, що ви не збиралися йому показувати.

Як ваш сайт «відкривають» фаззингом

Хакери використовують три загальні тактики:

1. Content Discovery (Пошук м’яса): Перебір імен файлів. Шукають бекапи, конфіги, логи помилок та тестові скрипти (test.php), які ви чи розробник залишили «на хвилинку».

Таблиця 1: Приклади урлів, які бот намагається знайти на сайті

2. Parameter Fuzzing (Пошук шпарин в лозиці): В адресний рядок підставляються приховані команди.

Таблиця 2: Приклади параметрів запитів, з якими роботи звертаються на ваш сайт.

3. Payload Fuzzing (фаззинг форм): Бот «згодовує» вашим формам зворотного зв’язку або якимось іншим лапки, дужки та шматки коду, сподіваючись, що база даних «чхне» та її знудить помилкою з технічною інформацією.

Таблиця 3: Фаззинг форм (Введення аномальних даних)

Значення лога: Ваша камера спостереження

Потрібно зауважити, що на першій лінії захисту – лінії сервера більшість фаззинг-атак відсікається і в 90% випадків адміністратори сайтів взагалі не звертають уваги на фаззинг. Це завдання для сисадмінів серверів, техпідтримки хостингу, де знаходиться сайт. Розумні сисадміни стежать за логами Apache та інших NGinx і відстежують підвищену активність і рубають її на корені. Поодинокі залишки, які таки проникають на сайт, рубаються різними плагінами безпеки, з якими адміни сайтів працюють за принципом “Постав-забув”.  Проте злі хакери не сплять і постійно вигадують нові алгоритми для своїх роботів і сподіватися лише на техпідтримку хостингу чи якийсь Akismet (плагін захисту форм) – не варто.  І адміністратору сайту теж потрібно займатися захистом від фаззингу. Тому що повільною сапою, потихеньку, але сайт цілком можуть зламати. Що ж може зробити адмін сайту? У нього немає доступу до «чорних ящиків» сервера.  Але є логи CMS і панель управління хостингом, в якій теж є логи доступу та логи помилок.

Методи боротьби: Оборона всередині сайту

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

• Гігієна – наше все: Ніколи, чуєте, ніколи не зберігайте архіви сайту в кореневих папках. Зробили бекап — завантажили на комп’ютер — видалили із сервера.
• Маскування адмінки:Змініть стандартну адресу входу (наприклад /wp-admin) на щось унікальне. 90% фаззерів просто пролетять повз, не знайшовши стандартних «дверей».
• Generic Errors:Налаштуйте CMS показ простих помилок. Замість “Помилка SQL у рядку 154 у файлі /var/www/user/db.php” користувач (і хакер) повинен бачити просто: “Щось пішло не так”.
• Розумні плагини: Встановіть модулі захисту (Wordfence, iThemes). Вони вміють автоматично банити IP, який занадто часто запитує неіснуючі файли.

Захист від фаззингу: Cloudflare – ваш вибивала на вході

Якщо хостинг і сисадміни – це поліцейський патруль, який розгрібає наслідки всередині, то Cloudflare – це потужний вибивала на вході в клуб. Це ваша перша лінія оборони. Його головна краса в тому, що він ловить фазерів за шкірку ще на вулиці, не даючи їм навіть торкнутися дверей вашого сервера. Щоб фаззинг не перетворився на головний біль, ваш вибивала повинен використовувати весь арсенал:

• WAF (Web Application Firewall): Це чорний перелік рецидивістів. Cloudflare знає «почерк» та обличчя популярних фазерів. Якщо бот намагається просунути в запит типовий код для злому популярних CMS, вибивала просто дає йому розворот без пояснення причин.
• Rate Limiting (Лічильник на вході): Справжній фазер – це часто кулемет, який випускає тисячі запитів за хвилину. Налаштуйте обмеження: якщо один і той же «відвідувач» стукає у двері частіше 10-20 разів на хвилину, вибивала відправляє його в бан. Це миттєво остуджує запал автоматичних скриптів, які намагаються підібрати паролі або знайти приховані папки.
• Custom Firewall Rules (Особисті орієнтування): Тут ви даєте вибивалі чіткі вказівки, кого не пускати за жодних умов. Створіть правила для блокування запитів до чутливих файлів: якщо хтось шукає .env, .git, .sql або старі бекапи типу config.php.bak – бан прилітає миттєво. Звичайному користувачеві там робити нічого.
• Security Level “High” та Managed Challenge: Це перевірка на адекватність. Підозрювальних типів змушують розгадати капчу або пройти невидимий JavaScript-тест. Фаззери – це тупі боти, вони не вміють вирішувати логічні завдання на льоту, тому їхня атака просто захлинеться на порозі.
• Bot Fight Mode: Режим «полювання на роботів». Cloudflare аналізує поведінку: людина за одну секунду не буде перевіряти наявність папок /admin/, /backup/ і /dev/. Якщо гість поводиться як робот — вибивала виставляє перед ним бетонну стіну.
• IP Firewall и Geo-Blocking: Навіщо пускати до клубу тих, кого ви не звали? Якщо ваш бізнес локальний і ви бачите атаку з країни, де у вас немає клієнтів, просто заблокуйте цей регіон. Одним кліком ви відсікаєте цілі ботнети.
• Origin Protection (Забитий чорний хід): Це критично важливо. Весь Cloudflare не буде мати жодної користі, якщо хакер дізнається «справжній» IP вашого сервера і піде в обхід вашого охоронця . Щоб цього не сталося, налаштуйте сервер (через .htaccess або конфіг Nginx) так, щоб він приймав запити лише від IP-адрес Cloudflare. Для решти сервер повинен прикидатися мертвим. Так ви гарантуєте, що жоден фаззер не пролізе через вікно, поки охоронець стоїть біля парадного входу. Не забудьте, правда, внести себе коханого у білий список, а також всіх контент-менеджерів та редакторів свого сайту, а то вибивала і викине вас за шкірку теж.

Зауважимо, що більшість з цих методів потрібно застосовувати обережно, оскільки вони впливають на трафік чи індексацію сайту.  Наприклад, можна виставити Rate Limiting так, що Cloud Flare буде викидати ботів Google, відповідальних за індексацію і тоді ви будете перейматися, чому ж ніхто не ходить на сайт.

Якщо сайт НЕ в CDN (Один на один із загрозою)

Якщо ваш сайт дивиться в світ «голою» IP-адресою:

• Пастки (Honeypots): Створіть файл secret_passwords.txt та не посилайтеся на нього ніде. Будь-хто, хто спробує його відкрити — стовідсотковий бот. Використовуйте плагіни, які забанять його за це миттєво.
• Заборона лістингу: Переконайтеся, що при переході на адресу типу:

/uploads/
/wp-content/uploads/
/images/
/pdf/

не відкривається список файлів.

• Файл .htaccess: Це ваш останній рубіж. Додайте до нього правила, що забороняють доступ до файлів конфігурації та бекапів).

Приклад htaccess с захистом від основних фаззинг-загроз

# 1. Заборона лістинга папок
Options -Indexes

# 2. Обмеження довжини рядка запиту (захист від диких параметрів)
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.{512,}$ [OR]
RewriteCond %{REQUEST_URI} ^.{512,}$
RewriteRule .* - [F,L]

# 3. Повна заборона доступа до системних файлів (.git, .env и т.д.)
RewriteRule "(^|/)\." - [F,L]

# 4. Глобальний фільтр на беккапи, архівы та конфіги
<FilesMatch "\.(bak|sql|sql\.gz|tar|zip|gz|7z|rar|env|ini|log|conf|config|old|save|swp|dist|git|sh|bat|bin|phtml|asp|aspx|jsp|cgi|pl|py|bak[0-9]|temp|tmp)$">
    Order allow,deny
    Deny from all
</FilesMatch>

# 5. Індивідуальний бан для "небезпечних" імен файлів
<FilesMatch "^(wp-config\.php|configuration\.php|settings\.php|db_backup\.sql|dump\.sql|phpinfo\.php|info\.php|test\.php|1\.php|cmd\.php|shell\.php)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Цей приклад – загальний, вам треба налаштувати його під себе. Хоча б для того, щоб не обмежити доступ для самого себе, якщо це потрібно вам, чи скриптам вашого сайту. Але для якогось простого сайту, на якому нема великого функціоналу, такий htaccess буде працювати.

Кейс hi-tech.ua: досвід відбиття реальної атаки

Автор цього матеріалу є адміном сайту https://hi-tech.ua, на якому ви зараз знаходитесь. Сайт під захистом CDN Cloud Flare. Все налаштовано, все за чек-листом та протоколами.  Буквально кілька днів тому, а саме 25 лютого 2026 року впав весь сервер, на якому знаходився сайт. Впав ближче до півночі. Пропав доступ на http. Наші поліцейські, сисадміни, підняли сервер. Як адмін сайту я швиденько, одним оком, подивився на логи доступу та помилок. Логи не роздуті, як завжди, є сліди фаззингу, ddos-атак немає, але все на рівні фону, такі скрипти прориваються постійно, але небагато, і відсікаються внутрішніми плагінами та налаштуваннями.  У логах Cloud Flare також все чисто, на рівні фону. Нічого такого, щоб вказувало на те, що саме наш сайт спричинив падіння сервера. Ну мало що там трапилося на серверному майданчику.  Однак наступного дня 26 лютого сервер знову впав. Його знову підняли.  І знову я вирішив подивитись логи. Цього разу логи доступу виявилися в 5 разів більшими за звичайні. А логи помилок – майже пустими. На перший погляд виглядало як ddos-атака. Але як же таке пропустив Cloud Flare, наш вибивала? Боти пройшли його та загрузли в другій лінії захисту. І чому першого дня логи не розпухли?

При більш пильному аналізі логів цього дня і минулих, виявилося що сайт зазнав комбінованого фазингу (Payload Fuzzing з SQL ін’єкцією у пошукову форму та багаторазовим кодуванням) з великої кількості (понад 1000) IP-адрес з абсолютно різних регіонів від України до США, від Китаю до Буркіна-Фа. Боти маскувались під AmazonBot, YandexBot, ChatBot та інші. Ось таких стрічок у лозі було достатньо багато:

GET /search/%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525253bassert%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528base64_decode%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252527cHJpbnQobWQ1KDMxMzM3KSk7%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252527%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525253b/ HTTP/1.1" 200 15130 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"

Причому з кожного IP робилися різні, неоднакові запити з частотою трохи більше 5 штук за хвилину. Дуже рідко. Тому їх пропустили і фільтри Cloud Flare та власні внутрішні плагіни безпеки. Погано було те, що пошукова форма повертала 200 OK,  і намагалася виконати запити до БД.  Хоча сама SQL-ін’єкція конвертувалася в звичайний текст, і не виконувался, але ж сам запит по пошуку беліберди у базі даних  виконувався. Сайт не зламали, скрізних дірок знайти не могли, SQL-ін’єкції не працювали, проте перевантажували важкими запитами базу даних та сервер багаторазовим декодуванням.   Сайт тишком-нишком довбався  ботами з невеликої кількості IP-адрес (до 50) протягом доби і сервер витримував та друга лінія захисту відпрацьовувала. Але потім у певний момент підключалося до атаки значно більша кількість IP.  І ось тут виникало перевантаження.

Довелося додати кілька правил безпеки в Cloud Flare, а заодно і в htaccess сайту, щоб десятки тисяч трупиків ботів повалилися в логи і сервер знову задихав вільно.

На закінчення

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

Пам’ятайте, фазінг – це гра на витривалість. Хакер сподівається, що ви будете лінивим і залишите десь “хвіст” у вигляді старого бекапу або файлу налаштуваннь.  Ваше завдання – бути чистюлею. Порядок у файлах та налаштований захист у Cloudflare  та htaccess роблять фаззинг проти вашого сайту марною тратою часу. А час – це ресурси для хакеру, і це єдине, що по-справжньому дорого для нього. Тому йому простіше пошукати когось іншого, не такого крутого, як ви.