UFW असूनही IPv6 वर VPS उघडा का राहतो?

एका वाक्यातील IPv6 firewall सापळा

तुमचा firewall IPv4 चे संरक्षण करतो. तुमच्या VPS ला जवळजवळ निश्चितपणे सार्वजनिक IPv6 address देखील असतो आणि अनेक सेवा त्यावर default ने listen करतात. तुमचा firewall फक्त IPv4 व्यापत असेल किंवा तुम्ही फक्त IPv4 filter करणाऱ्या cloud firewall वर अवलंबून असाल, तर या सर्व सेवा IPv6 द्वारे संपूर्ण इंटरनेटवरून पोहोचण्यायोग्य असतात, जरी तुमची IPv4 बाजू व्यवस्थित बंदिस्त दिसत असली तरी. तुम्ही curl वापरून port ची चाचणी करता, connection नाकारलेले दिसते आणि तुम्ही सुरक्षित असल्याचे समजता. मात्र attacker त्याच port शी IPv6 द्वारे connect होतो आणि आत प्रवेश करतो.

या मार्गदर्शकामध्ये सामान्य Ubuntu 24.04 VPS वर ही तफावत कुठून निर्माण होते, तुम्ही नेमके काय सार्वजनिकरीत्या उघडे ठेवले आहे ते कसे पाहायचे आणि ते कसे बंद करायचे हे दाखवले आहे. येथे UFW दोषी नाही. आधुनिक Ubuntu install वर UFW आधीपासूनच IPv6 हाताळतो. उघडेपणा त्याभोवतीच्या layers मुळे आणि कोणत्या सेवा listen करत आहेत हे तुम्हाला माहीत नसल्यामुळे निर्माण होतो.

तुमचा VPS सुरुवातीपासूनच IPv6 वर का असतो

आज जवळजवळ प्रत्येक VPS ला त्याच्या IPv4 पत्त्यासोबत सार्वजनिक IPv6 पत्ता, अनेकदा संपूर्ण /64, दिला जातो. तुमचा पत्ता तपासा:

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 इंटरनेटवरील कुठूनही route करता येतो, अगदी तुमच्या IPv4 पत्त्याप्रमाणे. आता कोणते ports listening आहेत ते पाहा:

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 हा column काळजीपूर्वक वाचा. 0.0.0.0:22 म्हणजे “प्रत्येक IPv4 पत्त्यावर listen करा.” [::]:22 म्हणजे “प्रत्येक IPv6 पत्त्यावर listen करा.” 127.0.0.1:5432 loopback ला bind केलेला आहे आणि तो सार्वजनिक नाही; त्यामुळे Postgres ची ही ओळ सुरक्षित आहे. [::] या दोन ओळी IPv6 द्वारे संपूर्ण इंटरनेटला उत्तर देतात, तर docker-proxy ही ओळ तुम्ही सुरू केल्याचे विसरू शकता.

बहुतेक daemons सुरुवातीपासूनच :: ला bind होतात, कारण Linux मध्ये :: socket सहसा IPv4 connections देखील स्वीकारतो. त्यामुळे नवीन server ची default स्थिती अशी असते: “दोन्ही stacks वर, सर्वत्र उत्तर द्या.” त्यासमोर असलेली एकमेव गोष्ट म्हणजे तुमचा firewall. म्हणून फक्त एका stack वर लक्ष ठेवणारा firewall ही गंभीर समस्या आहे.

IPv6 मधील अंतर प्रत्यक्षात कुठून निर्माण होते

याचे चार सामान्य स्रोत आहेत. एखाद्या सर्व्हरवर यापैकी एक किंवा एकाच वेळी अनेक स्रोत असू शकतात.

1. फक्त IPv4 वर फिल्टर करणारे cloud firewall. अनेक provider firewall आणि security-group products ची रचना IPv4 केंद्रित होती. त्यामुळे ते IPv6 कडे दुर्लक्ष करतात किंवा तुम्हाला स्वतंत्र IPv6 rules manually जोडावे लागतात. तुमचे एकमेव firewall provider dashboard मधील असेल आणि ते IPv6 कव्हर करत नसेल, तर IPv4 वरील port 22 बद्दल काहीही दाखवले असले तरी तुमच्या [::] services उघड्या राहतात. तुमच्या provider चे firewall documentation वाचा आणि त्यात विशेषतः IPv6 हा शब्द शोधा.

