OpenBSD 7.7 एक मजबूत फ़ायरवॉल आधार: pf.conf और sysctl.conf जो आपकी सुरक्षा करते हैं

OpenBSD लंबे समय से अपनी अडिग सुरक्षा सिद्धांतों के लिए जाना जाता है: समझदार डिफ़ॉल्ट सेटिंग्स, साफ़-सुथरा कोड, और "डिफ़ॉल्ट रूप से सुरक्षित" को नारे के बजाय एक अनिवार्य नियम के रूप में अपनाना। यदि आप एक ऐसा फ़ायरवॉल खोज रहे हैं जो दिन-प्रतिदिन के उपयोग में विश्वसनीय और समझने योग्य हो, तो OpenBSD आपको एक मजबूत आधार प्रदान करता है। साथ ही, मजबूत डिफ़ॉल्ट सेटिंग्स अच्छी हैं, लेकिन कुछ लक्षित नियंत्रण सुरक्षा स्तर और पूर्वानुमान को स्पष्ट रूप से बढ़ा देते हैं। बिना आपकी सेटअप को एक नाजुक विज्ञान परियोजना में बदले।
इस लेख के साथ, हम एक व्यावहारिक आधार प्रदान करना चाहते हैं जो छोटे नेटवर्क, होम लैब्स, और कई SMB वातावरणों को आत्मविश्वास के साथ सुरक्षित करता है—साथ ही पठनीय और बनाए रखने योग्य रहता है।

लंबी चेकलिस्ट और मनमाने ट्यूनिंग टिप्स के बजाय, आपको स्पष्ट तर्क के साथ अच्छी तरह से स्थापित निर्णय मिलेंगे। हम आपको दिखाएंगे कि क्यों एक विशेष विकल्प सेट किया गया है, यह कौन से जोखिमों को संबोधित करता है, और किन साइड इफेक्ट्स का ध्यान रखना चाहिए। लक्ष्य हर सैद्धांतिक हमले की स्थिति को कवर करना नहीं है, बल्कि आपको एक विश्वसनीय प्रारंभिक बिंदु देना है: सरल नियम, कम अपवाद, पूर्वानुमानित व्यवहार।

यह मार्गदर्शिका एक स्पष्ट रेखा का पालन करती है: स्पष्ट रूप से अनुमति दें; अन्यथा अवरुद्ध करें। बाहर से अंदर तक, केवल वही अनुमति है जो राउटर को स्वयं चाहिए; अंदर से बाहर तक, केवल वही अनुमति है जो आप वास्तव में चाहते हैं। DNS को दृश्य और नियंत्रित रखा जाता है। DoH, DoT, DoQ, और QUIC को कोई गुप्त बैकचैनल नहीं मिलता, ताकि आपके पास "अदृश्य" रास्ते न हों। स्टेट्स जानबूझकर इंटरफेस से बंधे होते हैं ताकि कनेक्शन वहीं रहें जहां से वे शुरू हुए थे। इससे सिस्टम पूर्वानुमानित होता है और समस्या निवारण सहनीय होता है। और क्योंकि पारदर्शिता दस चालाक तरकीबों से बेहतर है, सभी महत्वपूर्ण रास्तों पर लेबल होते हैं: दैनिक संचालन में आप तुरंत देख सकते हैं कि क्या उपयोग हो रहा है, क्या अस्वीकृत है, और कहाँ कड़ा करना है।

चीजों को ठोस बनाए रखने के लिए, हम दो pf प्रोफाइल प्रदान करते हैं जिनमें से आप चुन सकते हैं: एक कॉम्पैक्ट केवल राउटर संस्करण क्लासिक LAN-से-इंटरनेट परिदृश्यों के लिए, और एक राउटर+DMZ संस्करण यदि आप सेवाओं को अलग करना चाहते हैं। हम क्लाइंट DNS को सख्ती से 1.1.1.1 (वैकल्पिक रूप से 1.0.0.1 फॉलबैक के रूप में) पर लागू करते हैं। यह पेडेंट्री नहीं है—यह एक जानबूझकर वास्तुशिल्प विकल्प है: आप दृश्यता और नियंत्रण पुनः प्राप्त करते हैं। यदि कोई एप्लिकेशन कुछ और चाहता है, तो वह अलग दिखता है, और आप यह जानबूझकर निर्णय ले सकते हैं कि अपवाद कब और कहाँ जोड़ना है।

sysctl.conf इस रुख को कर्नेल स्तर पर पूरा करता है। OpenBSD पहले से ही बहुत कुछ अच्छा लेकर आता है, लेकिन कुछ स्विच सुरक्षा और पूर्वानुमान को मापनीय रूप से बढ़ाते हैं: एक हार्डनड malloc कॉन्फ़िगरेशन जो क्लासिक मेमोरी बग्स को पहले और जोर से फेल कराता है; SMT/Hyper-Threading को बंद करना जब साइड-चैनल जोखिम आपको कोई लाभ नहीं देते; W^X जो प्रक्रियाओं को समाप्त करना पसंद करता है बजाय उन्हें खतरनाक ग्रे क्षेत्रों में चलाने के; रीडायरेक्ट्स और गैर-आवश्यक टनलिंग प्रोटोकॉल को बंद करना; आधुनिक TCP विकल्प और मध्यम दर सीमाएं जो नेटवर्क "शोर" को कम करती हैं बिना वैध कार्य को तोड़े। ये चमकदार "ट्वीक्स" नहीं हैं—ये सुसंगत स्वच्छता हैं: कम हमला सतह, कम आश्चर्य, भार के तहत अधिक स्थिर व्यवहार।

