UFW में IPv6 सुरक्षा कैसे सुनिश्चित करें

IPv6 फायरवॉल से जुड़ी एक वाक्य की चेतावनी

आपका फायरवॉल केवल IPv4 को सुरक्षित करता है। आपके VPS के पास लगभग निश्चित रूप से एक public IPv6 पता भी होता है, और कई services डिफ़ॉल्ट रूप से उस पर listen करती हैं। यदि आपका फायरवॉल केवल IPv4 को कवर करता है, या आप किसी ऐसे cloud firewall पर निर्भर हैं जो केवल IPv4 को filter करता है, तो वे सभी services पूरे इंटरनेट से IPv6 के माध्यम से सुलभ (reachable) हैं, जबकि आपका IPv4 पक्ष सुरक्षित दिख रहा है। आप curl के साथ किसी port का परीक्षण करते हैं, connection refused देखते हैं, और सुरक्षित महसूस करते हैं। एक हमलावर उसी port से IPv6 के माध्यम से जुड़ता है और अंदर आ जाता है।

यह गाइड दिखाती है कि एक सामान्य Ubuntu 24.04 VPS पर यह कमी कहाँ से आती है, आप जो expose कर रहे हैं उसे सटीक रूप से कैसे देखें, और इसे कैसे बंद करें। यहाँ UFW दोषी नहीं है। आधुनिक Ubuntu install पर UFW पहले से ही IPv6 को संभालता है। यह जोखिम उसके आसपास की परतों से, और उन services से आता है जिनके बारे में आपको पता भी नहीं था कि वे listen कर रही हैं।

आपका VPS शुरू से ही IPv6 पर क्यों है

आजकल लगभग हर VPS एक public IPv6 address के साथ आता है, जो अक्सर पूरा एक /64 होता है, और साथ में एक IPv4 address भी मिलता है। अपना address जाँचें:

ip -6 addr show scope global

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet6 2001:db8:2a::1/64 scope global

वह 2001:db8:2a::1 इंटरनेट पर कहीं से भी routable है, बिल्कुल आपके IPv4 address की तरह। अब देखें कि कौन सी service listen कर रही है:

sudo ss -tlnp

State   Recv-Q  Local Address:Port   Process
LISTEN  0       0.0.0.0:22           sshd
LISTEN  0       [::]:22              sshd
LISTEN  0       127.0.0.1:5432       postgres
LISTEN  0       [::]:8080            docker-proxy

Local Address कॉलम को ध्यान से पढ़ें। 0.0.0.0:22 का अर्थ है "हर IPv4 address पर listen करें।" [::]:22 का अर्थ है "हर IPv6 address पर listen करें।" 127.0.0.1:5432 केवल loopback से जुड़ा है और बिल्कुल भी public नहीं है, इसलिए Postgres वाली लाइन सुरक्षित है। दो [::] लाइनें पूरे इंटरनेट को IPv6 पर जवाब देती हैं, और docker-proxy वाली वह है जिसे आप शुरू करना भूल गए थे।

अधिकांश daemons डिफ़ॉल्ट रूप से :: पर bind होते हैं, क्योंकि Linux पर एक :: socket आमतौर पर IPv4 को भी स्वीकार कर लेता है। इसलिए एक नए सर्वर की डिफ़ॉल्ट स्थिति यह होती है कि वह "हर जगह, दोनों stacks पर जवाब दे।" आपका firewall ही एकमात्र ऐसी चीज़ है जो इसके सामने खड़ी है, और यही कारण है कि जो firewall केवल एक stack को देखता है, वह एक बड़ी समस्या है।

IPv6 गैप वास्तव में कहाँ से आता है

इसके चार सामान्य स्रोत हैं। किसी एक सर्वर पर इनमें से एक या कई समस्याएं एक साथ हो सकती हैं।

1. एक क्लाउड फायरवॉल जो केवल IPv4 को फ़िल्टर करता है। कई प्रदाता फायरवॉल और सिक्योरिटी-ग्रुप उत्पाद IPv4 के इर्द-गिर्द विकसित हुए हैं और वे या तो IPv6 को अनदेखा करते हैं या उन्हें अलग से IPv6 नियमों की आवश्यकता होती है जिन्हें आपको मैन्युअल रूप से जोड़ना पड़ता है। यदि आपका एकमात्र फायरवॉल प्रदाता डैशबोर्ड में है और यह IPv6 को कवर नहीं करता है, तो आपके [::] सर्वर खुले हैं, चाहे IPv4 पर port 22 के बारे में वह कुछ भी कहे। अपने प्रदाता के फायरवॉल दस्तावेज़ पढ़ें और विशेष रूप से IPv6 शब्द खोजें।