2. ip6tables शिवाय स्वतः तयार केलेले iptables. iptables command केवळ IPv4 tables वर परिणाम करते. IPv6 साठी ip6tables ही पूर्णपणे स्वतंत्र command आहे आणि तिचे rules देखील स्वतंत्र असतात. तुम्ही iptables -A INPUT ... lines असलेली firewall script लिहिली, पण त्यांच्याशी जुळणारे ip6tables rules लिहिले नाहीत, तर तुमचे IPv6 firewall रिकामे राहते. Default ACCEPT policy असलेली रिकामी INPUT chain सर्व traffic ला परवानगी देते:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

या output मध्ये संपूर्ण समस्या एका स्क्रीनवर दिसते. IPv4 फिल्टर केलेले आहे, तर IPv6 सर्वांसाठी स्वीकारले जाते.

3. Docker ने ports थेट firewall च्या पलीकडे publish करणे. तुम्ही docker run -p 8080:80 चालवल्यावर Docker स्वतःचे rules UFW च्या rules च्या आधी जोडतो. त्यामुळे ufw status मध्ये तो port denied असल्याचे दाखवले तरी published port वर पोहोचता येते. आधुनिक Docker मध्ये हेच IPv6 वरूनही लागू होते. Docker UFW ला का bypass करते आणि container ports योग्य प्रकारे कसे filter करायचे या लेखात याची कार्यपद्धती आणि उपाय स्पष्ट केले आहेत. हे published ports कसे घोषित केले जातात, यासाठी VPS वरील Docker Compose ची मूलभूत माहिती पहा.

4. IPv6 बंद केलेले UFW. UFW IPv6 हाताळू शकते, परंतु त्यासाठी ते सक्षम केलेले असणे आवश्यक आहे. ही setting तपासा:

grep IPV6 /etc/default/ufw

आधुनिक Ubuntu मध्ये IPV6=yes असते. त्यामुळे UFW प्रत्येक rule दोन्ही stacks वर लागू करते. जुन्या image किंवा जुन्या guide मधून IPV6=no दिसत असेल, तर तुम्ही लिहिलेले प्रत्येक UFW rule केवळ IPv4 साठी आहे आणि IPv6 unmanaged राहते.

तुम्ही नेमके काय उघडे ठेवत आहात ते पाहा

अंदाज करू नका. बाहेरून त्याचे मोजमाप करा. प्रथम listening ports ची यादी करा आणि :: वर bound असलेला प्रत्येक port नोंदवा:

sudo ss -tlnp | grep '::'

त्यानंतर, वेगळ्या मशीनवरून सर्व्हरच्या सार्वजनिक IPv6 address शी connect करा आणि बंद असल्याचे तुम्हाला वाटणारा port तपासा:

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

यातून एखादे page किंवा banner मिळाल्यास, तो port IPv6 वर open आहे. बंद port साठी Connection refused किंवा timeout मिळतो. हे दोन्ही failures एकसारखे signal नाहीत. refused आणि timed out मधील फरक यावरून host ने उत्तर देऊन connection नाकारले की firewall ने तुमचे packet शांतपणे drop केले, हे समजते. संपूर्ण स्थिती पाहण्यासाठी, सर्व्हरच्या बाहेरून nmap वापरून IPv6 address scan करा:

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

IPv6 वर nmap ने open म्हणून दाखवलेला प्रत्येक port संपूर्ण internet वरून reachable असतो, तुमच्या IPv4 scan मध्ये काहीही दिसले असले तरी. IPv4 आणि IPv6 scans शेजारी-शेजारी compare करणे ही तफावत शोधण्याची सर्वात जलद पद्धत आहे: -6 वर open पण IPv4 वर closed असलेली कोणतीही गोष्ट म्हणजे firewall मध्ये दुर्लक्षित राहिलेली service आहे.