स्कोप से बाहर हैं अत्यधिक लक्षित हमले या पूर्ण IDS/IPS तैनाती। यदि आप मल्टी-स्टेज मॉनिटरिंग, गहरी प्रोटोकॉल निरीक्षण, या खतरा-इंटेल फीड चाहते हैं, तो यह कॉन्फ़िगरेशन आपकी राह में बाधा नहीं बनेगा; यह वह बुनियाद है जिस पर आप बाद में व्यवस्थित रूप से उन बिल्डिंग ब्लॉकों को जोड़ सकते हैं। हम जानबूझकर जटिल मल्टी-WAN नीतियों, विस्तृत पोर्ट-फॉरवर्डिंग परिदृश्यों, या विदेशी ओवरले नेटवर्क को यहाँ शामिल नहीं करते। ये सब संभव है, लेकिन बिना आधार की स्पष्टता को कम किए।

हमारी पठनीयता के प्रति प्रतिबद्धता का मतलब है कि हम जादू से अधिक यांत्रिकी पसंद करते हैं। NAT स्थैतिक है जहाँ रियल-टाइम प्रोटोकॉल को इसका लाभ मिलता है, और गतिशील है जहाँ इसका कोई फर्क नहीं पड़ता। QUIC बाहर रहता है ताकि DNS TLS स्ट्रीम्स के अंदर छिप न सके। IPv6 को शुरू में ब्लॉक किया जाता है ताकि "आधा खुला IPv6" न हो, जहाँ क्लाइंट v6 पसंद करते हैं जबकि फ़ायरवॉल इसे नियंत्रित नहीं करता; बाद में लेख में आपको IPv6 को सही तरीके से चालू करने की साफ़ विधि मिलेगी यदि आपको इसकी आवश्यकता हो। और जहाँ भी मदद मिलती है, हम एज केस को लेबल के साथ चिह्नित करते हैं—लॉग फ़ाइलों को रंगीन बनाने के लिए नहीं, बल्कि उत्तर पाने के लिए: किसने DoT बोलने की कोशिश की? कौन से होस्ट ने एंटी-रीबाइंड नियम को टक्कर दी? क्या ईग्रेस ब्लॉक्स को ट्रिगर करता है?

यह किसके लिए है? आपके लिए यदि आप प्रशासन को एक कला के रूप में लेते हैं और तीन सप्ताह अजीब साइड इफेक्ट्स का पीछा करने के बजाय एक साफ़ आधार पर एक घंटा बिताना पसंद करते हैं। आपके लिए यदि आप अपने नेटवर्क को समझना चाहते हैं बजाय डिफ़ॉल्ट अनुमतियों से आश्चर्यचकित होने के। और आपके लिए यदि आप "दो कुर्सियों के बीच" महसूस करते हैं: SOC/ब्लू-टीम उपकरण के लिए पर्याप्त बड़े नहीं, लेकिन एक सामान्य होम राउटर के लिए बहुत मांग वाले। यहाँ प्रस्तुत आधार कोई जादू नहीं है—यह एक समझदार मानक है: छोटा इतना कि आप इसे मास्टर कर सकें, मजबूत इतना कि आप इसे बनाए रख सकें।

खतरा मॉडल: हम किससे बचाव करते हैं—और किससे नहीं

यह आधार उन वातावरणों के लिए डिज़ाइन किया गया है जिनके पास समर्पित ब्लू टीम नहीं है लेकिन फिर भी विश्वसनीय मानक चाहते हैं। यह रोज़ाना आपके एज पर आने वाली सामान्य शोर से सुरक्षा करता है: व्यापक स्कैन, अवसरवादी एक्सप्लॉइट, "DNS ओवर एवरीथिंग" जैसे प्रोटोकॉल दुरुपयोग, गलत कॉन्फ़िगरेशन, या उदार ईग्रेस नीतियाँ जो डेटा निकासी को संभव बनाती हैं। यह वैकल्पिक सर्वरों को DMZ में संलग्न करता है, जिससे LAN में पार्श्व आंदोलन रोका जाता है। स्कोप में नहीं हैं अत्यधिक लक्षित हमले या पूर्ण IDS/IPS स्टैक्स—आप बाद में इन्हें इस आधार के ऊपर जोड़ सकते हैं।

डिज़ाइन सिद्धांत: छोटा हमला सतह, स्पष्ट जिम्मेदारियाँ

कॉन्फ़िगरेशन कई दिशानिर्देशों का पालन करता है जो भविष्य के समायोजन में मदद करते हैं:

• फेल-क्लोज्ड। यदि कुछ स्पष्ट रूप से अनुमति नहीं है, तो वह बंद रहता है—इनबाउंड और आउटबाउंड दोनों। आप परीक्षण में जल्दी सीखेंगे कि एक एप्लिकेशन को वास्तव में क्या चाहिए, और आप नियंत्रण बनाए रखेंगे।
• नियतात्मक स्टेट्स। if-bound सुनिश्चित करता है कि कनेक्शन उस इंटरफेस से जुड़ा रहे जहां से वह शुरू हुआ। एकल-WAN राउटर पर, यह जादुई "फ्लोटिंग" स्टेट्स की खोज को समाप्त करता है और समस्या निवारण आसान बनाता है।
• ईग्रेस न्यूनतमवाद। अंदर से बाहर, केवल वही जो वास्तव में आवश्यक है: क्लासिक वेब, मेल सबमिशन, VoIP/WebRTC के लिए परिभाषित UDP रेंज, और DNS केवल जहाँ आप चाहते हैं।
• अंदाज लगाने से पारदर्शिता बेहतर। QUIC ब्लॉक है, जैसे DoH/DoT/DoQ। हाँ, यह कुछ ऐप्स के लिए असुविधाजनक है। बदले में आपको स्पष्टता मिलती है: DNS DNS है, TLS TLS है। यदि कुछ छाया DNS चाहता है, तो वह अलग दिखता है।
• मजबूत डिफ़ॉल्ट। स्क्रबिंग, MSS कैपिंग, यादृच्छिक IDs, बोगन फ़िल्टर, एंटी-स्पूफिंग, TCP फ़्लैग स्वच्छता, और ICMP तथा RST के लिए समझदार दर सीमाएं। इनमें से कोई भी शानदार नहीं है—साथ में यह ठोस स्वच्छता है।
• IPv6 विकल्प के रूप में। IPv6 डिफ़ॉल्ट रूप से बंद है। यदि आप इसे चाहते हैं, तो लेख में एक साफ़ सक्षम करने का रास्ता शामिल है। हम लगातार "आधा खुला IPv6" से बचते हैं (फ़ायरवॉल इसे संभालता नहीं, क्लाइंट फिर भी इसे पसंद करते हैं)।

