Language: hi

शुरुआत से VPS सुरक्षा: SSH कुंजियाँ, फ़ायरवॉल और Fail2ban

Ubuntu इंस्टॉल होने के तुरंत बाद नए VPS को सुरक्षित नहीं मानना चाहिए। पहुँच कॉन्फ़िगर करने से पहले ही सर्वर स्कैनर को दिखाई देता है: वे SSH पासवर्ड आज़माते हैं, खुले हुए कंट्रोल पैनल खोजते हैं और सामान्य कमज़ोरियाँ जाँचते हैं। इस गाइड में हम VPS को शुरुआत से सुरक्षित करने के मूल चरण देखेंगे: अलग उपयोगकर्ता बनाना, SSH कुंजी प्रमाणीकरण कॉन्फ़िगर करना, UFW से नेटवर्क पोर्ट सीमित करना और Fail2ban जोड़ना। sudo विशेषाधिकार वाले उपयोगकर्ता द्वारा कमांड चलाने पर सभी चरण Ubuntu 22.04 और 24.04 में काम करते हैं।

शुरू करने से पहले: पोर्ट की सूची बनाएँ

पोर्ट “सिर्फ़ एहतियात के लिए” न खोलें। एक सामान्य वेब सर्वर को आम तौर पर इनकी आवश्यकता होती है:

• 22/tcp — SSH; आदर्श रूप से इसे IP से सीमित करें या केवल अतिरिक्त उपाय के रूप में किसी दूसरे पोर्ट पर ले जाएँ;
• 80/tcp — HTTP; HTTPS पर रीडायरेक्ट करने और प्रमाणपत्र सत्यापित करने के लिए आम तौर पर आवश्यक;
• 443/tcp — HTTPS।

यदि Nginx या Caddy सामने चल रहा है, तो 3000, 8080 या 9000 जैसे एप्लिकेशन पोर्ट इंटरनेट से सीधे उपलब्ध नहीं होने चाहिए। एप्लिकेशन को 127.0.0.1 पर बाँधें या उसके पोर्ट को केवल आंतरिक नेटवर्क पर अनुमति दें। पहले पता करें कि सर्वर पर क्या सुन रहा है:

sudo ss -tulpn

Docker इंस्टॉल करने के बाद उसके iptables नियमों को अलग से जाँचें: -p 3000:3000 प्रकाशित करने से अपेक्षित सेटअप के बाहर भी पोर्ट खुल सकता है। सार्वजनिक सेवा के लिए HTTPS प्रॉक्सी का उपयोग करना और आंतरिक पोर्ट छिपाकर रखना अधिक सुरक्षित है।

चरण 1. सिस्टम अपडेट करें और प्रशासक बनाएँ

दिए गए क्रेडेंशियल से VPS से कनेक्ट करें और अपडेट इंस्टॉल करें:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

अपना व्यक्तिगत उपयोगकर्ता बनाएँ। alex की जगह अपना नाम लिखें:

sudo adduser alex
sudo usermod -aG sudo alex

अलग टर्मिनल विंडो में नए खाते का परीक्षण करने से पहले मूल पहुँच न हटाएँ। यह महत्वपूर्ण नियम है: वर्तमान सत्र खुला होने पर SSH की गलती ठीक करना आसान होता है।

चरण 2. SSH कुंजी बनाएँ और सर्वर पर इंस्टॉल करें

अपने Linux, macOS या Windows PowerShell कंप्यूटर पर चलाएँ:

ssh-keygen -t ed25519 -C "alex@my-computer"

कुंजी को डिफ़ॉल्ट फ़ाइल में सहेजने के लिए Enter दबाएँ और फिर पासफ़्रेज़ सेट करें। निजी कुंजी कभी चैट में न भेजें, उसे रिपॉज़िटरी में न रखें और VPS पर कॉपी न करें। केवल .pub एक्सटेंशन वाली फ़ाइल सर्वर पर भेजी जानी चाहिए:

ssh-copy-id alex@SERVER_IP

यदि ssh-copy-id उपलब्ध नहीं है, तो PowerShell में Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub से सार्वजनिक कुंजी दिखाएँ और फिर उसे सर्वर पर जोड़ें:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

कुंजी को एक ही पंक्ति में चिपकाएँ और पासवर्ड बंद करने से पहले लॉगिन का परीक्षण करें:

ssh alex@SERVER_IP
sudo whoami

अंतिम कमांड का अपेक्षित परिणाम root है। यदि SSH क्लाइंट को कुंजी नहीं मिलती, तो उसे स्पष्ट रूप से बताएँ: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP।

चरण 3. root लॉगिन और पासवर्ड प्रमाणीकरण बंद करें

SSH कॉन्फ़िगरेशन का बैकअप लें:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

