UFW IPv6 فائر وال میں کھلا دروازہ

IPv6 فائر وال کا یہ خطرہ ایک جملے میں

آپ کا فائر وال IPv4 کو محفوظ رکھتا ہے۔ آپ کے VPS میں تقریباً یقینی طور پر ایک پبلک IPv6 ایڈریس بھی موجود ہے، اور بہت سے سروسز بطور ڈیفالٹ اسی پر سنتی ہیں۔ اگر آپ کا فائر وال صرف IPv4 کا احاطہ کرتا ہے، یا آپ ایسے کلاؤڈ فائر وال پر انحصار کرتے ہیں جو صرف IPv4 کو فلٹر کرتا ہے، تو آپ کے IPv4 سائڈ کو بند لگنے کے باوجود ان میں سے ہر سروس پوری انٹرنیٹ سے IPv6 کے ذریعے قابل رسائی ہے۔ آپ ایک پورٹ کو curl سے ٹیسٹ کرتے ہیں، کنکشن مسترد ہوتا ہے، اور آپ محفوظ محسوس کرتے ہیں۔ ایک ہیکر اسی پورٹ پر IPv6 کے ذریعے کنکٹ ہوتا ہے اور اندر آ جاتا ہے۔

یہ گائیڈ بتاتا ہے کہ ایک عام Ubuntu 24.04 VPS پر یہ خطرہ کہاں سے پیدا ہوتا ہے، آپ کیا چیزیں بے نقاب کر رہے ہیں اسے عین طور پر کیسے دیکھیں، اور اسے کیسے بند کریں۔ UFW یہاں ولن نہیں ہے۔ جدید Ubuntu انسٹالیشن پر UFW پہلے ہی IPv6 کو سنبھال لیتا ہے۔ یہ بے نقابی اس کے ارد گرد موجود تہوں سے آتی ہے، اور ان سروسز سے جن کے سن رہے ہونے کا آپ کو علم نہیں تھا۔

آپ کا VPS سب سے پہلے IPv6 پر کیوں ہے

آج کے تقریباً ہر VPS میں ایک پبلک IPv6 ایڈریس ہوتا ہے، اکثر ایک مکمل /64، اس کے IPv4 ایڈریس کے ساتھ۔ اپنا چیک کریں:

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 انٹرنیٹ پر کہیں سے بھی قابل رسائی ہے، بالکل آپ کے IPv4 ایڈریس کی طرح۔ اب دیکھیں کہ کیا لسٹن کر رہا ہے:

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 ایڈریس پر لسٹن کریں۔" [::]:22 کا مطلب ہے "ہر IPv6 ایڈریس پر لسٹن کریں۔" 127.0.0.1:5432 لوپ بیک سے باؤنڈ ہے اور بالکل پبلک نہیں ہے، اس لیے Postgres لائن محفوظ ہے۔ دو [::] لائنیں IPv6 کے ذریعے پورے انٹرنیٹ کا جواب دیتی ہیں، اور docker-proxy وہ ہے جسے آپ شروع کرنا بھول جاتے ہیں۔

زیادہ تر ڈیمنز باکس سے باہر :: سے باؤنڈ ہوتے ہیں، کیونکہ Linux پر ایک :: ساکٹ عام طور پر IPv4 کو بھی قبول کرتا ہے۔ اس لیے ایک نئے سرور کا ڈیفالٹ رویہ "دونوں اسٹیکس پر، ہر جگہ جواب دیں" ہے۔ آپ کا فائر وال اس کے سامنے واحد چیز ہے، اسی لیے صرف ایک اسٹیک کو دیکھنے والا فائر وال ایک حقیقی مسئلہ ہے۔

IPv6 کا فرق دراصل کہاں سے آتا ہے

چار عام وجوہات ہیں۔ کسی خاص مشین پر آپ کو ان میں سے کوئی ایک یا ایک ساتھ کئی ہو سکتی ہیں۔