sysctl.conf — कर्नेल-स्तरीय सुरक्षा लीवर जो वास्तव में मायने रखते हैं

OpenBSD पहले से ही मजबूत डिफ़ॉल्ट लाता है, लेकिन कुछ नियंत्रण सुरक्षा और पूर्वानुमान को स्पष्ट रूप से बढ़ाते हैं। यहाँ आवश्यकताएँ हैं—कोई अंतहीन चेकलिस्ट नहीं, केवल स्पष्ट तर्क।

• मेमोरी हार्डनिंग (vm.malloc_conf=CFGJRS)। गार्ड पेज, जंक पैटर्न, रेड ज़ोन, और कैनरीज़ क्लासिक मेमोरी बग्स को बहुत कठिन बनाते हैं और प्रक्रियाओं को जोर से फेल कराते हैं बजाय चुपचाप भ्रष्ट होने के। छोटा ओवरहेड लगभग सभी राउटर परिदृश्यों में इसके लायक है।
• CPU/हार्डवेयर: SMT बंद, एपर्चर बंद। hw.smt=0 साइड-चैनल जोखिम (Hyper-Threading) को कम करता है—राउटर पर थ्रूपुट हिट आमतौर पर न्यूनतम होता है। machdep.allowaperture=0 /dev/mem-शैली के शॉर्टकट बंद करता है; हेडलेस राउटर के लिए परफेक्ट। यदि आपको X11/KMS चाहिए, तो आप जानेंगे—अन्यथा इसे बंद रखें।
• राउटिंग और प्रोटोकॉल: IPv4 चालू, IPv6 जानबूझकर बंद। net.inet.ip.forwarding=1 आपके बॉक्स को IPv4 राउटर में बदल देता है। net.inet6.ip6.forwarding=0 "अनजाने" IPv6 राउटिंग को रोकता है। हम IP-in-IP, GRE, ESP/AH, और EtherIP जैसे गैर-आवश्यक टनल बंद कर देते हैं। कम क्रिप्टो/एन्कैप्सुलेशन मशीनरी का मतलब कम हमला सतह और उत्पादन में कम आश्चर्य।
• पुराने जाल को निष्क्रिय करना। निर्देशित प्रसारण बंद, रीडायरेक्ट्स अनदेखा—IPv4 और IPv6 दोनों के लिए। ICMP रीडायरेक्ट्स क्लासिक फुटगन हैं; यदि आप रास्ते बदलना चाहते हैं, तो इसे स्पष्ट रूप से राउटिंग या PF में करें, साइड चैनलों के माध्यम से नहीं।
• ICMP संयम के साथ। कोई प्रसारण इको नहीं, कोई टाइमस्टैम्प/नेटमास्क नहीं; त्रुटि पैकेट्स को उचित दर सीमा मिलती है। यह DDoS शोर को कम करता है बिना वैध कार्य को तोड़े। ICMP दुश्मन नहीं है—लेकिन इसे गार्डरेल्स की जरूरत है।
• UDP/TCP हार्डनिंग बिना जादू-टोने के। UDP चेकसम अनिवार्य हैं; समझदार सॉकेट बफ़र्स बदसूरत ड्रॉप्स से बचाते हैं। TCP के लिए, विंडो स्केलिंग, टाइमस्टैम्प, और SACK जैसे आधुनिक फीचर्स चालू रहते हैं—वे स्थिरता बढ़ाते हैं। ECN सक्रिय है; आधुनिक नेटवर्क में यह शायद ही कभी नुकसान पहुंचाता है और लोड के तहत मदद करता है। SYN कैश/बकेट सीमाएं और RST दर सीमाएं सामान्य स्कैन तरंगों को अवशोषित करती हैं।
• क्यूज, BPF, और W^X। लंबा if-queue विस्फोटों के दौरान ड्रॉप को कम करता है। बड़े BPF बफ़र्स डिबगिंग के लिए आपके भविष्य के लिए उपहार हैं। kern.wxabort=1 W^X लागू करता है: कोड या तो लिखने योग्य होता है या निष्पादित करने योग्य, कभी दोनों नहीं। उल्लंघन प्रक्रिया को मार देते हैं—फेल-क्लोज्ड, जैसा कि चाहिए। स्वैप एन्क्रिप्शन चालू रहता है ताकि संवेदनशील अवशेष कभी भी डिस्क पर प्लेनटेक्स्ट में न जाएं।

यह sysctl चयन जानबूझकर असाधारण नहीं है। यह "आमतौर पर काम करता है" से "तनाव के तहत लगातार व्यवहार करता है" की ओर झुकाव करता है। बस सुनिश्चित करें कि आप इसे sysctl -f से साफ़ लोड करें, कुछ काउंटरों (sysctl -n net.inet6.icmp6.errppslimit, netstat -m, pfctl -s memory) का संज्ञान लें, और सावधान रहें—यदि आप mbuf/क्लस्टर बजट, PF सीमाओं जैसे set limit frags को ट्वीक करते हैं तो समायोजन की आवश्यकता हो सकती है।

pf.conf: नियम जिन्हें आप समझा सकते हैं

