Apt - дивні запити на d16r8ew072anqo.cloudfront.net:80


17

У суботу (18 травня) я запустив одну зі своїх віртуальних машин (під керуванням сервера Ubuntu 18.04).

На мій подив, VM майже одразу намагався підключитися до d16r8ew072anqo.cloudfront.net:80чогось, чого я ніколи раніше не бачив - це досить "первозданна" установка Ubuntu, без спеціальних aptсховищ та встановлених лише декількох пакетів. Він ніколи не підключався до нічого підозрілого - в основному до доменів Ubuntu та Snap. (Я використовую Little Snitch для моніторингу мережевого трафіку, щоб я бачив з'єднання в режимі реального часу і можу також відмовити їм.)

Я витратив деякий час, намагаючись з’ясувати, що сталося, і я вважаю, що я звузив це до unattended-upgradesвстановлення патчів безпеки. Зокрема, коли я вручну перевстановив intel-microcode:amd64пакет, мені вдалося відтворити дивне з'єднання з CloudFront (хоча це могло бути просто збігом обставин).

Потім, у понеділок, я хотів задокументувати цю проблему, якщо щось подібне повториться, але, на мій подив, я не міг більше відтворити дивний зв'язок.

І єдиною помітною різницею в понеділок було те, що результат sudo apt-get install --reinstall intel-microcode:amd64[1] не мав Ign:1рядка.

Я шукав в Інтернеті, включаючи http://archive.ubuntu.com/ubuntu , grep-ди диск VM, перевіряв записи DNS про різне. ubuntu.comсубдоменів, спробувавши wgetрізні URL-адреси, щоб знайти переспрямування на підозрілий домен, але я не міг знайти жодної підказки про дивне підключення до CloudFront.

Моє запитання: чи хтось знає, що сталося, чи принаймні помітив той самий зв’язок у своїх журналах?

(До речі, мені відомо один приклад, коли команда Ubuntu використовувала CloudFront, щоб зняти свої сервери: невідповідність MD5 в моєму ISO 12.04, що відбувається? --Так я сподіваюся, що, можливо, це подібний випадок? )


[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

Відповіді:


24

Я зробив кілька запитів до груп безпеки та архіву з цього приводу, оскільки вони будуть авторитетним джерелом щодо того, очікувана ця поведінка чи ні. Нижче наведено короткий виклад того, що вони поділилися зі мною:

Ця спостережувана поведінка вивантажувала завантаження трафіку з дзеркал архіву на Cloudfront, і це робилося між середою 15 травня та понеділком 20 травня, щоб зменшити навантаження з серверів архівів, спеціально для оновлень Kernel та Microcode.

За словами тих команд, це вперше таке розвантаження було здійснено через CloudFront, і в цьому конкретному випадку очікувалося поведінку .


Хоча це виглядає підозріло, команди підтвердили зі мною через IRC, що така поведінка очікувана, і вони дивуються, що більше людей не помічали поведінки в минулому.

ВУЛЬТИМАТЕЛЬНО: Не зловмисна поведінка, а натомість очікувана поведінка, і вона потрібна для того, щоб речі не перевантажувалися на архівах серверів. (Це також був перший раз, коли вони повинні були це зробити, щоб принаймні нічого не підірвало хе)

Стандартна поведінка, що НЕ розвантажується на Cloudfront, повинна повернутися на місце вже зараз.


Дякую, це дуже гарна новина! Тому я здогадуюсь, що в понеділок, 20 травня, мої випробування відбулися після вимкнення CloudFront, і тому я більше не міг відтворити (не) питання.
Томаш Зелінський

Debian (з усіх дистрибутивів) використовує CloudFront та Fast CDN з 2016 року, тому Ubuntu, що робить те саме, там немає нічого нового ...
user1686

@grawity, за винятком того, що Ubuntu ніколи не потребував цього вивантажувати. Але ви не помиляєтеся, що у грандіозній схемі речей "нічого нового", але для Ubuntu було зроблено багато. (І це нетипове спостереження в Ubuntu.)
Томас Уорд

Це не очікувана поведінка. У мене налаштування squid-deb-proxy на сервері та клієнтах, це ім'я хоста заборонено в його списку, тому в результаті я отримую 403. Задавали питання на community.ubuntu.com для отримання офіційної реакції.
N0rbert

@ N0rbert ЦЕ ПОТРІБНО було лише тимчасовим; якщо це все ще триває, то хтось не розповів нам деталей або змінив поведінку сховища.
Thomas Ward
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.