VPS پر IPv6 firewall کی کھلی راہ کیسے بند کریں

ایک جملے میں IPv6 firewall کا مسئلہ

آپ کا firewall IPv4 کو محفوظ بناتا ہے۔ آپ کے VPS کے پاس تقریباً یقینی طور پر public IPv6 address بھی ہوتا ہے، اور بہت سی services بطور default اس پر listening کرتی ہیں۔ اگر آپ کا firewall صرف IPv4 کا احاطہ کرتا ہے، یا آپ ایسے cloud firewall پر انحصار کرتے ہیں جو صرف IPv4 traffic کو filter کرتا ہے، تو ان میں سے ہر service IPv6 کے ذریعے پوری internet سے قابل رسائی رہتی ہے، جبکہ آپ کا IPv4 حصہ محفوظ دکھائی دیتا ہے۔ آپ curl سے کسی port کو test کرتے ہیں، connection refused دیکھتے ہیں، اور خود کو محفوظ سمجھتے ہیں۔ ایک attacker اسی port سے IPv6 کے ذریعے connect کرتا ہے اور اندر داخل ہو جاتا ہے۔

یہ guide بتاتی ہے کہ عام Ubuntu 24.04 VPS پر یہ خلا کہاں سے پیدا ہوتا ہے، آپ عین کیا کچھ expose کر رہے ہیں اسے کیسے دیکھیں، اور اسے کیسے بند کریں۔ UFW یہاں مجرم نہیں ہے۔ جدید Ubuntu installation پر UFW پہلے ہی IPv6 کو handle کرتا ہے۔ exposure اس کے اردگرد موجود layers اور ان services کی وجہ سے ہوتا ہے جن کے listening کرنے سے آپ واقف نہیں تھے۔

آپ کا VPS بنیادی طور پر IPv6 پر کیوں دستیاب ہے

آج تقریباً ہر VPS کو اس کے IPv4 پتے کے ساتھ ایک public IPv6 address بھی ملتا ہے، جو اکثر مکمل /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 انٹرنیٹ پر کہیں سے بھی routable ہے، بالکل آپ کے IPv4 پتے کی طرح۔ اب دیکھیں کہ کون سی سروس 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 کالم کو غور سے دیکھیں۔ 0.0.0.0:22 کا مطلب ہے کہ سروس ہر IPv4 address پر listen کر رہی ہے۔ [::]:22 کا مطلب ہے کہ سروس ہر IPv6 address پر listen کر رہی ہے۔ 127.0.0.1:5432 loopback سے bound ہے اور بالکل public نہیں، اس لیے Postgres کی یہ لائن محفوظ ہے۔ دونوں [::] لائنیں IPv6 کے ذریعے پورے internet کو جواب دیتی ہیں، جبکہ docker-proxy وہ سروس ہے جسے آپ نے شروع کیا تھا اور بھول گئے۔

زیادہ تر daemons بطور default :: پر bind ہوتے ہیں، کیونکہ Linux میں :: socket عموماً IPv4 connections بھی قبول کرتا ہے۔ اس لیے نئے server کی default حالت یہ ہوتی ہے کہ وہ دونوں network stacks پر ہر جگہ سے آنے والی درخواستوں کا جواب دے۔ آپ کا firewall ہی اس کے سامنے واحد رکاوٹ ہے۔ اسی لیے ایسا firewall جو صرف ایک stack کو دیکھتا ہو، حقیقی مسئلہ بن جاتا ہے۔

اصل مسئلہ IPv6 کا خلا کہاں سے پیدا ہوتا ہے

اس کی چار عام وجوہات ہیں۔ کسی سرور پر ان میں سے ایک یا بیک وقت کئی وجوہات موجود ہو سکتی ہیں۔

