बिघडलेला ufw ruleset दुरुस्त करून प्रवेश कसा मिळवावा

प्रथम पुन्हा प्रवेश मिळवा

ufw मुळे तुमच्या VPS मधून तुमचा प्रवेश बंद झाला असल्यास, पुन्हा प्रवेश मिळवण्याचा मार्ग provider console किंवा rescue mode हा आहे. कारण blocking rule लागू झाल्यानंतर SSH वर आधारित कोणताही उपाय उपलब्ध राहत नाही. sshd ला तुमचे packet दिसण्यापूर्वीच kernel ते टाकून देतो. त्यामुळे नेटवर्कद्वारे login करण्यासाठी किंवा दुरुस्ती करण्यासाठी काहीही उपलब्ध राहत नाही. तुमच्या provider च्या control panel मध्ये console उघडा, त्या prompt वर login करा आणि एक command चालवा.

sudo ufw disable

तुम्हाला Firewall stopped and disabled on system startup दिसले पाहिजे. एक किंवा दोन सेकंदांत नवीन SSH connections पुन्हा कार्य करू लागतात. तुम्ही केलेली कोणतीही configuration हरवत नाही: disable kernel मधून rules unload करते आणि ENABLED=no ला /etc/ufw/ufw.conf मध्ये लिहिते, तर तुमचे rules पुढील ufw enable ची प्रतीक्षा करत /etc/ufw/user.rules मध्ये disk वर राहतात.

रीबूट करून प्रश्न सुटेल अशी अपेक्षा ठेवू नका. ufw boot वेळी आपोआप सुरू होते. त्यामुळे ENABLED=yes म्हणजे network सुरू होण्यापूर्वी तोच ruleset पुन्हा load होतो. ufw मुळे झालेल्या lockout वर रीबूट केल्याने काहीही बदलत नाही.

कन्सोलला कदाचित तुमच्याकडे नसलेला password आवश्यक आहे

Web console (VNC किंवा serial) हा मशीनला जोडलेला keyboard आहे. तो network path नाही, त्यामुळे कोणताही firewall rule त्याला block करू शकत नाही. मात्र त्यासाठी local login आवश्यक असतो. इथे key-only setup अयशस्वी होतो: तुम्ही तुमच्या sudo user साठी password कधीच सेट केला नसेल आणि root login locked असेल, तर console असा prompt दाखवतो ज्याला तुम्ही उत्तर देऊ शकत नाही. तुमच्याकडे अजून SSH असतानाच तो password सेट करा: sudo passwd yourname. बहुतेक panels root password reset करण्याची सुविधाही देतात. यामुळे सामान्यतः reboot करणे आवश्यक होते.

कन्सोल वापरता येत नसेल, तर provider चे rescue system boot करा. ते disk unmounted ठेवून स्वतंत्र operating system चालवते. त्यामुळे तुम्ही बाहेरून 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 असेलच असे नाही. नेहमीच्या system मध्ये reboot केल्यानंतर ufw तुम्ही manually enable करेपर्यंत बंद राहील.

किमान पुनर्प्राप्ती क्रम

या क्रमाने काम करा. पहिले चार टप्पे सुरक्षित आहेत. त्यानंतरचा टप्पा सुरक्षित नाही.

1. नियम unload करण्यासाठी आणि पुन्हा access मिळवण्यासाठी sudo ufw disable चालवा.
2. तुम्ही जोडलेले नियम, ते जोडणाऱ्या commands च्या स्वरूपात दाखवण्यासाठी sudo ufw show added चालवा. ufw inactive असताना हे काम करते; ufw status मात्र काम करत नाही.
3. sshd प्रत्यक्षात कोणत्या port वर listening करत आहे हे पडताळण्यासाठी sudo sshd -T | grep -i '^port' चालवा. तुम्ही ते बदलले नसल्यास, यामध्ये port 22 दिसते.
4. तुमचा प्रत्यक्ष port वापरून sudo ufw allow 22/tcp चालवा, जेणेकरून पुढील enable मुळे पुन्हा access बंद होणार नाही.
5. प्रथम rollback schedule करून sudo ufw enable चालवा. त्याची पद्धत या पृष्ठावर पुढे दिली आहे.