1. ایسا کلاؤڈ فائر وال جو صرف IPv4 کو فلٹر کرتا ہے۔ بہت سے فراہم کنندگان کے فائر وال اور سیکیورٹی گروپ پروڈکٹس IPv4 کے گرد بنے ہیں۔ یہ یا تو IPv6 کو نظر انداز کرتے ہیں یا الگ IPv6 قواعد کی ضرورت ہوتی ہے جو آپ کو دستی طور پر شامل کرنے پڑتے ہیں۔ اگر آپ کا واحد فائر وال فراہم کنندہ کے ڈیش بورڈ والا ہے اور وہ IPv6 کو احاطہ نہیں کرتا، تو آپ کی [::] سروسز کھلی ہوں گی، خواہ وہ IPv4 پر port 22 کے بارے میں کچھ بھی کہے۔ اپنے فراہم کنندہ کے فائر وال کی دستاویزات پڑھیں اور خاص طور پر IPv6 کالفظ تلاش کریں۔

2. دستی طور پر بنایا گیا iptables جس میں ip6tables نہیں ہے۔ iptables کمانڈ صرف IPv4 ٹیبلز کو تبدیل کرتی ہے۔ IPv6 کے لیے ایک بالکل الگ کمانڈ ہے، ip6tables، جس کے اپنے الگ قواعد ہیں۔ اگر آپ نے iptables -A INPUT ... لائنوں سے بھرا ہوا فائر وال اسکرپٹ لکھا ہے اور مطابقت رکھنے والے ip6tables قواعد کبھی نہیں لکھے، تو آپ کا IPv6 فائر وال خالی ہے، اور ایک خالی INPUT چین جس کی ڈیفالٹ پالیسی ACCEPT ہو، وہ سب کچھ کی اجازت دیتا ہے:

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. UFW جس میں IPv6 بند کر دیا گیا ہو۔ UFW IPv6 کو سنبھالتا ہے، لیکن صرف اس وقت جب اسے ایسا کرنے کے لیے کہا جائے۔ اس سوئچ کی جانچ کریں:

grep IPV6 /etc/default/ufw

جدید Ubuntu میں IPV6=yes شامل ہوتا ہے، اس لیے UFW ہر قاعدہ دونوں اسٹیکس پر لاگو کرتا ہے۔ اگر آپ کو IPV6=no نظر آتا ہے، جو کسی پرانی امیج یا پرانی گائیڈ کی وجہ سے ہو سکتا ہے، تو آپ نے جتنی بھی UFW قواعد لکھے ہیں وہ صرف IPv4 کے لیے ہیں، اور IPv6 بغیر انتظام چھوڑ دیا گیا ہے۔

دیکھیں کہ آپ کیا بے نقاب کر رہے ہیں

اندازہ نہ لگائیں۔ اسے باہر سے ناپیں۔ پہلے اپنے سننے والوں کی فہرست بنائیں اور ہر ایسے کو نوٹ کریں جو :: سے جڑا ہوا ہے:

sudo ss -tlnp | grep '::'

پھر، کسی دوسری مشین سے، سرور کے پبلک IPv6 پتے سے جڑیں اور ایک پورٹ آزمائیں جسے آپ بند سمجھتے ہیں:

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

اگر وہاں کوئی پیج یا بینر ملے تو پورٹ IPv6 پر کھلا ہوا ہے۔ بند پورٹ پر آپ کو Connection refused یا ٹائم آؤٹ ملے گا۔ مکمل صورتحال کے لیے، سرور سے باہر کسی مشین سے nmap کے ذریعے IPv6 پتہ اسکین کریں:

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

nmap جو بھی پورٹ IPv6 پر کھلا ہوا بتائے، وہ پورٹ پوری انٹرنیٹ کی پہنچ میں ہے، خواہ آپ کے IPv4 اسکین نے کچھ بھی دکھایا ہو۔ IPv4 اور IPv6 اسکین کو ایک ساتھ دیکھنا فرق تلاش کرنے کا تیز ترین طریقہ ہے: جو کچھ بھی -6 پر کھلا ہو مگر IPv4 پر بند ہو، وہ ایسا سروس ہے جسے آپ کا فائر وال نظر انداز کر رہا ہے۔

خلا کو ختم کریں

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 فلٹر ٹیبل بہترین حل ہے۔