सुनिश्चित करें कि फ़ाइल में ये पैरामीटर मौजूद हैं:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

Ubuntu में सेटिंग्स /etc/ssh/sshd_config.d/*.conf में भी हो सकती हैं, इसलिए प्रभावी कॉन्फ़िगरेशन जाँचें:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

यदि sshd -t कोई त्रुटि बताए, तो सिंटैक्स ठीक करने तक सेवा रीस्टार्ट न करें। जाँच सफल होने के बाद सेटिंग लागू करें:

sudo systemctl reload ssh

पुराना SSH कनेक्शन खुला रखें और नई विंडो में कुंजी-आधारित लॉगिन जाँचें। सत्यापित कुंजी के बिना पासवर्ड बंद करना सर्वर की पहुँच खोने का सबसे सामान्य कारण है।

चरण 4. SSH को ब्लॉक किए बिना UFW कॉन्फ़िगर करें

UFW Linux नेटवर्क नियमों के ऊपर बना सुविधाजनक रैपर है। पहले सुरक्षित डिफ़ॉल्ट सेट करें, फिर SSH और वेब पोर्ट की अनुमति दें:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

SSH नियम जोड़ने के बाद ही सक्रियण की पुष्टि करें। परिणाम की समीक्षा करें:

sudo ufw status verbose
sudo ufw status numbered

स्थायी ऑफिस IP के लिए आप SSH को उसी पते तक सीमित कर सकते हैं:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

इस विकल्प का उपयोग केवल स्थायी IP और प्रदाता के कंसोल तक पहुँच होने पर करें: पता बदलने पर आप स्वयं को सर्वर से बाहर कर सकते हैं।

एप्लिकेशन पोर्ट अस्थायी रूप से कैसे खोलें

यदि किसी सेवा को सीधे जाँचना आवश्यक हो, तो सीमित स्रोत के साथ नियम बनाएँ:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

परीक्षण के बाद ufw status numbered में दिखने वाले नंबर से इसे हटाएँ:

sudo ufw delete RULE_NUMBER

sudo ufw allow 1:65535/tcp का उपयोग न करें: ऐसा नियम फ़ायरवॉल को केवल औपचारिकता बना देता है।

चरण 5. SSH के लिए Fail2ban सक्षम करें

Fail2ban लॉग का विश्लेषण करता है और कई असफल लॉगिन प्रयासों के बाद अस्थायी ब्लॉकिंग नियम जोड़ता है। यह SSH कुंजियों या फ़ायरवॉल का विकल्प नहीं है, लेकिन स्वचालित brute-force प्रयासों के शोर को कम करता है।

स्थानीय कॉन्फ़िगरेशन बनाएँ ताकि पैकेज अपडेट आपकी सेटिंग्स को ओवरराइट न करें:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

[DEFAULT] सेक्शन में उचित मान सेट करें:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

सेवा शुरू करें और jail जाँचें:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

sshd आउटपुट में असफल प्रयासों और ब्लॉक किए गए पतों की संख्या जाँचें। अपना IP ban सूची में न जोड़ें। स्थायी अपवाद के लिए [DEFAULT] में ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP उपयोग करें।

चरण 6. स्वचालित अपडेट सक्षम करें

सुरक्षा पैकेजों के लिए स्वचालित अपडेट उपयोगी हैं, लेकिन कर्नेल रीबूट का प्रबंधन फिर भी करना पड़ता है:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

सप्ताह में एक बार जाँचें कि रीबूट आवश्यक है या नहीं:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

मैन्युअल रीबूट से पहले सुनिश्चित करें कि आपके पास काम करने वाली कुंजी और VPS कंसोल तक पहुँच है। रीबूट के बाद एप्लिकेशन सेवाएँ, Nginx, UFW और Fail2ban जाँचें।

चरण 7. बाहर से परिणाम जाँचें

सुरक्षा की जाँच किसी दूसरे कंप्यूटर से करें, केवल कॉन्फ़िगरेशन पढ़कर नहीं:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

कमांड को denial के साथ समाप्त होना चाहिए। काम करने वाले कुंजी-आधारित लॉगिन का अलग से परीक्षण करें:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

VPS पर सुनने वाले पतों और नियमों की जाँच करें:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

यदि एप्लिकेशन को सीधे उपलब्ध कराना उद्देश्य नहीं है, तो उसका पोर्ट 127.0.0.1 पर सुनना चाहिए। बाहरी होस्ट से आप nmap SERVER_IP चला सकते हैं, लेकिन केवल अपने सर्वर को स्कैन करें: बिना अनुमति किसी और के इंफ्रास्ट्रक्चर की जाँच कानून और प्रदाता के नियमों का उल्लंघन कर सकती है।

बैकअप और रिकवरी

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

पासवर्ड या टोकन को plain-text स्क्रिप्ट में न लिखें। यदि कोई secret उजागर हो जाए, तो उसे तुरंत रद्द करें और नया बनाएँ।

सुरक्षित प्रोजेक्ट के लिए VPS कैसे चुनें

सुरक्षा इंफ्रास्ट्रक्चर पर नियंत्रण से शुरू होती है। VPS पर आप ऑपरेटिंग सिस्टम, फ़ायरवॉल नियम, पहुँच विधि, बैकअप और सेवाओं का स्थान स्वयं चुन सकते हैं। छोटी वेबसाइट या API के लिए अतिरिक्त वर्चुअल कोर से अधिक महत्वपूर्ण स्थिर नेटवर्क, SSD स्टोरेज और रिकवरी कंसोल हैं।

tropic.host के VPS पर प्रोजेक्ट लॉन्च करते समय उसके सार्वजनिक प्रवेश बिंदु पहले से तय करें: अधिकांश मामलों में SSH, HTTP और HTTPS पर्याप्त हैं। डेटाबेस और कंट्रोल पैनल आंतरिक नेटवर्क में रखें। प्रोजेक्ट बढ़ने पर एप्लिकेशन, डेटाबेस और मॉनिटरिंग के लिए अलग VPS इंस्टेंस रखना विफलता के क्षेत्रों को अलग करने में मदद करता है।

सामान्य गलतियाँ

• कुंजी-आधारित लॉगिन जाँचने से पहले पासवर्ड बंद करना। वर्तमान सत्र खुला रखें और नए लॉगिन का अलग से परीक्षण करें।
• पूरे विश्व के लिए 22/tcp खुला छोड़ना, जबकि इसे केवल विश्वसनीय पतों से अनुमति दी जा सकती है।
• Docker पोर्ट सीधे प्रकाशित करना। पहले Docker और UFW नियम जाँचें।
• Fail2ban इंस्टॉल करके लॉग दोबारा कभी न जाँचना। बदलावों के बाद journalctl -u ssh और jail स्थिति की समीक्षा करें।

निष्कर्ष

जब चरण सही क्रम में किए जाएँ तो VPS की मूल सुरक्षा में अधिक समय नहीं लगता: अलग उपयोगकर्ता बनाएँ, SSH कुंजी इंस्टॉल करें, पहुँच सत्यापित करें, root लॉगिन और पासवर्ड बंद करें, UFW सक्षम करें, Fail2ban कॉन्फ़िगर करें और स्वचालित अपडेट सेट करें। इसके बाद बैकअप, लॉगिंग और बाहरी मॉनिटरिंग जोड़ें।

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

FAQ

क्या मुझे डिफ़ॉल्ट SSH पोर्ट बदलना चाहिए?

ज़रूरी नहीं। पोर्ट बदलने से स्वचालित शोर कम होता है, लेकिन यह कुंजियों, बंद पासवर्ड, UFW या Fail2ban का विकल्प नहीं है। पोर्ट बदलने पर फ़ायरवॉल नियम और Fail2ban jail में port पैरामीटर भी अपडेट करें।

UFW कॉन्फ़िगर करने के बाद पहुँच खो जाए तो क्या करें?

प्रदाता के वेब या rescue कंसोल का उपयोग करें, फिर SSH नियम और sshd कॉन्फ़िगरेशन जाँचें। नई पहुँच की पुष्टि होने तक पुराना काम करने वाला सत्र बंद न करें।

क्या Fail2ban SSH की सुरक्षा के लिए पर्याप्त है?

नहीं। Fail2ban उन लॉगिन विफलताओं के बाद प्रतिक्रिया देता है जो पहले ही हो चुकी हैं। आधार SSH कुंजियाँ, बंद पासवर्ड प्रमाणीकरण, न्यूनतम उपयोगकर्ता अनुमतियाँ और सीमित फ़ायरवॉल होना चाहिए।

क्या मैं SSH को केवल एक IP पते से अनुमति दे सकता हूँ?

हाँ, यदि पता स्थायी है: उस IP के लिए UFW allow from नियम जोड़ें। पहले से प्रदाता कंसोल या किसी अन्य fallback की पहुँच तय करें, क्योंकि IP बदलने के बाद कनेक्शन ब्लॉक हो जाएगा।

VPS सुरक्षा कितनी बार जाँचनी चाहिए?

SSH, फ़ायरवॉल या Docker पोर्ट प्रकाशन में हर बदलाव के बाद पोर्ट जाँच चलाएँ और लॉगिन का परीक्षण करें। नियमित रखरखाव के रूप में सप्ताह में कम-से-कम एक बार अपडेट और लॉग की समीक्षा करें, तथा बैकअप रिकवरी का नियमित परीक्षण करें।