ufw reset प्रत्यक्षात काय करते

ufw reset हा शेवटचा उपाय आहे; पहिली कृती नाही. तो firewall अक्षम करतो, प्रत्येक rules file चा backup घेतो आणि incoming साठी deny तसेच outgoing साठी allow अशी default धोरणे पुन्हा लागू करतो. प्रत्येक file साठी एक backup ओळ प्रदर्शित केली जाते:

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

reset केल्यानंतर एकही allow rule शिल्लक राहत नाही. त्यामुळे ही command SSH द्वारे न चालवता console वरून चालवा आणि firewall पुन्हा enable करण्यापूर्वी SSH rule जोडा. हे backups plain text स्वरूपात असतात. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 जुन्या rules कोणत्या होत्या ते दाखवते. त्यामुळे चुकून हटवायचा नसलेला ruleset पुन्हा तयार करता येतो.

ufw आपले नियम कुठे ठेवतो

आठवणीवर अंदाज करण्यापेक्षा फाइल वाचणे अधिक विश्वसनीय आहे. या पाच path मध्ये संपूर्ण स्थिती साठवलेली असते:

• /etc/ufw/user.rules आणि /etc/ufw/user6.rules: तुम्ही जोडलेले नियम, ज्यांचे मूल्यमापन ज्या क्रमाने केले जाते त्या क्रमाने.
• /etc/ufw/before.rules आणि /etc/ufw/after.rules, तसेच 6 variants: ufw तुमच्या नियमांभोवती वापरत असलेले framework. यात established connections साठीचा accept आणि loopback नियम समाविष्ट असतात.
• /etc/default/ufw: default policies आणि IPV6 switch.
• /etc/ufw/ufw.conf: ENABLED आणि log level.
• /var/log/ufw.log: logging सुरू केल्यानंतर कोणता network traffic block झाला ते.

ufw एखादी file पुन्हा लिहिण्यापूर्वी तिची timestamp असलेली copy तयार करतो. त्यामुळे ls /etc/ufw/ मध्ये user.rules.20260813_101500 सारखी नावे साठत जातात. हा तुमचा undo history आहे. नियम पूर्ववत करण्यास सुरुवात करण्यापूर्वी तो वाचणे उपयुक्त ठरते.

Disk वरील स्थितीऐवजी kernel मध्ये load केलेले नियम पाहण्यासाठी sudo ufw show raw वापरा, किंवा sudo iptables -S आणि sudo ip6tables -S वापरा. Ubuntu 22.04 आणि 24.04 मध्ये या commands nft backed versions आहेत. त्यामुळे sudo nft list ruleset तेच नियम नवीन syntax मध्ये दाखवतो.

ufw सक्षम केल्यावर माझे SSH सत्र का खंडित झाले?

डीफॉल्ट incoming policy deny असते. तुमच्या SSH port साठी कोणताही नियम नसताना ufw सक्षम केल्यास प्रत्येक नवीन connection बंद होते. ufw याबाबत इशारा देते: Command may disrupt existing ssh connections. Proceed with operation (y|n)? SSH allow rule लागू नसताना y ला उत्तर देणे हे या पृष्ठावर वर्णन केलेल्या सर्व समस्यांचे सर्वात सामान्य कारण आहे.

यातील गोंधळ निर्माण करणारा भाग म्हणजे होणारा विलंब. /etc/ufw/before.rules तुमचे स्वतःचे rules लागू होण्यापूर्वी ESTABLISHED,RELATED स्थितीतील packets स्वीकारते. त्यामुळे तुम्ही command चालवलेले session नेहमीप्रमाणे सुरू राहते. पुढील connection करताना, कदाचित काही तासांनी, lockout दिसून येते. तोपर्यंत firewall मधील बदलाशी त्याचा संबंध जाणवत नाही. पहिले SSH session बंद करण्यापूर्वी नेहमी दुसरे SSH session उघडा आणि ते कार्यरत असल्याची खात्री करा.

apt आणि DNS धोरणातील बदलानंतर काम करणे का थांबले?