1. ایسا cloud firewall جو صرف IPv4 کو filter کرتا ہے۔ بہت سے provider firewalls اور security-group products ابتدا میں IPv4 کے لیے بنائے گئے تھے۔ یہ یا تو IPv6 کو نظرانداز کرتے ہیں یا ان کے لیے الگ IPv6 rules درکار ہوتے ہیں، جنہیں آپ کو خود شامل کرنا پڑتا ہے۔ اگر آپ کا واحد firewall provider dashboard میں موجود ہے اور وہ IPv6 کو cover نہیں کرتا، تو آپ کی [::] services کھلی رہیں گی، چاہے IPv4 پر port 22 کے بارے میں کچھ بھی دکھایا گیا ہو۔ اپنے provider کی firewall documentation پڑھیں اور خاص طور پر IPv6 کا ذکر تلاش کریں۔

2. ایسا دستی طور پر بنایا گیا iptables configuration جس میں ip6tables موجود نہ ہو۔ iptables command صرف IPv4 tables پر اثرانداز ہوتی ہے۔ IPv6 کے لیے الگ command، ip6tables، استعمال ہوتی ہے اور اس کے rules بھی الگ ہوتے ہیں۔ اگر آپ نے iptables -A INPUT ... lines پر مشتمل firewall script لکھی ہے لیکن اس کے مطابق ip6tables rules نہیں لکھے، تو آپ کا IPv6 firewall خالی ہے۔ خالی INPUT chain اور default ACCEPT policy ہر چیز کی اجازت دیتی ہے:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

یہ output ایک ہی screen پر پورا مسئلہ دکھاتا ہے۔ IPv4 filter ہو رہا ہے، جبکہ IPv6 پوری دنیا سے connections قبول کر رہا ہے۔

3. Docker کا ports کو firewall سے گزرے بغیر براہ راست publish کرنا۔ جب آپ docker run -p 8080:80 چلاتے ہیں، تو Docker اپنے rules UFW کے rules سے پہلے شامل کرتا ہے۔ اس لیے published port اس وقت بھی قابل رسائی رہتا ہے جب ufw status دکھاتا ہو کہ وہ port denied ہے۔ جدید Docker میں یہی بات IPv6 پر بھی لاگو ہوتی ہے۔ Docker UFW کو bypass کیوں کرتا ہے اور container ports کو درست طریقے سے filter کیسے کریں میں اس mechanism اور اس کے حل کی وضاحت ہے۔ VPS پر Docker Compose کی بنیادی باتیں میں دیکھیں کہ یہ published ports کس طرح declare کیے جاتے ہیں۔

4. UFW میں IPv6 کا disabled ہونا۔ UFW IPv6 کو handle کرتا ہے، لیکن صرف اس وقت جب اسے اس کے لیے configure کیا جائے۔ یہ setting چیک کریں:

grep IPV6 /etc/default/ufw

جدید Ubuntu میں IPV6=yes شامل ہوتا ہے، اس لیے UFW ہر rule کو دونوں stacks پر apply کرتا ہے۔ اگر آپ کو IPV6=no نظر آئے، جو کسی پرانی image یا پرانی guide سے آیا ہو، تو آپ کے لکھے ہوئے تمام UFW rules صرف IPv4 تک محدود ہیں اور IPv6 unmanaged رہ جاتا ہے۔

معلوم کریں کہ آپ بالکل کیا expose کر رہے ہیں

اندازہ نہ لگائیں۔ باہر سے اس کی پیمائش کریں۔ پہلے اپنے listening ports کی فہرست بنائیں اور :: پر bind ہونے والے ہر port کو نوٹ کریں:

sudo ss -tlnp | grep '::'

پھر کسی دوسری machine سے server کے public IPv6 address سے connect کریں اور ایسا port آزما کر دیکھیں جس کے بارے میں آپ سمجھتے ہیں کہ وہ بند ہے:

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

اگر اس سے کوئی page یا banner واپس آتا ہے تو port IPv6 پر کھلا ہے۔ بند port آپ کو Connection refused یا timeout دیتا ہے۔ یہ دونوں failures ایک جیسا signal نہیں ہیں، اور refused اور timed out کے درمیان فرق سے معلوم ہوتا ہے کہ host نے جواب دے کر آپ کو واپس بھیجا یا firewall نے آپ کا packet خاموشی سے drop کر دیا۔ مکمل صورت حال دیکھنے کے لیے server سے باہر موجود machine سے nmap کے ذریعے IPv6 address scan کریں:

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

