域名前置技术101
域名前置技术已存在多年，笔者虽早知其概念，但直至近期与Chris Truncer合作进行红队测试时才深入探究其实现细节。幸运的是，Chris是一位优秀的导师，而该技术一旦拆解便显得十分简单。
网络请求基础原理
在深入域名前置前，需先理解网页获取的基本流程：
- 用户在浏览器输入含主机名的URL
- 操作系统对主机名执行DNS解析
- 根据解析获得的IP地址建立TCP连接
建立网络连接后，应用层启动并发送HTTP请求。HTTP/1.0时代，单IP仅能托管一个网站，因为服务器无法获知请求所用的主机名。HTTP/1.1引入"Host"头概念，使服务器能基于提供的主机名选择多个虚拟主机（即"命名虚拟主机"）。服务器会检查已知虚拟主机列表并选择对应站点，若无匹配则返回默认站点。
基础HTTP/1.1请求格式如下：
|
|
通常浏览器请求中URL主机名与Host头一致，但二者并无强制关联。通过curl可演示此特性：以下请求会连接bing.com但通过Host头请求google.com。由于Bing未配置google.com虚拟主机，返回错误信息。
|
|
尝试通过英国Google域名访问澳大利亚Google站点：
|
|
此请求成功的原因是英国Google服务器知晓所有虚拟主机，能正确路由请求并返回对应内容。
域名前置技术实现
当网站部署于内容分发网络（CDN）（如Amazon Cloudfront、Cloudflare、Microsoft Azure CDN或Google Cloud CDN）时，需设置域名的CNAME记录指向CDN服务器，并在CDNweb服务器上配置类似命名虚拟主机的机制以响应请求。配置时会指定"源站"服务器，CDN据此获取实际内容。
如前所示，网络连接使用的主机名无需与请求站点一致，因此可使用CDN托管的某个主机名建立连接，再通过Host头指定另一个站点。
证书处理机制
证书是否因主机名与Host头不匹配而产生警告或信息泄露？答案是否定的。回顾网络连接建立过程：首先建立TCP连接，随后进行TLS协商——该过程完全基于发起连接所用的主机名。Host头属于应用层流量，在底层连接建立完毕后才发挥作用。通过HTTPS重复Google/Bing示例并获取连接详情可验证此机制：
|
|
关键输出显示TLS连接使用Bing证书进行协商，无任何警告（证书有效），且直至HTTP请求发送Host头前均未出现Google相关信息。
实际应用场景
在与Chris的合作中，我们使用前置技术使基于HTTPS的命令控制（C2）通道突破企业网络过滤（其过滤策略基于请求发起主机名）。由于未进行SSL剥离（重要前提），过滤系统无法查看HTTP流量且无法基于Host头决策。我们选择托管于Cloudfront且信誉良好的公司域名，预期其能通过过滤。随后在Cloudfront上配置C2站点，将其源站指向真实服务器。定制信标软件使用"良性"主机名建立网络连接，在Host头中填入"恶意"主机名。对企业过滤器而言，流量指向可信站点，但CDN会识别对C2站点的请求并将所有流量路由至我们的服务器。
技术扩展应用
除隐藏C2流量外，该技术还可用于绕过审查过滤等场景。规避审查的原理与此一致：目标站点通过"可信"站点进行前置，通过定制浏览器插件或本地网络代理替换Host头为正确值。
防御措施局限性
若您的域名通过CDN提供服务，可能会考虑如何防止信誉被滥用。据目前认知，并无有效方法。此"漏洞"源于HTTP工作原理——网络连接与应用流量的分离。一旦将站点托管于共享服务器，建立网络连接后所有其他站点均可被访问。甚至无法查看相关日志，因为CDN识别Host头后所有流量均被路由至"恶意"站点，日志仅存于其账户中。唯一可监控的是DNS日志，尝试将请求与站点流量匹配——若发现大量请求但流量极少，可能存在异常。但由于缓存效应及日志匹配的工作量，该方法实际难以奏效。
如需实践Cloudfront域名前置配置，可参阅配套文章《使用Cloudfront进行域名前置——实战示例》。
相关文章：
- 使用CloudFront进行域名前置
- 使用Cloudflare进行域名前置
- 使用HTTP管道化隐藏请求
本文基于实际技术测试撰写，所有技术细节均经过实践验证。