pf आपको अनंत संभावनाएं देता है। हमारा आधार ठीक उतना ही लेता है जितना आपको मजबूत मानकों के लिए चाहिए—ना ज्यादा, ना कम।

• मैक्रोज़, टेबल्स, और लेबल्स—संरचना आधी लड़ाई है। स्पष्ट रूप से परिभाषित इंटरफेस और नेटवर्क से शुरू करें: WAN, LAN, और—DMZ संस्करण में—DMZ। बोगन, दुरुपयोगकर्ता, स्कैनर, और संदिग्ध DoH एंडपॉइंट्स के लिए वॉचलिस्ट के लिए टेबल जोड़ें। ये टेबल सजावट नहीं हैं: persist के साथ ये रीलोड के बाद भी जीवित रहते हैं, और overload के माध्यम से शोर स्रोत स्वचालित रूप से उनमें आ जाते हैं। नियमों पर सुसंगत लेबल्स आपको भारी pcap काम के बिना परिचालन दृश्यता देते हैं: pfctl -vvsr या systat pf आपको दिखाता है कि कार्रवाई कहाँ हो रही है।
• वैश्विक विकल्प—पूर्वानुमानित व्यवहार। set block-policy drop और "आक्रामक" अनुकूलन समझदार रूढ़िवादी डिफ़ॉल्ट हैं। set state-policy if-bound कनेक्शनों को उनके इनग्रैस इंटरफेस से जोड़ता है। हम स्टेट्स, फ्रैग्स, और src-nodes के लिए सीमाएं परिभाषित करते हैं, अनुकूली टाइमआउट सेट करते हैं, और syncookies को अनुकूली रूप से सक्षम करते हैं—वे जब लहर ऊँची होती है तब मदद करते हैं। loginterface आपको WAN सांख्यिकी देता है; set skip on lo0 आत्म-घात से बचाता है।
  IPv6 pf में डिफ़ॉल्ट रूप से ब्लॉक है, sysctl से मेल खाता है और "आधा खुला IPv6" को रोकता है। यदि आप IPv6 चाहते हैं, तो इसे जानबूझकर और स्पष्ट रूप से सक्षम करें।
