Защита сайта от фаззинга: Вас ломают, пока вы спите

Представьте, что к вашей входной двери подошел злодей. Бесшумно и  неспеша или со скоростью пулемета начал вставлять в замок тысячи разных ключей, отмычек, кусков проволоки, спички, какой-то мусор, заливает в замочную скважину растворы разных кислот и солей. Он не злится, он не устает. Он — робот. Он просто ищет то, что заставит замок сдаться, будет это хитрая отмычка или серная кислота.

В вебе это называется фаззинг(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: Fuzzing через формы (Ввод аномальных данных)

Значимость лога: Ваша «камера наблюдения»

Нужно заметить, что на первой линии защиты — линии сервера большинство фаззинг-атак отсекается и в 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 будет выкидывать ботов Гугл, отвечающих за индексацию и тогда вы будете гадать, почему же никто не ходит на сайт.

Если сайт НЕ в 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>

Кейс 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 и собственные внутренние плагины безопасности.  Плохо было то, что форма возвращала 200OK на такие запросы. Сайт не взломали, сквозных дырок найти не могли, SQL-инъекции не работали, так как превращались кодом сайта в обычный текст, однако перегружали  тяжелыми запросами базу данных и сервер многократным декодированием.  Сайт втихую долбился ботами с небольшого количества IP-адресов (до 50) в течении суток и сервер выдерживал и вторая линия защиты отрабатывала. Но потом в определенный момент подключалось к атаке значительно бОльшее количество IP.  И вот тут возникал перегруз.

Пришлось добавить несколько правил безопасности в Cloud Flare, а заодно  и в htaccess сайта, чтобы десятки тысяч трупиков ботов повалились в логи и сервер снова задышал свободно.

Заключение

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

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