No sábado (18 de maio) iniciei uma de minhas VMs (rodando Ubuntu 18.04 Server).
Para minha surpresa, a VM quase imediatamente tentou se conectar ao d16r8ew072anqo.cloudfront.net:80, algo que eu nunca tinha visto antes - é uma instalação bastante "primeira" do Ubuntu, sem aptrepositórios personalizados e apenas alguns pacotes instalados. Ele nunca havia se conectado a nada suspeito antes – principalmente aos domínios Ubuntu e Snap. (Eu uso o Little Snitch para monitorar o tráfego de rede, para ver as conexões em tempo real e também poder negá-las.)
Passei algum tempo tentando descobrir o que aconteceu e acredito que me limitei à unattended-upgradesinstalação de patches de segurança. Especificamente, quando reinstalei manualmente intel-microcode:amd64o pacote, consegui reproduzir a estranha conexão com o CloudFront (embora possa ter sido apenas uma coincidência).
Então, na segunda-feira, quis 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.
Eu pesquisei na web, incluindohttp://archive.ubuntu.com/ubuntu, grep-ed o disco da VM, verificou os registros DNS de diversos. 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 notou 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 talvez este 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
Responder1
Fiz algumas perguntas às equipes de Segurança e Arquivo sobre isso, pois elas seriam a fonte autorizada sobre se esse comportamento era esperado ou não. A seguir está um resumo do que eles compartilharam comigo:
Esse comportamento observado foi descarregar a carga de tráfego dos espelhos de arquivo para o Cloudfront e foi feito entre quarta-feira, 15 de maio, e segunda-feira, 20 de maio, a fim de aliviar a carga dos servidores de arquivo, especificamente para as atualizações de kernel e microcódigo.
Segundo essas equipes, esta é a primeira vez que tal offloading é feito via CloudFront e, neste caso específico, foicomportamento esperado.
Embora pareça suspeito, as equipes confirmaram comigo via IRC que esse comportamento era esperado e estão surpresos que mais pessoas não tenham notado esse comportamento no passado.
FINALMENTE: Não é um comportamento malicioso, mas sim um comportamento esperado e necessário para que as coisas não sobrecarreguem os servidores de arquivamento. (Também foi a primeira vez que eles fizeram isso, então pelo menos nada explodiu heh)
O comportamento padrão de NÃO descarregar para o Cloudfront deve estar de volta em vigor agora.