Am Samstag (18. Mai) habe ich eine meiner VMs (mit Ubuntu 18.04 Server) gestartet.
Zu meiner Überraschung versuchte die VM fast sofort, eine Verbindung herzustellen d16r8ew072anqo.cloudfront.net:80, was ich noch nie zuvor gesehen hatte – es handelt sich um eine ziemlich „makellose“ Ubuntu-Installation ohne benutzerdefinierte aptRepositories und mit nur wenigen installierten Paketen. Sie hatte sich noch nie zuvor mit etwas Verdächtigem verbunden – hauptsächlich mit Ubuntu- und Snap-Domänen. (Ich verwende Little Snitch, um den Netzwerkverkehr zu überwachen, sodass ich Verbindungen in Echtzeit sehe und sie auch ablehnen kann.)
Ich habe einige Zeit damit verbracht, herauszufinden, was passiert ist, und ich glaube, ich konnte es auf unattended-upgradesdie Installation von Sicherheitspatches eingrenzen. Insbesondere als ich intel-microcode:amd64das Paket manuell neu installierte, konnte ich die seltsame Verbindung zu CloudFront reproduzieren (obwohl es vielleicht nur ein Zufall war).
Am Montag wollte ich das Problem dann dokumentieren, für den Fall, dass so etwas noch einmal passiert, aber zu meiner Überraschung konnte ich die seltsame Verbindung nicht mehr reproduzieren.
Und der einzige erkennbare Unterschied am Montag war, dass die Ausgabe von
sudo apt-get install --reinstall intel-microcode:amd64[1] die Zeile nicht enthielt Ign:1.
Ich habe im Internet gesucht, unter anderemhttp://archive.ubuntu.com/ubuntu, grephabe die Festplatte der VM überprüft, die DNS-Einträge verschiedener ubuntu.comSubdomains geprüft, versucht wget, verschiedene URLs zu überprüfen, um 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 den gleichen Zusammenhang in seinen Protokollen bemerkt?
(Übrigens ist mir ein Beispiel bekannt, bei dem das Ubuntu-Team CloudFront zur Entlastung seiner Server nutzte: MD5-Nichtübereinstimmung auf meinem 12.04 ISO, was ist los? – also hoffe ich, dass dies vielleicht 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
Antwort1
Ich habe diesbezüglich einige Anfragen an die Sicherheits- und Archivteams gestellt, da diese die maßgebliche Quelle sind, um zu bestimmen, ob dies das erwartete Verhalten war oder nicht. Im Folgenden finden Sie eine Zusammenfassung dessen, was sie mir mitgeteilt haben:
Dieses beobachtete Verhalten verlagerte die Verkehrslast von den Archivspiegeln auf Cloudfront und wurde zwischen Mittwoch, dem 15. Mai, und Montag, dem 20. Mai, durchgeführt, um die Archivserver zu entlasten, insbesondere für die Kernel- und Mikrocode-Updates.
Laut diesen Teams ist dies das erste Mal, dass ein solches Offloading über CloudFront durchgeführt wurde, und in diesem speziellen Fall warerwartetes Verhalten.
Obwohl es verdächtig aussieht, haben mir die Teams per IRC bestätigt, dass es sich um ein erwartetes Verhalten handelte, und sie sind überrascht, dass dieses Verhalten in der Vergangenheit nicht mehr Leuten aufgefallen ist.
LETZTLICH: Kein böswilliges Verhalten, sondern erwartetes Verhalten, das erforderlich war, damit es nicht zu einer Überlastung der Archivserver kam. (Es war außerdem das erste Mal, dass sie das tun mussten, also ist wenigstens nichts in die Luft geflogen, heh)
Das Standardverhalten, NICHT an Cloudfront auszulagern, sollte jetzt wieder vorhanden sein.