Apt - 对 d16r8ew072anqo.cloudfront.net:80 的奇怪请求

Question

星期六（5 月 18 日），我启动了一台虚拟机（运行 Ubuntu 18.04 服务器）。

令我惊讶的是，VM 几乎立即尝试连接到d16r8ew072anqo.cloudfront.net:80，这是我以前从未见过的——这是一个非常“原始”的 Ubuntu 安装，没有自定义apt存储库，只安装了几个包。它以前从未连接到任何可疑的东西——主要是连接到 Ubuntu 和 Snap 域。（我使用 Little Snitch 来监控网络流量，因此我可以实时查看连接并可以拒绝它们。）

我花了一些时间试图弄清楚发生了什么，我相信我将范围缩小到unattended-upgrades安装安全补丁。具体来说，当我手动重新安装intel-microcode:amd64包时，我能够重现与 CloudFront 的奇怪连接（尽管这可能只是巧合）。

然后，在星期一，我想记录这个问题，以防再次发生类似的事情，但令我惊讶的是，我无法再重现这种奇怪的联系。

周一唯一可观察到的区别是sudo apt-get install --reinstall intel-microcode:amd64[1]的输出 没有这Ign:1条线。

我搜索了网络，包括http://archive.ubuntu.com/ubuntu，grep-ed 虚拟机的磁盘，检查了 misc 的 DNS 记录。ubuntu.com子域，尝试wget使用不同的 URL 来查找到可疑域的重定向——但我找不到任何关于与 CloudFront 的奇怪连接的线索。

我的问题是：有谁知道发生了什么，或者至少在他们的日志中注意到了相同的连接？

（顺便说一句，我知道一个例子，Ubuntu 团队使用 CloudFront 来减轻他们的服务器的 负担： 我的 12.04 ISO 上的 MD5 不匹配，这是怎么回事？ --所以我希望这可能是一个类似的情况？ )

---

[1]：

$ sudo apt-get install --reinstall intel-microcode:amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 1,801 kB of archives.
After this operation, 0 B of additional disk space will be used.
Ign:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 intel-microcode amd64 3.20190514.0ubuntu0.18.04.2
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 intel-microcode amd64 3.20190514.0ubuntu0.18.04.2 [1,801 kB]
Fetched 1,801 kB in 20s (89.2 kB/s)          
(Reading database ... 107477 files and directories currently installed.)
Preparing to unpack .../intel-microcode_3.20190514.0ubuntu0.18.04.2_amd64.deb ...
Unpacking intel-microcode (3.20190514.0ubuntu0.18.04.2) over (3.20190514.0ubuntu0.18.04.2) ...
Setting up intel-microcode (3.20190514.0ubuntu0.18.04.2) ...
update-initramfs: deferring update (trigger activated)
intel-microcode: microcode will be updated at next boot
Processing triggers for initramfs-tools (0.130ubuntu3.7) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-50-generic

Answer 1

我就此向安全和存档团队进行了一些询问，因为他们将成为有关这是否是预期行为的权威来源。以下是他们与我分享的内容摘要：

这种观察到的行为是将流量负载从存档镜像卸载到 Cloudfront，并在 5 月 15 日星期三和 5 月 20 日星期一之间完成，以减轻存档服务器的负载，特别是内核和微码更新。

根据这些团队的说法，这是第一次通过 CloudFront 完成此类卸载，在这种特殊情况下是预期行为。

虽然看起来很可疑，但团队已经通过 IRC 向我确认这是预期的行为，他们很惊讶过去有更多人没有注意到这种行为。

最终：不是恶意行为，而是预期行为，并且需要这样做才能使存档服务器上的内容不会超载。（这也是他们第一次不得不这样做，所以至少没有任何事情发生，呵呵）

现在应该恢复不卸载到 Cloudfront 的标准行为。