IPv6 پر nmap جس port کو open رپورٹ کرتا ہے، پورا internet اس تک پہنچ سکتا ہے، چاہے آپ کے IPv4 scan میں کچھ بھی دکھایا گیا ہو۔ IPv4 اور IPv6 scans کا ساتھ ساتھ موازنہ gap تلاش کرنے کا تیز ترین طریقہ ہے: -6 پر کھلا لیکن IPv4 پر بند ہر port ایسی service ہے جسے آپ کا firewall miss کر رہا ہے۔

خلا کو پُر کریں

UFW کو دونوں stacks کا احاطہ کرنے دیں اور default طور پر deny مقرر کریں۔ تبدیلی کی تصدیق کریں، پھر inbound traffic کے لیے default-deny policy مقرر کریں اور صرف مطلوبہ traffic کی اجازت دیں:

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 ہر rule کو 2 مرتبہ دکھاتا ہے: ایک مرتبہ سادہ صورت میں اور دوسری مرتبہ (v6) suffix کے ساتھ۔ جب آپ (v6) والی lines دیکھیں تو UFW IPv6 traffic filter کر رہا ہے:

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

اگر آپ iptables کو دستی طور پر manage کرتے ہیں تو ہر rule کو ip6tables میں بھی شامل کریں، یا nftables استعمال کریں۔ اس کے inet tables IPv4 اور IPv6 دونوں کا ایک ہی جگہ احاطہ کرتے ہیں اور اس قسم کی پوری غلطی ختم ہو جاتی ہے۔ اگر آپ خود rules لکھ رہے ہیں تو ایک ہی nftables inet filter table سب سے صاف حل ہے۔ اگر آپ کا VPS Ubuntu کے بجائے Rocky یا AlmaLinux چلاتا ہے تو configure کرنے کے لیے UFW موجود نہیں ہوتا۔ ایسی صورت میں firewalld وہ front end ہے جسے آپ manage کرتے ہیں، اور یہ دونوں stacks پر بیک وقت اپنی zone rules نافذ کرتا ہے۔

جن services کو public نہیں کرنا چاہتے، انہیں 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 سے block کرنے سے بہتر ہے، کیونکہ پھر پہنچنے کے لیے کوئی listener موجود ہی نہیں رہتا۔

Docker کے published ports کی حفاظت کے لیے UFW پر بھروسا نہ کریں۔ Container ports کو ہر interface کے بجائے کسی مخصوص address پر publish کریں، مثلاً -p 127.0.0.1:8080:80، تاکہ port صرف host اور ان targets سے reachable ہو جنہیں آپ دانستہ طور پر proxy کرتے ہیں۔ جب کسی container کو واقعی public ہونا ضروری ہو تو اسے Traefik reverse proxy کے پیچھے رکھیں اور صرف proxy کو publish کریں، ہر app کو نہیں۔

اپنے 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 ہے تو اوپر بیان کردہ چار ذرائع دوبارہ جانچیں: کوئی service اب بھی :: پر bind ہے اور اس کے سامنے کوئی rule موجود نہیں، Docker کا کوئی rule UFW سے پہلے لاگو ہو رہا ہے، یا provider firewall نے IPv6 ٹریفک کو کبھی دیکھا ہی نہیں۔

حساس services کو public internet سے مکمل طور پر دور رکھنا اس سے بھی زیادہ مضبوط طریقہ ہے۔ SSH اور admin panels کو WireGuard VPN کے پیچھے رکھیں اور ان کے ports کو اس طرح firewall کریں کہ وہ صرف tunnel پر جواب دیں۔ اس صورت میں IPv6 exposure کا سوال ان services پر لاگو نہیں رہتا۔ جو چیزیں public رہتی ہیں، ان پر ہونے والے brute-force scans کو سست کرنے کے لیے default-deny firewall کے ساتھ SSH کے سامنے Fail2ban رکھیں۔

