Menu
Вы когда-нибудь заглядывали в логи своего сервера и видели там сотни странных строк, где вместо обычного "GET" красуется "HEAD"? Если нет - обязательно загляните, и вы, вероятно, обнаружите целый зоопарк посетителей, которые не просят полную страницу, а только её заголовки. Я сам первое время думал: "Подумаешь, какая-то мелочь, не тратить же на это время". Пока однажды не увидел, как один и тот же IP за пять минут отправил двадцать HEAD-запросов к /wp-admin/setup-config.php. Тогда я понял: кто-то не просто любопытствует - он ищет уязвимости.
В этой статье я расскажу, что такое HEAD-запрос, зачем он нужен нормальным людям, а зачем - злоумышленникам. Вы научитесь читать логи, отличать плохие HEAD-запросы от хороших, а главное - настраивать защиту так, чтобы не мешать легитимным ботам (например, поисковым паукам) и одновременно отсекать незваных гостей.
HEAD - это один из стандартных методов HTTP, определённый в RFC 2616 и его преемниках. Если GET запрашивает всю страницу (и тело, и заголовки), то HEAD просит сервер вернуть только заголовки ответа, без тела. Представьте, что вы хотите узнать, изменился ли документ, не скачивая его целиком. Например, браузер может отправить HEAD, чтобы проверить Last‑Modified или Content‑Length, прежде чем качать большой файл. Или поисковый робот - чтобы узнать, не вернёт ли сервер ошибку 404, не нагружая сеть.
Технически HEAD должен вести себя точно так же, как GET, но без передачи тела. Сервер должен обработать запрос и вернуть те же заголовки, что и при GET, включая Content-Type, Content-Length, ETag, Last-Modified и другие. Однако само тело (HTML, JSON, картинка) не отправляется.
В логах (access.log) HEAD-запросы выглядят примерно так:
|
1 |
192.168.1.100 - - [30/May/2026:14:23:01 +0300] "HEAD / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" |
Обратите внимание на последний параметр - "0". Это размер ответа, и он действительно нулевой, потому что тело не передаётся. В отличие от GET, где там стояло бы, скажем, 15234 байта.
Прежде чем паниковать и блокировать всё подряд, научимся анализировать логи.
Не все HEAD-запросы - зло. Есть вполне легитимные сценарии:
А что же тогда должно насторожить? Давайте обратим внимание на несколько признаков:
Вы спросите: ну и что с того, что кто-то постучался в /wp-login.php через HEAD? Информации-то всего ничего. Однако злоумышленник может извлечь много полезного:
1. Определение версии CMS и плагинов. По заголовкам ответа (Server, X-Powered-By, X-Generator) можно распознать версию Apache, PHP, WordPress, Joomla. Например, заголовок "X-Powered-By: PHP/7.4.33" сразу говорит, что сайт на PHP 7.4, а значит, возможна эксплуатация известных именно под эту версию CMS уязвимостей. А заголовок "Set-Cookie: wp-settings-time-1" выдаёт WordPress.
2. Проверка существования файлов без триггера в логах ошибок. HEAD на /backup.sql, если файл существует, вернёт 200 OK, если нет - 404. При этом размер ответа 0, и в error.log не попадёт запись о "File not found", что позволяет сканеру действовать тише.
3. Обнаружение защитных механизмов. Если на HEAD-запрос приходит 403 Forbidden, а на GET - 200 OK, значит, фильтрация настроена небрежно. Это может указывать на уязвимость в WAF или конфигурации веб-сервера.
4. Проверка наличия редиректов. Заголовок Location при HEAD-запросе позволяет узнать, куда редиректит сервер, не следуя за редиректом. Это полезно для разведки скрытых страниц и анализа цепочек перенаправлений.
5. Сбор информации о кэшировании и SSL. Заголовки Cache-Control, Expires, ETag, а также информация о сертификате (при HTTPS) могут подсказать, как настроен кэш и есть ли защита от подмены.
Приведу пару примеров, которые я видел в логах своих клиентов.
Сканер уязвимостей WordPress. Вот запись:
|
1 |
45.33.22.11 - - [20/May/2026:03:15:02 +0300] "HEAD /wp-content/plugins/akismet/readme.txt HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36" |
User-Agent подделан под реальный браузер, но IP-адрес принадлежит дата-центру (можно проверить whois), и таких запросов было около 200 на разные пути: /wp-content/plugins/woocommerce/readme.txt, /wp-includes/wlwmanifest.xml, /xmlrpc.php. Злоумышленник искал readme-файлы популярных плагинов, чтобы узнать их версии и подобрать эксплойт.
Тестирование прокси и валидации заголовков.
|
1 |
185.130.5.253 - - [21/May/2026:10:22:11 +0300] "HEAD / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)" |
Запросов было много, но каждый раз разный User-Agent, причём с разными версиями IE. Это типичный приём для обхода защиты по User-Agent. Такая же активность наблюдалась и на другие популярные CMS. В итоге оказалось, что это ботнет сканировал тысячи сайтов на наличие уязвимости в плагине Contact Form 7.
Что мы делаем при обнаружении таких паттернов? Во-первых, собираем статистику частоты запросов. Во-вторых, проверяем IP через базы репутации (AbuseIPDB, Spamhaus). В-третьих, добавляем временное правило в iptables или .htaccess.
Теперь перейдём к главному - как оградить свой сервер от назойливых сканеров, не отрезав при этом добросовестные сервисы.
1. Рейт-лимитинг на уровне веб-сервера. Самый эффективный способ. В Nginx можно ограничить частоту HEAD-запросов с одного IP до разумного предела, например, 5 в минуту.
|
1 2 3 4 5 6 7 |
limit_req_zone $binary_remote_addr zone=headlimit:10m rate=5r/m; server { location / { limit_req zone=headlimit burst=3 nodelay; # ... } } |
Эти директивы будут действовать на все методы, но можно добавить условие только для HEAD (внутри location). Однако проще сделать общее ограничение на всех методах, так как GET тоже может быть атакой.
2. Блокировка по User-Agent с помощью .htaccess (Apache) или map (Nginx). Создайте список подозрительных User-Agent (python, curl, wget, go-http-client) и отправляйте им 403 Forbidden.
|
1 2 3 4 5 6 7 8 9 10 11 |
# Nginx map $http_user_agent $block_ua { default 0; ~*python 1; ~*curl 1; ~*wget 1; ~*go-http-client 1; } server { if ($block_ua) { return 403; } } |
Недостаток: опытные сканеры подделывают User-Agent под браузеры, но это отсечёт самых примитивных ботов.
3. Ограничение методов только на критических путях. Например, для /wp-login.php, /xmlrpc.php можно разрешить только POST (для логина) и запретить HEAD, GET, DELETE.
|
1 2 3 |
location = /wp-login.php { if ($request_method !~ ^(POST)$) { return 405; } } |
Это не защитит от GET-сканирования, но уменьшит поверхность атаки.
4. Использование модуля fail2ban с кастомными правилами. Анализируйте логи и баньте IP, которые делают много HEAD-запросов к несуществующим файлам или к админским папкам.
Пример jail.local для fail2ban:
|
1 2 3 4 5 6 7 |
[nginx-head-scan] enabled = true logpath = /var/log/nginx/access.log filter = head-scan maxretry = 20 findtime = 300 bantime = 3600 |
Фильтр head-scan.conf:
|
1 2 |
[Definition] failregex = ^ .* "HEAD .* (wp-admin|xmlrpc|backup|config) .*" 200 |
Это будет банить IP, которые делают 20 HEAD-запросов к чувствительным путям за 5 минут.
5. Настройка WAF (Web Application Firewall) на блокировку HEAD-запросов с определёнными паттернами. Если вы пользуетесь Cloudflare, можно написать правило в WAF (он умеет фильтровать по методу и URI). В ModSecurity тоже есть правила для ограничения методов.
Приведу полные рабочие фрагменты.
Nginx: ограничение HEAD на 10 в минуту, исключая Googlebot.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
geo $allow_google { default 1; 66.249.64.0/19 0; 66.249.80.0/20 0; } map $http_user_agent $is_googlebot { default 0; ~*Googlebot 1; } limit_req_zone $binary_remote_addr zone=head_limit:10m rate=10r/m; server { listen 80; if ($request_method = HEAD) { set $head_check 1; if ($is_googlebot) { set $head_check 0; } if ($allow_google = 0) { set $head_check 0; } if ($head_check) { limit_req zone=head_limit burst=5 nodelay; return 429; } } # остальная конфигурация } |
Этот пример: для HEAD-запросов применяем лимит, но пропускаем Googlebot по IP и User-Agent. Если лимит превышен, возвращаем 429 Too Many Requests.
Apache: запрет HEAD для всех, кроме Googlebot и определённых IP.
|
1 2 3 4 5 |
RewriteEngine On RewriteCond %{REQUEST_METHOD} HEAD RewriteCond %{REMOTE_ADDR} !^66\.249\.(6[4-9]|[7-8][0-9]|9[0-5])\. RewriteCond %{HTTP_USER_AGENT} !Googlebot RewriteRule .* - [R=403,L] |
Блокируем HEAD, если IP не из диапазона Googlebot и User-Agent не содержит Googlebot. Может быть, слишком строго, но эффективно.
Я предпочитаю Nginx, потому что он легче и гибче в настройке рейт-лимитов. Но если у вас Apache, используйте mod_evasive или mod_qos.
Ручной просмотр логов быстро надоедает. Настройте автоматическое оповещение. Например, напишите простой Python-скрипт, который раз в час парсит логи, собирает статистику HEAD-запросов по IP и, если IP превысил порог, отправляет команду на добавление в чёрный список.
Примерная логика:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
import re from collections import Counter logfile = "/var/log/nginx/access.log" head_ips = [] with open(logfile) as f: for line in f: if " HEAD " in line: ip = line.split()[0] if not re.search(r"(Googlebot|YandexBot|Pingdom)", line): head_ips.append(ip) counts = Counter(head_ips) for ip, cnt in counts.items(): if cnt > 50: print(f"Block {ip}, {cnt} HEAD requests") # os.system(f"iptables -A INPUT -s {ip} -j DROP") |
Важно: запускать такое с осторожностью, чтобы не заблокировать нормальных пользователей. Всегда оставляйте возможность исключить IP по белому списку.
Также полезно настроить отправку логов в SIEM (например, ELK, Splunk) и создать дашборд с аномалиями. Если вы увидите, что обычная доля HEAD-запросов - 1% от общего трафика, а вдруг стала 30% - это аномалия.
Не стоит полностью отключать HEAD - вы рискуете поломать полезные сервисы. Но ограничить частоту, заблокировать подозрительные IP и настроить мониторинг - обязательные шаги. Проверьте свои логи сегодня. Возможно, прямо сейчас какой-то любопытный скрипт проверяет ваш .git/config или wp-config.php.bak. Не дайте ему получить информацию, которую вы не планировали раскрывать.
И помните: безопасность - это не разовая настройка, а постоянный процесс. Регулярно просматривайте логи, обновляйте правила и списки исключений. И, конечно, не полагайтесь только на защиту от HEAD-запросов - это лишь малая часть общей стратегии.
Cloudflare окончательно заблокирован в РФ ещё летом 2025 года.
Функцию фильтрации ботов Cloudflare взял на себя российский антибот Killbot.
Принцип работы отличается от привычного, отслеживаются не знакомые всем при настройке других антибот решений параметры (входящие IP адреса, AS подсети ботов, User Agent и прочее, всё это легко подделывается), а уникальные для каждого набора браузеров слепки.
По отличию оригинального браузера от модифицированного, тот или иной заход определяется либо как заход реального посетителя, либо как заход бота.
Чтобы не повторяться - расписывал более подробно в статьях:
Попробовать бесплатно. При регистрации в Killbot введите промокод
promo13
и получите месяц тестирования платного тарифа Killbot (фильтрация трафика, 1000 руб) и Ads (отключение показа рекламы поведенческим ботам, 1000 руб) в качестве бонуса. Этого вам хватит на то, чтобы понять, подходит вам данное решение, или нет. На данный момент - в Рунете нет более достойной альтернативы, по соотношению цена-качество. Срок действия промокода ограничен по времени, куда-то записывать его нет смысла. В следующий раз промокод уже будет другой, поэтому использовать его нужно сейчас, когда вы читаете этот текст. Промокод действует только в форме регистрации. Если аккаунт уже создан - создайте новый, на другой почте, и при регистрации в последнем поле введите промокод.
Подпишитесь на Telegram канал / MAX для того, чтобы всегда быть в курсе последних новостей и обновленных настроек для защиты от ботов, а также оперативно получать новые материалы, выходящие на antibot24.ru
Автор статей: Сергей (AntiBot24). Эксперт в области фильтрации поведенческого трафика, настройки антибот систем. Высший рейтинг на Kwork, более 680 отзывов, 100% заказов успешно сдано, 56% повторных заказов. Пишу подробные статьи, инструкции по фильтрации ботов в своем блоге antibot24.ru
Всегда нужно иметь в виду, что те советы, которые вы прочли в статьях - это лишь часть настроек, которые я делаю при профессиональной экспертной настройке фильтрации поведенческих ботов. Все остальное - это непубличные профессиональные секреты. Любая информация, становящаяся общедоступной - достаточно быстро устаревает и перестает быть эффективной.
Если вы столкнулись с повышенной роботностью в Яндекс метрике, увеличением числа прямых заходов, увеличением количества отказов - вы всегда можете заказать у меня настройку Killbot.