sudo ufw default deny outgoing outbound DNS (domain name system) queries आणि outbound HTTP अवरोधित करते. त्यामुळे name resolution बंद होते आणि package updates थांबतात. apt update मध्ये Temporary failure resolving 'archive.ubuntu.com' नोंदवले जाते. Inbound SSH मात्र सुरू राहते, कारण त्याची उत्तरे ESTABLISHED असतात आणि framework नियमांमधून pass होतात. त्यामुळे firewall निर्दोष असल्यासारखा दिसतो, पण प्रत्यक्षात समस्येचे कारण firewall असतो.

तुम्हाला deny outgoing धोरण हवे असल्यास, मशीनला प्रत्यक्षात आवश्यक असलेले traffic खुले करा:

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

शेवटचा नियम नसल्यास clock मध्ये drift येतो. चुकीच्या clock मुळे TLS (transport layer security) certificate validation अयशस्वी होते. त्यामुळे curl ports ऐवजी dates संदर्भात fail होऊ लागते. हा त्रास बदल केल्यानंतर काही दिवसांनी दिसतो. म्हणून deny outgoing हे धोरण तुम्ही monitor करत असलेल्या मशीनसाठी योग्य आहे; एकदा setup करून सोडून देत असलेल्या मशीनसाठी नाही.

ufw नियम कधीच लागू का होत नाही?

ufw वापरकर्ता नियमांचा क्रमाने विचार करते आणि पहिला जुळणारा नियम मिळताच थांबते. व्यापक allow नंतर जोडलेला deny कधीच लागू होत नाही, कारण allow नियमामुळे पॅकेटचा निर्णय आधीच झालेला असतो. नियमांचा क्रम क्रमांकांसह दाखवा आणि आवश्यक स्थानावर नियम 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 लागू केले जाणारे नियम दाखवते आणि कोणताही बदल करत नाही. नियम प्रत्यक्ष लागू करण्यापूर्वी तो सुरक्षितपणे पाहण्याची ही योग्य पद्धत आहे.

Application profiles मध्ये आणखी एक अडचण असते. sudo ufw allow OpenSSH /etc/ufw/applications.d/openssh-server मधील profile वापरते आणि त्या profile मध्ये port 22 अभिप्रेत असतो. sshd port 2222 वर listening करत असल्यास, नियम कोणतीही सेवा वापरत नसलेला port उघडतो. त्यामुळे नियमांचा संच योग्य दिसत असूनही तुम्ही स्वतःला सर्व्हरबाहेर लॉक करू शकता. Port बदलल्यानंतर port number थेट वापरा. उर्वरित syntax VPS साठी ufw firewall ची मूलभूत माहिती मध्ये दिले आहे.

IPv4 नियम मला दिसत असलेल्या स्थितीचे स्पष्टीकरण का देत नाहीत?

कारण निम्मी network traffic IPv4 नसते. Ubuntu /etc/default/ufw मध्ये IPV6=yes उपलब्ध करून देते आणि त्यानंतर ufw /etc/ufw/user6.rules मध्ये स्वतंत्र v6 ruleset ठेवतो. ufw allow from 203.0.113.10 to any port 22 सारखा IPv4 address वापरून लिहिलेला rule कोणताही v6 rule तयार करत नाही. तुमच्या VPS कडे AAAA record असल्यास client IPv6 ला प्राधान्य देतो आणि तुमचे connection timeout होते, जरी ufw status मध्ये योग्य दिसणारा rule दाखवत असला तरी. ssh -6 user@host विरुद्ध ssh -4 user@host वापरून हा फरक तपासा. पहिली चाचणी यशस्वी झाली आणि दुसरी अयशस्वी झाली, तर ही तफावत v6 ruleset मध्ये आहे.

सुरक्षिततेच्या दृष्टीने उलट स्थिती अधिक धोकादायक आहे. IPV6=no असल्यास ufw ip6tables अजिबात व्यवस्थापित करत नाही. त्यामुळे v6 policy kernel च्या default ACCEPT वरच राहते. तुम्हाला बंद वाटणारा port त्याच्या IPv6 address वर प्रतिसाद देतो आणि कोणताही ufw command त्याचा उल्लेख करत नाही. sudo ip6tables -S आणि ss -tlnp वापरून तपासा आणि संपूर्ण माहितीकरिता ufw IPv6 ports कसे हाताळते वाचा.