त्रुटी दूर करा

UFW ने दोन्ही stack साठी नियम लागू करा आणि default-deny सेट करा. हा बदल झाला आहे याची खात्री करा. त्यानंतर inbound traffic साठी default-deny policy सेट करा आणि आवश्यक तेवढेच traffic allow करा:

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 enable करताना UFW आधीपासून active असेल, तर sudo ufw reload चालवेपर्यंत हा बदल लागू होत नाही.

ufw status प्रत्येक rule दोनदा दाखवते: एकदा साध्या स्वरूपात आणि एकदा (v6) suffix सह. (v6) ओळी दिसल्यास UFW IPv6 traffic filter करत आहे:

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

तुम्ही iptables हाताने व्यवस्थापित करत असल्यास, प्रत्येक rule ip6tables मध्येही लागू करा, किंवा nftables वापरा. nftables मधील inet tables IPv4 आणि IPv6 दोन्ही एकाच ठिकाणी हाताळतात आणि या प्रकारच्या चुका टाळतात. तुम्ही rules स्वतः लिहित असल्यास, एकच nftables inet filter table हा सर्वात स्वच्छ उपाय आहे. तुमचा VPS Ubuntu ऐवजी Rocky किंवा AlmaLinux चालवत असल्यास, configure करण्यासाठी UFW उपलब्ध नसते. त्याऐवजी तुम्ही firewalld हे front end म्हणून व्यवस्थापित करता. ते एकाच वेळी दोन्ही stack साठी zone rules लागू करते.

सार्वजनिक उपलब्ध नको असलेल्या services ना loopback वर bind करा. Database, admin panel किंवा metrics endpoint ला सामान्यतः public address ची गरज नसते. ते 127.0.0.1 आणि ::1 वर bind करा, म्हणजे ते सुरुवातीपासून routable address वर listen करणार नाहीत. Postgres साठी listen_addresses = 'localhost' सेट करा. App server साठी त्याला 127.0.0.1 वर bind करा आणि समोर reverse proxy ठेवा. Listener बंद करणे firewall rule लावण्यापेक्षा अधिक प्रभावी आहे, कारण त्यानंतर पोहोचण्यासाठी कोणताही listener उपलब्ध राहत नाही.

Docker च्या published ports चे संरक्षण UFW करेल असे गृहीत धरू नका. Container ports प्रत्येक interface वर publish करण्याऐवजी विशिष्ट address वर publish करा. उदाहरणार्थ, -p 127.0.0.1:8080:80 वापरा. त्यामुळे तो port फक्त host आणि तुम्ही जाणीवपूर्वक proxy केलेल्या ठिकाणांहून उपलब्ध राहील. एखादा container खरोखर public असणे आवश्यक असल्यास, त्याला Traefik reverse proxy मागे ठेवा आणि प्रत्येक app ऐवजी फक्त proxy publish करा.

तुमच्या provider firewall मध्ये IPv6 rules जोडा, किंवा IPv6 साठी तो firewall नाही हे स्वीकारा आणि त्याऐवजी host वरील UFW किंवा nftables कडे ही जबाबदारी द्या.

तुम्ही प्रत्यक्षात बंद केले आहे याची पडताळणी करा

बदल केल्यानंतर पुन्हा बाहेरून तीच चाचणी चालवा:

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

ज्या port ने आधी प्रतिसाद दिला होता, तो आता connection नाकारला पाहिजे किंवा timeout झाला पाहिजे. nmap ने तो filtered किंवा closed असल्याचे दाखवले पाहिजे. एखादा port अजूनही open असल्यास, वर नमूद केलेल्या चार स्रोतांची पुन्हा तपासणी करा: कोणताही नियम नसताना सेवा अजूनही :: शी bind झालेली असणे, UFW च्या आधी Docker चा नियम लागू होणे किंवा provider firewall ने IPv6 traffic मुळीच पाहिले नसणे.

