週六（5 月 18 日）我啟動了一台虛擬機器（執行 Ubuntu 18.04 Server）。
令我驚訝的是，虛擬機器幾乎立即嘗試連接到d16r8ew072anqo.cloudfront.net:80，這是我以前從未見過的——這是一個非常「原始」的 Ubuntu 安裝，沒有自訂apt儲存庫，只安裝了幾個軟體包。它以前從未連接到任何可疑的東西——主要是 Ubuntu 和 Snap 網域。 （我使用 Little Snitch 來監控網路流量，因此我可以即時查看連線並可以拒絕它們。）
我花了一些時間試圖弄清楚發生了什麼，我相信我將範圍縮小到unattended-upgrades安裝安全性修補程式。具體來說，當我手動重新安裝intel-microcode:amd64軟體包時，我能夠重現與 CloudFront 的奇怪連接（儘管這可能只是巧合）。
然後，在周一，我想記錄這個問題，以防類似的事情再次發生，但令我驚訝的是，我無法重現這種奇怪的聯繫。
週一唯一可觀察到的差異是 [1] 的輸出
sudo apt-get install --reinstall intel-microcode:amd64沒有這條Ign:1線。
我在網路上搜尋了一下，包括http://archive.ubuntu.com/ubuntu, grep-ed 虛擬機器磁碟，檢查雜項的 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
答案1
我向安全和存檔團隊詢問了此事，因為他們是這是否是預期行為的權威來源。以下是他們與我分享的內容摘要：
觀察到的行為是將流量負載從存檔鏡像卸載到 Cloudfront，是在 5 月 15 日星期三到 5 月 20 日星期一之間完成的，目的是減輕存檔伺服器的負載，特別是核心和微程式碼更新。
據這些團隊稱，這是第一次透過 CloudFront 完成此類卸載，在這種特殊情況下預期行為。
雖然看起來很可疑，但團隊已透過 IRC 向我確認這是預期的行為，而且令他們驚訝的是，更多的人過去沒有註意到這種行為。
最終：不是惡意行為，而是預期行為，並且是為了使存檔伺服器上的內容不會超載所必需的。 （這也是他們第一次不得不這樣做，所以至少沒有爆炸，呵呵）
不卸載到 Cloudfront 的標準行為現在應該恢復原狀。