Docker port ufw ने नाकारलेला असतानाही खुला का असतो?

Docker, nat table मध्ये DNAT (destination network address translation) नियम लिहून आणि FORWARD मध्ये स्वतःची chain समाविष्ट करून port प्रकाशित करते. ufw चे नियम INPUT path मध्ये असतात. Container कडे जाणारे network traffic host कडे वितरित न होता forward केले जाते. त्यामुळे ते तुमचा deny rule असलेल्या chain पर्यंत पोहोचत नाही. ufw सक्रिय असून सर्वकाही नाकारत असतानाही docker run -p 5432:5432 इंटरनेटवरून पोहोचण्यायोग्य असते.

sudo iptables -t nat -S DOCKER

सर्वात सोपा उपाय म्हणजे loopback वर publish करणे: -p 127.0.0.1:5432:5432 host-side binding 127.0.0.1 शी जोडते. त्यामुळे ufw काहीही सांगत असले तरी बाहेरील कोणतेही network traffic त्यापर्यंत पोहोचू शकत नाही. सेवा सार्वजनिकरित्या उपलब्ध असणे आवश्यक असल्यास ufw भोवती Docker ports प्रकाशित करणे या मार्गदर्शिकेत संबंधित प्रकरणे दिली आहेत.

नियम लागू करण्यापूर्वी rollback शेड्यूल करा

ही सवय firewall व्यवस्थापन सुरक्षितपणे करण्यासाठी महत्त्वाची आहे. कोणताही जोखमीचा बदल करण्यापूर्वी तो पूर्ववत करण्याची प्रक्रिया शेड्यूल करा. बदलामुळे तुमचा प्रवेश बंद झाला, तरी मशीन पाच मिनिटांत आपोआप पूर्वस्थितीत येईल आणि तुम्हाला console उघडण्याची गरज पडणार नाही.

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

systemd Running timer as unit: ufw-rollback.timer प्रिंट करते. आता तुमचा बदल करा. त्यानंतर नवीन SSH session उघडता येत असल्यास rollback रद्द करा:

sudo systemctl stop ufw-rollback.timer

ते session उघडता येत नसल्यास प्रतीक्षा करा. ufw स्वतःच बंद होईल आणि तुमचा पुढील प्रयत्न यशस्वी होईल. पारंपरिक shutdown -r +5 युक्ती ufw साठी उपयोगी ठरत नाही, कारण boot वेळी ufw तोच ruleset पुन्हा लोड करते.

दुसरा प्रवेशमार्ग ठेवा

• आपल्याला त्याची गरज भासण्यापूर्वी एकदा provider console मध्ये login करा आणि password कार्यरत असल्याची खात्री करा. कधीही तपासलेला console हा 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 सुरू केल्यानंतरचा काळ. नवीन VPS वरील पहिल्या दहा मिनिटांतील इतर setup कामांसोबत हे करा.

Refused किंवा timed out यावरून कोणता स्तर अयशस्वी झाला हे समजते

Connection refused याचा अर्थ पॅकेट सर्व्हरपर्यंत पोहोचले आणि एखाद्या घटकाने TCP reset परत पाठवला. नेटवर्क मार्ग योग्य आहे. त्यामुळे sshd थांबलेला आहे किंवा वेगळ्या पोर्टवर listening करत आहे. firewall हे कारण क्वचितच असते, कारण ufw default नुसार reject करण्याऐवजी drops करते.

Connection timed out याचा अर्थ कोणताही प्रतिसाद परत आला नाही. हे drop झाल्याचे लक्षण आहे: ufw, provider network firewall किंवा चुकीचा address. हे दोन errors योग्य प्रकारे समजून घेतल्यास अंदाज बांधण्यात जाणारा एक तास वाचतो आणि connection refused आणि timed out मधील फरक उर्वरित प्रकरणे स्पष्ट करतो.

पुढील बदल करण्यापूर्वी logging सुरू करा

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

