ٹوٹا ہوا ufw ruleset بحال کرنے کا طریقہ

پہلے دوبارہ رسائی حاصل کریں

اگر ufw نے آپ کو اپنے VPS سے باہر کر دیا ہے تو واپس داخل ہونے کا طریقہ provider console یا rescue mode ہے، کیونکہ blocking rule فعال ہونے کے بعد SSH پر مبنی کوئی حل کام نہیں کرتا۔ Kernel آپ کے packet کو sshd تک پہنچنے سے پہلے ہی drop کر دیتا ہے، اس لیے network کے ذریعے login یا مسئلہ حل کرنے کا کوئی راستہ نہیں رہتا۔ اپنے provider کے control panel میں console کھولیں، اس prompt پر login کریں، اور ایک command چلائیں۔

sudo ufw disable

آپ کو Firewall stopped and disabled on system startup نظر آنا چاہیے۔ نئی SSH connections ایک یا دو seconds میں دوبارہ کام کرنے لگتی ہیں۔ آپ کی کوئی configuration ضائع نہیں ہوتی: disable rules کو kernel سے unload کرتا ہے اور ENABLED=no کو /etc/ufw/ufw.conf میں لکھتا ہے، جبکہ آپ کے rules disk پر /etc/ufw/user.rules میں موجود رہتے ہیں اور اگلے ufw enable کا انتظار کرتے ہیں۔

reboot نہ کریں اور امید نہ رکھیں کہ مسئلہ حل ہو جائے گا۔ ufw boot کے وقت خود شروع ہوتا ہے، اس لیے ENABLED=yes کا مطلب ہے کہ network فعال ہونے سے پہلے وہی ruleset دوبارہ load ہو جائے گا۔ reboot کرنے سے ufw lockout کے بارے میں کچھ نہیں بدلتا۔

کنسول کے لیے ایسا password درکار ہے جو ممکن ہے آپ کے پاس نہ ہو

Web console (VNC یا serial) مشین سے منسلک keyboard ہوتا ہے۔ یہ network path نہیں ہوتا، اس لیے کوئی firewall rule اسے block نہیں کر سکتا۔ تاہم اس کے لیے local login درکار ہوتا ہے۔ یہی وہ مقام ہے جہاں صرف key پر مبنی setup ناکام ہوتے ہیں: اگر آپ نے اپنے sudo user کے لیے کبھی password مقرر نہیں کیا، اور root login locked ہے، تو کنسول ایسا prompt دکھاتا ہے جس کا آپ جواب نہیں دے سکتے۔ SSH دستیاب رہتے ہوئے ابھی یہ password مقرر کریں: sudo passwd yourname۔ زیادہ تر panels root password reset کرنے کی سہولت بھی دیتے ہیں، جس سے عموماً reboot ضروری ہو جاتا ہے۔

اگر کنسول قابلِ استعمال نہ ہو تو provider کا rescue system boot کریں۔ یہ ایک الگ operating system چلاتا ہے اور آپ کی disk mounted نہیں ہوتی، اس لیے آپ باہر سے ufw بند کر سکتے ہیں۔

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

پہلے lsblk چلائیں، کیونکہ root partition ہمیشہ /dev/vda1 نہیں ہوتی۔ Normal system میں reboot کریں۔ ufw اس وقت تک بند رہے گا جب تک آپ اسے خود enable نہ کریں۔

کم سے کم بحالی کا سلسلہ

اس ترتیب سے کام کریں۔ پہلے چار مراحل محفوظ ہیں۔ اس کے بعد والا محفوظ نہیں ہے۔

