सर्वर की बारह जाँचें, जो हफ़्ते में एक बार करने लायक़ हैं

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

नीचे बारह चीज़ें हैं जिन्हें नियमित रूप से जाँचना सार्थक है, कमांड सहित। यह चक्कर पंद्रह मिनट लेता है। क्रम उससे शुरू होता है जिससे भीतर आया जाता है और उस पर ख़त्म होता है जो अपने आप बिगड़ता है।

SSH: पाँच पंक्तियाँ

देखने की चीज़ फ़ाइल नहीं, बल्कि प्रभावी कॉन्फ़िगरेशन है: वह /etc/ssh/sshd_config, पूरी डायरेक्टरी sshd_config.d और संकलन के डिफ़ॉल्ट मानों से मिलकर बनती है।

sudo sshd -T | grep -iE 'permitrootlogin|passwordauthentication|permitemptypasswords|maxauthtries|x11forwarding'

हम जो देखना चाहते हैं: permitrootlogin no, passwordauthentication no, permitemptypasswords no, maxauthtries 3–4 के बीच और x11forwarding no। पहली तीन दरवाज़ा हैं, आख़िरी दो उसके कब्ज़े — प्रति कनेक्शन कोशिशों की सीमा, और ग्राफ़िक्स का अग्रेषण जिसकी सर्वर को कोई ज़रूरत नहीं।

दो चेतावनियाँ, दोनों ख़ुद को बाहर बंद कर लेने का आसान रास्ता। पहली: पासवर्ड से लॉगिन और root लॉगिन तब तक बंद न करें जब तक पुष्टि न हो जाए कि आपकी कुंजी काम करती है — एक अलग सत्र में, मौजूदा सत्र बंद किए बिना। अगर आप यह root के रूप में पासवर्ड से जुड़े हुए पढ़ रहे हैं, तो वही दो पंक्तियाँ आपको ही बाहर बंद कर देंगी।

दूसरी: फ़ाइलों का क्रम। OpenSSH किसी पैरामीटर का वह मान लेता है जो उसे पहले मिले, और sshd_config.d की फ़ाइलें वर्णक्रम में पढ़ी जाती हैं। क्लाउड इमेज वहाँ आम तौर पर 50-cloud-init.conf छोड़ जाती हैं, और अगर आपने अपनी फ़ाइल का नाम 90-hardening.conf जैसा रखा है तो वही भारी पड़ेगी। अपनी सेटिंग्स छोटे नंबर के नीचे रखें — 00- या 10-। और नतीजा फ़ाइल पढ़कर नहीं, sshd -T से जाँचा जाता है।

फ़ायरवॉल: एक जाँच

sudo ufw status verbose

यहाँ याद रखना चाहिए कि यह आउटपुट इरादे दिखाता है, नतीजे नहीं। कोई नियम सूची में हो सकता है और कुछ भी बंद न कर रहा हो: ख़ुद UFW बंद हो, पोर्ट को Docker का प्रकाशित किया कुछ संभाल रहा हो (वह अपने नियम UFW के नीचे iptables में लिखता है), या ट्रैफ़िक सर्वर तक किसी और रास्ते से पहुँच रहा हो। इसलिए नियमों की सूची को उससे मिलाना उपयोगी है जो वास्तव में बाहर की ओर सुन रहा है:

sudo ss -tulpn | grep -v '127.0.0.1\|::1'

fail2ban: दो जाँचें

सेवा का चलना ही काफ़ी नहीं — SSH के लिए काम करता हुआ jail भी चाहिए।

sudo fail2ban-client status
sudo fail2ban-client status sshd

यहाँ सबसे आम मुसीबत है चुप jail। Debian 12 और नए Ubuntu पर /var/log/auth.log शायद हो ही नहीं: rsyslog स्थापित नहीं होता और प्रविष्टियाँ केवल journald में रहती हैं। फ़ैक्ट्री logpath वाला jail तब चल पड़ता है, ख़ुद को सक्रिय बताता है और कभी किसी को ब्लॉक नहीं करता। इलाज उसे systemd के जर्नल की ओर मोड़ना है:

printf '[sshd]\nenabled = true\nbackend = systemd\n' | sudo tee /etc/fail2ban/jail.d/sshd-systemd.local
sudo systemctl restart fail2ban

वह संकेत जिससे यह कॉन्फ़िगरेशन खंगाले बिना पकड़ा जाता है: fail2ban-client status sshd में «Currently failed» और «Total failed» शून्य पर खड़े रहते हैं, जबकि जर्नल में असफल लॉगिन साफ़ मौजूद होते हैं।

अपडेट: तीन जाँचें

