VPN APT स्रोत: यह क्या देता है और इसे कैसे सीमित करें

VPN क्लाइंट डाउनलोड करना एक बार का निर्णय है; उसका APT रिपॉज़िटरी जोड़ना नहीं। दूसरा पैकेज प्रबंधक को बताता है कि भविष्य का सॉफ़्टवेयर कहाँ से आ सकता है, और यह डाउनलोड नहीं बल्कि अधिकार का स्थायी हस्तांतरण है। जब विक्रेता रिपॉज़िटरी ठीक से बनाए रखता है तब यह सही व्यवस्था हो सकती है। फिर भी यह सचेत निर्णय के योग्य है, और अधिकांश इंस्टॉल गाइड इसे छोड़ देते हैं।

हस्ताक्षर एक संग्रह को प्रमाणित करता है, उसके कोड को नहीं

APT हस्ताक्षरित रिपॉज़िटरी मेटाडेटा की जाँच करता है और फिर जो पैकेज वह लाता है उनके लिए उसी मेटाडेटा के भीतर के चेकसम पर भरोसा करता है। इससे यह सिद्ध होता है कि संग्रह वही है जो कुंजी धारक ने प्रकाशित किया, और उसके भीतर के कोड के बारे में कुछ नहीं। सही ढंग से हस्ताक्षरित पैकेज में भी असुरक्षित मेंटेनर स्क्रिप्ट हो सकती हैं, और पैकेज इंस्टॉल होते समय वे स्क्रिप्ट root के रूप में चलती हैं। apt-secure मार्गदर्शिका संग्रह प्रमाणीकरण और सॉफ़्टवेयर की समीक्षा के बीच ठीक यही रेखा खींचती है।

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

इसीलिए कुंजी की पहचान रिपॉज़िटरी URL जितने ही ध्यान के योग्य है। किसी पुराने फ़ोरम उत्तर के पते से ली गई कुंजी प्रकाशक के बारे में कुछ सिद्ध नहीं करती, जबकि HTTPS उस तक परिवहन की रक्षा करता है जिसने फ़ोन का उत्तर दिया। परिवहन सुरक्षा और प्रकाशक पहचान अलग प्रश्न हैं, और केवल पहला ही प्रमाणपत्र से हल होता है।

कुंजी को स्रोत तक सीमित करें, सिस्टम तक नहीं

आधुनिक APT स्रोत-विशिष्ट Signed-By संदर्भ स्वीकार करता है। ऑपरेटर द्वारा प्रबंधित कुंजी /etc/apt/keyrings/ के अंतर्गत रह सकती है, और स्रोत प्रविष्टि उस कुंजी का नाम देती है जिसे उस संग्रह को प्रमाणित करने की अनुमति है। यह उसी कुंजी को वैश्विक विश्वसनीय समुच्चय में डालने से अधिक संकीर्ण है, जहाँ वह ऐसे स्रोतों की गारंटी दे सकती है जिन्हें आप कभी अनुमति देना नहीं चाहते थे। विभिन्न पीढ़ियों की मार्गदर्शिकाओं के टुकड़े मिलाने के बजाय इंस्टॉल किए गए APT संस्करण और विक्रेता के वर्तमान निर्देशों का पालन करें।

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

सत्यापन बंद करके या किसी अज्ञात संग्रह को विश्वसनीय चिह्नित करके हस्ताक्षर विफलता कभी न ठीक करें। यह दृश्य त्रुटि को अदृश्य त्रुटि से बदल देता है, और अदृश्य तब तक रहती है जब तक कोई स्रोत सूची का ऑडिट न करे। यदि कुंजी मेल नहीं खाती, तो सही समाधान सही कुंजी ढूँढ़ना है, जाँच हटाना नहीं।