1. قواعد unload کرنے اور اپنی رسائی بحال کرنے کے لیے sudo ufw disable چلائیں۔
2. اپنے شامل کردہ قواعد ان commands کی صورت میں دکھانے کے لیے sudo ufw show added چلائیں جن سے وہ قواعد شامل کیے گئے تھے۔ یہ command اس وقت کام کرتی ہے جب ufw inactive ہو، جبکہ ufw status ایسا نہیں کرتا۔
3. اس کی تصدیق کرنے کے لیے sudo sshd -T | grep -i '^port' چلائیں کہ sshd واقعی کس port پر listening کر رہا ہے۔ اگر آپ نے اسے تبدیل نہ کیا ہو تو یہ port 22 دکھاتا ہے۔
4. اپنی حقیقی port استعمال کرتے ہوئے sudo ufw allow 22/tcp چلائیں، تاکہ اگلا enable دوبارہ lockout کا سبب نہ بنے۔
5. sudo ufw enable چلائیں، لیکن پہلے rollback schedule کریں۔ اس کی وضاحت اس صفحے کے نچلے حصے میں ہے۔

ufw reset اصل میں کیا کرتا ہے

ufw reset آخری چارہ کار ہے، پہلا قدم نہیں۔ یہ firewall کو disable کرتا ہے، rules کی ہر file کا backup بناتا ہے، اور default پالیسی کو incoming traffic کے لیے deny اور outgoing traffic کے لیے allow پر واپس لے آتا ہے۔ یہ ہر file کے لیے backup کی ایک سطر دکھاتا ہے:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

reset کے بعد آپ کے پاس کوئی allow rule نہیں رہتا۔ اس لیے اسے SSH کے ذریعے نہیں بلکہ console سے چلائیں، اور دوبارہ enable کرنے سے پہلے SSH rule شامل کریں۔ یہ backups سادہ text files ہوتی ہیں۔ sudo grep -n dport /etc/ufw/user.rules.20260813_101500 دکھاتا ہے کہ پرانے rules کیا تھے۔ اسی کی مدد سے آپ وہ ruleset دوبارہ بنا سکتے ہیں جسے آپ کا مقصد ضائع کرنا نہیں تھا۔

ufw اپنے rules کہاں محفوظ کرتا ہے

فائلیں پڑھنا، یادداشت سے اندازہ لگانے سے بہتر ہے۔ یہ 5 paths مکمل state محفوظ کرتے ہیں:

• /etc/ufw/user.rules اور /etc/ufw/user6.rules: آپ کے شامل کردہ rules، اسی ترتیب میں جس میں ان کا جائزہ لیا جاتا ہے۔
• /etc/ufw/before.rules اور /etc/ufw/after.rules، نیز 6 variants: وہ framework جس کے گرد ufw آپ کے rules کو منظم کرتا ہے، جس میں established connections کے لیے accept اور loopback rules شامل ہیں۔
• /etc/default/ufw: default policies اور IPV6 switch۔
• /etc/ufw/ufw.conf: ENABLED اور log level۔
• /var/log/ufw.log: logging فعال ہونے کے بعد کیا block کیا گیا۔

ufw کسی file کو دوبارہ لکھنے سے پہلے اس کی timestamp والی copy بناتا ہے، اس لیے ls /etc/ufw/ میں user.rules.20260813_101500 جیسے نام جمع ہوتے رہتے ہیں۔ یہ آپ کی undo history ہے، اور تبدیلیاں واپس کرنے سے پہلے اسے پڑھنا مفید ہے۔

disk پر موجود configuration کے بجائے kernel میں loaded configuration دیکھنے کے لیے sudo ufw show raw، یا sudo iptables -S اور sudo ip6tables -S استعمال کریں۔ Ubuntu 22.04 اور 24.04 میں یہ commands nft کے زیرِ پشت versions ہیں، اس لیے sudo nft list ruleset نئے syntax میں وہی rules دکھاتا ہے۔

ufw فعال کرنے سے میرا SSH session کیوں منقطع ہو گیا؟

Incoming traffic کی default policy deny ہوتی ہے۔ SSH port کے لیے کوئی rule بنائے بغیر ufw فعال کرنے سے ہر نئی connection بند ہو جاتی ہے۔ ufw اس بارے میں warning بھی دیتا ہے: Command may disrupt existing ssh connections. Proceed with operation (y|n)? SSH کے لیے allow rule موجود نہ ہونے پر y کا جواب دینا اس پورے صفحے پر بیان کردہ مسئلے کی سب سے عام وجہ ہے۔