• इनबाउंड ICMP: स्वस्थ रहने के लिए पर्याप्त खुला। WAN इंटरफेस पर हम ICMP इको और "अनपहुंच" को अनुमति देते हैं, स्टेटफुल और दर-सीमित। यह डिबगिंग में सुधार करता है (MTU/पथ समस्याओं को विश्वसनीय रूप से कैसे खोजें?) जबकि आपको पिंग बाढ़ से बचाता है। बाकी सब—खासतौर पर रीडायरेक्ट्स—बंद रहते हैं।
• स्क्रबिंग: कम फ्रैगमेंटेशन, कम निराशा। हम दोनों दिशाओं में स्क्रब करते हैं: यादृच्छिक IP IDs, एक रूढ़िवादी न्यूनतम TTL, MSS कैपिंग 1440 पर (व्यवहार में एक स्वस्थ मान), और TCP पुनःसंयोजन। यह फ्रैगमेंटेड/संशयास्पद पैकेट्स को स्टेट्स को जाम करने से रोकता है और PMTU सिरदर्द को कम करता है। इसके साथ, sysctl के माध्यम से MSS ट्यूनिंग शायद ही कभी आवश्यक होती है।
• NAT: जहाँ रियल टाइम मायने रखता है वहाँ स्थैतिक; जहाँ नहीं वहाँ गतिशील। UDP को स्थैतिक पोर्ट मिलते हैं—VoIP/WebRTC, गेमिंग, और कई रियल-टाइम प्रोटोकॉल के लिए सोना। बाकी सब उच्च अस्थायी रेंज का उपयोग करता है ताकि पैकेट कैप्चर में ईग्रेस पहचान समझदार रहे और टकराव कम हों। NAT सब कुछ पर लागू होता है सिवाय स्पष्ट रूप से परिभाषित प्रबंधन गंतव्यों के—कोई आश्चर्यजनक रास्ते नहीं।
• एंटी-स्पूफिंग, बोगन्स, नल पोर्ट्स। antispoof सभी संबंधित इंटरफेस पर नजर रखता है। WAN पर टूटे स्रोत मार्ग वाले पैकेट जल्दी गिरा दिए जाते हैं। हम बोगन्स को इनबाउंड और आउटबाउंड दोनों में ब्लॉक करते हैं; उदाहरण के लिए 10/8 या 127/8 से इंटरनेट ट्रैफ़िक आमतौर पर अन्य समस्याओं का संकेत है। हम नल पोर्ट्स और असंभव TCP फ्लैग्स भी साफ़ करते हैं—यह कोई रॉकेट साइंस नहीं है, लेकिन यह स्कैनरों और "रचनात्मक" उपकरणों के साथ आपके पते की जांच में दर्द बचाता है।
• डिफ़ॉल्ट अस्वीकृति: बड़ी झाड़ू। स्वच्छता के बाद आता है कठोर कट: सब कुछ ब्लॉक करें। यहाँ से, सब कुछ जानबूझकर अपवाद है।
• WAN पर इनबाउंड: केवल वही जो राउटर को चाहिए। यदि आपका अपस्ट्रीम इसे मांगता है तो हम इनबाउंड DHCP की अनुमति देते हैं। बस इतना ही। इंटरनेट से पहुंच योग्य सार्वजनिक DMZ इस आधार का उद्देश्य नहीं है; इसके लिए आप पोर्ट फॉरवर्ड्स परिभाषित करेंगे—कृपया संयम से।
• QUIC: HTTP/3 बाहर रहता है। हम WAN इंटरफेस पर UDP 80/443 ब्लॉक करते हैं। इससे QUIC दम घुटता है। इतना सख्त क्यों? क्योंकि QUIC एक सुविधाजनक टनल है—यहाँ तक कि DoH फ्लेवर्स और अन्य "सब कुछ एक स्ट्रीम में" तरकीबों के लिए भी। यदि बाद में आपको HTTP/3 की सचमुच जरूरत हो (और आप जानते हों क्यों), तो संकीर्ण अपवाद जोड़ें। आधार गति से अधिक पारदर्शिता को प्राथमिकता देता है।
• DoH/DoT/DoQ के लिए दृश्यता—स्पष्ट सीमाओं के साथ। DoT (853/TCP) और DoQ (784/UDP) को ईग्रेस पर ब्लॉक और इनबाउंड पर लॉग किया जाता है। LAN/DMZ में हम ज्ञात DoH होस्ट्स के लिए TLS कनेक्शनों को स्पष्ट रूप से लेबल करते हैं—जब तक आप सख्त संस्करण नहीं चुनते, तब तक नीति नहीं बदलते। मकसद: आप देख सकें जब क्लाइंट गुप्त DNS का प्रयास करते हैं।
• फ़ायरवॉल के लिए प्रशासनिक पहुँच: कड़ा और दर सीमित। LAN से फ़ायरवॉल के लिए SSH अनुमति है, स्टेट, फ्लैग स्वच्छता, और सौम्य दर सीमाओं के साथ। अपस्ट्रीम प्रबंधन पथ (जैसे, मोडेम/राउटर GUI) को लक्षित पास मिलते हैं; छोटे कनेक्शन-रेट गार्ड्स गलत क्लिक और स्प्रे को रोकते हैं। लेबल इन रास्तों को दृश्य रखते हैं।
• स्थानीय रिज़ॉल्वर के बिना DNS नीति: उम्मीद न करें, लागू करें। मुख्य बिंदु: LAN (और DMZ, यदि मौजूद हो) के क्लाइंट केवल 1.1.1.1 और वैकल्पिक रूप से 1.0.0.1 का उपयोग कर सकते हैं पोर्ट 53/TCP+UDP पर। पोर्ट 53 पर सब कुछ ब्लॉक और लॉग होता है। यह "अच्छा होना" नहीं है—यह दृश्यता के लिए महत्वपूर्ण है। आप तुरंत अन्य रिज़ॉल्वर या DoH/DoT/DoQ के उपयोग के प्रयास देखेंगे, जिन्हें आप अलग से ब्लॉक करते हैं। आप कभी भी किसी अन्य बाहरी रिज़ॉल्वर को स्वैप कर सकते हैं; यांत्रिकी समान रहती है।
• DMZ: कोई साइड डोर, कोई शॉर्टकट नहीं। DMZ संस्करण में कोई इन्ट्रा-DMZ संचार नहीं, LAN में कोई वापसी रास्ता नहीं, और केवल वहाँ रहने वाली सेवाओं (क्लासिक वेब, मेल सबमिशन, VoIP/WebRTC UDP रेंज) के लिए लक्षित ईग्रेस पास। DMZ से किसी भी अपस्ट्रीम GUI तक पहुंच बंद है; यह एक समझौता सर्वर को आपके प्रबंधन नेटवर्क को छूने से रोकता है। बाकी सब ब्लॉक और लॉग होता है—ताकि आप जल्दी से एक खोया हुआ स्क्रू ढूंढ सकें।
• आउटबाउंड जोखिम कम करें: क्लासिक्स बंद करें। आउटबाउंड में हम सामान्य संदिग्धों को ब्लॉक करते हैं: SMB/NetBIOS, RPC/NFS, TFTP, SNMP, RDP/VNC/WinRM, और अवसरवादी SMTP। प्रत्येक की जगह आपके नेटवर्क के अंदर या जानबूझकर रास्तों पर होती है; इंटरनेट पर वे डिफ़ॉल्ट रूप से नहीं होने चाहिए। यदि आपको अपवाद चाहिए, तो इसे जानबूझकर परिभाषित करें—लेबल के साथ।
• फ़ायरवॉल स्वयं: बाहर जाने की अनुमति, लेकिन दृश्य। फ़ायरवॉल इंटरनेट तक पहुंच सकता है—स्टेट्स, सीमाएं, और लेबल के साथ। आपको अपडेट, पैकेज, और डायग्नोस्टिक्स के लिए इसकी जरूरत है। इसे अधिक न करें: यह बॉक्स एक राउटर और वॉचडॉग है, ब्राउज़िंग टर्मिनल नहीं।
• एंटी-रीबाइंड, LAN→DMZ, और बड़ा साफ-सफाई। LAN और DMZ के बीच, केवल स्पष्ट रूप से परिभाषित रास्ते अनुमति प्राप्त हैं (जैसे, क्लाइंट्स से DMZ सेवा); वापसी रास्ता बंद रहता है। एंटी-रीबाइंड नियम क्लाइंट्स को DNS तरकीबों के माध्यम से फ़ायरवॉल के अंदर संरक्षित लक्ष्यों तक पहुँचने से रोकते हैं। बाकी जगह PF स्पष्ट "ना" कहता है—जहाँ त्वरित त्रुटि टोन समस्या निवारण में मदद करता है वहाँ वापसी के साथ।

केवल राउटर बनाम राउटर+DMZ: कौन सा प्रोफ़ाइल आपके लिए उपयुक्त है?

यदि आप केवल LAN को इंटरनेट से जोड़ना चाहते हैं, तो केवल राउटर आदर्श है—कॉम्पैक्ट, स्पष्ट, और फिर भी मजबूत। आपको एंटी-स्पूफिंग, बोगन फ़िल्टर, सख्त ईग्रेस रुख, DNS प्रवर्तन 1.1.1.1/1.0.0.1 तक, DoH/DoT/DoQ/QUIC नियंत्रण, LAN से फ़ायरवॉल के लिए प्रशासनिक SSH, और स्क्रबिंग, स्टेट्स, और सीमाओं के लिए सुव्यवस्थित डिफ़ॉल्ट मिलते हैं।

