El sábado (18 de mayo) inicié una de mis máquinas virtuales (que ejecuta Ubuntu 18.04 Server).
Para mi sorpresa, la VM intentó conectarse casi de inmediato d16r8ew072anqo.cloudfront.net:80, algo que nunca había visto antes: es una instalación bastante "prístina" de Ubuntu, sin aptrepositorios personalizados y solo unos pocos paquetes instalados. Nunca antes se había conectado a nada sospechoso, principalmente a dominios Ubuntu y Snap. (Utilizo Little Snitch para monitorear el tráfico de la red, de modo que veo las conexiones en tiempo real y también puedo negarlas).
Pasé algún tiempo tratando de descubrir qué sucedió y creo que lo limité a unattended-upgradesinstalar parches de seguridad. Específicamente, cuando reinstalé intel-microcode:amd64el paquete manualmente pude reproducir la extraña conexión a CloudFront (aunque podría haber sido solo una coincidencia).
Luego, el lunes, quise documentar el problema en caso de que vuelva a suceder algo similar, pero para mi sorpresa ya no pude reproducir la extraña conexión.
Y la única diferencia observable el lunes fue que la salida de
sudo apt-get install --reinstall intel-microcode:amd64[1] no tenía la Ign:1línea.
Busqué en la web, incluyendohttp://archive.ubuntu.com/ubuntu, grepeditó el disco de la VM, verificó los registros DNS de misc. ubuntu.comsubdominios, intenté wgetcambiar diferentes URL para encontrar una redirección al dominio sospechoso, pero no pude encontrar ninguna pista sobre la extraña conexión con CloudFront.
Mi pregunta es:¿Alguien sabe qué pasó, o al menos notó la misma conexión en sus registros?
(Por cierto, conozco un ejemplo en el que el equipo de Ubuntu utilizó CloudFront para aliviar sus servidores: MD5 no coincide en mi ISO 12.04, ¿qué está pasando? --Así que espero que tal vez este sea un caso similar.)
[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
Respuesta1
Hice algunas consultas a los equipos de Seguridad y Archivo sobre esto, ya que ellos serían la fuente autorizada sobre si este era el comportamiento esperado o no. El siguiente es un resumen de lo que compartieron conmigo:
Este comportamiento observado fue descargar la carga de tráfico de los espejos de archivo a Cloudfront y se realizó entre el miércoles 15 de mayo y el lunes 20 de mayo para aliviar la carga de los servidores de archivo, específicamente para las actualizaciones del kernel y el microcódigo.
Según esos equipos, esta es la primera vez que dicha descarga se realiza a través de CloudFront y en este caso particular fuecomportamiento esperado.
Si bien parece sospechoso, los equipos me confirmaron a través de IRC que este era un comportamiento esperado y están sorprendidos de que más personas no hayan notado el comportamiento en el pasado.
EN ÚLTIMA HORA: No es un comportamiento malicioso, sino que era un comportamiento esperado y era necesario para que las cosas no se sobrecargaran en los servidores de archivo. (También fue la primera vez que tuvieron que hacer esto, así que al menos nada explotó, je)
El comportamiento estándar de NO descargar a Cloudfront debería volver a estar vigente ahora.