Защита сайта от ботов: honeypot-ловушка, блокировка по IP и безопасная фильтрация

При этом универсальной волшебной кнопки не существует. Блокировка только по User-Agent помогает лишь против части шумных и примитивных ботов. Полная защита требует комбинации нескольких подходов: серверных ограничений, ловушек, логирования, rate limiting, проверки IP-репутации и анализа поведения.

Какие проблемы были у старых антибот-скриптов

Раньше часто использовали схему, где бот переходил по скрытой ссылке-ловушке, после чего PHP-скрипт сразу записывал IP в лог и дописывал строку Deny from ... в .htaccess. Формально это работало, но для современного проекта у такого подхода есть несколько слабых мест:

• динамическая запись в .htaccess из PHP — хрупкий и плохо масштабируемый путь;
• старый синтаксис Order / Allow / Deny относится к legacy-подходу Apache 2.2;
• скрытая однопиксельная ссылка ловит только часть примитивных ботов;
• robots.txt не является механизмом безопасности и не должен использоваться как защита чувствительных URL;
• слепое доверие к X-Forwarded-For может дать ложный IP-адрес;
• блокировка только по User-Agent легко обходится подменой заголовка.

Что лучше использовать сегодня

В современном варианте защиты от ботов имеет смысл разделить уровни:

1. Базовая фильтрация — серверные ограничения по IP, URL, методам, подозрительным User-Agent.
2. Honeypot-ловушка — скрытая приманка для примитивных парсеров и спам-ботов.
3. Локальный лог / SQLite-кэш — чтобы хранить подозрительные IP, время, URI, user-agent и историю срабатываний.
4. Реакция по уровню риска — логирование, временный бан, капча, challenge, жёсткий deny.
5. Инфраструктурный уровень — WAF, Cloudflare, fail2ban, rate limiting, CDN-защита.

Именно такая модель позволяет не смешивать в одном месте все задачи сразу и не превращать защиту сайта в набор опасных и плохо контролируемых хакапов.

Блокировка простых ботов на уровне Nginx

Если нужно быстро отсечь заведомо шумных и примитивных роботов по заголовку User-Agent, это удобнее делать на уровне веб-сервера.

if ($http_user_agent ~* "(HTTrack|WebCopier|Offline Explorer|masscan|sqlmap|nikto)") {
    return 403;
}

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

Такой подход полезен, но важно понимать его ограниченность: если бот меняет User-Agent, правило уже не даёт гарантированной защиты.

Блокировка по User-Agent в Apache

Для Apache вместо гигантского списка из сотен строк лучше использовать аккуратный, короткий и осознанный denylist по действительно вредным сигнатурам.

<IfModule mod_setenvif.c>
    SetEnvIfNoCase User-Agent "HTTrack" bad_bot
    SetEnvIfNoCase User-Agent "WebCopier" bad_bot
    SetEnvIfNoCase User-Agent "sqlmap" bad_bot
    SetEnvIfNoCase User-Agent "nikto" bad_bot
    SetEnvIfNoCase User-Agent "masscan" bad_bot
</IfModule>

<IfModule mod_authz_core.c>
    <RequireAll>
        Require all granted
        Require not env bad_bot
    </RequireAll>
</IfModule>

Такой вариант лучше старого синтаксиса Order Allow,Deny / Deny from env=bot, потому что он ближе к современной модели Apache 2.4 и проще в сопровождении.

Защищаем .htaccess и чувствительные файлы

Даже если вы используете серверные правила блокировки, сам файл .htaccess и другие чувствительные служебные файлы должны быть закрыты от прямого доступа.

<FilesMatch "^(\.htaccess|\.htpasswd|\.env|.*\.log|.*\.bak)$">
    Require all denied
</FilesMatch>

Для прав доступа на файл обычно достаточно минимально необходимых значений, без лишнего расширения прав на запись.

Почему не стоит дописывать .htaccess из PHP на лету

Когда PHP-скрипт на каждом срабатывании ловушки дописывает строку Deny from IP в .htaccess, это выглядит удобно, но на практике создаёт несколько проблем:

• файл конфигурации бесконтрольно разрастается;
• возникают риски гонок записи и конфликтов при одновременных запросах;
• откатить ошибочный бан становится сложнее;
• поддержка и аудит такого решения быстро превращаются в проблему;
• на больших объёмах трафика это плохо масштабируется.

Гораздо надёжнее хранить срабатывания в отдельном логе или SQLite-базе, а уже потом принимать решение: временно блокировать, жёстко банить, отправлять IP в fail2ban, отдавать challenge или просто накапливать статистику.

Ловушка для ботов: как её лучше делать сегодня

Идея honeypot-ловушки остаётся рабочей: бот должен попасть в специально подготовленную точку, куда обычный пользователь в нормальном сценарии не попадёт. Но вместо старой однопиксельной ссылки в форме лучше использовать более понятный и контролируемый вариант.