Blocked 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 नाही. rsyslog नसलेल्या minimal image मध्ये /var/log/ufw.log उपलब्ध नसते. त्याच lines sudo journalctl -k | grep UFW मधून येतात. ufw स्वतःच्या logging rules वर rate limiting लागू करते. त्यामुळे एखादी line दिसत नाही म्हणून packet allow झाला असे सिद्ध होत नाही.

तुम्ही जोडलेले नसलेले नियम आढळल्यास

स्वतःहून बदललेला ruleset ही firewall ची समस्या नाही. तो root असलेल्या कोणीतरी बदलला आहे. कोणते sudo commands चालवले गेले आणि कोणत्या account अंतर्गत चालवले गेले हे पाहण्यासाठी sudo grep ufw /var/log/auth.log चालवा. त्यानंतर त्याच timestamp च्या आसपासचे logins पाहण्यासाठी last चालवा. ही accounts तुमच्या परिचयातील कोणाशीही जुळत नसल्यास firewall चे debugging थांबवा आणि त्याऐवजी compromised VPS checklist वर काम करा. दुसरे कोणी नियंत्रित करत असलेल्या box वर firewall पुन्हा enable केल्याने समस्या फक्त लपते.

पुन्हा योग्य रचनेत आणा

कारण समजल्यानंतर, पुन्हा कनेक्शन बंद होणार नाही अशा पद्धतीने ufw पुन्हा enable करा. तुमचा प्रत्यक्ष SSH port allow करा, rollback schedule करा, ufw enable करा. त्यानंतर दुसऱ्या terminal मधून पूर्णपणे नवीन SSH session उघडा आणि ते कनेक्ट होत असल्याची खात्री करा. तो नवीन session सुरू झाल्यानंतरच तुम्ही ज्या session मध्ये काम करत आहात तो बंद करा. एक दिवस logging सुरू ठेवा, कारण user.rules वाचण्यापेक्षा कोणत्या परवानगीचा समावेश करायचा राहून गेला हे log तुम्हाला खूप लवकर दाखवते.

FAQ

ufw disable माझे नियम हटवते का?

नाही. disable ruleset kernel मधून unload करते आणि ENABLED=no ला /etc/ufw/ufw.conf मध्ये लिहिते. तुमचे नियम /etc/ufw/user.rules आणि /etc/ufw/user6.rules मध्येच राहतात. Firewall inactive असतानाही sudo ufw show added त्यांची यादी दाखवते. नियम साफ करणारी command ufw reset आहे. ती प्रत्येक file चा आधी backup घेते आणि Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' सारखी ओळ दाखवते.

VPS reboot केल्याने ufw lockout दूर होईल का?

नाही. /etc/ufw/ufw.conf मधील ENABLED=yes द्वारे ufw boot वेळी सुरू होते. त्यामुळे network सुरू होण्यापूर्वी तेच नियम पुन्हा load होतात आणि तुम्ही पुन्हा lockout होता. ufw बंद केल्यानंतर reboot केल्यासच, किंवा rescue mode मधून disk mount करून ती file संपादित केल्यानंतर reboot केल्यासच फायदा होतो. Provider console वापरा आणि तिथे sudo ufw disable चालवा.

ufw ने port deny केला असतानाही माझा Docker container reachable का आहे?

Docker प्रत्येक published port साठी स्वतःचे DNAT आणि FORWARD rules लिहिते. हा traffic host कडे deliver न होता container कडे forward केला जातो. त्यामुळे तो तुमचा ufw deny rule असलेल्या INPUT chain मधून जात नाही. Port फक्त host साठी असल्यास -p 127.0.0.1:5432:5432 वापरून तो loopback वर publish करा. Docker ने कोणते rules install केले ते sudo iptables -t nat -S DOCKER वापरून तपासा.

माझ्याकडे console password आणि rescue mode दोन्ही नाहीत. माझे पर्याय कोणते?

उरलेले पर्याय तुमच्या 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 एकदा तपासा. त्यामुळे पुढील lockout झाल्यास त्यातून बाहेर पडण्यासाठी तुम्हाला दोन मिनिटे पुरतील.