नया VPS सर्वर सुरक्षित कैसे करें: 10 मिनट की गाइड

सर्वर की सुरक्षा के शुरुआती 10 मिनट सबसे महत्वपूर्ण होते हैं

एक नया VPS सुरक्षित नहीं होता है। जैसे ही इसे public IP मिलता है, स्कैनर्स इसमें login करने की कोशिश करने लगते हैं। default image उन्हें एक बड़ा लक्ष्य देती है: root अक्सर पहुँच योग्य होता है, passwords की अनुमति होती है, कोई firewall नहीं होती और कुछ भी समय पर patch नहीं किया जाता। अच्छी खबर यह है कि इन सभी कमियों को दूर करने में केवल दस मिनट और कुछ commands का समय लगता है। यह वह runbook है जिसे मैं किसी भी नई चीज़ को डालने से पहले हर नए सर्वर पर चलाता हूँ।

इसे क्रम से पूरा करें, क्योंकि हर चरण पिछले पर आधारित है। हर चरण के लिए अपनी मार्गदर्शिका है, जिसे आप आगे बढ़ते हुए देख सकते हैं; यह पृष्ठ वह तेज़ रास्ता है जो इन सबको एक साथ जोड़ता है।

मिनट 1: सब कुछ अपडेट करें

अपने provider द्वारा दिए गए credentials का उपयोग करके root के रूप में log in करें, और किसी भी अन्य कार्य से पहले system को पूरी तरह से update करें:

apt update && apt upgrade -y

एक unpatched server सबसे आसान target होता है, इसलिए यह सबसे महत्वपूर्ण कदम है। एक बार जब यह प्रक्रिया पूरी हो जाए, तो automatic security updates set up करें ताकि आपको बार-बार manual update करने की आवश्यकता न पड़े।

मिनट 2: sudo के साथ एक सामान्य user बनाएँ

root के रूप में काम करना जारी न रखें। अपने लिए एक user बनाएँ और उसे sudo अधिकार दें:

adduser matt
usermod -aG sudo matt

यहाँ से आप इस user के रूप में login करें और प्रशासनिक कार्यों के लिए sudo का उपयोग करें। हर समय root के रूप में काम करने का अर्थ है कि हर गलती और हर compromise असीमित शक्ति के साथ होता है, जिसे रोकने के लिए ही एक unprivileged user के रूप में काम करना मौजूद है।

Minute 4: SSH keys सेट करें

Passwords का अनुमान लगाया जा सकता है, लेकिन keys का नहीं। अपने laptop पर, यदि आपके पास पहले से key नहीं है, तो एक बनाएँ:

ssh-keygen -t ed25519

फिर public half को सर्वर पर copy करें:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id के लिए नए user पर password login का चालू होना आवश्यक है; यदि यह पहले से बंद है, तो root की ~/.ssh/authorized_keys को /home/matt/.ssh/authorized_keys (जो matt के स्वामित्व में है) में copy करें, या अपनी public key को उस file में manually paste करें।

इस चरण के पीछे का मॉडल, प्रति device एक key, key login को खराब करने वाली permissions, और खोई हुई key को revoke करना, SSH key management basics में कवर किया गया है।

Log out करें और key का उपयोग करके matt के रूप में वापस log in करें, और अगले चरण पर जाने से पहले पुष्टि करें कि यह काम कर रहा है। key के साथ log in करने से पहले SSH को lock करना ही वह तरीका है जिससे लोग खुद को बाहर lock कर लेते हैं। यदि वह login Permission denied (publickey) के साथ वापस आता है, तो password पर वापस जाने के बजाय इसे अभी ठीक करें, क्योंकि वह एक संदेश five different faults को कवर करता है और ssh -v output आपको बताता है कि उनमें से कौन सी समस्या वास्तव में आपके साथ है।

मिनट 6: root login और passwords बंद करें