अलग-अलग: कुल कितने पैकेज इंतज़ार में हैं, उनमें से कितने सुरक्षा से जुड़े हैं, और क्या सिस्टम कर्नेल अपडेट के बाद रीस्टार्ट माँग रहा है।

sudo apt update
apt list --upgradable 2>/dev/null | grep -c -- '-security'
ls /var/run/reboot-required 2>/dev/null && echo 'रीस्टार्ट चाहिए'

तीसरी जाँच यह है कि स्वचालित सुरक्षा अपडेट चालू हैं या नहीं, ताकि पहली दो हर महीने की रस्म न बन जाएँ:

systemctl status unattended-upgrades --no-pager
cat /etc/apt/apt.conf.d/20auto-upgrades

उस फ़ाइल की दोनों पंक्तियों में 1 होना चाहिए। अगर पैकेज नहीं है: sudo apt install unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades।

प्रमाणपत्र: एक जाँच

Let's Encrypt का प्रमाणपत्र नब्बे दिन जीता है, और नवीनीकरण आम तौर पर अपने आप चलता है — ठीक उस दिन तक जब वह रुक जाता है। देखने की चीज़ रजिस्ट्रार का पैनल नहीं, बल्कि वह है जो सर्वर वास्तव में दे रहा है:

echo | openssl s_client -connect localhost:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
sudo certbot renew --dry-run

पहली कमांड उस प्रमाणपत्र की समाप्ति तिथि देती है जो उस नाम के लिए दिया जाता है; दूसरी असली समय-सीमा का इंतज़ार किए बिना पुष्टि करती है कि नवीनीकरण पार हो जाएगा। सर्वर जिन सभी नामों को संभालता है, उन सब पर नज़र डालना उपयोगी है, केवल मुख्य डोमेन पर नहीं: आम तौर पर वही उपडोमेन भूला जाता है जो बाद में जोड़ा गया हो।

डिस्क: एक जाँच

df -h
df -i

दो कमांड, क्योंकि जगह और फ़ाइलों की प्रविष्टियाँ एक-दूसरे से स्वतंत्र रूप से ख़त्म होती हैं। ज़्यादातर सर्वरों पर दूसरी पहले छत से टकराती है — PHP सत्रों या ऐप्लिकेशन कैश में लाखों छोटी फ़ाइलें IUse% को 100 पर पहुँचा देती हैं जबकि गीगाबाइट ख़ाली पड़े होते हैं। दोनों मामलों पर हमारा अलग लेख है।

इस सूची में गड़बड़ क्या है

सूची सही है, मगर उसमें एक गुण है: वह माँगती है कि कोई उसे याद रखे। हफ़्ते में पंद्रह मिनट ज़्यादा नहीं, जब तक सर्वर एक है और जब तक कोई वजह है। दो शांत महीनों के बाद चक्कर छूट जाता है, और jail के रुक जाने का पता किसी और के लॉग से चलता है।

इसीलिए हमने ठीक यही बारह जाँचें एक अलग मुफ़्त पैनल में इकट्ठा कीं — Arcivéo FREE। यह एक ही कमांड से स्थापित होता है, आपके अपने सर्वर पर चलता है, हमें कुछ नहीं भेजता और पंजीकरण नहीं माँगता। एक संग्राहक cron से हर पाँच मिनट पर चलता है और वही सब स्थानीय डेटाबेस में लिखता है: SSH लॉगिन और अस्वीकृत कनेक्शन, UFW और fail2ban की स्थिति, लंबित सुरक्षा अपडेट, प्रमाणपत्रों की समय-सीमाएँ, डिस्क की जगह। इतिहास सात दिन का है, इंटरफ़ेस 34 भाषाओं में। क़ीमत शून्य है, काम के सर्वर पर भी: लाइसेंस पैनल को अपनी मशीनों पर, कंपनी की मशीनों समेत, स्थापित करने की अनुमति देता है, और उसे आगे बेचने या दूसरों के सर्वरों के लिए सेवा के रूप में चलाने की अनुमति नहीं देता।

मुफ़्त संस्करण का ढेर मामूली है: यह UFW और fail2ban को स्थापित और चालू करता है, और उसके बाद स्थिति दिखाता है। ModSecurity, Suricata, AIDE और बाक़ी मॉड्यूल उसमें नहीं हैं, वे भुगतान वाले से संबंध रखते हैं। लेकिन साप्ताहिक चक्कर को दिमाग़ में रखना बंद करने के लिए इतना ही काफ़ी है। वही डेटा पूरे पैनल पर कैसा दिखता है — नीचे दिए डेमो पेजों पर।