2. बिना ip6tables के मैन्युअल रूप से बनाए गए iptables। iptables कमांड केवल IPv4 टेबल्स को प्रभावित करती है। IPv6 के लिए एक पूरी तरह से अलग कमांड, ip6tables है, जिसके अपने अलग नियम होते हैं। यदि आपने iptables -A INPUT ... लाइनों से भरा एक फायरवॉल स्क्रिप्ट लिखा है और कभी भी संबंधित ip6tables नियम नहीं लिखे, तो आपका IPv6 फायरवॉल खाली है, और डिफ़ॉल्ट ACCEPT पॉलिसी वाली एक खाली INPUT चेन सब कुछ अनुमति देती है:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

यह आउटपुट एक ही स्क्रीन पर पूरा जाल है। IPv4 फ़िल्टर किया गया है, IPv6 दुनिया को स्वीकार करता है।

3. Docker का आपके फायरवॉल के आगे पोर्ट पब्लिश करना। जब आप docker run -p 8080:80 चलाते हैं, तो Docker अपने स्वयं के नियमों को UFW के नियमों से पहले डाल देता है, इसलिए एक पब्लिश किया गया पोर्ट तब भी पहुंच योग्य होता है जब ufw status कहता है कि वह पोर्ट अस्वीकृत है, और आधुनिक Docker पर यही IPv6 पर भी लागू होता है। Docker UFW को क्यों बायपास करता है, और कंटेनर पोर्ट को ठीक से कैसे फ़िल्टर करें इस तंत्र और समाधानों की व्याख्या करता है। ये पब्लिश किए गए पोर्ट कैसे घोषित किए जाते हैं, यह जानने के लिए VPS पर Docker Compose की मूल बातें देखें।

4. IPv6 बंद होने के साथ UFW। UFW IPv6 को संभालता है, लेकिन केवल तभी जब उसे ऐसा करने के लिए कहा जाए। स्विच की जाँच करें:

grep IPV6 /etc/default/ufw

आधुनिक Ubuntu में IPV6=yes होता है, इसलिए UFW प्रत्येक नियम को दोनों स्टैक पर लागू करता है। यदि आप किसी पुरानी इमेज या पुरानी गाइड से IPV6=no देखते हैं, तो आपके द्वारा लिखा गया प्रत्येक UFW नियम केवल IPv4 के लिए है, और IPv6 अनमैनेज्ड रह जाता है।

यह देखें कि आप वास्तव में क्या expose कर रहे हैं

अनुमान न लगाएँ। इसे बाहर से मापें। सबसे पहले अपने listeners की सूची बनाएँ और :: से bound हर एक को नोट करें:

sudo ss -tlnp | grep '::'

फिर, एक अलग मशीन से, सर्वर के सार्वजनिक IPv6 पते से कनेक्ट करें और उस port को आज़माएँ जिसे आप बंद मानते हैं:

curl -6 -v http://[2001:db8:2a::1]:8080/

यदि यह कोई पेज या banner लौटाता है, तो वह port IPv6 पर खुला है। एक बंद port आपको Connection refused या timeout देगा। ये दोनों विफलताएँ एक ही संकेत नहीं हैं, और refused और timed out के बीच का अंतर आपको बताता है कि क्या host ने उत्तर दिया और आपको मना कर दिया, या firewall ने चुपचाप आपके packet को drop कर दिया। पूरी तस्वीर के लिए, सर्वर के बाहर से nmap के साथ IPv6 पते को स्कैन करें:

nmap -6 2001:db8:2a::1

nmap जो भी port IPv6 पर खुला बताता है, वह एक ऐसा port है जिसे पूरा इंटरनेट एक्सेस कर सकता है, चाहे आपके IPv4 स्कैन ने कुछ भी दिखाया हो। IPv4 और IPv6 स्कैन की तुलना करना अंतर खोजने का सबसे तेज़ तरीका है: जो कुछ भी -6 पर खुला है लेकिन IPv4 पर बंद है, वह एक ऐसी service है जिसे आपका firewall सुरक्षित नहीं कर पा रहा है।

अंतर को समाप्त करें

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

sudo sed -i 's/^IPV6=no/IPV6=yes/' /etc/default/ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

यदि IPV6=yes को बदलते समय UFW पहले से सक्रिय था, तो यह बदलाव तब तक प्रभावी नहीं होगा जब तक आप sudo ufw reload नहीं चलाते।

