Apt - dziwne prośby do d16r8ew072anqo.cloudfront.net:80

W sobotę (18 maja) uruchomiłem jedną z moich maszyn wirtualnych (z systemem Ubuntu 18.04 Server).

Ku mojemu zdziwieniu maszyna wirtualna niemal natychmiast podjęła próbę połączenia się z d16r8ew072anqo.cloudfront.net:80czymś, czego nigdy wcześniej nie widziałem - jest to dość „nieskazitelna” instalacja Ubuntu, bez niestandardowych aptrepozytoriów i zainstalowanych tylko kilka pakietów. Nigdy wcześniej nie łączyło się z niczym podejrzanym - głównie z domenami Ubuntu i Snap. (Używam Little Snitcha do monitorowania ruchu sieciowego, dzięki czemu widzę połączenia w czasie rzeczywistym i mogę je również odmawiać.)

Spędziłem trochę czasu próbując dowiedzieć się, co się stało, i uważam, że zawęziłem to do unattended-upgradesinstalowania łatek bezpieczeństwa. W szczególności, kiedy ręcznie ponownie instalowałem intel-microcode:amd64pakiet, byłem w stanie odtworzyć dziwne połączenie z CloudFront (chociaż mogło to być tylko zbiegiem okoliczności).

W poniedziałek chciałem udokumentować problem na wypadek, gdyby coś podobnego się powtórzyło, ale ku mojemu zaskoczeniu nie byłem w stanie odtworzyć dziwnego związku.

A jedyną zauważalną różnicą w poniedziałek było to, że wyjście z sudo apt-get install --reinstall intel-microcode:amd64[1] nie miało Ign:1linii.

Przeszukałem sieć, w tym http://archive.ubuntu.com/ubuntu , grep-ed na dysku maszyny wirtualnej, sprawdziłem rekordy DNS misc. ubuntu.compoddomeny, próbowałem - wgetwpisując różne adresy URL, aby znaleźć przekierowanie do podejrzanej domeny - ale nie mogłem znaleźć żadnych wskazówek na temat dziwnego połączenia z CloudFront.

Moje pytanie brzmi: czy ktoś wie, co się stało, lub przynajmniej zauważył to samo połączenie w swoich logach?

(Nawiasem mówiąc, znam jeden przykład, w którym zespół Ubuntu użył CloudFront do odciążenia swoich serwerów: niedopasowanie MD5 na moim ISO 12.04, co się dzieje? - więc mam nadzieję, że może to podobny przypadek? )

[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

Zrobiłem o tym kilka pytań do zespołów ds. Bezpieczeństwa i archiwów, ponieważ byłyby one wiarygodnym źródłem informacji o tym, czy było to oczekiwane zachowanie, czy nie. Oto podsumowanie tego, co mi udostępnili:

To zaobserwowane zachowanie odciążyło obciążenie z serwerów lustrzanych archiwum do Cloudfront i zostało wykonane między środą 15 maja a poniedziałkiem 20 maja w celu zmniejszenia obciążenia serwerów archiwów, szczególnie w przypadku aktualizacji jądra i mikrokodu.

Według tych zespołów po raz pierwszy takie odciążenie zostało wykonane za pośrednictwem CloudFront, aw tym konkretnym przypadku oczekiwano zachowania .

Choć wygląda to podejrzanie, zespoły potwierdziły ze mną za pośrednictwem IRC, że było to oczekiwane zachowanie i są zaskoczeni, że więcej osób nie zauważyło takiego zachowania w przeszłości.

NAJWYŻSZE: Nie jest to złośliwe zachowanie, ale było oczekiwanym zachowaniem i było wymagane, aby rzeczy nie przeciążały serwerów archiwum. (To był też pierwszy raz, kiedy musieli to zrobić, więc przynajmniej nic nie wybuchło heh)

Standardowe zachowanie NIE odciążania do Cloudfront powinno być teraz na swoim miejscu.