الجھن تاخیر کی وجہ سے پیدا ہوتی ہے۔ /etc/ufw/before.rules آپ کے بنائے ہوئے rules تک پہنچنے سے پہلے ESTABLISHED,RELATED state کے packets قبول کرتا ہے، اس لیے جس session میں آپ نے command چلائی تھی وہ معمول کے مطابق کام کرتا رہتا ہے۔ lockout صرف اگلی connection پر ظاہر ہوتا ہے، جو کئی گھنٹے بعد بھی بن سکتی ہے، اور اس وقت firewall کی تبدیلی اس سے متعلق محسوس نہیں ہوتی۔ پہلی connection بند کرنے سے پہلے ہمیشہ دوسری SSH session کھول کر تصدیق کریں کہ وہ کام کر رہی ہے۔

apt اور DNS پالیسی میں تبدیلی کے بعد کیوں کام کرنا بند کر گئے؟

sudo ufw default deny outgoing outbound DNS (domain name system) queries اور outbound HTTP کو block کرتا ہے، اس لیے name resolution ختم ہو جاتی ہے اور package updates رک جاتی ہیں۔ apt update، Temporary failure resolving 'archive.ubuntu.com' رپورٹ کرتا ہے۔ Inbound SSH اب بھی کام کرتا ہے، کیونکہ اس کے جوابات ESTABLISHED ہوتے ہیں اور framework rules سے گزر جاتے ہیں۔ اس طرح firewall بظاہر بے قصور لگتا ہے، حالانکہ اصل وجہ وہی ہے۔

اگر آپ outgoing traffic کے لیے deny policy چاہتے ہیں تو صرف وہی کھولیں جس کی machine کو واقعی ضرورت ہے:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

آخری rule کے بغیر clock میں وقت کا فرق بڑھتا رہتا ہے، اور غلط clock TLS (transport layer security) certificate validation کو ناکام کر دیتی ہے۔ اس کے بعد curl ports کے بجائے dates کی بنیاد پر fail ہونا شروع ہوتا ہے۔ یہ علامت تبدیلی کے کئی دن بعد ظاہر ہوتی ہے۔ اسی لیے deny outgoing ایسی machines کے لیے policy ہے جنہیں آپ monitor کرتے ہیں، نہ کہ ایسی box کے لیے جسے آپ صرف ایک بار setup کرتے ہیں۔

میرا ufw rule کبھی match کیوں نہیں کرتا؟

ufw صارف کے rules کو ترتیب سے evaluate کرتا ہے اور پہلے match پر رک جاتا ہے۔ وسیع `allow کے بعد شامل کیا گیا deny کبھی apply نہیں ہوتا، کیونکہ allow` پہلے ہی packet کے بارے میں فیصلہ کر چکا ہوتا ہے۔ ترتیب کو نمبروں کے ساتھ دکھائیں، پھر مطلوبہ position پر rule insert کریں۔

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

`sudo ufw --dry-run allow 8080/tcp` ان rules کو دکھاتا ہے جو لکھے جائیں گے، لیکن کوئی تبدیلی نہیں کرتا۔ کسی rule کے live ہونے سے پہلے اسے پڑھنے کا یہ محفوظ طریقہ ہے۔

Application profiles میں ایک اور مسئلہ ہوتا ہے۔ `sudo ufw allow OpenSSH، /etc/ufw/applications.d/openssh-server میں موجود profile استعمال کرتا ہے، اور اس profile کا مطلب port 22 ہے۔ اگر sshd`، 2222 پر listening کر رہا ہو تو rule ایسے port کو کھول دے گا جسے کوئی service استعمال نہیں کر رہی، اور آپ ایسے ruleset کے ساتھ access سے محروم ہو جائیں گے جو بظاہر درست دکھائی دیتا ہے۔ Port منتقل کرنے کے بعد port number براہِ راست استعمال کریں۔ باقی syntax کی وضاحت VPS کے لیے ufw firewall کی بنیادی باتیں میں ہے۔