रिपॉज़िटरी का विवरण और कुंजी की पहचान प्रोजेक्ट या किसी प्रबंधित व्यवस्थापक से प्राप्त करें। ब्लॉग पोस्ट से कॉपी की गई कुंजी लेखकत्व के बारे में दावा है, उसका प्रमाण नहीं। जब विक्रेता रोटेशन चैनल प्रकाशित करे, तो उसे कुंजी के साथ ही दर्ज करें, क्योंकि वही चैनल अगला रोटेशन संभव बनाता है।

स्रोत पिनिंग पैकेज अनुमति-सूची नहीं है

कुंजी को एक स्रोत तक सीमित करना यह सीमित करता है कि वह किस संग्रह को प्रमाणित कर सकती है, यह नहीं कि वह संग्रह कौन से पैकेज प्रकाशित कर सकता है। रिपॉज़िटरी आपके चाहे VPN क्लाइंट से कहीं अधिक भेज सकता है, और APT का उम्मीदवार चयन और प्राथमिकताएँ तय करती हैं कि कौन सा योग्य संस्करण जीतेगा। पुष्टि करने से पहले प्रस्तावित लेन-देन की समीक्षा करें, निर्भरता सूची सहित, क्योंकि निर्भरताएँ उसी संग्रह से आती हैं। कुंजी का दायरा ’केवल यह पैकेज’ नहीं कह सकता।

यदि अधिक मजबूत नियंत्रण चाहिए, तो उसे पैकेज नामों या संस्करणों पर नीति के रूप में व्यक्त करें और उस नीति को कॉन्फ़िगरेशन प्रबंधन के अधीन रखें। लेन-देन पढ़ने में एक मिनट लगता है; छह महीने बाद अप्रत्याशित पैकेज खोजने में एक समीक्षा लगती है।

अप्रत्याशित पैकेज आगे बढ़ने का नहीं, रुकने का क्षण हैं, और संग्रह के स्वामी से प्रश्न यह है कि वे क्यों आवश्यक हैं। एक क्लाइंट के आसपास दर्जन भर पैकेज प्रकाशित करना डेस्कटॉप सूट भेजने वाले विक्रेता के लिए सामान्य है। यह इंस्टॉल गाइड के संकेत से बड़ी सतह भी है, और यही भाग दर्ज करने योग्य है। दोनों में से कोई परिणाम हस्ताक्षर पर अविश्वास का कारण नहीं है; दोनों आपने क्या स्वीकार किया यह लिखने का कारण हैं।

अधिकार और उसे हटाने का तरीका दर्ज करें

संग्रह का स्वामी, समर्थित ऑपरेटिंग सिस्टम संस्करण, कुंजी रोटेशन चैनल और हटाने की प्रक्रिया लिखें। ये चार तथ्य वही हैं जिनकी उत्तराधिकारी को आवश्यकता होती है जब क्लाइंट सेवानिवृत्त होता है या विक्रेता अपनी कुंजी घुमाता है। इनके बिना अगला व्यक्ति बिना किसी कहानी के एक स्रोत पंक्ति और एक कुंजी फ़ाइल विरासत में पाता है।

हटाना ही वह चरण है जो छूट जाता है, इसलिए इसे इंस्टॉल के समय लिखें। स्रोत प्रविष्टि और उसकी समर्पित कुंजी एक साथ मिटाएँ, और फ़ाइल हटाने से पहले जाँचें कि उस कुंजी का संदर्भ कहीं और है या नहीं। उस जाँच के बिना मिटाई गई साझा कुंजी सफ़ाई को असंबंधित रुकावट में बदल देती है, जो नियमित बदलाव के लिए सबसे बुरा परिणाम है। फिर पुष्टि करें कि प्रविष्टि जाने के बाद भी सामान्य अपडेट हल होते हैं।

रिपॉज़िटरी हटाने के बाद एक बात बचती है: उससे पहले से इंस्टॉल कोई भी पैकेज तब तक चलता रहता है जब तक कोई उसे बदल न दे। ईमानदार प्रश्न यह है कि आपने कौन सा अधिकार जोड़ा, और उसकी भूमिका कितनी संकीर्णता से व्यक्त की गई थी।