जैसे ही आप सेवाएं होस्ट करते हैं—यहाँ तक कि यदि वे केवल आंतरिक हों—राउटर+DMZ समझ में आता है। एक DMZ विफलताओं को सीमित करता है और संभावना कम करता है कि एक समझौता सेवा आपके LAN में प्रवेश का माध्यम बने। इन्ट्रा-DMZ बंद रहता है; ईग्रेस व्हाइटलिस्ट-आधारित और LAN से कड़ा होता है। DNS समान रूप से सख्त है; NTP तब तक बंद रहता है जब तक आपको वास्तव में इसकी आवश्यकता न हो।

IPv6 को सही तरीके से सक्षम करना

आधार IPv6 को ब्लॉक करता है ताकि कुछ भी आधा खुला न रहे। यदि आपको IPv6 चाहिए, तो इसे जानबूझकर और सुसंगत रूप से सक्षम करें: sysctl के माध्यम से राउटिंग, inet6 pf नियमों से मेल, एक साफ़ ईग्रेस योजना (हाँ, यहाँ भी DNS प्रवर्तन—केवल v6 के लिए), और RA/DHCPv6 पर स्पष्ट निर्णय। v4 से अच्छी आदतें प्रतिबिंबित करें: एंटी-स्पूफिंग, डिफ़ॉल्ट अस्वीकृति, QUIC/DoH/DoQ प्रबंधन, और दृश्य अपवाद—ना ज्यादा, ना कम। सबसे महत्वपूर्ण सुझाव: v6 को "चुपके से" न लाएं। यदि यह मौजूद है, तो इसे सही करें—या अभी नहीं।

ऑपरेशन, डायग्नोस्टिक्स, और फॉरेंसिक्स: मापें, अंदाजा न लगाएं

एक सख्त नीति तभी अच्छी होती है जब आप इसे दैनिक जीवन में पढ़ सकें। pf तीन चैनलों के माध्यम से मदद करता है:

लेबल्स। हर संबंधित नियम एक वर्णनात्मक लेबल रखता है। pfctl -vvsr में, आप देख सकते हैं कि कौन से रास्ते उपयोग हो रहे हैं, कौन से ब्लॉक हैं, और कार्रवाई कहाँ हो रही है। व्यवहार में यह अक्सर मुद्दों को संकुचित करने के लिए पर्याप्त होता है।

टेबल्स। pfctl -t <table> -T show के साथ आप दुरुपयोगकर्ता/स्कैनर प्रविष्टियां पढ़ते हैं। overload इन टेबलों को स्वचालित रूप से भरता है जब क्लाइंट असामान्य संख्या में कनेक्शन खोलते हैं। यह सजा नहीं है; यह सीटबेल्ट है—फिसलन आपको विंडशील्ड के माध्यम से उड़ने नहीं देती।

न्यूनतम pcap। tcpdump आपका दोस्त है—लेकिन इसे उद्देश्यपूर्ण रूप से उपयोग करें। DNS/DoH नियंत्रण के लिए, तेज़ नज़रें जैसे
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
अक्सर पर्याप्त होती हैं। यह योजना के साथ फॉरेंसिक्स है, "Wireshark जब तक आपकी आँखें पानी न आ जाएं" नहीं।

एक स्वस्थ परीक्षण कैनन। जब आप नियम बदलते हैं, तो पहले उन्हें बिना लोड किए संकलित करें: pfctl -nf /etc/pf.conf। फिर pfctl -f—और यदि कुछ टूटता है, तो लेबल्स और टेबल्स सुधारों का मार्गदर्शन करते हैं। DNS प्रवर्तन के लिए, सक्रिय परीक्षण करें: drill @1.1.1.1 openbsd.org काम करना चाहिए; drill @9.9.9.9 openbsd.org ब्लॉक होना चाहिए। QUIC के लिए, सत्यापित करें कि curl -I --http3 https://example.com UDP पर नहीं जाता; इसे HTTP/2 पर वापस जाना चाहिए। DoT/DoQ को 1.1.1.1:853 और UDP 784 पर जानबूझकर प्रयासों से सत्यापित करें—वे असफल होने चाहिए, और आपको लेबल वाले नियमों पर ब्लॉक काउंटर दिखना चाहिए।

ईग्रेस परिवर्तनों के लिए सुझाव। जब आप कुछ खोलते हैं, तो इसे अस्थायी रूप से बहुत स्पष्ट लेबल के साथ चिह्नित करें और एक सप्ताह बाद जांचें कि क्या इसका वास्तव में उपयोग हो रहा है। यदि कोई उपयोग नहीं करता, तो इसे हटा दें। इससे आपका आधार पतला रहता है।

फोकलोर के बिना प्रदर्शन विचार

यह सेटअप रेज़र की धार पर ट्यून नहीं है—यह स्थिरता के लिए ट्यून है। कुछ परिणाम महत्वपूर्ण हैं:

QUIC ब्लॉकिंग कुछ साइटों को थोड़ा धीमा कर सकता है। यह एक जानबूझकर व्यापार है: गति से अधिक दृश्यता। यदि आपके पास HTTP/3 की वैध अनुमति के कारण हैं, तो इसे सर्जिकल रूप से करें (टेबल में लक्ष्य, उन्हें लेबल करें, हो गया)।

ECN चालू अधिकांश आधुनिक नेटवर्क में ठीक है। यदि कोई विदेशी मिडलबॉक्स ECN को पसंद नहीं करता, तो आप इसे जल्दी देखेंगे और उस विशेष मामले में ECN को अक्षम कर सकते हैं—आधार आपके खिलाफ नहीं है।