ان سروسز کو loopback سے بائنڈ کریں جنہیں آپ عوامی نہیں چاہتے۔ ایک ڈیٹا بیس، ایک ایڈمن پینل، یا میٹرکس اینڈ پوائنٹ کے لیے شاذ و نادر ہی عوامی پتے کی ضرورت ہوتی ہے۔ اسے 127.0.0.1 اور ::1 سے بائنڈ کریں تاکہ یہ کسی روٹ ایبل پتے پر سننے کے لیے شروع ہی نہ ہو۔ Postgres کے لیے، listen_addresses = 'localhost' مقرر کریں۔ ایک ایپ سرور کے لیے، اسے 127.0.0.1 سے بائنڈ کریں اور اس کے سامنے ایک ریورس پراکسی لگائیں۔ لسنر کو بند کرنا اسے فائر وال سے محفوظ کرنے سے بہتر ہے، کیونکہ اس طرح پہنچنے کے لیے کچھ ہوتا ہی نہیں۔

Docker کے شائع کردہ پورٹس کی حفاظت کے لیے UFW پر بھروسہ نہ کریں۔ کنٹینر پورٹس کو ہر انٹرفیس کے بجائے ایک مخصوص پتے پر شائع کریں، مثال کے طور پر -p 127.0.0.1:8080:80، تاکہ پورٹ صرف ہوسٹ اور جس چیز کو آپ جان بوجھ کر پراکسی کرتے ہیں وہاں سے ہی قابل رسائی ہو۔ جب کسی کنٹینر کی واقعی عوامی ہونے ضرورت ہو، تو اسے ایک Traefik ریورس پراکسی کے پیچھے رکھیں اور صرف پراکسی شائع کریں، ہر ایپ کو نہیں۔

اپنے پرووائیڈر فائر وال میں IPv6 کے اصول شامل کریں، یا اس بات کو تسلیم کریں کہ یہ IPv6 کے لیے آپ کا فائر وال نہیں ہے اور ہوسٹ پر UFW یا nftables کو یہ کام کرنے دیں۔

تصدیق کریں کہ آپ واقعی بند ہیں

اپنی تبدیلیوں کے بعد وہی بیرونی ٹیسٹ دوبارہ چلائیں:

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

وہ پورٹ جو پہلے جواب دیتی تھی اب مسترد ہونی چاہیے یا ٹائم آؤٹ ہونا چاہیے، اور nmap کو اسے فلٹرڈ یا کلوزڈ رپورٹ کرنا چاہیے۔ اگر کوئی پورٹ اب بھی کھلی ہے، تو اوپر دیے گئے چاروں ذرائع پر دوبارہ غور کریں: :: سے اب بھی جُڑا ہوا کوئی سروس جس کے آگے کوئی رول نہیں ہے، UFW سے پہلے موجود کوئی Docker رول، یا ایسا پرووائیڈر فائر وال جس نے IPv6 کو دیکھا ہی نہیں۔

حساس سروسز کو عوامی انٹرنیٹ سے مکمل طور پر ہٹانا زیادہ بہتر ہے۔ SSH اور ایڈمن پینلز کو WireGuard VPN کے پیچھے رکھیں اور ان کے پورٹس کو فائر وال کے ذریعے بند کریں تاکہ وہ صرف ٹنل پر جواب دیں، اور پھر IPv6 ایکسپوژر کا مسئلہ ان پر لاگو نہیں ہوتا۔ جو کچھ عوامی رہتا ہے اس پر ہونے والے brute-force سکینز کو سست کرنے کے لیے، default-deny فائر وال کے ساتھ ساتھ SSH کے آگے Fail2ban لگائیں۔

اگر پورٹس خود آپ کے لیے نیا تصور ہیں، تو پورٹس کیا ہیں اور سروسز کیسے سنتی ہیں وہ بنیادی رہنما ہے جسے پہلے پڑھنا چاہیے۔

FAQ

کیا UFW بطورِ پیش فرض IPv6 کو بلاک کرتا ہے؟