IPv4 قواعد میرے مشاہدے کی وضاحت کیوں نہیں کرتیں؟

کیونکہ آدھی network traffic IPv4 نہیں ہے۔ Ubuntu /etc/default/ufw میں IPV6=yes فراہم کرتا ہے، اور ufw پھر /etc/ufw/user6.rules میں متوازی v6 ruleset برقرار رکھتا ہے۔ IPv4 address کے ساتھ لکھی گئی rule، مثلاً ufw allow from 203.0.113.10 to any port 22، کوئی v6 rule نہیں بناتی۔ اگر آپ کے VPS کے لیے AAAA record موجود ہے، client IPv6 کو ترجیح دیتا ہے، اور آپ کا connection timeout ہو جاتا ہے، جبکہ ufw status ایسی rule دکھاتا ہے جو درست معلوم ہوتی ہے۔ ssh -4 user@host کو ssh -6 user@host کے مقابل چلا کر فرق کی جانچ کریں۔ اگر پہلی command کامیاب ہو اور دوسری ناکام، تو مسئلہ v6 ruleset میں ہے۔

اس کے برعکس صورت security کے لیے زیادہ خطرناک ہے۔ IPV6=no کے ساتھ ufw ip6tables کو بالکل manage نہیں کرتا، اس لیے v6 policy kernel کے default ACCEPT پر رہتی ہے۔ جس port کو آپ بند سمجھتے ہیں، وہ اپنے IPv6 address پر جواب دیتا ہے، اور کوئی ufw command اسے کبھی ظاہر نہیں کرے گی۔ sudo ip6tables -S اور ss -tlnp سے جانچ کریں، اور مکمل وضاحت کے لیے ufw IPv6 ports کو کیسے handle کرتا ہے پڑھیں۔

Docker کے port کے کھلے ہونے کی وجہ کیا ہے، جبکہ ufw اسے deny کر رہا ہے؟

Docker، nat table میں DNAT (destination network address translation) rules لکھ کر اور FORWARD میں اپنی chain شامل کر کے ports publish کرتا ہے۔ ufw کے rules INPUT path میں موجود ہوتے ہیں۔ Container تک جانے والی traffic host کو deliver ہونے کے بجائے forward کی جاتی ہے، اس لیے وہ اس chain تک نہیں پہنچتی جس میں آپ کا deny rule موجود ہے۔ چنانچہ ufw کے فعال ہونے اور ہر چیز deny کرنے کے باوجود docker run -p 5432:5432 internet سے قابل رسائی رہتا ہے۔

sudo iptables -t nat -S DOCKER

آسان ترین حل یہ ہے کہ port کو loopback پر publish کریں: -p 127.0.0.1:5432:5432 host side کو 127.0.0.1 سے bind کرتا ہے، اور ufw کی setting کچھ بھی ہو، کوئی external system اسے access نہیں کر سکتا۔ ufw کے اردگرد Docker ports publish کرنا ان صورتوں کا احاطہ کرتا ہے جن میں service کو public رکھنا ضروری ہو۔

قاعدہ لاگو کرنے سے پہلے rollback schedule کریں

یہ وہ عادت ہے جو firewall کے کام کو قابلِ انتظام بناتی ہے۔ کسی بھی خطرناک تبدیلی سے پہلے اسے واپس کرنے کا عمل schedule کریں۔ اگر تبدیلی آپ کو access سے محروم کر دے تو machine پانچ منٹ میں خود بحال ہو جاتی ہے، اور آپ کو console کھولنے کی ضرورت نہیں پڑتی۔

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd Running timer as unit: ufw-rollback.timer print کرتا ہے۔ اب اپنی تبدیلی کریں۔ اگر اس کے بعد بھی آپ نیا SSH session کھول سکتے ہیں تو rollback cancel کریں:

sudo systemctl stop ufw-rollback.timer