अब जब आपकी key काम कर रही है, तो उन दो रास्तों को बंद करें जिनका उपयोग स्कैनर्स करते हैं। एक drop-in file का उपयोग करें ताकि package upgrades इसे overwrite न करें। इसका नाम 00- रखें ताकि यह 50-cloud-init.conf से पहले sort हो, जिसके साथ Ubuntu cloud images में PasswordAuthentication yes आता है; sshd सबसे पहले पढ़ी गई value को ही रखता है, इसलिए बाद में sort होने वाली file चुपचाप विफल हो जाएगी:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

इसके बाद SSH को reload करें:

sudo systemctl restart ssh

फिर उन settings की जाँच करें जिनका sshd वास्तव में उपयोग कर रहा है, ताकि कोई विफल drop-in आपको भ्रमित न कर सके:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Passwords बंद होने और root login हट जाने के बाद, आपके सर्वर पर होने वाला निरंतर brute-force traffic सफल नहीं हो सकता। पूर्ण प्रक्रिया, जिसमें एक वैकल्पिक port परिवर्तन भी शामिल है, VPS पर SSH hardening में दी गई है।

मिनट 8: फायरवॉल चालू करें

इनबाउंड आने वाले सभी ट्रैफिक को डिफ़ॉल्ट रूप से अस्वीकार (default-deny) करें, और फिर केवल आवश्यक ट्रैफिक को अनुमति दें। SSH को सक्षम करने से पहले उसे अनुमति दें, अन्यथा आपका कनेक्शन कट जाएगा:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

किसी भी ऐसी सर्विस के लिए allow नियम जोड़ें जिसे आप वास्तव में चला रहे हैं, जैसे कि वेबसाइट के लिए 80/tcp और 443/tcp। यदि इसके बाद कोई नया SSH सत्र कनेक्ट होना बंद कर देता है, तो कुछ भी करने से पहले त्रुटि को पढ़ें, क्योंकि अस्वीकृति का मतलब है कि sshd ने उत्तर दिया और टाइमआउट का मतलब आमतौर पर यह है कि फायरवॉल ने पैकेट को रोक लिया है। जाँचें कि IPv4 और IPv6 दोनों कवर किए गए हैं, क्योंकि जो फायरवॉल केवल IPv4 को फ़िल्टर करता है, वह IPv6 साइड को पूरी तरह खुला छोड़ देता है। पूरी जानकारी VPS पर फायरवॉल 101 में उपलब्ध है। ये ufw कमांड Ubuntu या Debian के लिए हैं; Rocky या AlmaLinux बॉक्स पर डिफ़ॉल्ट-अस्वीकार का लक्ष्य समान है लेकिन टूल firewalld है, इसलिए इसके बजाय इस चरण के firewalld संस्करण का पालन करें।

मिनट 10: Fail2ban के साथ स्कैनर्स की गति धीमी करें

अंत में, उन IP addresses को बाहर निकालने के लिए Fail2ban जोड़ें जो आपके ports पर लगातार हमला करते हैं:

sudo apt install -y fail2ban

Ubuntu 24.04 पर, इसका डिफ़ॉल्ट इंस्टॉलेशन पहले बूट से ही SSH की सुरक्षा करता है। चूंकि keys पहले से ही आवश्यक हैं, इसलिए यह एक अतिरिक्त सुरक्षा उपाय है जो log noise को कम करता है और बार-बार हमला करने वालों को ब्लॉक करता है, न कि यह आपकी मुख्य सुरक्षा प्रणाली है।

आपकी चेकलिस्ट

यह रनबुक है। प्रत्येक कंट्रोल को टिक करने और एक व्यक्तिगत चेकलिस्ट तैयार करने के लिए नीचे दिए गए जनरेटर का उपयोग करें, जिसे आप सर्वर के साथ रख सकते हैं। इसमें प्रत्येक चरण के लिए सटीक कमांड शामिल है:

प्रत्येक नए सर्वर के लिए इस पर काम करें और यह पूरी प्रक्रिया आपकी आदत बन जाएगी। अभी दिए गए दस मिनट आपको उस बहुत खराब दोपहर से बचाते हैं जो सर्वर के हैक (breach) होने के बाद आती है।

