Náhodné názvy hostitelů

Proč se mi v protokolech HTTP zobrazují názvy hostitelů, které jsem nekonfiguroval?

Pokud používáte částečné nastavení zóny (CNAME), se ve vašich protokolech HTTP požadavků mohou objevit stovky náhodných názvů hostitelů, i když přes proxy směrujete jen několik DNS záznamů. Způsobují to útoky manipulací s hlavičkou Host, nikoli chyba v protokolování Cloudflare.

Co to způsobuje?

Útočníci používají techniku zvanou Host header injection:

Zjistí IP adresy Cloudflare, které obsluhují váš proxovaný hostitelský název (například pomocí vyhledání DNS u známé proxované subdomény).
Odesílají HTTP požadavky přímo na tyto IP adresy s podvrženou Host hlaviček obsahujících náhodné odhady subdomén.
Cloudflare zaznamenává Host hodnotu hlavičky beze změny v ClientRequestHost .
Požadavky se dostanou až ke Cloudflare, protože míří na platné IP adresy Cloudflare, útočník ale ovládá Host obsah hlavičky.

http.host pole obsahuje Host hlavičku z původního požadavku, což znamená, že se ve vašich protokolech mohou objevit hodnoty ovládané útočníkem.

Proč jsou částečné zóny náchylné?

U částečných zón (CNAME):

U vašeho autoritativního poskytovatele DNS směřují na Cloudflare přes CNAME pouze konkrétní hostnames.
Cloudflare nemá kontrolu nad celou zónou, a proto nemůže ověřit, že příchozí Host hlavičky odpovídají nakonfigurovaným záznamům.
Útočníci mohou subdomény enumerovat odesíláním požadavků na známé funkční IP adresy s odhadovanými Host hlaviček.

Jak tento vzor rozpoznám?

Ukazatel	Na co si dát pozor
Rozložení počtu požadavků	Legitimní hostname mají tisíce požadavků. Podezřelé hostname mají vždy přesně dva až pět požadavků.
Vzory názvů hostitelů	Sekvenční čísla (`0-0`, `0-56`, `007`), běžná slova (`admin`, `api`, `test`, `staging`), nebo interní názvy služeb (`airflow`, `consul`, `prometheus`).
Zdrojové IP adresy	Podezřelé požadavky často pocházejí z malé skupiny IP adres (infrastruktura skenerů).
Kódy odpovědi	Mnoho odpovědí 4xx (hostname nenalezen, neshoda SSL).
Korelace DNS	Podezřelé hostname se v protokolech DNS dotazů neobjevují.

Příklad vzoru dat

"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

Jak mohu tyto požadavky blokovat?

Vytvořte Vlastní pravidlo WAF která povoluje pouze požadavky s platným Host hlavičky:

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

Mohu je místo toho odfiltrovat ze svých protokolů?

Ano. Pokud dáváte přednost čistším protokolům bez blokování provozu:

Na úrovni Logpush : filtrujte úlohu tak, aby zahrnovala pouze ověřeně bezpečné názvy hostitelů pomocí Filtry Logpush.
Na úrovni SIEM : při analýze protokolů filtrujte nebo vylučte názvy hostitelů s počtem požadavků pod stanovenou prahovou hodnotou.

Dostávají se tyto požadavky až k mému originu?

Případně, pokud Host hlavička náhodou odpovídá nakonfigurovanému hostname, nebo pokud máte výchozí či catch-all origin server. Zkontrolujte EdgeResponseStatus a OriginResponseStatus a zjistěte, zda došlo ke kontaktování origin serverů.

Jde o bezpečnostní riziko?

Riziko je nízké až střední. Hlavní obavy jsou:

Únik informací, pokud chybové stránky odhalují interní podrobnosti.
Spotřeba prostředků, pokud požadavky dosáhnou vašeho origin serveru.
Šum v protokolech, který ztěžuje identifikaci skutečných útoků.

Proč mají podezřelé názvy hostitelů přesně dva požadavky?

Automatizované skenery obvykle odešlou na každý odhad subdomény jeden až dva požadavky: jeden úvodní pokus a případně jedno opakování. Toto rovnoměrné rozložení je spolehlivým ukazatelem skenovací aktivity.

Jak ověřím, že moje řešení funguje?

Po implementaci pravidla WAF:

Zkontrolujte Firewall Events pro blokované požadavky odpovídající vašemu pravidlu.
Porovnejte objem protokolů před změnou a po ní. Podezřelé názvy hostitelů by měly zmizet.
Ověřte, že legitimní provoz není ovlivněn, a to porovnáním počtu požadavků u skutečných hostname.