ufw status प्रत्येक नियम को दो बार सूचीबद्ध करता है, एक बार सामान्य रूप से और एक बार (v6) सफिक्स के साथ। जब आप (v6) लाइनें देखते हैं, तो UFW IPv6 को फ़िल्टर कर रहा होता है:

22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

यदि आप iptables को मैन्युअल रूप से प्रबंधित करते हैं, तो हर नियम को ip6tables में भी दोहराएं, या nftables पर स्विच करें, जिसकी inet टेबल IPv4 और IPv6 को एक ही स्थान पर कवर करती है और इस प्रकार की गलतियों की संभावना को पूरी तरह समाप्त कर देती है। जब आप स्वयं नियम लिख रहे हों, तो एक एकल nftables inet फ़िल्टर टेबल सबसे स्वच्छ समाधान है। यदि आपका VPS Ubuntu के बजाय Rocky या AlmaLinux चलाता है, तो कॉन्फ़िगर करने के लिए कोई UFW नहीं है और firewalld वह फ्रंट एंड है जिसे आप इसके बजाय प्रबंधित करते हैं, जो अपने ज़ोन नियमों को एक साथ दोनों स्टैक पर लागू करता है।

जिन सेवाओं को आप सार्वजनिक नहीं करना चाहते, उन्हें loopback पर बाइंड करें। डेटाबेस, एडमिन पैनल या मेट्रिक्स एंडपॉइंट को शायद ही कभी सार्वजनिक पते की आवश्यकता होती है। इसे 127.0.0.1 और ::1 पर बाइंड करें ताकि यह कभी भी रूट करने योग्य पते पर लिसन न करे। Postgres के लिए, listen_addresses = 'localhost' सेट करें। ऐप सर्वर के लिए, इसे 127.0.0.1 पर बाइंड करें और सामने एक reverse proxy रखें। लिसनर को बंद करना उसे फ़ायरवॉल करने से बेहतर है, क्योंकि ऐसा करने पर पहुँचने के लिए कुछ भी नहीं बचता।

Docker के पब्लिश किए गए पोर्ट्स की सुरक्षा के लिए UFW पर भरोसा न करें। कंटेनर पोर्ट्स को हर इंटरफ़ेस के बजाय एक विशिष्ट पते पर पब्लिश करें, उदाहरण के लिए -p 127.0.0.1:8080:80, ताकि पोर्ट केवल होस्ट और आपके द्वारा जानबूझकर प्रॉक्सी की गई चीज़ों से ही पहुँचा जा सके। जब किसी कंटेनर को वास्तव में सार्वजनिक होना ही हो, तो उसे Traefik reverse proxy के पीछे रखें और केवल प्रॉक्सी को पब्लिश करें, न कि प्रत्येक ऐप को।

अपने प्रदाता फ़ायरवॉल में IPv6 नियम जोड़ें, या यह स्वीकार करें कि यह IPv6 के लिए आपका फ़ायरवॉल नहीं है और होस्ट पर UFW या nftables को वह काम करने दें।

सुनिश्चित करें कि पोर्ट वास्तव में बंद हैं

अपने बदलावों के बाद बाहर से वही टेस्ट दोबारा चलाएं:

curl -6 -v http://[2001:db8:2a::1]:8080/
nmap -6 2001:db8:2a::1

जो पोर्ट पहले जवाब दे रहा था, उसे अब कनेक्शन रिफ्यूज या टाइम आउट करना चाहिए, और nmap को इसे filtered या closed रिपोर्ट करना चाहिए। यदि कोई पोर्ट अभी भी open है, तो ऊपर दिए गए चार स्रोतों की दोबारा जांच करें: कोई सर्विस अभी भी :: पर बाइंड है जिसके आगे कोई नियम नहीं है, UFW से पहले कोई Docker नियम मौजूद है, या किसी प्रोवाइडर फायरवॉल ने IPv6 को कभी देखा ही नहीं।

संवेदनशील सर्विसेज को पूरी तरह से पब्लिक इंटरनेट से दूर रखना और भी अधिक सुरक्षित है। SSH और एडमिन पैनल को WireGuard VPN के पीछे रखें और उनके पोर्ट्स को फायरवॉल करें ताकि वे केवल टनल पर ही जवाब दें, जिससे उन पर IPv6 एक्सपोजर का सवाल लागू ही नहीं होगा। जो कुछ भी पब्लिक रहता है, उस पर होने वाले ब्रूट-फोर्स स्कैन को धीमा करने के लिए, डिफ़ॉल्ट-डिनाय फायरवॉल के ऊपर SSH के सामने Fail2ban लगाएं।