ایک جدید Ubuntu 24.04 انسٹالیشن پر، ہاں۔ UFW /etc/default/ufw سے IPV6=yes کو پڑھتا ہے اور ہر اصول کو IPv4 اور IPv6 دونوں پر لاگو کرتا ہے، اور ufw status IPv6 کے اصولوں کو (v6) لاحقے کے ساتھ دکھاتا ہے۔ یہ مسئلہ اس وقت سامنے آتا ہے جب IPV6=no (کسی پرانی تصویر یا پرانے ٹیوٹوریل کی وجہ سے)، جب آپ کسی ایسے فراہم کنندہ فائر وال پر انحصار کرتے ہیں جو صرف IPv4 کو فلٹر کرتا ہے، یا جب Docker کسی پورٹ کو UFW سے گذر کر شائع کرتا ہے۔ اس سوئچ کو grep IPV6 /etc/default/ufw سے چیک کریں۔

میں کیسے چیک کروں کہ میرا VPS IPv6 پر کیا بے نقاب کر رہا ہے؟

sudo ss -tlnp چلائیں اور ہر اس لسنر کو نوٹ کریں جس کا مقامی پتہ [::] سے شروع ہوتا ہے، جس کا مطلب ہے کہ یہ ہر IPv6 انٹرفیس پر جواب دیتا ہے۔ پھر، کسی دوسری مشین سے، سرور کا عوامی IPv6 پتہ براہ راست curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ سے ٹیسٹ کریں، یا اسے nmap -6 YOUR:IPV6::ADDR سے سکین کریں۔ IPv6 سکین پر کوئی بھی پورٹ جو کھلی ہو لیکن IPv4 پر بند ہو، وہی آپ کا فرق ہے۔

جب UFW کہتا ہے کہ پورٹ بلاک ہے تو میں اپنے Docker کنٹینر کے پورٹ تک کیسے پہنچ سکتا ہوں؟

جب آپ کسی پورٹ کو -p کے ساتھ شائع کرتے ہیں تو Docker اپنے فائر وال کے اصولات UFW کے اصولات سے پہلے داخل کرتا ہے، لہذا شائع شدہ پورٹ قابلِ رسائی رہتی ہے حالانکہ ufw status اسے مسترد شدہ دکھاتا ہے۔ یہ IPv4 پر ہوتا ہے، اور IPv6 پر بھی ہوتا ہے جب Docker کی IPv6 سپورٹ آن ہو۔ کسی مخصوص پتے جیسے -p 127.0.0.1:8080:80 پر شائع کریں، یا کنٹینر کو کسی ریورس پراکسی کے پیچھے رکھیں اور صرف پراکسی شائع کریں۔

کیا مجھے اب بھی IPv6 فائر وال کی ضرورت ہے اگر میرا IPv4 فائر وال مضبوط ہے؟

ہاں۔ IPv4 اور IPv6 الگ نیٹ ورک اسٹیکس ہیں جن کے الگ فائر وال اصولات ہیں۔ IPv4 اصولات کا بہترین سیٹ IPv6 ٹریفک کے لیے کچھ نہیں کرتا۔ اگر آپ کے VPS کا ایک عوامی IPv6 پتہ ہے، اور تقریباً سب کا ہے، تو :: پر لسن کرنے والی کوئی بھی سروس اس وقت تک IPv6 پر قابلِ رسائی رہتی ہے جب تک کہ کوئی IPv6 فائر وال اصول یا لوپ بیک بائنڈنگ اسے نہ روکے۔

میں کسی سروس کو صرف IPv4 پر، یا صرف لوکل ہوسٹ پر لسن کرنے کے لیے کیسے بناؤں؟

سروس کا بائنڈ پتہ اس کی اپنی کنفیگ میں سیٹ کریں۔ صرف IPv4 لوپ بیک کے لیے 127.0.0.1 پر بائنڈ کریں، یا تمام IPv4 پتوں کے لیے 0.0.0.0 پر بائنڈ کریں جس میں کوئی IPv6 لسنر نہ ہو۔ Postgres listen_addresses استعمال کرتا ہے، SSH ListenAddress استعمال کرتا ہے، اور زیادہ تر ایپ سرورز ایک ہوسٹ یا بائنڈ فلیگ فراہم کرتے ہیں۔ نتیجہ کو sudo ss -tlnp سے تصدیق کریں اور چیک کریں کہ Local Address اب [::] کو نہیں دکھاتا۔