اگر آپ وہ session نہیں کھول سکتے تو انتظار کریں۔ ufw خود بند ہو جائے گا، اور آپ کی اگلی کوشش connect ہو جائے گی۔ کلاسک shutdown -r +5 trick ufw کے ساتھ مدد نہیں کرتی، کیونکہ ufw boot کے وقت وہی ruleset دوبارہ load کرتا ہے۔

دوسرا طریقۂ رسائی برقرار رکھیں

• ضرورت پیش آنے سے پہلے provider console میں ایک بار login کریں اور تصدیق کریں کہ password کام کرتا ہے۔ جس console کو آپ نے کبھی test نہ کیا ہو، وہ backup نہیں ہے۔
• اپنا الگ key رکھنے والا دوسرا sudo user برقرار رکھیں، تاکہ ایک خراب authorized_keys file آپ کی رسائی مکمل طور پر ختم نہ کر دے۔
• معلوم کریں کہ آیا آپ کا provider panel میں ufw سے الگ network firewall چلاتا ہے۔ یہ وہی ports block کرتا ہے، اور ufw status اس کا کبھی ذکر نہیں کرے گا۔
• اگر وہ address dynamic ہے تو ufw allow from <your home address> کو اپنا واحد SSH rule نہ بنائیں۔ provider اسے راتوں رات تبدیل کر دے گا اور آپ کی رسائی ختم ہو جائے گی۔

یہ سب کرنے کا سب سے کم خرچ وقت fresh server پر ہوتا ہے۔ اسے دیگر setup کاموں کے ساتھ نئے VPS کے پہلے دس منٹ میں مکمل کریں۔

Refused یا timed out سے معلوم ہوتا ہے کہ خرابی کس layer میں ہے

Connection refused کا مطلب ہے کہ packet سرور تک پہنچا اور کسی چیز نے واپس TCP reset بھیجا۔ Network path درست ہے، اس لیے یا تو sshd بند ہے یا مختلف port پر listening کر رہا ہے۔ Firewall شاذونادر ہی وجہ ہوتا ہے، کیونکہ ufw default طور پر drop کرتا ہے، reject نہیں۔

Connection timed out کا مطلب ہے کہ بالکل کوئی جواب واپس نہیں آیا۔ یہ drop کی علامت ہے: ufw، provider کا network firewall، یا غلط address۔ ان دونوں errors کو درست طور پر سمجھنے سے اندازہ لگانے میں ضائع ہونے والا ایک گھنٹہ بچ جاتا ہے، اور connection refused اور timed out کے درمیان فرق باقی cases کی وضاحت کرتا ہے۔

اگلی تبدیلی سے پہلے logging فعال کریں

sudo ufw logging on
sudo tail -f /var/log/ufw.log

بلاک کیا گیا packet اس طرح نظر آتا ہے:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 میں اپنا address اور SRC= میں موجود اندراج اس بات کا ثبوت ہے کہ آپ کو ufw روک رہا ہے، نہ کہ network اور نہ ہی sshd۔ ایسی minimal image میں جس میں rsyslog موجود نہ ہو، /var/log/ufw.log نہیں ہوتا، اور یہی lines sudo journalctl -k | grep UFW سے آتی ہیں۔ ufw اپنی logging rules پر rate limiting نافذ کرتا ہے، اس لیے کسی line کا نہ ملنا اس بات کا ثبوت نہیں کہ packet کو اجازت دی گئی تھی۔

اگر آپ کو ایسی rules ملیں جو آپ نے شامل نہیں کیں

جو ruleset خود تبدیل ہو جائے، وہ firewall کا مسئلہ نہیں ہوتا۔ کسی ایسے شخص نے، جس کے پاس root رسائی تھی، اسے تبدیل کیا ہے۔ چلائے گئے sudo commands اور متعلقہ account دیکھنے کے لیے sudo grep ufw /var/log/auth.log چلائیں، پھر اسی timestamp کے آس پاس کے logins دیکھنے کے لیے last چلائیں۔ اگر accounts آپ کے علم میں موجود کسی شخص سے مطابقت نہیں رکھتے تو firewall کی debugging روک دیں اور اس کے بجائے compromised VPS checklist پر کام کریں۔ جس box پر کوئی دوسرا شخص control رکھتا ہو، اس پر firewall دوبارہ فعال کرنے سے مسئلہ صرف چھپتا ہے۔

