Apt - solicitações estranhas para d16r8ew072anqo.cloudfront.net:80

No sábado (18 de maio), iniciei uma das minhas VMs (executando o Ubuntu 18.04 Server).

Para minha surpresa, a VM quase imediatamente tentou se conectar d16r8ew072anqo.cloudfront.net:80, algo que eu nunca vi antes - é uma instalação bastante "pura" do Ubuntu, sem aptrepositórios personalizados e apenas alguns pacotes instalados. Ele nunca havia se conectado a algo suspeito antes - principalmente aos domínios Ubuntu e Snap. (Eu uso o Little Snitch para monitorar o tráfego da rede, para ver as conexões em tempo real e também posso negá-las.)

Passei algum tempo tentando descobrir o que aconteceu e acredito que o reduzi à unattended-upgradesinstalação de patches de segurança. Especificamente, quando reinstalei o intel-microcode:amd64pacote manualmente, consegui reproduzir a conexão estranha com o CloudFront (embora possa ter sido apenas uma coincidência).

Então, na segunda-feira, eu queria documentar o problema caso algo semelhante acontecesse novamente, mas, para minha surpresa, não consegui mais reproduzir a estranha conexão.

E a única diferença observável na segunda-feira foi que a saída de sudo apt-get install --reinstall intel-microcode:amd64[1] não tinha a Ign:1linha.

Pesquisei na web, incluindo http://archive.ubuntu.com/ubuntu , grepno disco da VM, verifiquei os registros DNS do misc. ubuntu.comsubdomínios, tentei wgetusar URLs diferentes para encontrar um redirecionamento para o domínio suspeito - mas não consegui encontrar nenhuma pista sobre a estranha conexão com o CloudFront.

Minha pergunta é: alguém sabe o que aconteceu, ou pelo menos percebeu a mesma conexão em seus logs?

(A propósito, estou ciente de um exemplo em que a equipe do Ubuntu usou o CloudFront para aliviar seus servidores: incompatibilidade MD5 na minha ISO 12.04, o que está acontecendo? - então, espero que esse seja um caso semelhante? )

[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

Fiz algumas perguntas às equipes de Segurança e Arquivamento sobre isso, pois elas seriam a fonte autorizada sobre se esse era o comportamento esperado ou não. A seguir, é apresentado um resumo do que eles compartilharam comigo:

Esse comportamento observado descarregava a carga de tráfego dos espelhos de arquivamento para o Cloudfront e foi realizado entre quarta-feira, 15 de maio e segunda-feira, 20 de maio, a fim de aliviar a carga dos servidores de arquivamento, especificamente para as atualizações do Kernel e do Microcódigo.

Segundo essas equipes, é a primeira vez que esse descarregamento é feito via CloudFront e, nesse caso em particular, era esperado um comportamento .

Embora pareça suspeito, as equipes confirmaram comigo via IRC que esse era um comportamento esperado e eles ficam surpresos que mais pessoas não haviam percebido o comportamento no passado.

FINALMENTE: Não é um comportamento malicioso, mas o comportamento esperado era necessário e era necessário para que as coisas não sobrecarregassem os servidores de arquivamento. (Foi também a primeira vez que eles fizeram isso, pelo menos nada explodiu heh)

O comportamento padrão de NÃO transferir para o Cloudfront deve estar de volta ao local agora.