स्थैतिक UDP NAT पोर्ट रियल-टाइम प्रोटोकॉल के लिए उपहार हैं। जिसने भी WebRTC मुद्दों का पीछा किया है, वह जानता है कि यह कितना मूल्यवान है। यह कुछ भी खर्च नहीं करता, सिवाय इसके कि यह समझना कि UDP के लिए NAT पोर्ट "यादृच्छिकता" सुरक्षा सुविधा नहीं है।

if-queues और BPF बफ़र्स व्यावहारिक रूप से सेट किए गए हैं: विस्फोटों के लिए पर्याप्त हेडरूम, और डिबग सत्र जो 4 KB बफ़र्स पर नहीं मरते। यदि आप सचमुच लाइन रेट को धकेलते हैं, तो मापें और समायोजित करें—इसके विपरीत नहीं।

सामान्य गलतियाँ—और उन्हें सहजता से कैसे संभालें

"मेरा ऐप केवल DoH के साथ काम करता है!" तो इसे अपवाद चाहिए—या बेहतर, एक ईमानदार मूल्यांकन। DoH स्वाभाविक रूप से खराब नहीं है, लेकिन यह घर या व्यवसायों में नेटवर्क नियंत्रण के लिए प्रतिकूल है। आप विशिष्ट होस्ट्स को टेबल में अनुमति दे सकते हैं; इसे एक जानबूझकर अपवाद रखें, वैश्विक खुलापन नहीं।

"वीडियो कॉल रुक-रुक कर चलती हैं।" पहले सत्यापित करें कि आपके प्रदाता के UDP रेंज कवर हैं (Zoom/Teams/WebRTC)। स्थैतिक UDP पोर्ट मदद करते हैं, लेकिन सही ईग्रेस मार्ग के बिना कुछ भी बेहतर नहीं होगा। सर्जिकल रूप से समायोजित करें, व्यापक रूप से नहीं।

"मेरा मेल क्लाइंट सीधे भेज नहीं सकता।" सही—आउटबाउंड पोर्ट 25 ब्लॉक है। मेल को सबमिशन (465/587) के माध्यम से आपके प्रदाता या सर्वर को जाना चाहिए, सीधे इंटरनेट पर नहीं। यदि आवश्यक हो, तो उन सबमिशन पोर्ट्स को अनुमति दें—स्पष्ट रूप से लेबल किए हुए।

"IPv6 अचानक टूट गया।" इस आधार में, v6 ब्लॉक है। यदि क्लाइंट v6 पसंद करते हैं जबकि फ़ायरवॉल इसे राउट नहीं करता, तो आपको टाइमआउट दिखाई देंगे। या तो v6 को सही तरीके से सक्षम करें (नियमों के साथ) या क्लाइंट्स को स्पष्ट करें (RA/ND) कि v6 अभी उपलब्ध नहीं है।

"नियम परिवर्तन के बाद अजीब प्रभाव।" सोचें स्टेट्स के बारे में। पुराने स्टेट्स डिफ़ॉल्ट रूप से जीवित रहते हैं। जब आप मुख्य नीति बदलते हैं (जैसे, नया ईग्रेस पोर्ट खोलना), प्रभावित स्टेट्स को मारें (pfctl -k ...) या, यदि आवश्यक हो, सभी को फ्लश करें (pfctl -F state)। उसके बाद, दुनिया फिर से संगत होती है।

यह आधार "सुरक्षित" क्यों है—और यहाँ सुरक्षा का क्या मतलब है

सुरक्षा कभी पूर्ण नहीं होती। लेकिन यह मापनीय होती है जब आप स्पष्ट लक्ष्य सेट करते हैं और अपनी राह का ईमानदारी से सत्यापन करते हैं। यह आधार हमला सतह को कम करता है क्योंकि यह:

• हर इनबाउंड एक्सपोजर को न्यूनतम करता है,
• ईग्रेस को नियम के बजाय अपवाद बनाता है,
• DNS को दृश्यमान और नियंत्रित रखता है,
• छिपे हुए रास्तों (QUIC/DoH/DoT/DoQ) को लगातार ब्लॉक करता है,
• छद्म-विशेषताएं (रीडायरेक्ट्स, प्रसारण) को अक्षम करता है,
• मजबूत TCP/ICMP डिफ़ॉल्ट लागू करता है,
• स्टेट हैंडलिंग को नियतात्मक बनाता है,

और आपको दैनिक संचालन में उपयोग देखने के लिए उपकरण देता है।

साथ ही, कॉन्फ़िगरेशन बनाए रखने योग्य रहता है। यह "सुरक्षित" इसलिए नहीं है क्योंकि इसमें 3,000 लाइनें हैं; यह इसलिए सुरक्षित है क्योंकि आप हर लाइन समझा सकते हैं।

माइग्रेशन: कैसे आगे बढ़ें

यदि आप मौजूदा pf कॉन्फ़िगरेशन से आ रहे हैं, तो चरण-दर-चरण आगे बढ़ें:

सबसे पहले sysctl। हार्डनिंग लोड करें जो सेवा उपलब्धता को बाधित न करे। असामान्य ICMP या RST शोर के लिए लॉग जांचें।

pf नीति के साथ परीक्षण करें। pfctl -nf और एक लैब या रखरखाव विंडो का उपयोग करें। पहली बार सक्षम करते समय, LAN से फ़ायरवॉल के लिए SSH का ध्यान रखें—खुद को लॉक करना मज़ेदार नहीं है।

ईग्रेस कड़ा करें। DNS प्रवर्तन चालू करें और निरीक्षण करें। फिर धीरे-धीरे क्लासिक जोखिम सेवाओं को बंद करें। एक से दो सप्ताह की निगरानी अंधेरे स्थानों को खोजने में मदद करती है।

