Ubuntu सर्वर को सुरक्षित करने के लिए SSH सिर्फ़ keys से अनुमत करें, default-deny फ़ायरवॉल चलाएँ, सुरक्षा अपडेट अपने-आप इंस्टॉल होने दें, बार-बार की लॉगिन विफलताओं को ब्लॉक करें, सिर्फ़ ज़रूरी सर्विस ही बाहर खोलें और टेस्ट किए हुए बैकअप रखें। ये छह कदम पब्लिक सर्वर पर होने वाले ज़्यादातर हमलों को रोक देते हैं।
कमांड Ubuntu 24.04 LTS के लिए हैं और थोड़े अंतर के साथ Debian 12 पर भी काम करती हैं। इन्हें sudo वाले यूज़र से चलाएँ। अगर आपने अभी बुनियादी काम नहीं किए हैं, तो नए VPS पर पहले कदम से शुरू करें।
1. पहले पैच करें, फिर पैच रखें
sudo apt update && sudo apt full-upgrade -y
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
जाँचें कि टाइमर एक्टिव है:
systemctl list-timers | grep apt
अब सुरक्षा अपडेट हर दिन इंस्टॉल होते हैं। समय-समय पर cat /var/run/reboot-required से देखें कि कोई रीबूट बाकी तो नहीं।
2. SSH को सख़्त करें
सिर्फ़ keys
पक्का करें कि आपकी key किसी sudo यूज़र के लिए काम करती है (देखें SSH keys)। फिर:
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no
AllowUsers deploy
EOF
sudo sshd -t && sudo systemctl reload ssh
AllowUsersSSH को सिर्फ़ आपके बताए अकाउंट तक सीमित करता है।deployकी जगह अपना यूज़र लिखें।sshd -tफ़ाइल को वैलिडेट करता है; अगर कुछ प्रिंट नहीं होता, तो सिंटैक्स ठीक है।
मौजूदा टर्मिनल बंद करने से पहले एक नए टर्मिनल से टेस्ट करें।
असल में लागू सेटिंग्स जाँचें
Drop-in फ़ाइलें क्रम से पढ़ी जाती हैं, और पहली वैल्यू लागू होती है। पुष्टि करें कि sshd असल में क्या इस्तेमाल कर रहा है:
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers'
अगर 50-cloud-init.conf जैसी कोई cloud-init फ़ाइल PasswordAuthentication yes सेट करती है, तो आपकी 10- फ़ाइल पहले पढ़ी जाती है और वही लागू होती है।
3. UFW के साथ default-deny फ़ायरवॉल
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit OpenSSH # SSH अनुमत करें, बार-बार की कोशिशों पर रेट लिमिट
sudo ufw allow 80,443/tcp # सिर्फ़ तभी, जब आप वेब सर्वर चलाते हैं
sudo ufw enable
sudo ufw status numbered
ufw limit उस एड्रेस को ब्लॉक कर देता है जो 30 सेकंड में छह या ज़्यादा कनेक्शन खोलता है, जिससे स्कैनर धीमे पड़ते हैं।
जब तक /etc/default/ufw में IPV6=yes सेट है (Ubuntu पर यही डिफ़ॉल्ट है), UFW IPv6 को भी कवर करता है।
SSH को अपने एड्रेस तक सीमित करें
अगर आप किसी तय एड्रेस से कनेक्ट करते हैं, तो SSH सिर्फ़ वहीं से अनुमत करें:
sudo ufw delete limit OpenSSH
sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp # उदाहरण रेंज
Docker से जुड़ी चेतावनी
Docker अपने खुद के iptables नियम लिखता है, और पब्लिश किए गए कंटेनर पोर्ट UFW को बायपास कर देते हैं। कंटेनर को localhost (127.0.0.1:8080:80) पर बाइंड करें और आगे एक रिवर्स प्रॉक्सी रखें, या क्लाउड फ़ायरवॉल पर फ़िल्टर करें। Docker Compose गाइड यह तरीका दिखाती है।
4. आगे एक क्लाउड फ़ायरवॉल जोड़ें
सर्वर के बाहर का फ़ायरवॉल तब भी काम करता रहता है जब कोई UFW बंद कर दे, और एक रूल सेट कई सर्वर को कवर कर सकता है। Wolkra पर फ़ायरवॉल stateful हैं, इनबाउंड और आउटबाउंड नियम सपोर्ट करते हैं, सर्वर या लेबल सेलेक्टर पर लागू होते हैं और इनका कोई शुल्क नहीं है। एक आम रूल सेट:
| दिशा | प्रोटोकॉल | पोर्ट | सोर्स |
|---|---|---|---|
| इनबाउंड | TCP | 22 | आपके ऑफ़िस या VPN की रेंज |
| इनबाउंड | TCP | 80, 443 | कोई भी |
| इनबाउंड | ICMP | – | कोई भी |
स्टेप्स के लिए डॉक्स में फ़ायरवॉल देखें।
5. Fail2ban से ब्रूट फ़ोर्स ब्लॉक करें
sudo apt install -y fail2ban python3-systemd
sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
[sshd]
enabled = true
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
backend = systemd सीधे journal पढ़ता है, और Ubuntu 24.04 SSH के लॉग इसी तरह रखता है। [DEFAULT] में ignoreip में अपना एड्रेस जोड़ें ताकि आप खुद को कभी बैन न करें।
6. जो सुन रहा है, उसे कम करें
हर खुला पोर्ट कुछ ऐसा है जिसे पैच करना होगा। उनकी सूची देखें:
sudo ss -tulpn
हर लाइन के लिए पूछें कि क्या उस तक इंटरनेट से पहुँचना ज़रूरी है। डेटाबेस, Redis और एडमिन पैनल के लिए आमतौर पर नहीं। उन्हें 127.0.0.1 या किसी प्राइवेट नेटवर्क एड्रेस पर बाइंड करें, और जो पैकेज इस्तेमाल नहीं करते उन्हें हटा दें:
sudo apt purge --autoremove <package>
7. कर्नेल और नेटवर्क स्टैक को सुरक्षित करें
Ubuntu के डिफ़ॉल्ट समझदारी भरे हैं। पब्लिक सर्वर पर कुछ अतिरिक्त सेटिंग्स मदद करती हैं:
sudo tee /etc/sysctl.d/90-hardening.conf >/dev/null <<'EOF'
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
EOF
sudo sysctl --system
अगर सर्वर ट्रैफ़िक रूट करता है, जैसे VPN गेटवे के रूप में, तो redirect वाली सेटिंग्स छोड़ दें।
8. sudo सावधानी से इस्तेमाल करें
- sudo सिर्फ़ उन्हीं लोगों को दें जिन्हें इसकी ज़रूरत है:
getent group sudoउनकी सूची दिखाता है। - इंटरैक्टिव अकाउंट पर कभी
NOPASSWD: ALLन लगाएँ। ऑटोमेशन के लिए बिना पासवर्ड वाला sudo कुछ खास कमांड तक सीमित रखें। - SSH में keys इस्तेमाल होने पर भी अपने sudo यूज़र पर पासवर्ड सेट करें:
sudo passwd deploy।
9. लॉग और लॉगिन पर नज़र रखें
last -n 20 # हाल के लॉगिन
sudo journalctl -u ssh --since today
sudo journalctl -p err -b # बूट के बाद की एरर
फ़ाइल इंटीग्रिटी और एक जल्दी ऑडिट के लिए Lynis एक अच्छी शुरुआत है:
sudo apt install -y lynis
sudo lynis audit system
यह एक हार्डनिंग इंडेक्स और सुझावों की सूची प्रिंट करता है। इन्हें आदेश नहीं, बल्कि सुझाव की तरह लें।
Wolkra कंसोल हर सर्वर के लिए CPU, डिस्क और नेटवर्क ग्राफ़ दिखाता है (मॉनिटरिंग)। ट्रैफ़िक या CPU में अचानक उछाल अक्सर किसी सर्विस के हैक होने का पहला संकेत होता है।
10. सिर्फ़ सर्वर नहीं, अकाउंट भी सुरक्षित करें
अगर कोई आपके क्लाउड अकाउंट में लॉग इन कर सकता है, तो सर्वर हार्डनिंग बेकार है। Wolkra कंसोल में:
- टू-फ़ैक्टर ऑथेंटिकेशन (TOTP) चालू करें;
- एक्टिव सेशन देखें और पुराने सेशन से साइन आउट करें;
- टीम के सदस्यों को सबसे कम ज़रूरी रोल दें;
- जहाँ हो सके, read-only, IP-सीमित और एक्सपायर होने वाले API टोकन इस्तेमाल करें।
देखें अकाउंट सुरक्षा और API टोकन।
11. बैकअप लें, और रिस्टोर टेस्ट करें
सुरक्षा में रिकवरी भी शामिल है। रोज़ाना बैकअप या स्नैपशॉट चालू करें और कम से कम एक कॉपी सर्वर के बाहर रखें। फिर यह साबित करने के लिए कि यह काम करता है, एक बार नए सर्वर पर रिस्टोर करें। बैकअप स्ट्रैटेजी गाइड में पूरी योजना है।
चेकलिस्ट
- ऑटोमैटिक सुरक्षा अपडेट चालू
- सिर्फ़ SSH keys, root लॉगिन बंद,
AllowUsersसेट - UFW default deny, सिर्फ़ ज़रूरी पोर्ट खुले
- आगे क्लाउड फ़ायरवॉल, SSH जाने-पहचाने रेंज तक सीमित
- Fail2ban चल रहा है
-
ss -tulpnमें कुछ भी अनपेक्षित नहीं - Sysctl हार्डनिंग लागू
- sudo सीमित, क्लाउड अकाउंट पर 2FA चालू
- बैकअप चालू और एक रिस्टोर टेस्ट हो चुका
अगर नियम सख़्त करते समय कुछ गड़बड़ हो जाए, तो सर्वर व्यू में ब्राउज़र कंसोल और रेस्क्यू मोड से आप SSH के बिना वापस अंदर पहुँच सकते हैं।
अक्सर पूछे जाने वाले सवाल
Ubuntu सर्वर को सुरक्षित करने का सबसे ज़रूरी कदम क्या है?
SSH keys इस्तेमाल करें और पासवर्ड लॉगिन बंद करें। नए सर्वर पर ज़्यादातर हमले अपने-आप चलने वाले पासवर्ड अनुमान होते हैं, और सिर्फ़ key से लॉगिन उन्हें रोक देता है।
पासवर्ड बंद हों तो क्या Fail2ban की ज़रूरत है?
तब यह कम ज़रूरी है, लेकिन फिर भी यह लॉग का शोर घटाता है और स्कैनर को धीमा करता है। यह वेब लॉगिन और पासवर्ड इस्तेमाल करने वाली दूसरी सर्विस के लिए भी उपयोगी है।
क्या मुझे SSH पोर्ट बदलना चाहिए?
इससे लॉग का शोर कम होता है, लेकिन यह असली सुरक्षा नहीं है। फ़ायरवॉल से SSH को जाने-पहचाने सोर्स एड्रेस तक सीमित करना कहीं ज़्यादा असरदार है।
क्या UFW काफ़ी है, या क्लाउड फ़ायरवॉल भी चाहिए?
UFW सर्वर को अंदर से सुरक्षित रखता है। क्लाउड फ़ायरवॉल ट्रैफ़िक को पहुँचने से पहले ही फ़िल्टर करता है और तब भी काम करता है जब कोई सर्वर के अपने नियम तोड़ दे। दोनों का इस्तेमाल एक अच्छा डिफ़ॉल्ट है।
क्या ये स्टेप Debian 12 पर काम करते हैं?
लगभग सभी। Debian वही पैकेज इस्तेमाल करता है; अगर sudo और ufw न हों, तो पहले उन्हें इंस्टॉल करें।