Apt: strane richieste a d16r8ew072anqo.cloudfront.net:80

Sabato (18 maggio) ho avviato una delle mie macchine virtuali (con Ubuntu 18.04 Server).

Con mia sorpresa, la VM quasi immediatamente ha tentato di connettersi d16r8ew072anqo.cloudfront.net:80, qualcosa che non avevo mai visto prima - è un'installazione piuttosto "incontaminata" di Ubuntu, senza aptrepository personalizzati e solo alcuni pacchetti installati. Non si era mai collegato a qualcosa di sospetto prima, principalmente ai domini Ubuntu e Snap. (Uso Little Snitch per monitorare il traffico di rete, quindi vedo le connessioni in tempo reale e posso negarle.)

Ho trascorso un po 'di tempo a cercare di capire cosa è successo e credo di averlo ridotto unattended-upgradesall'installazione di patch di sicurezza. In particolare, quando ho reinstallato manualmente il intel-microcode:amd64pacchetto sono stato in grado di riprodurre la strana connessione a CloudFront (anche se potrebbe essere stata solo una coincidenza).

Quindi, lunedì, ho voluto documentare il problema nel caso in cui qualcosa di simile accada di nuovo, ma con mia sorpresa non sono più riuscito a riprodurre la strana connessione.

E l'unica differenza osservabile lunedì è stata che l'output di sudo apt-get install --reinstall intel-microcode:amd64[1] non aveva la Ign:1linea.

Ho cercato sul web, incluso http://archive.ubuntu.com/ubuntu , grep-ed il disco della VM, ho controllato i record DNS di misc. ubuntu.comsottodomini, wgetho provato a utilizzare URL diversi per trovare un reindirizzamento al dominio sospetto, ma non sono riuscito a trovare alcun indizio sulla strana connessione a CloudFront.

La mia domanda è: qualcuno sa cosa è successo o almeno ha notato la stessa connessione nei propri registri?

(A proposito, sono a conoscenza di un esempio in cui il team di Ubuntu ha utilizzato CloudFront per scaricare i propri server: mancata corrispondenza MD5 sul mio ISO 12.04, cosa sta succedendo? - quindi spero che forse sia un caso simile? )

[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

Ho fatto alcuni interrogativi ai team di sicurezza e archivio a riguardo, in quanto sarebbero la fonte autorevole sul fatto che si trattasse di un comportamento previsto o meno. Di seguito è riportato un riepilogo di ciò che hanno condiviso con me:

Questo comportamento osservato stava scaricando il carico del traffico dai mirror degli archivi su Cloudfront ed è stato eseguito tra mercoledì 15 maggio e lunedì 20 maggio per alleviare il carico dai server di archivio, in particolare per gli aggiornamenti Kernel e Microcode.

Secondo tali team, questa è la prima volta che tale offload è stato eseguito tramite CloudFront e in questo caso particolare era previsto un comportamento .

Anche se sembra sospetto, i team hanno confermato con me tramite IRC che questo era un comportamento previsto e sono sorpresi che più persone non abbiano notato il comportamento in passato.

ULTIMATAMENTE: comportamento non dannoso, ma invece era previsto comportamento ed era necessario affinché le cose non si sovraccaricassero sui server di archivio. (Era anche la prima volta che hanno dovuto farlo, quindi almeno non è esploso, eh)

Il comportamento standard di NOT offloading su Cloudfront dovrebbe essere di nuovo attivo.