Apt - yêu cầu lạ đối với d16r8ew072anqo.cloudfront.net:80


17

Vào thứ bảy (18 tháng 5), tôi đã khởi động một trong những máy ảo của mình (chạy Ubuntu 18.04 Server).

Thật ngạc nhiên, VM gần như ngay lập tức cố gắng kết nối d16r8ew072anqo.cloudfront.net:80, thứ mà tôi chưa từng thấy trước đây - đó là một bản cài đặt Ubuntu "nguyên sơ", không có aptkho lưu trữ tùy chỉnh và chỉ có một vài gói được cài đặt. Nó chưa bao giờ kết nối với bất kỳ điều gì đáng ngờ trước đây - chủ yếu là các miền Ubuntu và Snap. (Tôi sử dụng Little Snitch để theo dõi lưu lượng mạng để tôi thấy các kết nối trong thời gian thực và cũng có thể từ chối chúng.)

Tôi đã dành một chút thời gian để cố gắng tìm hiểu những gì đã xảy ra và tôi tin rằng tôi đã thu hẹp nó để unattended-upgradescài đặt các bản vá bảo mật. Cụ thể, khi tôi cài đặt lại intel-microcode:amd64gói thủ công, tôi có thể tạo lại kết nối lạ với CloudFront (mặc dù có thể đó chỉ là sự trùng hợp ngẫu nhiên).

Sau đó, vào thứ Hai, tôi muốn ghi lại vấn đề trong trường hợp điều gì đó tương tự lại xảy ra, nhưng thật ngạc nhiên, tôi không thể tái tạo kết nối lạ nữa.

Và sự khác biệt duy nhất có thể quan sát được vào thứ Hai là đầu ra từ sudo apt-get install --reinstall intel-microcode:amd64[1] không có Ign:1dòng.

Tôi đã tìm kiếm trên web, bao gồm http://archive.ubfox.com/ubfox , grep-ed đĩa của VM, kiểm tra các bản ghi DNS của linh tinh. ubuntu.comtên miền phụ, đã thử chuyển wgetcác URL khác nhau để tìm chuyển hướng đến tên miền đáng ngờ - nhưng tôi không thể tìm thấy bất kỳ manh mối nào về kết nối lạ với CloudFront.

Câu hỏi của tôi là: có ai biết chuyện gì đã xảy ra không, hoặc ít nhất nhận thấy cùng một kết nối trong nhật ký của họ?

(Nhân tiện, tôi biết một ví dụ trong đó nhóm Ubuntu đã sử dụng CloudFront để giải phóng các máy chủ của họ: MD5 không khớp với ISO 12.04 của tôi, chuyện gì đang xảy ra? - tôi có hy vọng rằng đây có thể là trường hợp tương tự không? )


[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

Câu trả lời:


24

Tôi đã thực hiện một số yêu cầu cho các nhóm Bảo mật và Lưu trữ về việc này, vì họ sẽ là nguồn có thẩm quyền về việc liệu đây có phải là hành vi dự kiến ​​hay không. Sau đây là tóm tắt về những gì họ đã chia sẻ với tôi:

Hành vi được quan sát này đã giảm tải lưu lượng truy cập từ các máy nhân bản lưu trữ lên Cloudfront và được thực hiện trong khoảng từ Thứ Tư ngày 15 tháng 5 đến Thứ Hai ngày 20 tháng 5 để giảm tải từ Máy chủ Lưu trữ, đặc biệt cho các bản cập nhật Kernel và Microcode.

Theo các nhóm này, đây là lần đầu tiên việc giảm tải như vậy được thực hiện thông qua CloudFront và trong trường hợp cụ thể này là hành vi dự kiến .


Mặc dù có vẻ nghi ngờ, các đội đã xác nhận với tôi thông qua IRC rằng đây là hành vi được mong đợi và họ ngạc nhiên khi nhiều người không chú ý đến hành vi này trong quá khứ.

TUYỆT VỜI: Không phải hành vi độc hại, mà thay vào đó là hành vi được mong đợi và được yêu cầu để mọi thứ không quá tải trên các máy chủ lưu trữ. (Đó cũng là lần đầu tiên họ phải làm điều này vì vậy ít nhất không có gì xảy ra cả heh)

Hành vi tiêu chuẩn KHÔNG giảm tải cho Cloudfront nên quay lại ngay bây giờ.


Cảm ơn bạn, đó là tin rất tốt! Vì vậy, tôi đoán rằng vào thứ Hai, ngày 20 tháng 5, các thử nghiệm của tôi đã xảy ra sau khi CloudFront bị tắt và đó là lý do tại sao tôi không còn có thể tái tạo vấn đề (không phải).
Tomasz Zieliński

Debian (trong tất cả các bản phát hành) đã sử dụng CloudFront và CDN nhanh chóng kể từ năm 2016, do đó, Ubuntu làm điều tương tự không có gì mới ở đó ...
grawity

@grawity ngoại trừ Ubuntu dường như chưa bao giờ cần giảm tải điều này. Nhưng bạn không sai, 'không có gì mới' trong sơ đồ lớn nhưng đối với Ubuntu thì chưa được thực hiện nhiều. (Và là một quan sát không điển hình trong Ubuntu.)
Thomas Ward

Đây không phải là hành vi dự kiến. Tôi đã thiết lập squid-deb-proxy trên máy chủ và máy khách, tên máy chủ này không được phép trong danh sách trắng của nó, vì vậy tôi nhận được 403 là kết quả. Đặt câu hỏi trên Community.ubfox.com để có phản ứng chính thức.
N0rbert

@ N0rbert điều này chỉ nên tạm thời; nếu điều này vẫn đang diễn ra thì ai đó không cho chúng tôi biết chi tiết hoặc đã thay đổi hành vi của kho lưu trữ.
Thomas Ward
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.