Apt - d16r8ew072anqo.cloudfront.net:80 के लिए अजीब अनुरोध


17

शनिवार (18 मई) को मैंने अपना एक वीएम (उबंटू 18.04 सर्वर) चलाना शुरू किया।

मेरे आश्चर्य के लिए, वीएम ने लगभग तुरंत कनेक्ट करने का प्रयास किया d16r8ew072anqo.cloudfront.net:80, कुछ ऐसा जो मैंने पहले कभी नहीं देखा है - यह उबंटू की एक बहुत अच्छी "प्राचीन" स्थापना है, जिसमें कोई कस्टम aptरिपॉजिटरी नहीं है, और बस कुछ पैकेज स्थापित हैं। यह पहले से कुछ भी संदिग्ध से जुड़ा नहीं था - ज्यादातर उबंटू और स्नैप डोमेन के लिए। (मैं नेटवर्क ट्रैफिक की निगरानी के लिए लिटिल स्निच का उपयोग करता हूं ताकि मैं वास्तविक समय में कनेक्शन देखूं और उन्हें भी अस्वीकार कर सकूं।)

मैंने कुछ समय बिताने की कोशिश की कि क्या हुआ और मुझे विश्वास है कि मैंने इसे unattended-upgradesसिक्योरिटी पैच स्थापित करने के लिए सीमित कर दिया है । विशेष रूप से, जब मैंने मैन्युअल रूप से intel-microcode:amd64पैकेज को पुन: स्थापित किया था तो मैं CloudFront के लिए अजीब कनेक्शन को पुन: पेश करने में सक्षम था (हालांकि यह सिर्फ एक संयोग हो सकता है)।

फिर, सोमवार को, मैं इस मामले को दस्तावेज बनाना चाहता था यदि ऐसा ही कुछ फिर से होता है, लेकिन मेरे आश्चर्य के लिए मैं अब अजीब कनेक्शन को पुन: पेश नहीं कर सका।

और सोमवार को केवल देखने योग्य अंतर यह था कि sudo apt-get install --reinstall intel-microcode:amd64[1] से आउटपुट में Ign:1लाइन नहीं थी।

मैंने वेब खोजा, जिसमें http://archive.ubuntu.com/ubuntu , grepVM की डिस्क शामिल है, ने misc के DNS रिकॉर्ड्स की जाँच की। ubuntu.comउप डोमेन, wgetसंदिग्ध डोमेन पर पुनर्निर्देशित करने के लिए विभिन्न URL की कोशिश की - लेकिन मुझे CloudFront के अजीब कनेक्शन के बारे में कोई सुराग नहीं मिला।

मेरा प्रश्न है: क्या किसी को पता है कि क्या हुआ था, या कम से कम उनके लॉग में एक ही कनेक्शन देखा गया था?

(वैसे, मैं एक उदाहरण से अवगत हूं, जहां उबंटू टीम ने अपने सर्वर को राहत देने के लिए CloudFront का उपयोग किया है: MD5 मेरे 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

मैंने इस बारे में सिक्योरिटी और आर्काइव टीमों को कुछ अशुभताएं दीं, क्योंकि वे आधिकारिक स्रोत थे कि यह अपेक्षित व्यवहार था या नहीं। निम्नलिखित वे मेरे साथ साझा किए गए का एक सारांश है:

यह देखा गया व्यवहार आर्काइव दर्पण से क्लाउडफ्रंट तक ट्रैफिक लोड को हटा रहा था, और विशेष रूप से कर्नेल और माइक्रोकोड अपडेट के लिए, आर्काइव सर्वर से लोड को कम करने के लिए बुधवार 15 मई और सोमवार 20 मई के बीच किया गया था।

उन टीमों के अनुसार, यह पहली बार है जब इस तरह के उतार-चढ़ाव क्लाउडफ्रंट के माध्यम से किए गए थे, और इस विशेष मामले में अपेक्षित व्यवहार था ।


हालांकि यह संदिग्ध लग रहा है, टीमों ने मेरे साथ आईआरसी के माध्यम से पुष्टि की है कि यह अपेक्षित व्यवहार था, और वे आश्चर्यचकित हैं कि अधिक लोगों ने अतीत में व्यवहार पर ध्यान नहीं दिया था।

ULTIMATELY: दुर्भावनापूर्ण व्यवहार नहीं है, बल्कि इसके बदले में अपेक्षित व्यवहार था, और अभिलेख सर्वर पर चीजों को अधिभार नहीं देने के लिए आवश्यक था। (यह पहली बार भी था जब उन्हें ऐसा करना पड़ा था, इसलिए कम से कम कुछ भी नहीं हुआ था।

क्लाउडफ्रंट के लिए ऑफ-लोडिंग का मानक व्यवहार अब वापस नहीं होना चाहिए।


धन्यवाद, यह बहुत अच्छी खबर है! इसलिए मुझे लगता है कि सोमवार, 20 मई को, क्लाउडफ्रंट के बंद होने के बाद मेरा परीक्षण हुआ और इसीलिए मैं अब (गैर) मुद्दे को पुन: पेश नहीं कर सका।
टॉमाज़ ज़िलिओस्की

2016 के बाद से डेबियन (सभी डिस्ट्रोस के) CloudFront और Fastly CDN का उपयोग कर रहे हैं, इसलिए उबंटू ऐसा ही कर रहा है, वहाँ कुछ भी नया नहीं है ...
user1686

@ सिवाय इसके कि उबंटू को कभी भी इसे उतारने की जरूरत नहीं पड़ी। लेकिन आप गलत नहीं हैं कि चीजों की भव्य योजना में यह 'कुछ भी नया नहीं है' लेकिन उबंटू के लिए बहुत कुछ नहीं किया गया है। (और उबंटू में एक atypical अवलोकन है।)
थॉमस वार्ड

यह अपेक्षित व्यवहार नहीं है। मेरे पास सर्वर और क्लाइंट पर स्क्वीड-डिबेट-प्रॉक्सी सेटअप है, इसके श्वेतसूची में इस होस्टनाम की अनुमति नहीं है, इसलिए मुझे परिणाम के रूप में 403 मिलते हैं। आधिकारिक प्रतिक्रिया प्राप्त करने के लिए community.ubuntu.com पर प्रश्न पूछा गया ।
N0rbert

@ N0rbert यह SHOULD केवल अस्थायी रहा है; यदि यह अभी भी चल रहा है, तो किसी ने हमें विवरण नहीं बताया है या रिपॉजिटरी व्यवहार को बदल दिया है।
थॉमस वार्ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.