Apt - странные запросы к d16r8ew072anqo.cloudfront.net:80

В субботу (18 мая) я запустил одну из своих виртуальных машин (на которой установлен Ubuntu 18.04 Server).

К моему удивлению, виртуальная машина почти сразу попыталась подключиться 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- на диске виртуальной машины, проверил DNS-записи misc. ubuntu.comсубдомены, пытались - wgetнабирая разные URL-адреса, чтобы найти редирект на подозрительный домен - но я не смог найти какой-либо подсказки о странной связи с CloudFront.

У меня вопрос: кто-нибудь знает, что произошло, или хотя бы заметил такое же соединение в своих логах?

(Кстати, мне известен один пример, когда команда Ubuntu использовала CloudFront для облегчения работы своих серверов: несоответствие MD5 на моем 12.04 ISO, что происходит? - так что я надеюсь, что, возможно, это аналогичный случай? )

[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

Я сделал несколько запросов к командам безопасности и архивов об этом, поскольку они были бы авторитетным источником того, было ли это ожидаемым поведением или нет. Ниже приводится краткое изложение того, что они поделились со мной:

Это наблюдаемое поведение приводило к разгрузке трафика с зеркал архива в Cloudfront, и оно было выполнено между средой 15 мая и понедельником 20 мая, чтобы облегчить загрузку с серверов архивов, особенно для обновлений ядра и микрокода.

По словам тех команд, это впервые, когда такая разгрузка была сделана через CloudFront, и в данном конкретном случае было ожидаемое поведение .

Хотя это выглядит подозрительно, команды через IRC подтвердили мне, что это было ожидаемое поведение, и они удивлены, что больше людей не заметили такого поведения в прошлом.

В конечном счете: не злонамеренное поведение, а скорее ожидаемое поведение, которое необходимо для того, чтобы вещи не перегружались на архивных серверах. (Это был также первый раз, когда им пришлось это сделать, так что, по крайней мере, ничего не взорвалось, хе)

Стандартное поведение НЕ разгрузки в Cloudfront должно быть восстановлено.