यदि पोर्ट्स आपके लिए नया विषय हैं, तो पोर्ट क्या होते हैं और सर्विसेज कैसे लिसन करती हैं वह शुरुआती लेख है जिसे आपको सबसे पहले पढ़ना चाहिए।

FAQ

क्या UFW डिफ़ॉल्ट रूप से IPv6 को ब्लॉक करता है?

आधुनिक Ubuntu 24.04 इंस्टॉलेशन पर, हाँ। UFW IPV6=yes को /etc/default/ufw से पढ़ता है और प्रत्येक नियम को IPv4 और IPv6 दोनों पर लागू करता है, और ufw status में IPv6 नियम (v6) सफिक्स के साथ दिखाई देते हैं। समस्या तब आती है जब IPV6=no (किसी पुरानी इमेज या पुराने ट्यूटोरियल से) का उपयोग किया जाता है, जब आप किसी ऐसे प्रोवाइडर फायरवॉल पर निर्भर होते हैं जो केवल IPv4 को फ़िल्टर करता है, या जब Docker किसी पोर्ट को UFW के ऊपर से पब्लिश कर देता है। grep IPV6 /etc/default/ufw के साथ स्विच की जाँच करें।

मैं यह कैसे जाँचूँ कि मेरा VPS IPv6 पर क्या एक्सपोज़ कर रहा है?

sudo ss -tlnp चलाएँ और उन सभी लिसनर्स (listeners) को नोट करें जिनका लोकल एड्रेस [::] से शुरू होता है, जिसका अर्थ है कि यह हर IPv6 इंटरफ़ेस पर उत्तर देता है। फिर, किसी अन्य मशीन से, सर्वर के पब्लिक IPv6 एड्रेस को सीधे curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ के साथ टेस्ट करें, या nmap -6 YOUR:IPV6::ADDR के साथ स्कैन करें। IPv6 स्कैन पर खुला लेकिन IPv4 पर बंद कोई भी पोर्ट आपकी सुरक्षा में कमी है।

जब UFW कहता है कि पोर्ट ब्लॉक है, तो मैं अपने Docker कंटेनर के पोर्ट तक क्यों पहुँच सकता हूँ?

जब आप -p के साथ पोर्ट पब्लिश करते हैं, तो Docker UFW के नियमों से पहले अपने स्वयं के फायरवॉल नियम डाल देता है, इसलिए पब्लिश किया गया पोर्ट तब भी पहुँच योग्य होता है भले ही ufw status उसे डिनाइड (denied) के रूप में दिखाता हो। यह IPv4 पर होता है, और IPv6 पर भी तब होता है जब Docker का IPv6 सपोर्ट चालू हो। किसी विशिष्ट एड्रेस जैसे -p 127.0.0.1:8080:80 पर पब्लिश करें, या कंटेनर को रिवर्स प्रॉक्सी के पीछे रखें और केवल प्रॉक्सी को ही पब्लिश करें।

क्या मुझे अभी भी IPv6 फायरवॉल की आवश्यकता है यदि मेरा IPv4 फायरवॉल मजबूत है?

हाँ। IPv4 और IPv6 अलग-अलग नेटवर्क स्टैक हैं जिनमें अलग-अलग फायरवॉल नियम होते हैं। IPv4 नियमों का एक सटीक सेट IPv6 ट्रैफ़िक के लिए कुछ नहीं करता है। यदि आपके VPS के पास पब्लिक IPv6 एड्रेस है, और लगभग सभी के पास होता है, तो :: पर लिसन करने वाली कोई भी सर्विस तब तक IPv6 पर पहुँच योग्य रहती है जब तक कि कोई IPv6 फायरवॉल नियम या लूपबैक बाइंडिंग उसे रोक न दे।

मैं किसी सर्विस को केवल IPv4 पर, या केवल localhost पर लिसन करने के लिए कैसे सेट करूँ?

सर्विस के कॉन्फ़िगरेशन में उसका बाइंड एड्रेस सेट करें। केवल IPv4 लूपबैक के लिए 127.0.0.1 पर बाइंड करें, या बिना IPv6 लिसनर के सभी IPv4 एड्रेस के लिए 0.0.0.0 पर बाइंड करें। Postgres listen_addresses का उपयोग करता है, SSH ListenAddress का उपयोग करता है, और अधिकांश ऐप सर्वर एक होस्ट या बाइंड फ्लैग एक्सपोज़ करते हैं। परिणाम को sudo ss -tlnp के साथ कन्फर्म करें और जाँचें कि Local Address अब [::] नहीं दिखा रहा है।