Случайные имена хостов

Почему в моих журналах HTTP отображаются имена хостов, которые я не настраивал?

Если вы используете частичная настройка зоны (CNAME), в журналах HTTP-запросов может появиться множество случайных имён хостов, даже если через прокси проходит всего несколько DNS-записей. Это вызвано атаками с подменой заголовка Host, а не ошибкой в журналировании Cloudflare.

Чем это вызвано?

Злоумышленники используют технику под названием Host header injection:

Они определяют IP-адреса Cloudflare, обслуживающие ваш проксируемый домен (например, с помощью DNS-запроса к известному проксируемому поддомену).
Затем они отправляют HTTP-запросы напрямую на эти IP-адреса с подделанным Host заголовков со случайно подобранными поддоменами.
Cloudflare записывает Host значение заголовка без изменений в ClientRequestHost поле.
Запросы достигают Cloudflare, поскольку нацелены на действительные IP-адреса Cloudflare, однако атакующий контролирует Host содержимое заголовка.

http.host поле содержит Host заголовок из исходного запроса, а значит, в ваших журналах могут появляться значения, контролируемые злоумышленником.

Почему частичные зоны подвержены этому?

Для частичных зон (CNAME):

У вашего авторитетного DNS-провайдера через CNAME на Cloudflare указывают только определённые имена хостов.
Cloudflare не управляет зоной полностью, поэтому не может проверить, что входящие Host заголовки совпадают с настроенными записями.
Злоумышленники могут перебирать поддомены, отправляя запросы на заведомо рабочие IP-адреса с предполагаемыми Host заголовки.

Как распознать этот шаблон?

Индикатор	На что обратить внимание
Распределение количества запросов	Легитимные имена хостов получают тысячи запросов. Подозрительные имена хостов получают ровно от двух до пяти запросов на каждое имя.
Шаблоны имён хостов	Порядковые номера (`0-0`, `0-56`, `007`), распространённые слова (`admin`, `api`, `test`, `staging`), либо названия внутренних служб (`airflow`, `consul`, `prometheus`).
IP-адреса источника	Подозрительные запросы часто поступают с небольшого набора IP-адресов (инфраструктура сканеров).
Коды ответа	Множество ответов 4xx (hostname не найден, несоответствие SSL).
Корреляция DNS	Подозрительные имена хостов не отображаются в журналах DNS-запросов.

Пример шаблона данных

"ClientRequestHost","_count"
"legitimate-proxied.example.com","12498"    # Real traffic
"another-proxied.example.com","6082"        # Real traffic
"0-0.example.com","2"                       # Scanner
"admin.example.com","2"                     # Scanner
"api-staging.example.com","2"               # Scanner
"1234567890.example.com","2"                # Scanner

Как заблокировать эти запросы?

Создайте Пользовательское правило WAF который разрешает только запросы с действительным Host заголовки:

Expression:
(http.host ne "proxied-hostname-1.example.com" and
 http.host ne "proxied-hostname-2.example.com" and
 http.host ne "proxied-hostname-3.example.com")

Action: Block

Можно ли вместо этого отфильтровать их в своих журналах?

Да. Если вы предпочитаете более чистые журналы без блокировки трафика:

На уровне Logpush : отфильтруйте задание так, чтобы оно включало только заведомо надёжные имена хостов, используя Фильтры Logpush.
На уровне SIEM : отфильтруйте или исключите имена хостов с количеством запросов ниже порогового значения при анализе логов.

Доходят ли эти запросы до моего origin-сервера?

Возможно, если Host заголовок случайно совпадает с настроенным именем хоста, либо у вас настроен origin-сервер по умолчанию или catch-all origin-сервер. Проверьте EdgeResponseStatus и OriginResponseStatus чтобы проверить, был ли выполнен запрос к origin.

Представляет ли это риск для безопасности?

Риск низкий или умеренный. Основные опасения:

Утечка информации, если страницы ошибок раскрывают внутренние подробности.
Потребление ресурсов, если запросы достигают вашего origin-сервера.
Шум в журналах, из-за которого сложнее выявлять реальные атаки.

Почему у подозрительных имён хостов ровно два запроса?

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

Как убедиться, что моё решение работает?

После внедрения правила WAF:

Проверьте Firewall Events для заблокированных запросов, соответствующих вашему правилу.
Сравните объём журналов до и после изменения: подозрительные имена хостов должны исчезнуть.
Убедитесь, что легитимный трафик не пострадал, сравнив количество запросов для реальных hostname.