UFW اس لیے بنایا گیا تھا کہ فائروال تین کمانڈوں سے مرتب ہو سکے، اور اس میں وہ کامیاب ہے۔ مسئلہ کہیں اور ہے: ufw status ارادے دکھاتا ہے، نتائج نہیں۔ ایک قاعدہ فہرست میں ہو سکتا ہے اور بالکل کچھ بھی بند نہ کرتا ہو — تین مختلف وجوہ سے، اور یہ سب حقیقی سرورز پر باقاعدگی سے سامنے آتی ہیں۔

ایسا آغاز جو آپ کو باہر بند نہ کرے

کمانڈوں کی ترتیب اہم ہے۔ پہلے SSH کی اجازت دیں، پھر فعال کریں:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

SSH کی اجازت سے پہلے ufw enable آپ ہی کا سیشن کاٹ دیتا ہے، اور اس کے بعد صرف فراہم کنندہ کا کنسول بچتا ہے۔ اگر سرور پہلے سے مرتب ہے اور آپ کو یقین نہیں تو دوسرا کنکشن کھلا رکھیں — وہ ناکام ترمیم سے بچ جاتا ہے۔

تفصیلی حالت دیکھیں؛ مختصر والی طے شدہ پالیسی چھپا دیتی ہے:

sudo ufw status verbose

پہلی غلطی: قاعدہ موجود ہے اور پورٹ دنیا کے لیے کھلا ہے

دوسروں کی ترتیبات میں سب سے عام سطر:

sudo ufw allow 3306

MySQL یوں کھولا جاتا ہے «تاکہ گھر سے جڑ سکوں» — اور پورے انٹرنیٹ کے لیے کھل جاتا ہے۔ دو درست صورتیں ہیں اور دونوں بہتر ہیں:

sudo ufw allow from 203.0.113.25 to any port 3306

یا، اور زیادہ قابلِ اعتماد، سروس کو باہر نکلنے ہی نہ دیں: MySQL کی ترتیبات میں bind-address = 127.0.0.1، اور بیرونی رسائی SSH سرنگ کے ذریعے۔ فائروال دوسری صف ہے؛ پہلی یہ کہ سروس عوامی پتے پر سنے ہی نہیں۔ UFW کا قاعدہ غلطی سے مٹ سکتا ہے، جبکہ bind-address خود سے نہیں بدلتا۔

دوسری غلطی: IPv6

ufw allow from 203.0.113.25 جیسا قاعدہ صرف IPv4 پر لاگو ہوتا ہے۔ اگر سرور کا IPv6 پتہ ہو — اور بیشتر VPS کا ہوتا ہے، فعال — تو سروس اس کے ذریعے قابلِ رسائی رہتی ہے۔ فراہم کنندہ نے پتہ دیا، آپ کو یاد نہیں، اسکینر کو یاد ہے۔

جانچیں کہ v6 کی چھانٹ سرے سے فعال ہے (/etc/default/ufw میں IPV6=yes) اور سروس بلاضرورت :: پر نہیں سن رہی:

ss -tulpn | grep ':::'

جو قواعد پتہ واضح طور پر بتاتے ہیں انہیں پروٹوکول کے ہر نسخے کے لیے الگ لکھنا پڑتا ہے۔

تیسری غلطی: Docker

سب سے کوفت انگیز۔ Docker پورٹ شائع کرتے ہوئے اپنے قواعد iptables کی زنجیروں میں UFW کے لکھے ہوئے قواعد سے پہلے جوڑ دیتا ہے۔ نتیجتاً -p 5432:5432 کے ساتھ چلایا گیا کنٹینر انٹرنیٹ سے قابلِ رسائی ہوتا ہے حالانکہ UFW Status: active اور deny incoming کی پالیسی بتاتا ہے۔ فائروال خراب نہیں — بس اس کی باری ہی نہیں آتی۔

علاج UFW میں نہیں بلکہ پورٹ شائع کرنے کے طریقے میں ہے:

ports:
  - "127.0.0.1:5432:5432"

مقامی پتے سے جوڑنا سب سے سادہ اور قابلِ اعتماد حل ہے۔ باہر کی طرف صرف وہی دیکھنا چاہیے جو واقعی زائرین کو خدمت دیتا ہے: عموماً کسی ریورس پراکسی کے پورٹ 80 اور 443۔

قواعد کی ترتیب

UFW پہلا میل کھاتا قاعدہ لاگو کرتا ہے اور وہیں رک جاتا ہے۔ اس لیے اجازت کے بعد جوڑی گئی ممانعت کام نہیں کرے گی: اس کی باری ہی نہیں آتی۔ نمبر شماری دیکھیں اور جہاں ضرورت ہو وہاں داخل کریں:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

قواعد نمبر سے مٹتے ہیں، مگر ہر مٹانے کے بعد نمبر کھسک جاتے ہیں — ایک ایک کر کے مٹائیں اور فہرست دوبارہ پڑھیں۔

باہر سے جانچ

مقامی کمانڈیں دکھاتی ہیں کہ کیا مرتب ہے۔ واقعی کیا نکلا، یہ صرف کسی دوسری مشین سے نظر آتا ہے:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

کوئی بھی دوسرا سرور یا آپ کا گھریلو کمپیوٹر کام دے گا۔ یہی واحد جانچ ہے جو جھوٹ نہیں بولتی، اور ہر نمایاں دوبارہ ترتیب کے بعد اسے چلانا چاہیے — خاص طور پر ایسی کسی چیز کی تنصیب کے بعد جو «خود نیٹ ورک مرتب کرتی ہے»: Docker، کنٹرول پینل، VPN۔

لاگ

بطور طے شدہ UFW تقریباً کچھ نہیں لکھتا۔ اسے یوں فعال کریں:

sudo ufw logging low

اندراجات /var/log/ufw.log میں جاتے ہیں — مگر صرف اسی صورت جب نظام میں rsyslog ہو۔ Debian 12 اور Ubuntu 24.04 پر شاید نہ ہو، اور تب سب کچھ systemd کے جرنل میں چلا جاتا ہے:

sudo journalctl -k | grep -i '\[UFW'

خالی /var/log/ufw.log بذاتِ خود کچھ نہیں کہتا — پہلے جرنل میں دیکھیں۔

فائروال سے کیا توقع رکھیں

UFW وہ بند کرتا ہے جو قابلِ رسائی نہیں ہونا چاہیے۔ جو کھلا ہے اس کی درخواستوں کے مواد کی جانچ وہ نہیں کرتا: پورٹ 443 سب کے لیے کھلا ہے، اور سائٹ پر جو کچھ آتا ہے بلا رکاوٹ آتا ہے۔ یہ دوسرے اوزاروں کا کام ہے — ایپلیکیشن کی سطح پر WAF، اور ٹریفک کی سطح پر IDS۔ فائروال کا کام زیادہ سادہ اور زیادہ اہم ہے: کھلے پورٹوں کی فہرست اُس سے میل کھائے جو آپ اس کے بارے میں سمجھتے ہیں۔ یہ فہرست فعال قواعد کے ساتھ ایک صفحے پر کیسی لگتی ہے، نیچے ڈیمو دکھاتا ہے۔