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, le VM a presque immédiatement tenté de se connecter à d16r8ew072anqo.cloudfront.net:80, quelque chose que je n'avais jamais vu auparavant - c'est une installation assez "vierge" d'Ubuntu, sans référentiels apt personnalisés, et juste quelques paquets 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 réduit à unattended-upgrades installation de correctifs de sécurité. Plus précisément, lorsque j'ai réinstallé manuellement intel-microcode:AMD64 package 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 le Ign:1 ligne.
J'ai cherché sur le Web, y compris http://archive.ubuntu.com/ubunt , grep- ed le disque de la machine virtuelle, vérifié les enregistrements DNS de divers. ubuntu.com sous-domaines, a essayé wget- ting 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 a au moins remarqué la même connexion dans leurs journaux?
(Au fait, je connais un exemple où l'équipe Ubuntu a utilisé CloudFront pour soulager leurs serveurs: incompatibilité 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'archivage 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 était comportement attend.
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.