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। फ़ायरवॉल का काम अधिक विनम्र और अधिक महत्वपूर्ण है: कि खुले पोर्टों की सूची उससे मेल खाए जो आप उसके बारे में मानते हैं। सक्रिय नियमों के साथ यह सूची एक पन्ने पर कैसी लगती है, नीचे डेमो पर।