Apt - permintaan aneh ke d16r8ew072anqo.cloudfront.net:80

Pada hari Sabtu (18 Mei) saya memulai salah satu VM saya (menjalankan Ubuntu 18.04 Server).

Yang mengejutkan saya, VM segera berusaha untuk terhubung d16r8ew072anqo.cloudfront.net:80, sesuatu yang belum pernah saya lihat sebelumnya - ini adalah instalasi Ubuntu yang "murni", tanpa aptrepositori khusus , dan hanya beberapa paket yang diinstal. Itu tidak pernah terhubung ke sesuatu yang mencurigakan sebelumnya - sebagian besar ke Ubuntu dan domain Snap. (Saya menggunakan Little Snitch untuk memonitor lalu lintas jaringan sehingga saya melihat koneksi secara real time dan dapat menolaknya juga.)

Saya menghabiskan beberapa waktu untuk mencari tahu apa yang terjadi dan saya percaya saya mempersempitnya untuk unattended-upgradesmenginstal patch keamanan. Khususnya, ketika saya menginstal ulang intel-microcode:amd64paket secara manual, saya dapat mereproduksi koneksi aneh ke CloudFront (walaupun itu mungkin hanya kebetulan).

Kemudian, pada hari Senin, saya ingin mendokumentasikan masalah ini seandainya hal serupa terjadi lagi, tetapi saya terkejut karena saya tidak dapat mereproduksi koneksi aneh itu lagi.

Dan satu-satunya perbedaan yang terlihat pada hari Senin adalah bahwa output dari sudo apt-get install --reinstall intel-microcode:amd64[1] tidak memiliki Ign:1garis.

Saya mencari di web, termasuk http://archive.ubuntu.com/ubuntu , grep-ed disk VM, memeriksa catatan DNS misc. ubuntu.comsubdomain, mencoba wget-URL yang berbeda untuk menemukan pengalihan ke domain yang mencurigakan - tetapi saya tidak dapat menemukan petunjuk tentang koneksi aneh ke CloudFront.

Pertanyaan saya adalah: apakah ada yang tahu apa yang terjadi, atau paling tidak memperhatikan koneksi yang sama dalam log mereka?

(Omong-omong, saya mengetahui satu contoh di mana tim Ubuntu menggunakan CloudFront untuk meringankan server mereka: ketidakcocokan MD5 pada ISO 12,04 saya, apa yang terjadi? - jadi saya berharap mungkin ini kasus yang sama? )

[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

Saya membuat beberapa pertanyaan kepada tim Keamanan dan Arsip tentang hal ini, karena mereka akan menjadi sumber yang berwenang tentang apakah ini perilaku yang diharapkan atau tidak. Berikut ini adalah ringkasan dari apa yang mereka bagikan dengan saya:

Perilaku yang diamati ini membongkar muatan lalu lintas dari cermin arsip ke Cloudfront, dan dilakukan antara Rabu 15 Mei dan Senin 20 Mei untuk meringankan beban dari Server Arsip, khususnya untuk pembaruan Kernel dan Mikrokode.

Menurut tim-tim itu, ini adalah pertama kalinya pembongkaran dilakukan melalui CloudFront, dan dalam hal ini perilaku yang diharapkan .

Meskipun terlihat mencurigakan, tim telah mengkonfirmasi dengan saya melalui IRC bahwa ini adalah perilaku yang diharapkan, dan mereka terkejut bahwa lebih banyak orang tidak memperhatikan perilaku di masa lalu.

ULTIMATELY: Bukan perilaku jahat, melainkan perilaku yang diharapkan, dan diperlukan agar hal-hal tidak kelebihan pada server arsip. (Itu juga pertama kalinya mereka harus melakukan ini jadi setidaknya tidak ada yang meledak heh)

Perilaku standar BUKAN pembongkaran ke Cloudfront harus kembali pada tempatnya sekarang.