В субботу (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 разных ubuntu.comподдоменов, попробовал wgetперенаправить по разным URL-адресам подозрительный домен, но не смог найти никаких зацепок о странном подключении к CloudFront.
Мой вопрос:кто-нибудь знает, что произошло, или, по крайней мере, заметил такую же связь в своих журналах?
(Кстати, мне известен один пример, когда команда Ubuntu использовала CloudFront для разгрузки своих серверов: Несоответствие MD5 на моем ISO 12.04. Что происходит? --поэтому я надеюсь, что, возможно, это похожий случай?)
[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
Я сделал несколько запросов в команды Security и Archive по этому поводу, так как они были бы авторитетным источником относительно того, было ли это ожидаемым поведением или нет. Ниже приводится резюме того, чем они поделились со мной:
Это наблюдаемое поведение заключалось в разгрузке трафика с архивных зеркал на Cloudfront и было реализовано в период со среды 15 мая по понедельник 20 мая с целью снижения нагрузки на архивные серверы, в частности, для обновлений ядра и микрокода.
По словам этих команд, это первый случай, когда такая разгрузка была осуществлена через CloudFront, и в данном конкретном случае это былоожидаемое поведение.
Хотя это выглядит подозрительно, команды подтвердили мне через IRC, что это ожидаемое поведение, и они удивлены, что больше людей не замечали подобного поведения в прошлом.
В КОНЕЧНОМ СЧЕТЕ: Это не вредоносное поведение, а ожидаемое поведение, и оно было необходимо для того, чтобы не перегружать архивные серверы. (И это был первый раз, когда им пришлось это сделать, так что, по крайней мере, ничего не вышло из строя, хех)
Теперь стандартное поведение ОТКАЗА от выгрузки в Cloudfront должно вернуться на место.