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

В субботу (18 мая) я запустил один из своих VMs (рабочий Сервер Ubuntu 18.04).

К моему удивлению VM почти сразу попытался соединиться с d16r8ew072anqo.cloudfront.net:80, что-то, что я никогда не видел прежде - это - довольно "нетронутая" установка Ubuntu без пользовательского apt репозитории и всего несколько пакетов установлены. Это никогда не соединялось ни с чем подозрительным прежде - главным образом к доменам Ubuntu и Snap. (Я использую Мало, Умыкают для контроля сетевого трафика, таким образом, я вижу соединения в режиме реального времени и могу отклонить их также.)

Я провел некоторое время, пытаясь выяснить то, что произошло, и я полагаю, что сузил его к unattended-upgrades установка патчей безопасности. А именно, когда я вручную переустановил intel-microcode:amd64 пакет я смог воспроизвести странное соединение с CloudFront (хотя это, возможно, было просто совпадение).

Затем в понедельник я хотел зарегистрировать проблему в случае, если что-то подобное происходит снова, но к моему удивлению я не мог больше воспроизводить странное соединение.

И единственное заметное различие в понедельник было то, что вывод от sudo apt-get install --reinstall intel-microcode:amd64 [1] не имел Ign:1 строка.

Я искал сеть, включая http://archive.ubuntu.com/ubuntu, grep- редактор диск VM, проверенный записи DNS разного. 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
17
задан 23 May 2019 в 16:38

1 ответ

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

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

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


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

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

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

0
ответ дан 23 May 2019 в 16:38

Другие вопросы по тегам:

Похожие вопросы: