Ubuntu 24.04 में unattended-upgrades क्या डिफ़ॉल्ट है?

स्वचालित सुरक्षा अपडेट सेट करना क्यों आवश्यक है

जो सर्वर पैच नहीं किया गया है, वह इंटरनेट पर सबसे आसान लक्ष्य है। छोटे सर्वरों के साथ होने वाली अधिकांश सुरक्षा सेंधमारी (breaches) बहुत जटिल नहीं होतीं; वे किसी पुराने पैकेज में मौजूद उस ज्ञात बग के कारण होती हैं जिसे मालिक ने कभी अपडेट नहीं किया। Ubuntu एक ऐसा टूल प्रदान करता है जो इस कमी को स्वयं पूरा करता है: unattended-upgrades सुरक्षा अपडेट को स्वचालित रूप से, एक निर्धारित समय पर, आपके लॉग इन किए बिना ही इंस्टॉल कर देता है। यह VPS पर उपलब्ध सबसे सस्ता सुरक्षा उपाय है, और Ubuntu पर इसे सेट करने में केवल कुछ मिनट लगते हैं।

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

चरण 1: इसे इंस्टॉल और सक्षम करें

Ubuntu 24.04 पर यह पैकेज अक्सर मौजूद होता है लेकिन हमेशा सक्षम नहीं होता। इसे इंस्टॉल करें और चालू करें:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

dpkg-reconfigure प्रॉम्प्ट एक हाँ या ना वाला प्रश्न पूछता है, कि क्या स्थिर अपडेट को स्वचालित रूप से डाउनलोड और इंस्टॉल करना है। हाँ (yes) चुनें। यह उस फ़ाइल को लिखता है जो दैनिक कार्य को चालू करती है:

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

पहली पंक्ति पैकेज सूची को दैनिक रूप से रिफ्रेश करती है; दूसरी पंक्ति unattended upgrade को दैनिक रूप से चलाती है। दोनों को 1 पर सेट करने का अर्थ है कि मशीन हर दिन, एक systemd टाइमर पर, बिना किसी अतिरिक्त हस्तक्षेप के सुरक्षा अपडेट की जाँच करती है और उन्हें लागू करती है।

चरण 2: तय करें कि स्वचालित रूप से क्या लागू किया जाए

यह नीति /etc/apt/apt.conf.d/50unattended-upgrades में स्थित है। इसे खोलें और शीर्ष के पास Allowed-Origins ब्लॉक को देखें:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

-security पंक्तियाँ महत्वपूर्ण हैं, और वे डिफ़ॉल्ट रूप से सक्षम हैं। यह रूढ़िवादी नीति है: सुरक्षा अपडेट अंदर, सामान्य फीचर अपडेट आपके लिए छोड़ दिए गए हैं ताकि आप अपनी पसंद के अनुसार उन्हें मैन्युअल रूप से लागू कर सकें। आप सभी अपडेट को स्वचालित रूप से लागू करने के लिए "${distro_id}:${distro_codename}-updates" ओरिजिन लाइन जोड़ सकते हैं, लेकिन ऐसे सर्वर के लिए जो आपकी महत्वपूर्ण सेवाओं को होस्ट करता है, केवल सुरक्षा पैच को स्वचालित रूप से लेना अधिक सुरक्षित डिफ़ॉल्ट है। इसे वैसा ही रहने दें जैसा यह शिप किया गया है, जब तक कि आपके पास इसे न बदलने का कोई विशेष कारण न हो।

चरण 3: रीबूट को संभालना

कुछ अपडेट, जैसे कि कर्नल या कोर लाइब्रेरी, रीबूट के बाद ही पूरी तरह प्रभावी होते हैं। unattended-upgrades आपके सर्वर को तब तक रीबूट नहीं करेगा जब तक आप उसे ऐसा करने के लिए नहीं कहते, जिसका अर्थ है कि एक पैच किया गया कर्नल तब तक अप्रयुक्त रह सकता है जब तक आप स्वयं रीबूट न करें। तय करें कि आप इसे कैसे संभालना चाहते हैं, और इसे 50unattended-upgrades में स्पष्ट रूप से सेट करें:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

यह सर्वर को सुबह चार बजे रीबूट करता है, लेकिन केवल तभी जब किसी अपडेट के लिए इसकी आवश्यकता हो। बिना फेलओवर क्लस्टर वाले एक अकेले VPS पर, सुबह-सुबह एक संक्षिप्त रीबूट आमतौर पर कर्नल फिक्स के साथ अपडेट रहने के लिए सही समझौता है। यदि आपका सर्वर ऐसी कोई सेवा चलाता है जिसे कभी भी अप्रत्याशित रूप से रीस्टार्ट नहीं होना चाहिए, तो रीबूट को बंद रखें और /var/run/reboot-required की जाँच करने के बाद स्वयं रीबूट करने की आदत डालें।

चरण 4: पुष्टि करें कि यह काम कर रहा है

यह जानने के लिए एक दिन का इंतजार न करें कि क्या कार्य चल रहा है। एक ड्राई रन चलाएँ जो बिना कुछ बदले यह दिखाए कि वास्तव में क्या लागू किया जाएगा:

sudo unattended-upgrade --dry-run --debug

आउटपुट उन पैकेजों को सूचीबद्ध करता है जिन पर यह विचार करता है और वे किन ओरिजिन से आते हैं, ताकि आप नीति को क्रियान्वित होते देख सकें। वास्तविक कार्य के कम से कम एक बार चलने के बाद, इसका रिकॉर्ड यहाँ होता है:

cat /var/log/unattended-upgrades/unattended-upgrades.log

वह लॉग इस प्रश्न का उत्तर है कि "क्या मेरा सर्वर वास्तव में खुद को पैच कर रहा है।" यदि यह दिखाता है कि सुरक्षा पैकेज एक निर्धारित समय पर इंस्टॉल हो रहे हैं, तो कार्य काम कर रहा है।

यह कहाँ फिट बैठता है

स्वचालित अपडेट एक सुरक्षित सर्वर की एक परत है, न कि पूरी सुरक्षा। वे ज्ञात बग्स को बने रहने से रोकते हैं, लेकिन वे इस बारे में कुछ नहीं करते कि कौन लॉग इन कर सकता है या क्या एक्सपोज़्ड है। इन्हें SSH hardening के साथ जोड़ें ताकि फ्रंट डोर को ब्रूट-फोर्स न किया जा सके, एक डिफ़ॉल्ट-डिनाई UFW firewall का उपयोग करें ताकि केवल वही पहुँच योग्य हो जिसे आप चुनते हैं, और unprivileged service users का उपयोग करें ताकि एक समझौता किया गया ऐप पूरे बॉक्स को न ले सके। आपके द्वारा होस्ट किए गए ऐप्स इन सबके ऊपर अपने स्वयं के सीक्रेट्स रखते हैं, इसलिए यदि यह बॉक्स एक self-hosted पासवर्ड वॉल्ट चलाता है, तो एक Vaultwarden hardening pass एडमिन टोकन और बैकअप फ़ाइल को कवर करता है जिसे apt पैचिंग की कोई भी मात्रा सुरक्षित नहीं कर पाएगी। पैचिंग उन छेदों को बंद करती है जिनके बारे में आप जानते हैं; अन्य परतें उन नुकसानों को सीमित करती हैं जिनके बारे में आप नहीं जानते।

FAQ

क्या unattended-upgrades हर अपडेट को लागू करता है या केवल सुरक्षा अपडेट को?

डिफ़ॉल्ट रूप से, केवल सुरक्षा अपडेट। /etc/apt/apt.conf.d/50unattended-upgrades में Allowed-Origins ब्लॉक -security ओरिजिन को सक्षम करता है और सामान्य फीचर अपडेट को आपके द्वारा मैन्युअल रूप से लागू करने के लिए छोड़ देता है। यह जानबूझकर किया गया है: सुरक्षा पैच कम जोखिम वाले होते हैं और स्वचालित रूप से लेने योग्य होते हैं, जबकि फीचर अपग्रेड व्यवहार बदल सकते हैं, इसलिए अधिकांश सर्वरों को रूढ़िवादी डिफ़ॉल्ट बनाए रखना चाहिए।

क्या स्वचालित अपडेट मेरे सर्वर को रीबूट करेंगे?

केवल तभी जब आप उन्हें ऐसा करने के लिए कहेंगे। कॉन्फ़िगरेशन में Unattended-Upgrade::Automatic-Reboot "true" और एक Automatic-Reboot-Time सेट करें, और सर्वर उस समय रीबूट हो जाएगा जब किसी अपडेट के लिए इसकी आवश्यकता होगी, उदाहरण के लिए कर्नल पैच के बाद। यदि बंद रखा जाए, तो एक पैच किया गया कर्नल तब तक प्रतीक्षा करता है जब तक आप स्वयं रीबूट न करें; यह जानने के लिए कि कब कोई पैच लंबित है, /var/run/reboot-required की जाँच करें।

मैं यह कैसे जाँचूँ कि स्वचालित अपडेट वास्तव में चल रहे हैं?

अभी क्या लागू किया जाएगा यह देखने के लिए sudo unattended-upgrade --dry-run --debug चलाएँ, बिना कुछ बदले, और पिछले रन के रिकॉर्ड के लिए /var/log/unattended-upgrades/unattended-upgrades.log पढ़ें; प्रत्येक स्वचालित इंस्टॉलेशन /var/log/apt/history.log में भी दर्ज होता है। यदि लॉग दैनिक समय पर सुरक्षा पैकेज इंस्टॉल होना दिखाता है, तो टाइमर काम कर रहा है। यदि ड्राई रन No packages found that can be upgraded unattended प्रिंट करता है, तो या तो सब कुछ पहले से ही अपडेट है या आपके द्वारा अनुमत ओरिजिन सुरक्षा रिपॉजिटरी से मेल खाने के लिए बहुत सीमित हैं।

क्या unattended-upgrades मेरे सर्वर को सुरक्षित रखने के लिए पर्याप्त है?

नहीं, लेकिन यह एक आवश्यक परत है। यह ज्ञात कमजोरियों को बिना पैच किए रहने से रोकता है, जो सेंधमारी के सबसे सामान्य प्रकार को रोकता है, लेकिन यह एक्सेस या एक्सपोज़र को नियंत्रित नहीं करता है। इसे SSH hardening, एक डिफ़ॉल्ट-डिनाई फ़ायरवॉल, और least-privilege सर्विस उपयोगकर्ताओं के साथ जोड़ें ताकि एक ऐसा सर्वर मिले जिसे तोड़ना वास्तव में कठिन हो।