如果使用部分(CNAME)zone 设置,即使只代理了少量 DNS 记录,HTTP 请求日志中仍可能出现数百个随机主机名。这是由 Host 标头操纵攻击引起的,并非 Cloudflare 日志记录的缺陷。
攻击者使用一种称为 Host 标头注入的技术:
- 他们发现为你的已代理主机名提供服务的 Cloudflare IP 地址(例如,通过对已知已代理子域进行 DNS 查询)。
- 他们直接向这些 IP 发送 HTTP 请求,并伪造包含随机子域猜测的
Host标头。 - Cloudflare 将
Host标头值原样记录在ClientRequestHost字段中。 - 这些请求会到达 Cloudflare,因为它们针对的是有效的 Cloudflare IP——但攻击者控制着
Host标头内容。
http.host 字段 包含原始请求中的 Host 标头,因此攻击者控制的值会出现在你的日志中。
对于部分(CNAME)zone:
- 只有特定主机名通过你的权威 DNS 提供商以 CNAME 指向 Cloudflare。
- Cloudflare 不控制整个 zone,因此无法验证传入的
Host标头是否与已配置的记录匹配。 - 攻击者可以通过向已知有效的 IP 发送带有猜测
Host标头的请求来枚举子域。
| 指标 | 需要关注的内容 |
|---|---|
| 请求计数分布 | 合法主机名有数千个请求。可疑主机名各自通常只有两到五个请求。 |
| 主机名模式 | 连续数字(0-0、0-56、007)、常见词(admin、api、test、staging),或内部服务名称(airflow、consul、prometheus)。 |
| 源 IP | 可疑请求通常来自一小部分 IP(扫描基础设施)。 |
| 响应代码 | 大量 4xx 响应(主机名未找到、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 层面 — 在日志分析期间过滤或排除请求计数低于阈值的主机名。
有可能——如果 Host 标头恰好匹配已配置的主机名,或者你有默认或 catch-all 源站。检查 EdgeResponseStatus 和 OriginResponseStatus,以查看是否联系了源站。
风险为低到中等。主要问题包括:
- 若错误页面泄露内部详情,则存在信息泄露。
- 若请求到达源站,则存在资源消耗。
- 日志噪音会让真实攻击更难识别。
自动扫描器通常对每个子域猜测发送一到两个请求——一次初始探测,可能还有一次重试。这种均匀分布是扫描活动的可靠指标。
实施 WAF 规则后:
- 在 Firewall Events(防火墙事件) 中检查与你的规则匹配的被阻止请求。
- 比较实施前后的日志量——可疑主机名应消失。
- 通过检查真实主机名的请求计数,确认合法流量未受影响。