اسے دوبارہ درست حالت میں لائیں

وجہ معلوم ہونے کے بعد ufw کو اس طرح دوبارہ فعال کریں کہ lockout دوبارہ نہ ہو سکے۔ اپنا اصل SSH port allow کریں، rollback شیڈول کریں، ufw فعال کریں، پھر کسی دوسرے terminal سے بالکل نیا SSH session کھول کر تصدیق کریں کہ یہ connect ہو رہا ہے۔ اس نئے session کے قائم ہونے کے بعد ہی موجودہ session بند کریں۔ ایک دن تک logging فعال رکھیں، کیونکہ log یہ زیادہ تیزی سے بتاتا ہے کہ آپ کس چیز کو allow کرنا بھول گئے، بہ نسبت user.rules پڑھنے کے۔

FAQ

کیا ufw disable میرے rules حذف کر دیتا ہے؟

نہیں۔ disable ruleset کو kernel سے unload کرتا ہے اور ENABLED=no کو /etc/ufw/ufw.conf میں لکھتا ہے۔ آپ کے rules /etc/ufw/user.rules اور /etc/ufw/user6.rules میں موجود رہتے ہیں، اور firewall غیر فعال ہونے کے باوجود sudo ufw show added انہیں فہرست میں دکھاتا ہے۔ انہیں صاف کرنے کا command ufw reset ہے، اور یہ ہر file کا پہلے backup بناتا ہے۔ یہ Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' جیسی line دکھاتا ہے۔

کیا میرے VPS کو reboot کرنے سے ufw lockout ختم ہو جائے گا؟

نہیں۔ ufw boot کے وقت /etc/ufw/ufw.conf میں موجود ENABLED=yes سے شروع ہوتا ہے، اس لیے network شروع ہونے سے پہلے وہی rules دوبارہ load ہو جاتے ہیں اور آپ پھر lock out ہو جاتے ہیں۔ reboot صرف اس وقت مدد کرتا ہے جب آپ ufw بند کر چکے ہوں، یا rescue mode میں disk mount کر کے اس file میں ترمیم کر چکے ہوں۔ provider console استعمال کریں اور وہاں sudo ufw disable چلائیں۔

ufw port deny کرنے کے باوجود میرا Docker container reachable کیوں ہے؟

Docker ہر published port کے لیے اپنے DNAT اور FORWARD rules لکھتا ہے۔ یہ traffic host کو deliver ہونے کے بجائے container کو forward ہو جاتا ہے، اس لیے یہ INPUT chain سے نہیں گزرتا جہاں آپ کا ufw deny rule موجود ہوتا ہے۔ جب port صرف host کے لیے ہو تو -p 127.0.0.1:5432:5432 کے ساتھ اسے loopback پر publish کریں، اور Docker نے کیا install کیا ہے یہ دیکھنے کے لیے sudo iptables -t nat -S DOCKER کا معائنہ کریں۔

میرے پاس console password اور rescue mode دونوں نہیں ہیں۔ میرے options کیا ہیں؟

باقی options آپ کے provider سے متعلق ہیں: control panel سے password reset، جس سے عموماً server reboot ہوتا ہے، یا disk کو کسی دوسرے instance کے ساتھ attach کرنا تاکہ آپ وہاں سے /etc/ufw/ufw.conf میں ترمیم کر سکیں۔ server rebuild کرنے سے پہلے support سے پوچھیں، کیونکہ rebuild اس میں موجود data کو تباہ کر دیتا ہے۔ واپس login ہونے کے بعد sudo passwd yourname چلائیں اور console login ایک بار test کریں، تاکہ اگلا lockout آپ کے دو منٹ سے زیادہ نہ لے۔