最近发现了使用二级域名作为 Linux Hostname 会有坑,甚至还会造成潜在的信息安全问题。因此写了一篇博客,总结如下,全文可以在 https://josephcz.xyz/technology/linux/never-use-2ld-as-hostname/ 阅读
倘若我们将服务器的 Hostname 切换为二级域名,例如 example[.]com
时,会发生什么呢?在这里我们假设一个没有被任何人注册的域名,例如 some-not-registered-domain[.]com
;并假设 com[.]com
这一域名被恶意人士注册。
接下来,我们使用 ping
命令,加上需要解析的域名,看看实际访问的域名时哪一个:
是的,在使用二级域名作为 Hostname 的情况下,当 ping 一个尚未注册的域名 some-not-registered-domain[.]com
时,由于 Hostname 和 Search Domain 的配置,会自动 fallback 到 some-not-registered-domain[.]com[.]com
上!遗憾的是,不管是否使用 Search Domain ,这个问题都存在——而将 Hostanme 设置为 FQDN 让这个问题更加隐蔽了。
这个问题不仅影响了 ping 、curl ,也影响了几乎所有使用 glibc 的程序:OpenSSL 、MySQL 、Nginx 、Apache……等等。如果它们的某个功能需要解析域名,则都会有同样的问题。
未被注册的域名值得警惕,但是这一问题如果发生在你自己的域名上呢?
回到我遇到的问题上来。我刚刚设置了 api-v2023[.]josephcz[.]xyz
这一域名的解析。而 DNS 解析的生效需要时间,在递归 DNS 未获取到生效的记录的情况下,会返回一个空记录。而空记录和 NXDOMAIN 错误一样,会触发 Search Domain 的 fallback 机制。因此,服务器上对 api-v2023[.]josephcz[.]xyz
全部被发送到了 api-v2023[.]josephcz[.]xyz[.]xyz
。
使用 tcpdump -i ens3 -nt -s 500 port domain
命令可以清楚地看到这一过程:
IP 10.0.0.12.57943 > 1.1.1.1.53: 27244+ A? api-v2023[.]josephcz[.]xyz. (35)
IP 10.0.0.12.57943 > 1.1.1.1.53: 19043+ AAAA? api-v2023[.]josephcz[.]xyz. (35)
IP 1.1.1.1.53 > 10.0.0.12.57943: 19043 0/1/0 (106)
IP 1.1.1.1.53 > 10.0.0.12.57943: 27244 0/1/0 (106)
IP 10.0.0.12.46092 > 1.1.1.1.53: 51629+ A? api-v2023[.]josephcz[.]xyz[.]xyz. (39)
IP 10.0.0.12.46092 > 1.1.1.1.53: 61104+ AAAA? api-v2023[.]josephcz[.]xyz[.]xyz. (39)
IP 1.1.1.1.53 > 10.0.0.12.46092: 51629 3/0/0 CNAME xyz[.]xyz., A 52.9.36.254, A 54.241.183.58 (85)
好在 XYZ 域名的注册局保留了 XYZ[.]XYZ
。但是如果换成解析其他域名,例如 some-api-host[.]aws
或者 pki[.]goog
,而相关域名的注册局又忘记保留了 aws
、goog
之类的域名呢?
在设置 Linux 的 Hostname 时,永远不要使用一个二级域名——无论是将 Hostname 设置为 FQDN 还是配置 Search Domain 。永远使用一个三级或以上的、受你自己控制的域名作为 Hostname 。
此外,启用强制性的 TLS 并正确部署证书信任也可以在一定程度上缓解这一问题——由于对方无法获得正确的 TLS 证书,即使解析被 fallback 到恶意攻击者的域名上,也难以窃取你的机密信息。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.