Apt - คำขอแปลก ๆ ไปยัง d16r8ew072anqo.cloudfront.net:80


17

ในวันเสาร์ (18 พฤษภาคม) ฉันเริ่มต้นหนึ่งใน VMs ของฉัน (ใช้เซิร์ฟเวอร์ 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-ed ดิสก์ของ VM ตรวจสอบระเบียน DNS ของ misc ubuntu.comโดเมนย่อยพยายามใช้wgetURL ที่แตกต่างกันเพื่อค้นหาการเปลี่ยนเส้นทางไปยังโดเมนที่น่าสงสัย - แต่ฉันไม่พบเบาะแสเกี่ยวกับการเชื่อมต่อที่แปลกไปยัง CloudFront

คำถามของฉันคือ:ไม่มีใครรู้ว่าเกิดอะไรขึ้นหรืออย่างน้อยก็สังเกตเห็นการเชื่อมต่อเดียวกันในบันทึกของพวกเขา?

(โดยวิธีการฉันรู้ตัวอย่างหนึ่งที่ทีม Ubuntu ใช้ CloudFront เพื่อลดเซิร์ฟเวอร์ของพวกเขา: MD5 ไม่ตรงกันใน 12.04 ISO ของฉันเกิดอะไร ขึ้น - ฉันหวังว่านี่อาจจะเป็นกรณีที่คล้ายกัน )


[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

ฉันทำบางคำถามกับทีม Security และ Archive เกี่ยวกับเรื่องนี้เนื่องจากพวกเขาจะเป็นแหล่งข้อมูลที่เชื่อถือได้ว่าสิ่งนี้เป็นพฤติกรรมที่คาดหวังหรือไม่ ต่อไปนี้เป็นบทสรุปของสิ่งที่พวกเขาแบ่งปันกับฉัน:

พฤติกรรมที่สังเกตได้นี้คือการลดภาระการรับส่งข้อมูลจากไฟล์เก็บถาวรไปยัง Cloudfront และดำเนินการระหว่างวันพุธที่ 15 พฤษภาคมถึงวันจันทร์ที่ 20 พฤษภาคมเพื่อบรรเทาภาระจากเซิร์ฟเวอร์เก็บถาวรโดยเฉพาะสำหรับการอัปเดตเคอร์เนลและไมโครโค้ด

ตามที่ทีมดังกล่าวนี้เป็นครั้งแรกที่ถ่ายดังกล่าวได้กระทำผ่าน CloudFront และในกรณีนี้โดยเฉพาะได้รับการคาดว่าพฤติกรรม


ในขณะที่ดูน่าสงสัยทีมยืนยันกับฉันผ่าน IRC ว่าสิ่งนี้เป็นพฤติกรรมที่คาดหวังและพวกเขาก็ประหลาดใจที่มีคนจำนวนมากไม่ได้สังเกตเห็นพฤติกรรมในอดีต

ULTIMATELY: ไม่ใช่พฤติกรรมที่เป็นอันตราย แต่กลับเป็นพฤติกรรมที่คาดหวังและจำเป็นต้องมีเพื่อให้สิ่งต่าง ๆ ไม่เกินพิกัดบนเซิร์ฟเวอร์เก็บถาวร (เป็นครั้งแรกที่พวกเขาต้องทำเช่นนี้อย่างน้อยก็ไม่มีอะไรเกิดขึ้น)

พฤติกรรมมาตรฐานของการไม่ถ่ายข้อมูลไปยัง Cloudfront ควรกลับมาใช้งานได้ทันที


ขอบคุณที่เป็นข่าวดีมาก! ดังนั้นฉันเดาว่าในวันจันทร์ที่ 20 พฤษภาคมการทดลองของฉันเกิดขึ้นหลังจากที่ CloudFront ถูกปิดและนั่นเป็นสาเหตุที่ฉันไม่สามารถสร้างปัญหา (ไม่ใช่) อีกต่อไป
Tomasz Zieliński

Debian (จาก distros ทั้งหมด) ใช้งาน CloudFront และ Fastly CDNs ตั้งแต่ปี 2559 ดังนั้น Ubuntu ที่ทำสิ่งเดียวกันนั้นไม่มีอะไรใหม่ที่นั่น ...
user1686

@grawity ยกเว้นว่า Ubuntu ไม่เคยคิดจะถ่ายสิ่งนี้ แต่คุณไม่ผิดก็คือ 'ไม่มีอะไรใหม่' ในรูปแบบที่ยิ่งใหญ่ของสิ่งต่าง ๆ แต่สำหรับ Ubuntu นั้นยังไม่ได้ทำอะไรมากนัก (และเป็นข้อสังเกตที่ผิดปกติใน Ubuntu)
Thomas Ward

นี่ไม่ใช่พฤติกรรมที่คาดหวัง ฉันมีการตั้งค่า squid-deb-proxy บนเซิร์ฟเวอร์และไคลเอนต์ชื่อโฮสต์นี้ไม่ได้รับอนุญาตในรายการที่อนุญาตดังนั้นฉันจึงได้รับ 403 ตามผลลัพธ์ คำถามที่ถูกถามเกี่ยวกับcommunity.ubuntu.comเพื่อรับปฏิกิริยาอย่างเป็นทางการ
N0rbert

@ N0rbert นี้ควรเป็นเพียงชั่วคราว ถ้าสิ่งนี้ยังคงเกิดขึ้นอยู่จะไม่มีใครบอกรายละเอียดกับเราหรือเปลี่ยนแปลงพฤติกรรมของที่เก็บ
โธมัสวอร์ด
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.