Самые частые сценарии:

• скрытое поле в форме, которое не должен заполнять человек;
• скрытый bait-URL, к которому нет нормальной пользовательской навигации;
• специальная ловушка в JS / DOM для примитивных парсеров;
• URL-приманка для сканеров, которые перебирают предсказуемые пути.

Пример скрытого honeypot-поля в форме

<form method="post" action="/contact/send">
    <input type="text" name="name" required>
    <input type="email" name="email" required>
    <textarea name="message" required></textarea>

    <div class="hp-field" aria-hidden="true">
        <label for="company_website">Не заполняйте это поле</label>
        <input type="text" name="company_website" id="company_website" tabindex="-1" autocomplete="off">
    </div>

    <button type="submit">Отправить</button>
</form>

CSS для такого поля:

.hp-field {
    position: absolute !important;
    left: -9999px !important;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

Если поле заполнено, это сильный сигнал, что форму отправляет не человек, а бот.

Пример проверки в PHP

<?php
declare(strict_types=1);

$honeypot = trim((string)($_POST['company_website'] ?? ''));

if ($honeypot !== '') {
    http_response_code(403);
    exit('Forbidden');
}

Для спам-форм и простых ботов такой сценарий часто работает лучше, чем старый вариант с однопиксельной ссылкой внутри формы.

Ловушка через bait-URL

Если вы хотите именно отдельный URL-приманку, лучше сделать его не как скрипт, который сразу правит .htaccess, а как контролируемую точку логирования.

Например, создаём маршрут /bot-trap/collect, который:

• фиксирует IP, URI, referer, user-agent, время и тип срабатывания;
• увеличивает счётчик подозрительности IP;
• при достижении порога меняет статус на временный бан;
• не трогает серверные конфиги напрямую.

Пример PHP-обработчика ловушки

<?php
declare(strict_types=1);

$pdo = new PDO('sqlite:' . __DIR__ . '/var/security/bot_trap.sqlite');
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

$pdo->exec("
CREATE TABLE IF NOT EXISTS bot_trap_hits (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    ip TEXT NOT NULL,
    request_uri TEXT NOT NULL,
    referer TEXT,
    user_agent TEXT,
    created_at TEXT NOT NULL
);

CREATE TABLE IF NOT EXISTS bot_ip_flags (
    ip TEXT PRIMARY KEY,
    score INTEGER NOT NULL DEFAULT 0,
    status TEXT NOT NULL DEFAULT 'suspicious',
    last_seen_at TEXT NOT NULL
);
");

$ip = $_SERVER['REMOTE_ADDR'] ?? '';
$requestUri = $_SERVER['REQUEST_URI'] ?? '';
$referer = $_SERVER['HTTP_REFERER'] ?? '';
$userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
$now = gmdate('Y-m-d H:i:s');

if (!filter_var($ip, FILTER_VALIDATE_IP)) {
    http_response_code(204);
    exit;
}

$stmt = $pdo->prepare("
    INSERT INTO bot_trap_hits (ip, request_uri, referer, user_agent, created_at)
    VALUES (:ip, :request_uri, :referer, :user_agent, :created_at)
");
$stmt->execute([
    ':ip' => $ip,
    ':request_uri' => $requestUri,
    ':referer' => $referer,
    ':user_agent' => $userAgent,
    ':created_at' => $now,
]);

$stmt = $pdo->prepare("
    INSERT INTO bot_ip_flags (ip, score, status, last_seen_at)
    VALUES (:ip, 1, 'suspicious', :last_seen_at)
    ON CONFLICT(ip) DO UPDATE SET
        score = bot_ip_flags.score + 1,
        status = CASE
            WHEN bot_ip_flags.score + 1 >= 3 THEN 'blocked'
            ELSE 'suspicious'
        END,
        last_seen_at = excluded.last_seen_at
");
$stmt->execute([
    ':ip' => $ip,
    ':last_seen_at' => $now,
]);

http_response_code(204);
exit;

В этом варианте ловушка только собирает факты и поднимает уровень риска. А окончательное решение о блокировке можно принимать уже отдельно.

Как жёстко блокировать IP безопаснее

Если IP уже признан действительно вредным, надёжнее не править .htaccess по строкам, а использовать:

• локальную deny-базу и раннюю проверку в приложении;
• fail2ban по логам;
• правила в Nginx / Apache / firewall;
• WAF или защиту уровня CDN.

Для Apache 2.4 жёсткое ограничение по IP выглядит так:

<IfModule mod_authz_core.c>
    <RequireAll>
        Require all granted
        Require not ip 203.0.113.10
        Require not ip 198.51.100.0/24
    </RequireAll>
</IfModule>

Такой подход намного чище и безопаснее, чем бесконечно дописывать старые строки вида Deny from ....

Почему robots.txt здесь не защита

Частая ошибка в антибот-материалах — закрывать bait-URL через robots.txt и воспринимать это как защиту от попадания посторонних в ловушку. На практике robots.txt нужен прежде всего для управления обходом поисковыми роботами, а не для защиты чувствительных URL.

Для honeypot-URL такой файл можно использовать как дополнительную подсказку корректным поисковым роботам, но рассчитывать на него как на механизм безопасности нельзя.

Почему нельзя слепо доверять X-Forwarded-For

Если ваш проект стоит за прокси, балансировщиком или CDN, может возникнуть соблазн брать «настоящий» IP из X-Forwarded-For. Но делать это можно только если запрос пришёл от доверенного прокси. В противном случае клиент может просто подделать этот заголовок.

Поэтому в простом PHP-антиботе безопаснее использовать REMOTE_ADDR, а разбор X-Forwarded-For включать только при корректной схеме trusted proxy.

Какая стратегия реально работает лучше

Вместо старой логики «поймали → сразу дописали IP в .htaccess» лучше использовать поэтапную модель:

1. Поймали подозрительное срабатывание в honeypot.
2. Записали событие в лог или SQLite.
3. Подняли счётчик риска для IP.
4. При повторных срабатываниях перевели IP в режим временного ограничения.
5. При явной вредоносной активности передали IP в denylist / fail2ban / WAF.

Такой подход даёт намного меньше ложных блокировок и лучше подходит для реальной эксплуатации сайта.

Типовые ошибки при защите сайта от ботов

• полагаться только на User-Agent;
• доверять X-Forwarded-For без trusted proxy;
• использовать robots.txt как механизм безопасности;
• динамически переписывать .htaccess из PHP;
• копировать огромные blacklist-списки без анализа реальных логов;
• не разделять мягкую и жёсткую реакцию на срабатывание ловушки;
• не вести историю и счётчики повторных подозрительных обращений;
• не тестировать исключения для нормальных роботов и внутренних сервисов.

Когда нужна уже не ловушка, а полноценная защита

Honeypot и простая фильтрация — это хороший лёгкий уровень защиты, но он не решает всё. Если на проект идёт серьёзный шумный трафик, сканирование уязвимостей, брутфорс форм входа или признаки DDoS, нужно подниматься на уровень выше:

• rate limiting;
• WAF;
• Cloudflare или аналогичная защита на edge-уровне;
• fail2ban по логам;
• капчи и challenge-механизмы;
• изоляция чувствительных маршрутов и административных зон.

Когда я использую AntiPF

Если простого honeypot, нескольких WAF-правил и ручных блокировок уже недостаточно, на своих проектах я использую AntiPF — собственную систему фильтрации подозрительного трафика. Её задача — не «заблокировать как можно больше», а собирать сигналы, вести логирование, учитывать риск и аккуратно отличать проверенных поисковых краулеров и других полезных роботов от подозрительных запросов и подделок.

AntiPF не заменяет Cloudflare, серверный WAF или rate limiting: эти уровни дополняют друг друга. Для коммерческого проекта, где проблема уже выходит за рамки одной формы или одного IP, можно начать с диагностики и настройки защиты сайта от DDoS и вредоносного трафика.

Вывод

Защита сайта от ботов действительно может начинаться с простых вещей: блокировки по вредным User-Agent, honeypot-ловушки и логирования подозрительных IP. Но современный антибот должен быть не только рабочим, но и безопасным в сопровождении.

Поэтому вместо старой схемы с однопиксельной ссылкой и автоматическим дописыванием Deny from ... в .htaccess лучше строить более аккуратную модель: ловушка → лог → счётчик риска → временная реакция → жёсткий ban только при достаточных основаниях.

FAQ

Можно ли блокировать ботов только по User-Agent?

Частично да, но это защитит только от части примитивных роботов. Подмена User-Agent делает такой метод ограниченным по эффективности.

Нужна ли сегодня скрытая ловушка для ботов?

Да, как дополнительный сигнал она всё ещё полезна. Но её не стоит считать полноценной защитой сама по себе.

Можно ли дописывать .htaccess из PHP?

Технически можно, но для современного проекта это плохая практика. Гораздо надёжнее хранить deny-логику отдельно и применять серверные блокировки осознанно и централизованно.

Достаточно ли robots.txt, чтобы защитить URL ловушки?

Нет. robots.txt полезен для управления обходом поисковыми роботами, но не является механизмом безопасности.

Что лучше использовать для хранения подозрительных IP?

Для лёгкого проекта хорошо подходит SQLite или отдельный лог. Это удобнее, чем сразу править серверный конфиг при каждом срабатывании.

Связаться в Telegram

Следующие страницы вас также могут заинтересовать:

• Робототехника
• Аутсорсинг: что это такое и как он может помочь вашему бизнесу?
• SEO-продвижение образовательного сайта: 7 лет — от старого HTML до AI Search
• Промышленные роботы: что это, виды, устройство и применение
• Паллетирование: что это такое, технологии, оборудование и роботизация

Обновлено: 05.10.2026