एक बार आवश्यक चीजें लागू हो जाने के बाद, Ubuntu पर स्वचालित सुरक्षा अपडेट आपको बार-बार लॉग इन किए बिना सर्वर को अपडेट रखने में मदद करते हैं। इसके बाद आप जो भी सर्विस इंस्टॉल करते हैं, उसे अपनी सुरक्षा जांच की आवश्यकता होती है, और कमजोर बिंदु बदल जाते हैं: self-hosted पासवर्ड वॉल्ट के साथ सर्वर कभी भी plaintext में डेटा नहीं रखता है, इसलिए Vaultwarden के वास्तविक जोखिम केवल एडमिन टोकन और बैकअप फाइल तक सीमित होते हैं।

FAQ

नए VPS पर मुझे सबसे पहले क्या करना चाहिए?

apt update && apt upgrade -y का उपयोग करके सिस्टम को अपडेट करें, फिर sudo के साथ एक सामान्य उपयोगकर्ता बनाएँ और root के रूप में काम करना बंद कर दें। इसके बाद, SSH keys सेट करें, root login और password authentication को अक्षम (disable) करें, एक default-deny firewall सक्षम करें, और Fail2ban इंस्टॉल करें। इस क्रम में काम करने से प्रत्येक चरण सुरक्षित रहता है और आप खुद को सर्वर से बाहर (lock out) नहीं करेंगे।

SSH को सुरक्षित करते समय मैं खुद को बाहर होने से कैसे बचाऊं?

पासवर्ड या root login को अक्षम करने से पहले अपनी SSH key login को सेट करें और उसका परीक्षण करें। यह पुष्टि करने के लिए कि यह काम कर रही है, लॉग आउट करें और फिर key के साथ वापस लॉग इन करें, उसके बाद ही PasswordAuthentication और PermitRootLogin को बंद करें। जब आप firewall सक्षम करें, तो ufw enable चलाने से पहले port 22 को अनुमति दें। यदि आप गलती से बाहर हो जाते हैं, तो आपके प्रदाता का web console आपको बिना SSH के वापस प्रवेश दिला सकता है।

क्या मुझे छोटे सर्वर पर भी इन सबकी वास्तव में आवश्यकता है?

हाँ, क्योंकि स्कैनर्स को इस बात से कोई फर्क नहीं पड़ता कि आपका सर्वर कितना छोटा है। वे हर public IP को एक ही तरीके से लक्षित करते हैं। पूरी प्रक्रिया में लगभग दस मिनट लगते हैं और यह आसान रास्तों को बंद कर देती है: कोई root login नहीं, कोई पासवर्ड अनुमान नहीं, आपकी अनुमति के बिना कुछ भी expose नहीं, और ज्ञात बग्स अपने आप पैच हो जाते हैं।

सबसे महत्वपूर्ण कदम कौन सा है?

केवल key-आधारित SSH का उपयोग करना और root login को अक्षम करना। नए VPS पर अधिकांश हमले root के खिलाफ स्वचालित पासवर्ड अनुमान (automated password guesses) होते हैं, और इन दोनों को बंद करने से उस श्रेणी के सभी हमले असंभव हो जाते हैं। इसके बाद firewall और Fail2ban यह सीमित करते हैं कि क्या expose है और जो कुछ भी बचता है उसकी गति धीमी कर देते हैं।

मैं यह कैसे पुष्टि करूँ कि सर्वर वास्तव में सुरक्षित (locked down) है?

भरोसा करने से पहले तीन चीजों की स्वयं जाँच करें। sudo ss -tlnp चलाएँ और पुष्टि करें कि केवल वही ports public address पर listening हैं जिन्हें आप खोलना चाहते थे, और कोई भी ऐसी 0.0.0.0 या [::] सेवा नहीं है जिसे आप भूल गए हों। sudo ufw status verbose चलाएँ और पुष्टि करें कि default incoming policy deny है और plain तथा (v6) दोनों नियम मौजूद हैं। और हमेशा पहली SSH session बंद करने से पहले दूसरी session खोलें, ताकि SSH configuration में कोई गलती आपको सर्वर से बाहर न कर दे। यदि ये तीनों सही दिखते हैं, तो बुनियादी सुरक्षा लागू हो चुकी है।