DMZ पेश करें (यदि आवश्यक हो)। सेवाओं को स्थानांतरित करें, इन्ट्रा-DMZ और DMZ→LAN बंद रखें। केवल वास्तव में आवश्यक ईग्रेस रास्ते खोलें। निरीक्षण करें और सुधार करें।

IPv6 पर जानबूझकर निर्णय लें। या तो इसे सही तरीके से सक्षम करें—या इसे बंद रखें और क्लाइंट्स को सूचित रखें।

प्रत्येक चरण जोखिम भरे बड़े बदलाव के बिना सुरक्षा बढ़ाता है।

आप बाद में आसानी से क्या बढ़ा सकते हैं

यह आधार एक बुनियाद है, पिंजरा नहीं। सामान्य विस्तार:

1. QUIC/DoH के लिए लक्षित अपवाद यदि आपके पास मान्य कारण हैं—हमेशा टेबल्स और लेबल्स के माध्यम से।
2. मिनिमल हमला सतह के साथ साइट-टू-साइट VPNs; sysctl डिफ़ॉल्ट आपको तब तक प्रतिबंधित नहीं करते जब तक आप प्रोटोकॉल स्पष्ट रूप से अनुमति न दें।
3. मॉनिटरिंग/अलर्टिंग। pf काउंटर और systat pf बुनियादी मेट्रिक्स के लिए बढ़िया हैं। अधिक के लिए, pf लॉग्स को केंद्रीय सिस्टम पर भेजें।
4. IPv6, पूरी तरह से v4 लॉजिक के प्रतिबिंब के साथ—बोल्ट-ऑन के रूप में नहीं।

अपग्रेड और रखरखाव पर एक शब्द

OpenBSD अपने वादों को निभाता है—लेकिन अपग्रेड के दौरान रिलीज नोट्स पढ़ें, खासकर pf सिंटैक्स और कर्नेल डिफ़ॉल्ट्स के आसपास। लेबल्स, टेबल्स, और स्पष्ट मैक्रोज़ आपके कॉन्फ़िग को संस्करणों के बीच जल्दी सत्यापित करने में मदद करते हैं। हर अपवाद को टिप्पणी करें: यह क्यों मौजूद है, किसे चाहिए, आपने इसे आखिरी बार कब समीक्षा किया। अपवाद पाप नहीं हैं—अटिप्पणी अपवाद तकनीकी ऋण हैं।

निष्कर्ष: स्पष्टता सबसे अच्छी हार्डनिंग है

इस आधार का एक सरल लक्ष्य है: जटिलता से अधिक स्पष्टता। आपको एक OpenBSD फ़ायरवॉल मिलता है जो दैनिक उपयोग में पूर्वानुमानित है, हमला सतह को छोटा रखता है, और आपको लेबल्स, टेबल्स, और समझदार डिफ़ॉल्ट्स के माध्यम से दिखाता है कि वास्तव में क्या हो रहा है। हम स्पष्ट विकल्पों को अप्रत्यक्ष साइड इफेक्ट्स से प्राथमिकता देते हैं: सख्त ईग्रेस नीति, परिभाषित रिज़ॉल्वर तक DNS प्रवर्तन, QUIC या DoH/DoT/DoQ पर कोई गुप्त साइड चैनल नहीं, नियतात्मक स्टेट्स, और मजबूत कर्नेल स्विच। परिणाम एक शैक्षणिक शोपीस नहीं बल्कि एक टिकाऊ प्रारंभिक बिंदु है जिस पर आप आत्मविश्वास के साथ निर्माण कर सकते हैं।

यह ध्यान देना महत्वपूर्ण है कि यह आधार जानबूझकर कोई स्थानीय रिज़ॉल्वर और कोई स्थानीय NTP सेवा नहीं मानता। यह उन सेटअप्स को लक्षित करता है जो बिना अतिरिक्त अवसंरचना के जल्दी स्थिर हो जाना चाहिए। यदि आप बाद में ऑन-प्रिम कंट्रोल चाहते हैं, तो आप इसे सहजता से जोड़ सकते हैं—आर्किटेक्चर तैयार है, मूल रुख को छोड़े बिना।

आपकी खोज बचाने के लिए: आप नीचे पूर्ण कॉन्फ़िगरेशन प्रस्ताव पाएंगे—दोनों pf.conf प्रोफाइल (केवल राउटर बिना DMZ और राउटर+DMZ सख्त पृथक्करण के साथ) साथ ही हार्डनड sysctl.conf। यह लेख निर्णयों को समझाता है; नीचे की फाइलें उन्हें 1:1 लागू करती हैं। यदि आप अनुक्रम का पालन करते हैं "सत्यापित करें → लोड करें → मापें", तो आप जल्दी एक पुनरुत्पादित परिणाम तक पहुंचेंगे।

इतना ही महत्वपूर्ण है कि स्कोप के बारे में ईमानदार रहें: यहाँ अत्यधिक लक्षित हमले या पूर्ण IDS/IPS परिदृश्य केंद्र में नहीं हैंव्यवस्थित रूप से जोड़ सकें। तीन विस्तार पथ व्यावहारिक रूप से उपयोगी साबित हुए हैं।

यदि आपके पास विशिष्ट नियमों को कड़ा करने, विशेष आवश्यकताओं, या अपने स्वयं के संचालन से अवलोकन साझा करने के विचार हैं: कृपया संपर्क करें। वास्तविक दुनिया की प्रतिक्रिया सार्थक सुधारों के लिए सबसे अच्छा उत्प्रेरक है—और यह भविष्य के सुधारों में योगदान देगा। सुरक्षा एक प्रक्रिया है, दौड़ नहीं; एक स्पष्ट आधार और अनुभव साझा करने वाले समुदाय के साथ, "अच्छा" जल्दी "उत्कृष्ट" में बदल जाता है।

sysctl.conf ड