संवेदनशील सेवा सार्वजनिक internet वरून पूर्णपणे दूर ठेवणे अधिक सुरक्षित आहे. SSH आणि admin panels WireGuard VPN मागे ठेवा आणि त्यांच्या ports वर firewall नियम लावा, जेणेकरून ते फक्त tunnel वरूनच प्रतिसाद देतील. त्यामुळे त्यांच्यासाठी IPv6 exposure चा प्रश्न लागू राहत नाही. सार्वजनिक ठेवलेल्या सेवांवर होणारे brute-force scans कमी करण्यासाठी, default-deny firewall वर SSH च्या पुढे Fail2ban लावा.

Ports तुमच्यासाठी नवीन असतील, तर आधी ports म्हणजे काय आणि services कशा listen करतात हा परिचय वाचा.

FAQ

UFW डीफॉल्टनुसार IPv6 अवरोधित करते का?

आधुनिक Ubuntu 24.04 install मध्ये, होय. UFW /etc/default/ufw मधून IPV6=yes वाचते आणि प्रत्येक rule IPv4 तसेच IPv6 वर लागू करते. ufw status मध्ये IPv6 rules साठी (v6) suffix दिसतो. समस्या तेव्हा उद्भवते, जेव्हा IPV6=no (जुन्या image किंवा जुन्या tutorial मधून) असते, तुम्ही केवळ IPv4 traffic filter करणाऱ्या provider firewall वर अवलंबून असता किंवा Docker UFW च्या पलीकडे port publish करते. हे switch grep IPV6 /etc/default/ufw ने तपासा.

माझा VPS IPv6 वर काय उघडे ठेवत आहे हे कसे तपासू?

sudo ss -tlnp चालवा आणि ज्यांचा local address [::] ने सुरू होतो असे प्रत्येक listener नोंदवा. याचा अर्थ तो प्रत्येक IPv6 interface वर requests स्वीकारतो. त्यानंतर, वेगळ्या machine वरून server च्या public IPv6 address ची curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ ने थेट चाचणी करा किंवा nmap -6 YOUR:IPV6::ADDR ने scan करा. IPv6 scan मध्ये open पण IPv4 वर closed असलेला कोणताही port हा तुमच्या configuration मधील gap आहे.

UFW एखादा port blocked असल्याचे दाखवत असताना माझ्या Docker container च्या port पर्यंत पोहोचता का येते?

-p वापरून port publish केल्यावर Docker स्वतःचे firewall rules UFW च्या आधी लागू करते. त्यामुळे ufw status तो port denied असल्याचे दाखवत असले तरी published port reachable राहतो. हे IPv4 वर घडते आणि Docker चे IPv6 support सुरू असल्यास IPv6 वरही घडते. -p 127.0.0.1:8080:80 सारख्या specific address वर publish करा किंवा container ला reverse proxy च्या मागे ठेवा आणि फक्त proxy publish करा.

माझे IPv4 firewall मजबूत असल्यास IPv6 firewall तरीही आवश्यक आहे का?

होय. IPv4 आणि IPv6 हे स्वतंत्र network stacks असून त्यांचे firewall rules देखील स्वतंत्र असतात. IPv4 rules चा परिपूर्ण संच IPv6 traffic साठी काहीही करत नाही. तुमच्या VPS कडे public IPv6 address असल्यास, आणि बहुतेक VPS कडे तो असतो, तर :: वर listening करणारी कोणतीही service IPv6 वर reachable राहते. IPv6 firewall rule किंवा loopback binding ती थांबवत नाही तोपर्यंत हे असेच राहते.

एखादी service फक्त IPv4 वर किंवा फक्त localhost वर listen करेल अशी configuration कशी करावी?

Service च्या स्वतःच्या config मध्ये तिचा bind address सेट करा. फक्त IPv4 loopback साठी 127.0.0.1 वर bind करा किंवा कोणताही IPv6 listener नसलेल्या सर्व IPv4 addresses साठी 0.0.0.0 वर bind करा. Postgres मध्ये listen_addresses, SSH मध्ये ListenAddress वापरले जाते. बहुतेक app servers मध्ये host किंवा bind flag उपलब्ध असतो. sudo ss -tlnp ने परिणामाची खात्री करा आणि Local Address मध्ये यापुढे [::] दिसत नाही हे तपासा.