Apt - demandes étranges à d16r8ew072anqo.cloudfront.net:80

Le samedi 18 mai, j'ai démarré l'une de mes machines virtuelles (exécutant le serveur Ubuntu 18.04).

À ma grande surprise, la machine virtuelle a presque immédiatement tenté de se connecter à d16r8ew072anqo.cloudfront.net:80quelque chose que je n'avais jamais vu auparavant - c'est une installation assez "vierge" d'Ubuntu, sans aptréférentiels personnalisés et seulement quelques packages installés. Il ne s'était jamais connecté à rien de suspect auparavant - principalement aux domaines Ubuntu et Snap. (J'utilise Little Snitch pour surveiller le trafic réseau, donc je vois les connexions en temps réel et je peux également les refuser.)

J'ai passé un peu de temps à essayer de comprendre ce qui s'est passé et je pense que je l'ai limité à l' unattended-upgradesinstallation de correctifs de sécurité. Plus précisément, lorsque j'ai réinstallé manuellement le intel-microcode:amd64package, j'ai pu reproduire l'étrange connexion à CloudFront (bien que ce ne soit qu'une coïncidence).

Lundi, j'ai voulu documenter le problème au cas où quelque chose de similaire se reproduirait, mais à ma grande surprise, je ne pouvais plus reproduire l'étrange connexion.

Et la seule différence observable lundi était que la sortie de sudo apt-get install --reinstall intel-microcode:amd64[1] n'avait pas la Ign:1ligne.

J'ai cherché sur le Web, y compris http://archive.ubuntu.com/ubuntu , grep-ed le disque de la machine virtuelle, vérifié les enregistrements DNS de divers. ubuntu.comsous-domaines, a essayé de wgettrouver différentes URL pour trouver une redirection vers le domaine suspect - mais je n'ai trouvé aucun indice sur l'étrange connexion à CloudFront.

Ma question est: est -ce que quelqu'un sait ce qui s'est passé, ou au moins a remarqué la même connexion dans leurs journaux?

(Soit dit en passant, je connais un exemple où l'équipe Ubuntu a utilisé CloudFront pour soulager leurs serveurs: discordance MD5 sur mon ISO 12.04, que se passe-t- il ? - alors j'espère que c'est peut-être un cas similaire? )

[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

J'ai posé des questions aux équipes de sécurité et d'archivage à ce sujet, car elles seraient la source faisant autorité pour savoir si c'était un comportement attendu ou non. Ce qui suit est un résumé de ce qu'ils ont partagé avec moi:

Ce comportement observé déchargeait la charge de trafic des miroirs d'archives vers Cloudfront, et a été effectué entre le mercredi 15 mai et le lundi 20 mai afin d'alléger la charge des serveurs d'archives, en particulier pour les mises à jour du noyau et du microcode.

Selon ces équipes, c'est la première fois qu'un tel déchargement est effectué via CloudFront, et dans ce cas particulier, il s'agit d'un comportement attendu .

Bien que cela semble suspect, les équipes ont confirmé avec moi via IRC que c'était un comportement attendu, et elles sont surprises que plus de gens n'aient pas remarqué le comportement dans le passé.

ULTIMATELY: Pas de comportement malveillant, mais plutôt un comportement attendu, et était nécessaire pour que les choses ne surchargent pas sur les serveurs d'archives. (C'était aussi la première fois qu'ils devaient faire ça donc au moins rien n'a explosé heh)

Le comportement standard de NON déchargement vers Cloudfront devrait être à nouveau en place maintenant.