Apt - seltsame Anfragen an d16r8ew072anqo.cloudfront.net:80

Am Samstag (18. Mai) habe ich eine meiner VMs gestartet (mit Ubuntu 18.04 Server).

Zu meiner Überraschung hat die VM fast sofort versucht, eine Verbindung herzustellen d16r8ew072anqo.cloudfront.net:80, was ich noch nie zuvor gesehen habe - es ist eine ziemlich "makellose" Installation von Ubuntu, ohne benutzerdefinierte Einstellungenapt Repositorys und mit nur wenigen installierten Paketen. Es hatte noch nie zuvor eine Verbindung zu verdächtigen Objekten hergestellt - hauptsächlich zu Ubuntu- und Snap-Domains. (Ich verwende Little Snitch, um den Netzwerkverkehr zu überwachen, damit ich Verbindungen in Echtzeit sehe und sie auch ablehnen kann.)

Ich habe einige Zeit damit verbracht, herauszufinden, was passiert ist, und ich glaube, ich habe es auf die unattended-upgradesInstallation von Sicherheitspatches beschränkt. Insbesondere als ich das intel-microcode:amd64Paket manuell neu installierte , konnte ich die seltsame Verbindung zu CloudFront reproduzieren (obwohl dies möglicherweise nur ein Zufall war).

Dann, am Montag, wollte ich das Problem dokumentieren, falls wieder etwas Ähnliches passiert, aber zu meiner Überraschung konnte ich die seltsame Verbindung nicht mehr reproduzieren.

Und der einzige beobachtbare Unterschied am Montag war, dass die Ausgabe von sudo apt-get install --reinstall intel-microcode:amd64[1] nicht die Ign:1Zeile hatte.

Ich suchte im Internet, einschließlich http://archive.ubuntu.com/ubuntu , grep-ed der Festplatte des VM, überprüft die DNS - Einträge von misc. ubuntu.comSubdomains haben versucht, wgetüber verschiedene URLs eine Weiterleitung zu der verdächtigen Domain zu finden, aber ich konnte keinen Hinweis auf die seltsame Verbindung zu CloudFront finden.

Meine Frage ist: Weiß jemand, was passiert ist, oder hat zumindest die gleiche Verbindung in ihren Protokollen bemerkt?

(Übrigens ist mir ein Beispiel bekannt, bei dem das Ubuntu-Team CloudFront zum Entlasten seiner Server verwendet hat: MD5-Konflikt auf meiner 12.04-ISO, was ist los? - also hoffe ich, dass dies möglicherweise ein ähnlicher Fall ist? )

[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

Ich habe die Sicherheits- und Archivteams dazu befragt, da sie die maßgebliche Quelle dafür sind, ob dieses Verhalten erwartet wurde oder nicht. Das Folgende ist eine Zusammenfassung dessen, was sie mit mir geteilt haben:

Bei diesem beobachteten Verhalten wurde die Verkehrslast von den Archivspiegeln nach Cloudfront verlagert und zwischen Mittwoch, dem 15. Mai und Montag, dem 20. Mai durchgeführt, um die Last von den Archivservern zu verringern, insbesondere für die Kernel- und Mikrocode-Aktualisierungen.

Laut diesen Teams war dies das erste Mal, dass eine solche Auslagerung über CloudFront durchgeführt wurde, und in diesem speziellen Fall wurde Verhalten erwartet .

Obwohl es verdächtig aussieht, haben die Teams mir via IRC bestätigt, dass dies erwartet wurde, und sie sind überrascht, dass mehr Menschen das Verhalten in der Vergangenheit nicht bemerkt haben.

ULTIMATELY: Kein böswilliges Verhalten, sondern erwartetes Verhalten, das erforderlich ist, damit die Archivserver nicht überlastet werden. (Es war auch das erste Mal, dass sie dies tun mussten, damit zumindest nichts explodierte.)

Das Standardverhalten beim NICHT-Auslagern in Cloudfront sollte jetzt wieder vorhanden sein.