नए VPS पर Lynis का पहला रन आमतौर पर 60 के आसपास कुछ देता है और सुझावों की लंबी सूची, जिसमें साफ़ नहीं होता कि पहले किसे पकड़ें। अच्छी ख़बर: 80 से 85 एक शाम का काम है, और ज़्यादातर कदम दिखावटी नहीं, सचमुच करने लायक हैं। बुरी ख़बर: आख़िरी पंद्रह अंक किराए की वर्चुअल मशीन पर पहुँच से बाहर हैं, और उनके पीछे भागना ग़लती है।

index क्या दिखाता है और क्या नहीं

hardening index पास हुए परीक्षणों का कुल के प्रति अनुपात है, भार के साथ — न कि सुरक्षा का प्रतिशत। Lynis लगभग तीन सौ परीक्षण चलाता है और दो अलग सूचियाँ देता है: warnings, जो असली समस्याओं जैसी दिखती हैं, और suggestions, जो बेहतर किया जा सकता है। हमेशा चेतावनियों से शुरू करें; वे आमतौर पर मुट्ठी भर ही होती हैं।

सौ अंक होते ही नहीं: कुछ सुझावों के लिए सिस्टम लगाते समय लिए गए निर्णय चाहिए (/home, /tmp और /var के लिए अलग विभाजन), कुछ के लिए बूटलोडर तक पहुँच चाहिए जो VPS पर नहीं है, और कुछ आपस में टकराते हैं। और अपने index की दूसरों से तुलना करना बेकार है: Lynis उसके लिए अंक काटता है जो मशीन पर चल रहा है। हर चलती सेवा एक और खुला पोर्ट है, उसका अपना कॉन्फ़िग और दर्जन भर नए सुझाव, इसीलिए ऊँचे आँकड़े वहाँ ज़्यादा मिलते हैं जहाँ SSH के सिवा कुछ चलता ही नहीं। साइट, डेटाबेस और मेल वाले काम करते सर्वर के लिए 85 अच्छा नतीजा है।

इसे root के रूप में चलाएँ

sudo lynis audit system

sudo के बिना Lynis हर वह परीक्षण छोड़ देता है जिसे सिस्टम फ़ाइलें चाहिए, और कम index दिखाता है — इसलिए नहीं कि सर्वर बुरा है, बल्कि इसलिए कि जाँचें दिखी ही नहीं। रिपोर्ट /var/log/lynis-report.dat में लिखी जाती है, पढ़ने लायक लॉग /var/log/lynis.log में।

आउटपुट की हर पंक्ति परीक्षण के पहचानकर्ता से शुरू होती है, जैसे SSH-7408 या KRNL-6000। इसी पहचानकर्ता से व्याख्या भी मिलती है और परीक्षण बंद करने का तरीका भी — इसका रूप याद रखें, नीचे सब कुछ इसी के इर्द-गिर्द है।

असल में संख्या क्या बढ़ाता है

SSH (SSH-7408)। सबसे भारी हिस्सा: एक ही परीक्षण एक साथ दर्जन भर पैरामीटर जाँचता है। पूरी sshd_config न बदलें; अलग फ़ाइल डालें ताकि पैकेज अपडेट आपका काम मिटा न सके:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

सेवा दोबारा लोड करने से पहले sshd -t अनिवार्य है: सत्र चालू रहते कॉन्फ़िग में की गई ग़लती आपको बाहर छोड़ देगी। और PasswordAuthentication no लगाने से पहले पक्का कर लें कि कुंजी वाकई काम करती है — दूसरे खुले टर्मिनल से।

कर्नेल पैरामीटर (KRNL-6000)। परीक्षण दो दर्जन sysctl क़ीमतें जाँचता है। उनके लिए फ़ाइल:

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

ग़ैरमौजूद औज़ार। सुझावों का अच्छा-ख़ासा हिस्सा बस इतना है कि «जो नहीं है उसे लगाओ»: auditd (सिस्टम घटनाओं का लेखा), aide (फ़ाइलों की अखंडता), debsums (पैकेजों की अखंडता), unattended-upgrades (स्वचालित सुरक्षा अपडेट), sysstat और acct (प्रक्रियाओं का हिसाब), मैलवेयर स्कैनर। इनमें से हर एक एक-दो सुझाव बंद करता है, पर इन्हें अंकों के लिए न लगाएँ: इनके बिना घटना के बाद आप कुछ भी दोबारा नहीं जोड़ पाएँगे।

छोटी चीज़ें जिनका मेहनत-से-फ़ायदा अनुपात अच्छा है। /etc/login.defs में umask 027; उसी फ़ाइल में पासवर्ड की उम्र; /etc/issue और /etc/issue.net के बैनर; कंपाइलर सिर्फ़ root के लिए पढ़ने योग्य (chmod 700 /usr/bin/gcc)। बैनरों के बारे में ईमानदारी से: वे सुरक्षा के लिए कुछ नहीं करते, वे क़ानूनी औपचारिकता हैं — पर अंक ज़रूर देते हैं।

login.defs में एक जाल

sed से पंक्ति बदलकर umask संपादित करने पर अक्सर फ़ाइल में एक साथ कई UMASK पंक्तियाँ रह जाती हैं। तब Lynis क़ीमत गिनता ही नहीं, और परीक्षण AUTH-9328 लाल बना रहता है, जबकि सेटिंग की हुई दिखती है। संपादन के बाद जाँचें:

grep -c '^UMASK' /etc/login.defs

ठीक एक होनी चाहिए। यही बात उस फ़ाइल के हर दूसरे पैरामीटर पर लागू होती है।

झूठे नतीजे और उन्हें सही तरीक़े से चुप कराना

कुछ चेतावनियाँ आपके सर्वर पर लागू ही नहीं होतीं। जीता-जागता उदाहरण: एक बड़े प्रदाता के VPS पर परीक्षण PKGS-7388 बताता है कि सुरक्षा रिपॉज़िटरी नहीं मिली — सिर्फ़ इसलिए कि रिपॉज़िटरी deb822 प्रारूप में मिरर फ़ाइल के संदर्भ के साथ वर्णित हैं, और Lynis जानी-पहचानी पंक्ति ढूँढ़ रहा है। सुरक्षा अपडेट बिल्कुल ठीक आते हैं।

इसे रिपोर्ट से पंक्तियाँ मिटाकर नहीं, प्रोफ़ाइल से चुप कराएँ। प्रोफ़ाइल फ़ाइलों का विस्तार .prf है (.prof नहीं — यहाँ आधा घंटा गँवाना आसान है), और आपके अपने नियम /etc/lynis/custom.prf में जाते हैं:

skip-test=PKGS-7388
skip-test=KRNL-5788

एक नियम: हर पंक्ति के साथ टिप्पणी चाहिए कि परीक्षण क्यों छोड़ा गया। छह महीने बाद आपको याद नहीं रहेगा कि वह इसलिए बंद था कि लागू नहीं होता या इसलिए कि ठीक करना बहुत झंझट था — और इन दोनों का फ़र्क़ ही पूरी बात है।

क्या नहीं करना चाहिए

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

इसीलिए Lynis को एक बार नहीं, समयसारणी पर चलाना और रिपोर्टें रखना समझदारी है, ताकि तुलना के लिए कुछ हो। एक पन्ने पर इकट्ठा यह कैसा लगता है, नीचे डेमो दिखाता है: index, परीक्षण पहचानकर्ताओं के साथ चेतावनियों की सूची, और पिछले रन से क्या बदला।