Apt - solicitudes extrañas a d16r8ew072anqo.cloudfront.net:80


17

El sábado (18 de mayo) comencé una de mis máquinas virtuales (ejecutando 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 algo sospechoso, principalmente a dominios Ubuntu y Snap. (Uso Little Snitch para monitorear el tráfico de la red, así que veo las conexiones en tiempo real y también puedo negarlas).

Pasé un tiempo tratando de averiguar qué sucedió y creo que lo reduje a la unattended-upgradesinstalación de parches de seguridad. Específicamente, cuando reinstalé manualmente el intel-microcode:amd64paquete pude reproducir la conexión extraña a CloudFront (aunque podría haber sido solo una coincidencia).

Luego, el lunes, quería documentar el problema en caso de que algo similar ocurriera nuevamente, pero para mi sorpresa, ya no pude reproducir la conexión extraña.

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, incluyendo http://archive.ubuntu.com/ubuntu , grepedité el disco de la máquina virtual, verifiqué los registros DNS de misceláneos. ubuntu.comsubdominios, probé wgetdiferentes URL para encontrar una redirección al dominio sospechoso, pero no pude encontrar ninguna pista sobre la extraña conexión a CloudFront.

Mi pregunta es: ¿alguien sabe lo que sucedió, o al menos notó la misma conexión en sus registros?

(Por cierto, conozco un ejemplo en el que el equipo de Ubuntu usó CloudFront para liberar sus servidores: desajuste de MD5 en mi ISO 12.04, ¿qué está pasando? ¿Entonces espero que 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

Respuestas:


24

Hice algunas preguntas a los equipos de Seguridad y Archivo sobre esto, ya que serían la fuente autorizada sobre si este era un comportamiento esperado o no. El siguiente es un resumen de lo que compartieron conmigo:

Este comportamiento observado estaba descargando 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 de Kernel y 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 se esperaba un comportamiento .


Si bien parece sospechoso, los equipos me han confirmado 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.

ULTIMADAMENTE: No es un comportamiento malicioso, sino un comportamiento esperado, y era necesario para que las cosas no se sobrecarguen 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 su lugar ahora.


Gracias, ¡son muy buenas noticias! Así que supongo que el lunes 20 de mayo, mis pruebas ocurrieron después de que CloudFront se apagó y es por eso que ya no pude reproducir el problema (no).
Tomasz Zieliński

Debian (de todas las distribuciones) ha estado usando CloudFront y Fastly CDNs desde 2016, por lo que Ubuntu haciendo lo mismo no es nada nuevo ...
user1686

@grawity excepto que Ubuntu nunca pareció necesitar descargar esto. Pero no te equivocas, no es 'nada nuevo' en el gran esquema de las cosas, pero para Ubuntu no se ha hecho mucho. (Y es una observación atípica en Ubuntu.)
Thomas Ward

Este no es un comportamiento esperado. Tengo la configuración de proxy squid-deb en el servidor y los clientes, este nombre de host no está permitido en su lista blanca, por lo que obtengo 403 como resultado. Pregunta formulada en community.ubuntu.com para obtener una reacción oficial.
N0rbert

@ N0rbert esto DEBERÍA haber sido solo temporal; Si esto sigue sucediendo, alguien no nos ha dado detalles o ha alterado los comportamientos del repositorio.
Thomas Ward
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.