اگر ports کا تصور آپ کے لیے نیا ہے تو پہلے ports کیا ہیں اور services کیسے listen کرتی ہیں پڑھیں۔

FAQ

کیا UFW بطور ڈیفالٹ IPv6 کو block کرتا ہے؟

جدید Ubuntu 24.04 کی installation میں جواب ہاں ہے۔ UFW /etc/default/ufw سے IPV6=yes پڑھتا ہے اور ہر rule کو IPv4 اور IPv6 دونوں پر لاگو کرتا ہے، جبکہ ufw status IPv6 rules کو (v6) suffix کے ساتھ دکھاتا ہے۔ مسئلہ اس وقت پیدا ہوتا ہے جب IPV6=no کسی پرانی image یا پرانے tutorial سے آیا ہو، جب آپ ایسے provider firewall پر انحصار کریں جو صرف IPv4 کو filter کرتا ہو، یا جب Docker کسی port کو UFW سے آگے publish کر دے۔ grep IPV6 /etc/default/ufw سے یہ setting check کریں۔

میں کیسے check کروں کہ میرا VPS IPv6 پر کیا expose کر رہا ہے؟

sudo ss -tlnp چلائیں اور ہر اس listener کو نوٹ کریں جس کا local address [::] سے شروع ہوتا ہے۔ اس کا مطلب ہے کہ وہ ہر IPv6 interface پر requests قبول کرتا ہے۔ پھر کسی دوسری machine سے server کے public IPv6 address کو براہِ راست curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ کے ذریعے test کریں، یا nmap -6 YOUR:IPV6::ADDR سے scan کریں۔ IPv6 scan میں open لیکن IPv4 پر closed ہر port آپ کے security gap کی نشاندہی کرتا ہے۔

UFW کے blocked بتانے کے باوجود میں اپنے Docker container کے port تک کیوں پہنچ سکتا ہوں؟

جب آپ -p کے ذریعے کوئی port publish کرتے ہیں تو Docker اپنے firewall rules، UFW rules سے پہلے insert کرتا ہے۔ اس لیے published port قابلِ رسائی رہتا ہے، حالانکہ ufw status اسے denied دکھاتا ہے۔ یہ IPv4 پر ہوتا ہے، اور Docker کی IPv6 support فعال ہونے پر IPv6 پر بھی ہوتا ہے۔ کسی مخصوص address، مثلاً -p 127.0.0.1:8080:80، پر publish کریں، یا container کو reverse proxy کے پیچھے رکھیں اور صرف reverse proxy کو publish کریں۔

اگر میرا IPv4 firewall مضبوط ہے تو کیا مجھے پھر بھی IPv6 firewall درکار ہے؟

ہاں۔ IPv4 اور IPv6 الگ network stacks ہیں اور ان کے firewall rules بھی الگ ہوتے ہیں۔ IPv4 rules کا مکمل set IPv6 traffic پر کوئی اثر نہیں ڈالتا۔ اگر آپ کے VPS کا public IPv6 address ہے، اور تقریباً تمام VPS میں ہوتا ہے، تو :: پر listening کرنے والی کوئی بھی service IPv6 کے ذریعے قابلِ رسائی رہتی ہے، جب تک IPv6 firewall rule یا loopback binding اسے روک نہ دے۔

میں کسی service کو صرف IPv4 پر، یا صرف localhost پر، کیسے listen کروا سکتا ہوں؟

Service کی اپنی configuration میں bind address مقرر کریں۔ صرف IPv4 loopback کے لیے 127.0.0.1 پر bind کریں، یا تمام IPv4 addresses کے لیے 0.0.0.0 پر bind کریں؛ اس صورت میں IPv6 listener نہیں ہوگا۔ Postgres میں listen_addresses استعمال ہوتا ہے، SSH میں ListenAddress، اور زیادہ تر app servers host یا bind flag فراہم کرتے ہیں۔ نتیجہ sudo ss -tlnp سے confirm کریں اور check کریں کہ Local Address اب [::] نہیں دکھاتا۔