Apt - d16r8ew072anqo.cloudfront.net:80 için garip istekler


17

18 Mayıs Cumartesi günü VM'lerimden birini başlattım (Ubuntu 18.04 Server'ı çalıştırıyorum).

Şaşırtıcı bir şekilde, VM hemen hemen bağlanmaya çalıştı d16r8ew072anqo.cloudfront.net:80, daha önce hiç görmediğim bir şey - bu, özel apthavuzları olmayan ve sadece birkaç paket yüklü olmayan Ubuntu'nun oldukça "bozulmamış" bir kurulumu . Daha önce hiç şüpheli bir şeye bağlanmamıştı - çoğunlukla Ubuntu ve Snap alanlarına. (Ağ trafiğini izlemek için Little Snitch kullanıyorum, böylece bağlantıları gerçek zamanlı olarak görüyorum ve onları reddedebiliyorum.)

Ne olduğunu anlamaya çalışmak için biraz zaman harcadım ve inanıyorum ki unattended-upgradesgüvenlik yamaları yüklemek için daralttım . Özellikle, intel-microcode:amd64paketi manuel olarak yeniden yüklediğimde , CloudFront'a garip bağlantıyı yeniden üretebildim (ancak bir tesadüf olabilir).

Sonra, Pazartesi günü, benzer bir şeyin tekrarlanması durumunda sorunu belgelemek istedim, ama şaşırtıcı bir şekilde artık garip bağlantıyı yeniden üretemedim.

Ve Pazartesi günü gözlemlenen tek fark, sudo apt-get install --reinstall intel-microcode:amd64[1] ' den elde edilen çıkışın Ign:1 çizgiye .

Ben de dahil olmak üzere web, arama http://archive.ubuntu.com/ubuntu , grepSM'nin diski -ed, Çeşitli bağlantıların DNS kayıtlarını kontrol etti. ubuntu.comalt alan adları, denendiwget şüpheli alana bir yönlendirme bulmak için farklı URL'ler - ancak CloudFront'a garip bağlantı hakkında herhangi bir ipucu bulamadım.

Sorum şu: Herkes neler olduğunu biliyor ya da en azından günlüklerinde aynı bağlantıyı fark etti mi?

(Bu arada, Ubuntu ekibinin sunucularını rahatlatmak için CloudFront'u kullandığı bir örneğin farkındayım: 12.04 ISO'mda MD5 uyuşmazlığı, neler oluyor? - yani bunun benzer bir durum olduğunu umuyorum? )


[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

Yanıtlar:


24

Güvenlik ve Arşiv ekiplerine, bunun beklenen davranış olup olmadığı konusunda yetkili bir kaynak olacağı için, bazı soruşturmalar yaptım. Aşağıda benimle paylaştıkları şeyin bir özeti verilmiştir:

Bu gözlemlenen davranış, trafik yükünü arşiv aynalarından Cloudfront'a yüklüydü ve özellikle Çekirdek ve Mikrokod güncellemeleri için Arşiv Sunucularından yükü hafifletmek amacıyla 15 Mayıs Çarşamba ile 20 Mayıs Pazartesi arasında yapıldı.

Bu ekiplere göre, bu tür boşaltma ilk kez CloudFront üzerinden yapıldı ve bu durumda beklenen davranış oldu .


Şüpheli görünse de, ekipler benimle IRC aracılığıyla bunun beklenen davranış olduğunu doğruladılar ve geçmişte daha fazla insanın davranışları fark etmediğine şaşırıyorlar.

ULTIMATELY: Kötü niyetli davranışlar değil, beklenen davranışlar vardı ve arşiv sunucularında aşırı yüklenmemesi için gerekliydi. (Bunu ilk kez yapmak zorunda kaldıklarından en azından hiçbir şey havaya uçmadı heh)

Cloudfront'a DOLDURMAMANIN standart davranışı şimdi yerinde olmalıdır.


Teşekkür ederim, bu çok iyi bir haber! Bu yüzden sanırım 20 Mayıs Pazartesi günü denemelerim CloudFront kapatıldıktan sonra gerçekleşti ve bu yüzden artık (olmayan) sorunu yeniden üretemedim.
Tomasz Zieliński

Debian (tüm dağıtımlardan) 2016'dan beri CloudFront ve
Fastly CDN'leri

@grawity, Ubuntu'nun bunu hiç boşaltması gerekmiyor gibi görünüyordu. Ama yanılmıyorsunuz, şeylerin büyük düzeninde 'yeni bir şey' değil, çünkü Ubuntu için çok fazla şey yapılmadı. (Ve Ubuntu'da atipik bir gözlemdir.)
Thomas Ward

Bu beklenen bir davranış değildir. Sunucu ve istemcilerde kalamar-deb-proxy kurulum var, bu ana makine beyaz listesinde izin verilmiyor, bu yüzden sonuç olarak 403 olsun. Resmi tepki almak için community.ubuntu.com hakkında soru sordu .
N0rbert

@ N0rbert bu sadece geçici olmalı; bu hala devam ediyorsa, o zaman birisi bize bilgi vermedi ya da depo davranışlarını değiştirmedi .
Thomas Ward
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.