पासवर्ड-संरक्षित अतिथी SSID हे सुरक्षित अतिथी नेटवर्क नाही. हे रेडिओ लिंक एनक्रिप्ट करू शकते, परंतु यामुळे अभ्यागताला कर्मचाऱ्यांच्या सबनेटवर जाण्यापासून रोखता येत नाही, एका अतिथी डिव्हाइसला दुसऱ्यावर हल्ला करण्यापासून रोखता येत नाही, Captive Portal ला क्रेडेंशियल चोरीपासून वाचवता येत नाही, किंवा साइन-इन दरम्यान गोळा केलेल्या वैयक्तिक डेटाचे नियमन करता येत नाही. त्यामुळे, How to secure guest WiFi ची सुरुवात एका व्यापक डिझाइन प्रश्नाने होते: कनेक्ट केलेले डिव्हाइस कुठे पोहोचू शकते, वेन्यू कोणती ओळख राखून ठेवतो आणि टीम गैरवापर किती लवकर शोधू शकते?
याचे व्यावहारिक उत्तर बहुस्तरीय आहे. मजबूत वायरलेस एन्क्रिप्शन वापरा, राउटिंग बाउंड्रीवर गेस्ट ट्रॅफिक वेगळे करा, लॅटरल मुव्हमेंट नियंत्रित करा, ठिकाणाला सुसंगत असे ऑथेंटिकेशन निवडा, गोळा केला जाणारा डेटा कमीत कमी ठेवा आणि नेटवर्कला एका वन-ऑफ कॉन्फिगरेशन ऐवजी मॉनिटर केलेल्या सेवेच्या रूपात ऑपरेट करा.
बहुतांश गेस्ट WiFi सेटअप्स दिसतात त्यापेक्षा कमी सुरक्षित का असतात
अतिथी SSID पासवर्ड प्रदर्शित करू शकते, क्लायंटना VLAN वर नियुक्त करू शकते आणि तरीही टाळता येण्याजोग्या जोखमीसाठी जागा उघडी ठेवू शकते. UK सरकारी मार्गदर्शक तत्त्वांनुसार अतिथी आणि कॉर्पोरेट ट्रॅफिकमध्ये स्पष्ट वेगळेपण असणे आवश्यक आहे आणि अतिथी वापरकर्त्यांनी इंटरनेट सेवांपर्यंत पोहोचण्यापूर्वी प्रमाणीकरण करणे आवश्यक आहे. त्यांचे सुरक्षा मानक अतिथी प्रवेशाला सेगमेंटेशन आणि ऑथेंटिकेशन नियंत्रण बनवते, पासवर्डची निवड नाही. UK सरकारी वायरलेस नेटवर्क सुरक्षा मानक
हल्ल्याची व्याप्ती केवळ रेडिओ नेटवर्कपुरती मर्यादित नसते. एक Captive Portal क्रेडेंशियल्स गोळा करू शकते, एखादे अप्लायन्स ॲडमिनिस्ट्रेटिव्ह ॲक्सेस उघडे करू शकते आणि व्हिजिटर डेटाबेस सेवेला आवश्यकतेपेक्षा जास्त वैयक्तिक माहिती राखून ठेवू शकतो. VLANs आणि पोर्टल पेजेस हे समस्येच्या केवळ एका भागाचे निराकरण करतात.
वापरकर्त्यांचे वर्तन आणखी एक धोका निर्माण करते. २०१२ मधील एका UK सर्वेक्षणात आधीच दिसून आले होते की ५६% सार्वजनिक WiFi वापरकर्ते ब्राउझिंग करण्यापूर्वी WiFi एन्क्रिप्टेड आहे की नाही हे तपासत नव्हते, तर सार्वजनिक WiFi वापरणारे ४२% प्रौढ व्यक्ती नेटवर्क सुरक्षित आहे की नाही हे कधीच किंवा क्वचितच तपासत होते. यामध्ये वापरकर्ते सार्वजनिक WiFi वर ईमेल पासवर्ड, सोशल-मीडिया क्रेडेंशियल्स, पेमेंट-कार्ड तपशील आणि ऑनलाइन बँकिंग पासवर्ड प्रविष्ट करत असल्याचे देखील नोंदवले गेले. हे आकडे एक ऐतिहासिक बेसलाइन आहेत, प्रत्येक सध्याच्या डेप्लॉयमेंटचे वर्णन नाही. तरीही ते दर्शवतात की एखादे ठिकाण अभ्यागतांनी बनावट SSID ओळखण्यावर किंवा कनेक्शन विश्वासार्ह आहे की नाही हे ठरवण्यावर अवलंबून राहू शकत नाही. UK सार्वजनिक WiFi वापरकर्ता-धोका सर्वेक्षण
वास्तविक उपयोजनांमध्ये दिसणाऱ्या तीन त्रुटी
- एक विसरलेला फायरवॉल नियम: एखादे कॉफी शॉप त्याच्या अतिथी SSID ला VLAN वर मॅप करते, परंतु जुना नियम अद्याप POS सबनेटच्या दिशेने ट्रॅफिकला परवानगी देतो. VLAN अस्तित्वात आहे, तरीही राउटिंग पॉलिसी आयसोलेशन अयशस्वी करते.
- एक निष्काळजी पोर्टल फॉर्म: एखादे हॉटेल स्प्लॅश पेजवर अतिथींना ईमेल पत्ता आणि पासवर्डसारखी माहिती विचारते. कमकुवत ट्रान्सपोर्ट सुरक्षा, जास्त प्रमाणात माहिती गोळा करणे किंवा उघडा असलेला डेटाबेस पोर्टलला ओळख डेटाच्या चोरीचे स्त्रोत बनवतो.
- एक अनमॅनेज्ड उपकरण: एखादे क्लिनिक त्याच्या कंट्रोलर किंवा ॲक्सेस पॉइंट्सवर डीफॉल्ट ॲडमिनिस्ट्रेटिव्ह ॲक्सेस सुरू ठेवते. मॅनेजमेंट प्लेनचा ताबा घेणारा आक्रमणकर्ता वायरलेस कॉन्फिगरेशन बदलू शकतो, जरी अतिथी ट्रॅफिक इतर प्रकारे आयसोलेट केलेले असले तरीही.
व्यावहारिक नियम: गेस्ट डिव्हाइसेसना जोडणी झाल्यापासूनच अविश्वासू समजा. एन्क्रिप्शन कनेक्शनचे रक्षण करते, सेगमेंटेशन पोहोच मर्यादित करते, ऑथेंटिकेशन जबाबदारी निश्चित करते, आणि मॉनिटरिंग दर्शवते की कोणी या नियंत्रणांचा गैरवापर कधी केला.
PSK रोटेशन हे केवळ एक नियंत्रण आहे. अतिथी सामायिक केलेल्या कीचे स्क्रीनशॉट घेऊ शकतात, ती पुन्हा वापरू शकतात किंवा प्रकाशित करू शकतात आणि ती बदलल्याने उघड झालेले व्यवस्थापन इंटरफेस, कमकुवत पोर्टल किंवा अधिक परवानग्या देणारी फायरवॉल दुरुस्त होत नाही. सुरक्षित अतिथी WiFi ला गोपनीयता, नियंत्रण, ओळख आणि ऑपरेशनल देखरेख यासाठी स्वतंत्र नियंत्रणांची आवश्यकता असते. वेन्यूकडे अभ्यागतांच्या डेटासाठी धारणा आणि प्रवेश धोरण असणे देखील आवश्यक आहे, कारण अतिथी डेटाबेस उघडा ठेवून नेटवर्क सुरक्षित केल्याने केवळ अर्धीच समस्या सुटते.
योग्य एन्क्रिप्शन आणि ऑथेंटिकेशन निवडणे
एनक्रिप्शनची निवड वेन्यूच्या डिव्हाइस मिक्स आणि जबाबदारीच्या गरजेनुसार असावी. यूके सरकारचे SS 019 वायरलेस मानक हे सामायिक वायरलेस नेटवर्कसाठी WPA2-PSK with AES ला व्यावहारिक आधारभूत मानका म्हणून ओळखते आणि अंदाजा लावणाऱ्या हल्ल्यांना तोंड देऊ शकणारी लांब प्री-शेअर्ड की वापरण्याची शिफारस करते. चार यादृच्छिकपणे निवडलेले शब्द सुरक्षा आणि वापरण्यायोग्यता या दरम्यान एक व्यावहारिक संतुलन देतात. जिथे जुनी डिव्हाइसेस किंवा साधा अभ्यागत अनुभव यामुळे ओळख-आधारित प्रवेश नाकारला जातो, तिथे हे योग्य राहते.
WPA3-Personal हे SAE द्वारे पासवर्डचा अंदाज लावण्याविरुद्धची सुरक्षा मजबूत करते आणि प्रत्येक कनेक्शनसाठी अधिक मजबूत सेशन संरक्षण प्रदान करते. सामायिक क्रेडेंशियल हीच त्याची मर्यादा राहते. नेटवर्क ओळखू शकत नाही की कोणत्या अभ्यागताने ते वापरले आहे, आणि कोणताही अतिथी की कॉपी किंवा वितरित करू शकतो. सुसंगत डिव्हाइसेस आणि सुलभ ऑनबोर्डिंग महत्त्वाचे असताना WPA3-Personal चा वापर करा. ट्रान्झिशन मोड केवळ तिथेच सक्षम करा जिथे जुन्या क्लायंटना अजूनही त्याची आवश्यकता आहे, कारण जुन्या डिव्हाइसेसना सपोर्ट दिल्याने कमकुवत सुसंगततेचा मार्ग लांबतो.
WPA3-Enterprise हे 802.1X वापरते आणि वापरकर्ता किंवा डिव्हाइस ओळखीसाठी प्रवेश नियुक्त करते. प्रमाणपत्रांसह EAP-TLS ऑपरेटरना अधिक स्पष्ट रद्द करण्याची प्रक्रिया देते. प्रत्येक अभ्यागताची क्रेडेंशियल न बदलता एक तडजोड केलेली ओळख निष्क्रिय केली जाऊ शकते. PEAP समाविष्ट करणे सोपे असू शकते, परंतु पासवर्ड हाताळणी आणि फिशिंग जोखीम कायम राहतात. Purple चे WPA-Enterprise मार्गदर्शन आर्किटेक्चर आणि त्याच्या उपयोजन विचारांचे स्पष्टीकरण देते.
जेव्हा ऑपरेशन्समधील साधेपणा हा वैयक्तिक उत्तरदायित्वापेक्षा जास्त महत्त्वाचा असतो तेव्हा सामायिक प्रवेश निवडा. जेव्हा रिव्होकेशन, वारंवार भेटी किंवा ऑडिट रेकॉर्ड महत्त्वाचे असतात तेव्हा ओळख-आधारित प्रवेश निवडा.
Captive Portal हे वर्कफ्लो आहेत, एन्क्रिप्शन नाही
एक Captive Portal ऑनबोर्डिंग आणि पॉलिसी स्वीकारणे व्यवस्थापित करते. हे सर्व गेस्ट ट्रॅफिक एंड टू एंड एन्क्रिप्ट करत नाही आणि ते WPA2 किंवा WPA3, VLAN सेपरेशन किंवा फायरवॉल कंट्रोल्सची जागा घेऊ शकत नाही. जर पोर्टल आवश्यकतेपेक्षा जास्त माहिती गोळा करत असेल, तर ते डेटा-गव्हर्नन्ससाठी देखील एक समस्या बनू शकते.
| पद्धत | सुरक्षा सामर्थ्य | उपयोजन प्रयत्न | सर्वोत्तम तंदुरुस्त |
|---|---|---|---|
| क्लिक-थ्रू | कमी ओळख हमी, साधे प्रवेश नियंत्रण | कमी | सार्वजनिक जागा जिथे उत्तरदायित्वाच्या आवश्यकता मर्यादित आहेत |
| व्हाउचर | उत्कृष्ट सत्र उत्तरदायित्व आणि वेळ नियंत्रण | मध्यम | कार्यक्रम आणि सेवा पुरवलेली स्थळे |
| SMS OTP | प्रवेश फोन नंबरशी जोडतो, परंतु गोपनीयता आणि वितरण अवलंबित्व तयार करतो | मध्यम | अशी स्थळे ज्यांना संपूर्ण ओळख प्रदात्याशिवाय मजबूत ओळखीची आवश्यकता आहे |
| सोशल लॉगिन | तृतीय-पक्ष आणि संमतीच्या परिणामांसह, सोयीस्कर ओळख सिग्नल | मध्यम | किरकोळ आणि आदरातिथ्य विपणन प्रवास |
| ईमेल नोंदणी | संमती आणि पुनरावृत्ती भेटींसाठी उपयुक्त, परंतु अभ्यागत डेटाबेस तयार करते | मध्यम | स्पष्ट धारणा धोरण असलेली ग्राहकाभिमुख स्थळे |
| प्रमाणपत्रांसह 802.1X | मजबूत प्रति-डिव्हाइस ओळख आणि रद्द करणे | उच्च | एंटरप्राइझ, नियमन केलेले आणि वारंवार भेट देणारे वातावरण |
यामधील मुख्य तडजोड म्हणजे गव्हर्नन्स. एका क्लिक-थ्रू पेजवर केवळ पावतीची नोंद होते, अर्थपूर्ण ओळखीची नाही. SMS आणि सोशल लॉगिनमुळे वैयक्तिक-डेटा संकलन आणि तृतीय-पक्षावरील अवलंबित्व वाढते. ईमेल नोंदणीमुळे व्हिजिटर डेटाबेस तयार होतो, त्यामुळे प्रशासकीय प्रवेश मर्यादित करा, उद्देशाचे दस्तऐवजीकरण करा, डेटा साठवून ठेवण्याच्या मर्यादा निश्चित करा आणि डेटा हटवण्यासाठी किंवा दुरुस्त करण्यासाठी एक प्रक्रिया प्रदान करा.
ठिकाण-विशिष्ट (venue-specific) ऑपरेटिंग मॉडेल्ससाठी, पर्याय मर्यादित ठेवा: जेथे कर्मचाऱ्यांना मर्यादित वेळेची जबाबदारी हवी असेल तेथे व्हाउचर वापरा आणि जेथे ते ठिकाण आयडेंटिटी सर्व्हिस आणि सर्टिफिकेट लाइफसायकल ऑपरेट करू शकत असेल तेथे एंटरप्राइझ ऑथेंटिकेशन वापरा. पुढील चेकलिस्ट नेटवर्क डिझाइनची पुनरावृत्ती न करता त्या निर्णयांना ठिकाणाच्या प्रकारांशी जोडते.
PSK रोटेशन केवळ तेव्हाच उपयुक्त ठरते जेव्हा त्याचे वितरण नियंत्रित असते. जर एखाद्या अतिथीने स्क्रीनशॉटमध्ये की पोस्ट केली, तर ती नंतर रोटेट केल्याने धोका मर्यादित होतो परंतु त्यामुळे ओळख सिद्ध होत नाही. सर्वात सोपी पद्धत निवडा जी त्या ठिकाणाला जबाबदारी, प्रायव्हसी कंट्रोल्स आणि व्यवस्थापित करता येईल असा ऑपरेशनल वर्कलोड प्रदान करेल.
नेटवर्क सेगमेंटेशन आणि आयसोलेशन डिझाइन करणे
किमान उपयुक्त सीमा लेयर तीनवर असते. अतिथी SSID ला त्याच्या स्वतःच्या VLAN वर ठेवा, त्याला समर्पित DHCP स्कोप नियुक्त करा आणि त्याला अशा फायरवॉलद्वारे रूट करा ज्याची डीफॉल्ट स्थिती कर्मचारी, IoT, पेमेंट आणि व्यवस्थापन नेटवर्कचा प्रवेश नाकारण्याची आहे. केवळ ठिकाणाला आवश्यक असलेल्या आउटबाउंड सेवांनाच परवानगी द्या, सहसा वेब आणि DNS, नंतर केवळ वास्तविक आवश्यकता असेल तेव्हाच स्पष्ट अपवाद जोडा.
यूके सरकारचे वायरलेस मार्गदर्शन अभ्यागत प्रवेशाद्वारे विशेषाधिकार प्राप्त LAN प्रवेश उघडा न करण्याची आवश्यकता व्यक्त करते आणि अभ्यागत डिव्हाइसेस दरम्यान विलगीकरण करण्याची शिफारस करते. एक व्यावहारिक यूके हार्डनिंग क्रम अतिथी SSID ला त्याच्या स्वतःच्या VLAN वर ठेवतो, स्टेटफुल आउटबाउंड फायरवॉल नियम वापरतो आणि क्लायंट-टू-क्लायंट ट्रॅफिक ब्लॉक करतो. UK guest WiFi hardening guidance
टोपोलॉजीला धोक्याशी सुसंगत करा
एखादे लहान ठिकाण एकच गेस्ट VLAN, AP-लेव्हल क्लायंट आयसोलेशन आणि केवळ इंटरनेटसाठीचा फायरवॉल नियम वापरू शकते. हे स्वस्त आणि व्यावहारिक आहे, परंतु यामुळे विशिष्ट भूमिकांसाठी पॉलिसी लागू करण्यास कमी वाव मिळतो आणि जेव्हा ते ठिकाण पेमेंट टर्मिनल्स, कॅमेरे किंवा बिल्डिंग सिस्टम्स जोडते तेव्हा ही यंत्रणा कमकुवत बनू शकते.
एका मध्यम आकाराच्या ठिकाणाने गेस्ट, स्टाफ आणि IoT VLANs वेगळे ठेवले पाहिजेत, ज्यामध्ये राउटर किंवा फायरवॉल लेयर-थ्री बाउंड्री लागू करेल. वायरलेस इन्फ्रास्ट्रक्चर तसेच फायरवॉलवर क्लायंट आयसोलेशन सक्षम करणे आवश्यक आहे, कारण अतिथींना एकाच IP रेंजमध्ये एकमेकांवर हल्ला करता आला नाही पाहिजे.
एंटरप्राइझ किंवा मल्टि-साईट उपयोजनासाठी VRFs, किंवा त्यासमान व्हर्च्युअल पृथक्करण मॉडेल, भूमिका-आधारित फायरवॉल पॉलिसी आणि केंद्रीय NAC ची आवश्यकता असू शकते. प्रत्येक डिव्हाइसला संपूर्ण 802.1X रोलआउटला समर्थन देण्याची आवश्यकता न ठेवता, वेगवेगळ्या प्री-शेअर्ड की डिव्हाइसेस किंवा भूमिकांशी मॅप करून iPSK BYOD-हेवी वातावरणासाठी उपयुक्त मध्यम मार्ग प्रदान करू शकते. यासाठी अजूनही लाइफसायकल व्यवस्थापनाची आवश्यकता असते आणि याला सर्टिफिकेट-दर्जाची ओळख समजण्याची चूक करू नये.
Purple चे private-area network मार्गदर्शन वेगवेगळ्या वापरकर्ता गटांनी इन्फ्रास्ट्रक्चर शेअर करताना कशा प्रकारच्या आयसोलेशनची आवश्यकता असते याचे वर्णन करते.
वारंवार येणाऱ्या ट्रंक एररची प्रत्यक्ष तपासणी करणे आवश्यक आहे. स्विच ट्रंकवर टॅग केलेले अतिथी VLAN पूर्णपणे वैध असू शकते, परंतु जर तो ट्रंक कोर नेटवर्कला चुकीचे प्रवेश मार्ग देखील उघडे करून देत असेल, तर ब्रॉडकास्ट डोमेन आणि राउटिंग पॉलिसी अपेक्षेप्रमाणे काम करू शकत नाही. अतिथी डिव्हाइसवरून चाचणी करा, अंतर्गत सेवा आणि व्यवस्थापन इंटरफेसमध्ये प्रवेश करण्याचा प्रयत्न करा आणि पीअर-टू-पीअर ट्रॅफिक अयशस्वी होत असल्याची खात्री करा. कंट्रोलरमध्ये VLAN नाव योग्य दिसत आहे म्हणून डिझाइन मंजूर करू नका.
प्रमाणपत्र-आधारित प्रवेश आणि अखंड रोमिंग
प्रमाणपत्र-आधारित प्रवेशामुळे व्हिजिटरचा अनुभव “SSID शोधा, पासवर्ड वाचा, पोर्टल स्वीकारा” वरून थेट स्वयंचलित नेटवर्क निवड आणि ऑथेंटिकेशनमध्ये बदलतो. Passpoint किंवा OpenRoaming सह, एखादे डिव्हाइस विश्वासू प्रदाता शोधू शकते, नेटवर्क प्रमाणित करू शकते आणि प्रत्येक भेटीच्या वेळी शेअर्ड की न दाखवता कनेक्ट होऊ शकते. अतिथीला कदाचित कोणतेही स्पॅश पेज अजिबात दिसणार नाही.
ऑपरेटरसाठी, त्या साधेपणासाठी खऱ्या इन्फ्रास्ट्रक्चरची आवश्यकता असते. आपल्याला एक RADIUS किंवा क्लाउड ऑथेंटिकेशन सर्व्हिस, एक सर्टिफिकेट किंवा फेडरेशन प्रदाता, अचूकपणे जाहिरात केलेली रोमिंग माहिती आणि डिव्हाइस प्रोफाइलिंग आणि ओळख रिव्होकेशनसाठी प्रक्रिया आवश्यक आहे. Purple चे Passpoint विहंगावलोकन या प्रकारच्या पासवर्डशिवायच्या रोमिंग मॉडेलचा समावेश करते.
ऑपरेटरला काय फायदा होतो
प्रिंट करण्यासाठी, फोटो काढण्यासाठी किंवा फिरवण्यासाठी येथे कोणतीही सामुदायिक PSK नसते. फेडरेशन आणि ऑनबोर्डिंग मॉडेलवर अवलंबून, प्रवेश वैयक्तिक डिव्हाइस ओळख, SIM-समर्थित संबंध किंवा ईमेल-आधारित नावनोंदणीशी संबंधित केला जाऊ शकतो. हे सुरक्षा टीमला अधिक अचूक रिव्होकेशन पॉईंट प्रदान करते आणि एकाच क्रेडेंशियलमध्ये कोणताही बदल न करण्याचे प्रलोभन कमी करते कारण ते बदलल्याने प्रत्येक पाहुण्याची गैरसोय होईल.
पुन्हा पुन्हा येणाऱ्या पाहुण्यांची संख्या असलेल्या हॉटेल साखळीसाठी हा ऑपरेशनल गुंतवणूक करणे योग्य ठरू शकते, कारण परत येणाऱ्या पाहुण्यांना सहभागी असलेल्या सर्व प्रॉपर्टीजवर स्वयंचलित कनेक्टिव्हिटीचा फायदा मिळतो. यामुळे रिसेप्शन डेस्कला पासवर्ड स्पष्ट करण्याची आवश्यकता राहत नाही आणि हॉटेल साखळी सर्व ठिकाणी सुसंगत पॉलिसी लागू करू शकते.
कॉफी शॉपला संपूर्ण PKI प्रोग्रामची आवश्यकता नसू शकते. एक विश्वसनीय Google किंवा Apple हॉटस्पॉट फेडरेशन अशा पाहुण्यांसाठी सोपा रोमिंग अनुभव देऊ शकते ज्यांचे डिव्हाइस आणि अकाउंट्स याला सपोर्ट करतात, तर इतरांसाठी पारंपारिक गेस्ट पद्धत उपलब्ध राहते.
हे कुठे योग्य ठरत नाही
अनमॅनेज्ड BYOD वर सर्टिफिकेट लाइफसायकल हा सर्वात कठीण भाग आहे. डिव्हाइसेस बदलले जातात, प्रोफाइल जुने होतात, वापरकर्ते नावनोंदणी कशी कार्य करते हे विसरतात आणि सपोर्ट टीम्सना अयशस्वी सर्टिफिकेट आणि कव्हरेज किंवा DNS समस्येमधील फरक ओळखावा लागतो. डिव्हाइस प्रोफाइलिंग देखील महत्त्वाचे आहे, कारण सर्टिफिकेट हे केवळ नोंदणीकृत ओळख सिद्ध करते, डिव्हाइस निरोगी आहे किंवा प्रत्येक नेटवर्क भूमिकेसाठी योग्य आहेच असे नाही.
जेव्हा पुन्हा भेटी देणारे, नियमन केलेली माहिती किंवा पार्टनर रोमिंग यांमुळे उपयोजन आणि सपोर्टच्या खर्चाचे समर्थन होत असेल, तेव्हाच प्रमाणपत्र-आधारित प्रवेश वापरा. जर व्हिजिटर्सपैकी केवळ थोडाच हिस्सा याचा वापर करणार असेल आणि वेन्यूकडे आयडेंटिटी लाइफसायकल व्यवस्थापित करण्यासाठी कोणतीही टीम नसेल, तर कोणीही देखरेख न करणारी सिस्टीम तैनात करण्याऐवजी चांगल्या प्रकारे नियंत्रित पर्सनल किंवा व्हाउचर मॉडेलने सुरुवात करा.
मॉनिटरिंग, पॅचिंग आणि इन्सिडेंट रिस्पॉन्स
गेस्ट WiFi हे प्रत्यक्ष वापरादरम्यान सुरक्षित होते, कंट्रोलरमध्ये कोणीतरी 'Save' वर क्लिक केल्यावर लगेच नाही. टीमला ॲक्सेस पॉइंट्स, गेटवे, DHCP असाइनमेंट, ऑथेंटिकेशन वर्कफ्लो, DNS वर्तन आणि आउटबाउंड ट्रॅफिक या सर्व गोष्टींवर लक्ष ठेवण्याची आवश्यकता असते, जेणेकरून डिव्हाइस, सेशन आणि पॉलिसी निर्णयांना जोडण्यासाठी पुरेसा संदर्भ मिळेल.
शक्य असेल तिथे कंट्रोलर आणि फायरवॉल लॉग्स मध्यवर्ती स्टोअर किंवा SIEM कडे पाठवा. ऑथेंटिकेशन रेकॉर्ड्स सोबतच DHCP लीज रेकॉर्ड्स ठेवा, कारण एखाद्या घटनेच्या तपासासाठी बऱ्याचदा तात्पुरत्या पत्त्याचा संबंध डिव्हाइस आणि सेशनशी जोडणे आवश्यक असते. डेटा साठवून ठेवण्याचा कालावधी कोणत्याही अनियंत्रित डीफॉल्ट ऐवजी, वेन्यूच्या दस्तऐवजीकरण केलेल्या कायदेशीर, कराराच्या आणि उल्लंघन-प्रतिसाद आवश्यकतांशी जुळणारा असावा.
अशा वर्तनावर लक्ष ठेवा जे कॉन्फिगरेशन रोखू शकत नाही
वेन्यूच्या SSID चा वापर करणाऱ्या संशयास्पद ॲक्सेस पॉइंट्स, असामान्य DNS व्हॉल्यूम किंवा टनेलिंग पॅटर्न, वारंवार अपयशी ठरणारे Captive Portal, अनपेक्षित आउटबाउंड गंतव्यस्थाने आणि ऑनबोर्डिंग सेवेविरुद्ध संशयास्पद क्रेडेंशियल-स्टफिंग क्रियाकलापांवर लक्ष ठेवा. फिल्टरिंग आणि रेट नियंत्रणे गैरवापर कमी करू शकतात, परंतु ते या सिग्नलच्या पुनरावलोकनाची जागा घेऊ शकत नाहीत.
ॲक्सेस-पॉइंट फर्मवेअर आणि वायरलेस-कंट्रोलर पॅचेस अगदी गेस्ट SSID वर देखील महत्त्वाचे ठरतात. एक अतिथी नेटवर्क अंतर्गत सिस्टीमपासून वेगळे केले जाऊ शकते, परंतु तरीही ते वेगळेपण लागू करणारे उपकरण असुरक्षित राहू शकते. एखाद्या प्रातिनिधिक साइटवर अपडेट्स तपासा, रीबूट केल्यानंतर अतिथी धोरणाची खात्री करा आणि आवृत्ती व रोलबॅक पाथ नोंदवून ठेवा.
जेव्हा एखाद्या घटनेचा संशय येतो, तेव्हा कोणताही व्यत्यय आणणारा बदल करण्यापूर्वी पुरावे जतन करा.
- ओळखा: प्रभावित SSID, साईट्स, ॲक्सेस पॉइंट्स, कंट्रोलर, गेटवे, आयडेंटिटी सर्व्हिस आणि वेळेचा कालावधी निश्चित करा.
- नियंत्रित करा: आवश्यक असल्यास प्रभावित SSID निष्क्रिय करा, प्रमाणपत्रे किंवा व्हाउचर रद्द करा, दुर्भावनापूर्ण गंतव्यस्थाने ब्लॉक करा आणि तडजोड केलेली उपकरणे आयसोलेट करा.
- संवाद साधा: ठिकाणच्या कर्मचाऱ्यांना काय बदल झाले ते सांगा, फलक किंवा स्टेटस पेज अपडेट करा आणि ओळखण्यायोग्य अभ्यागत डेटा गोळा केला गेला असल्यास कायदेशीर किंवा गोपनीयता टीम्सना सामील करा.
- पुनरावलोकन करा: बिघाड रेडिओ, VLAN, फायरवॉल, पोर्टल, मॅनेजमेंट प्लेन किंवा डेटा स्टोअरमधून झाला आहे का ते निश्चित करा.
- सुधारणा करा: नियंत्रण दुरुस्त करा, अतिथी डिव्हाइसवरून त्याची चाचणी घ्या आणि रनबुक अपडेट करा.
अतिथी SSID ही जीवनचक्र असलेली एक सेवा आहे. कॉन्फिगरेशन हे केवळ पहिले प्रकाशन आहे.
तुमच्या ठिकाणासाठी एक व्यावहारिक हार्डनिंग चेकलिस्ट
गृहीतकांवर नव्हे, तर पुराव्यांच्या आधारे चेकलिस्ट पूर्ण करा. कंट्रोलर सेटिंगचा स्क्रीनशॉट हे सिद्ध करतो की सेटिंग अस्तित्वात आहे. वास्तविक गेस्ट डिव्हाइसवरून घेतलेली चाचणी हे सिद्ध करते की पॉलिसी वायरलेस, स्विचिंग, राउटिंग आणि फायरवॉल लेयर्सवर योग्यरित्या काम करत आहे.
नेटवर्क नियंत्रणे
- जिथे सपोर्ट असेल तिथे WPA3 निवडा. जेथे जुन्या क्लायंटना गरज असेल तिथेच AES सह WPA2 उपलब्ध ठेवा, आणि सामायिक मॉडेल आवश्यक असल्यास लांब, रँडमली तयार केलेला PSK वापरा.
- एक समर्पित गेस्ट VLAN तयार करा. त्याला स्वतःची DHCP श्रेणी द्या आणि कॉर्पोरेट, पेमेंट, IoT, आणि मॅनेजमेंट नेटवर्कचे सर्व मार्ग काढून टाका.
- क्लायंट आयसोलेशन सक्षम करा. एक गेस्ट डिव्हाइस दुसऱ्या गेस्ट डिव्हाइसला शोधू किंवा कनेक्ट करू शकत नाही याची खात्री करा.
- इग्रेस मर्यादित करा. आवश्यक आउटबाउंड वेब आणि DNS ट्रॅफिकला अनुमती देणारे आणि नको असलेले प्रोटोकॉल व डेस्टिनेशन्स ब्लॉक करणारे स्टेटफुल नियम लागू करा.
- DNS सुरक्षित करा. ठिकाणानुसार योग्य फिल्टरिंग वापरा आणि असामान्य क्वेरी वर्तनाबद्दल अलर्ट मिळवा.
- पोर्टल सुरक्षित करा. वैध प्रमाणपत्रासह HTTPS वर स्प्लॅश पेज आणि सर्व फॉर्म सबमिशन चालवा. केवळ घोषित उद्दिष्टाशी संबंधित असलेली माहिती गोळा करा.
ओळख आणि डेटा गव्हर्नन्स
- शक्य असेल तिथे सामायिक ऍक्सेस बदला. जेव्हा ठिकाणाला ट्रेसिबिलिटीची आवश्यकता असते तेव्हा व्हाउचर, प्रति-वापरकर्ता क्रेडेंशियल, RADIUS, किंवा क्लाउड ऑथेंटिकेशन वापरा.
- दस्तऐवजीकरण केलेल्या वेळापत्रकानुसार सामायिक PSK बदला. काही ठिकाणांसाठी त्रैमासिक बदल हे एक उपयुक्त ऑपरेशनल ध्येय आहे, परंतु यामुळे आधीच शेअर केलेली की बदलत नाही. शक्य तिथे, PSK ऐवजी वैयक्तिक ऍक्सेस द्या.
- व्हिजिटर रेकॉर्ड निश्चित करा. ठिकाणाला ईमेल पत्ता, फोन नंबर, डिव्हाइस आयडेंटिफायर आवश्यक आहे की केवळ अटींची स्वीकृती हवी आहे ते ठरवा.
- प्रशासकीय ऍक्सेस मर्यादित करा. प्लॅटफॉर्म प्रशासकांसाठी MFA आवश्यक करा आणि ऑपरेशनल रिपोर्टिंग परवानग्या बल्क डेटा एक्सपोर्टपासून वेगळ्या ठेवा.
- डेटा ठेवण्याचा नियम तयार करा. संपर्क आणि सेशन माहिती किती काळ ठेवली जाईल, कोण त्यात प्रवेश करू शकते आणि डेटा हटवण्याच्या विनंत्या कशा हाताळल्या जातात हे स्पष्ट करा.
डे-टू ऑपरेशन्स
- लॉग्स केंद्रित करा. कंट्रोलर, फायरवॉल, DHCP आणि ऑथेंटिकेशन इव्हेंट्स सुरक्षित स्टोअरमध्ये फॉरवर्ड करा.
- इन्फ्रास्ट्रक्चर पॅच करा. AP आणि कंट्रोलर फर्मवेअर व्हेंडरच्या सपोर्टेड मेंटेनन्स विंडोमध्ये ठेवा आणि अपडेट्सनंतर पॉलिसी अंमलबजावणीची चाचणी घ्या.
- शटडाउनची चाचणी घ्या. SSID कोण अक्षम करू शकते, सक्रिय ओळख कोण रद्द करू शकते, डेस्टिनेशन्स कोण ब्लॉक करू शकते आणि आउटेजची माहिती कोण देऊ शकते याचे दस्तऐवजीकरण करा.
- ऍक्सेस चाचणी चालवा. एका गेस्ट डिव्हाइसवरून, अंतर्गत सेवा, पीअर डिव्हाइसेस, राउटर मॅनेजमेंट इंटरफेस, DNS फिल्टरिंग आणि पोर्टल TLS ची चाचणी घ्या.
- बदलानंतर डिझाइनचे पुनरावलोकन करा. नवीन स्विचेस, पेमेंट सिस्टम, कॅमेरा, भाडेकरू आणि पोर्टल फील्ड्स यामुळे आधीचे गृहितक अमान्य ठरू शकते.
| स्थळ प्रकार | शिफारस केलेले प्रमाणीकरण | हे का योग्य आहे | तडजोड |
|---|---|---|---|
| कॅफे | नियंत्रित रोटेशनसह सामायिक PSK, किंवा योग्य असेल तिथे क्लिक-थ्रू | कमी-अडथळ्याचा प्रवेश लहान भेटींसाठी योग्य ठरतो | की (कीवर्ड) पसरू शकते आणि ओळख खात्री मर्यादित राहते |
| हॉटेल | खोल्यांसाठी व्हाउचर, पुन्हा येणाऱ्या अभ्यागतांसाठी Passpoint सह | वेळ-मर्यादित प्रवेश आणि पुन्हा येणाऱ्या पाहुण्यांना समर्थन देते | अधिक परिचालन समन्वय आणि डिव्हाइस समर्थनाची आवश्यकता असते |
| क्लिनिक | व्यवस्थापित वापरकर्त्यांसाठी डिव्हाइस प्रमाणपत्रांसह 802.1X, अभ्यागतांसाठी घट्टपणे वेगळा केलेला अतिथी प्रवेश | ओळख आणि संवेदनशील वातावरण वेगळे ठेवते | प्रमाणपत्र जीवनचक्र आणि समर्थनासाठी शिस्तीची आवश्यकता असते |
| शाळा | व्हाउचर किंवा व्यवस्थापित ओळख-आधारित प्रवेश | प्रवेश विद्यार्थी, कर्मचारी, अभ्यागत किंवा कार्यक्रमांचे अनुसरण करू शकतो | विविध वापरकर्ता गटांना स्वतंत्र धोरण आणि संरक्षणात्मक पुनरावलोकनाची आवश्यकता असते |
| कोवर्किंग स्पेस | प्रति-वापरकर्ता व्हाउचर किंवा 802.1X, बँडविड्थ नियंत्रणासह | सदस्यांना उत्तरदायित्व आणि अंदाज करण्यायोग्य सेवेची आवश्यकता असते | ऑनबोर्डिंग आणि ऑफबोर्डिंग ही निरंतर प्रशासकीय कार्ये बनतात |
गेस्ट WiFi सुरक्षित करण्याबद्दल वारंवार विचारले जाणारे प्रश्न
दरमहा सामायिक केलेला PSK बदलणे पुरेसे आहे का?
सहसा नाही. रोटेशनमुळे क्रेडेंशियलचे आयुष्य मर्यादित होते, परंतु ते आपल्याला हे सांगत नाही की कोणत्या अतिथीने त्याचा वापर केला आणि पुढील बदलापूर्वी स्क्रीनशॉट इतरत्र पसरण्यापासून ते रोखू शकत नाही. जर वेन्यूला जबाबदारी निश्चित करायची असेल, तर वारंवार पासवर्ड बदलण्यावर अवलंबून राहण्याऐवजी व्हाउचर, प्रति-वापरकर्ता क्रेडेंशियल्स किंवा प्रमाणपत्र-आधारित प्रवेशाकडे वळा.
बँडविड्थ मर्यादा गैरवापर रोखतात का?
ते वापराचे प्रमाण नियंत्रित करतात, हेतू नाही. प्रति-वापरकर्ता मर्यादा एखाद्या अतिथीला संपूर्ण कनेक्शन संपवण्यापासून रोखू शकते, तर QoS गेस्ट ट्रॅफिकपेक्षा बिझनेस-क्रिटिकल ट्रॅफिकला प्राधान्य देऊ शकते. यापैकी कोणतेही नियंत्रण फिशिंग, दुर्भावनायुक्त DNS ॲक्टिव्हिटी, क्रेडेंशियल चोरी किंवा अंतर्गत सिस्टम्सपर्यंत पोहोचण्याच्या प्रयत्नांना रोखत नाही.
जर एखाद्या गेस्टने बेकायदेशीर माहिती डाउनलोड केली, तर ते ठिकाण कायदेशीररित्या जबाबदार धरले जाते का?
याचे उत्तर तथ्ये, करार, लागू असलेले कायदे आणि वेन्यू ठेवत असलेल्या रेकॉर्डवर अवलंबून असते. एक समजूतदार ऑपरेटर दस्तऐवजीकरण केलेले स्वीकार्य-वापर धोरण ठेवतो, संबंधित ऑथेंटिकेशन आणि नेटवर्क लॉग सुरक्षित ठेवतो, जिथे समर्थनीय असेल तिथे गैरवापर करणाऱ्या ट्रॅफिकवर निर्बंध घालतो आणि कोणत्याही प्रकारच्या संरक्षणाचे आश्वासन देण्याऐवजी आपल्या कायदेशीर आणि गोपनीयता टीम्सकडून सल्ला घेतो.
संशयित सुरक्षा उल्लंघनानंतर पहिल्या ६० मिनिटांत काय केले पाहिजे?
काहीही पुसून टाकण्यापूर्वी किंवा रीबिल्ड करण्यापूर्वी AP, कंट्रोलर, फायरवॉल, RADIUS, captive portal आणि DHCP रेकॉर्ड्स जतन करा. प्रभावित साइट आणि वेळेची विंडो ओळखा, आवश्यकता असल्यास SSID प्रतिबंधित करा किंवा ओळखी रद्द करा, संबंधित लीज आणि ऑथेंटिकेशन ट्रेलचा स्नॅपशॉट घ्या आणि प्रत्येक कृतीची नोंद ठेवा. डॅशबोर्ड स्वच्छ दिसण्याच्या प्रयत्नात पुरावे नष्ट करू नका.
Captive Portal मुळे WiFi सुरक्षित होते का?
नाही. हे केवळ ॲक्सेस व्यवस्थापित करते आणि संमती किंवा आयडेंटिटी संकलनास समर्थन देऊ शकते, परंतु हे WPA2 किंवा WPA3 एन्क्रिप्शन, VLAN आयसोलेशन, क्लायंट आयसोलेशन, फायरवॉल पॉलिसी, पॅचिंग किंवा डेटा गव्हर्नन्सची जागा घेत नाही. पोर्टलला डिझाइनमधील एक घटक म्हणून समजा आणि त्यामागील अप्लायन्स आणि डेटाबेस सुरक्षित करा.
सामायिक पासवर्डपेक्षा अधिक आवश्यक असलेल्या वातावरणासाठी Purple हे captive portal ऑथेंटिकेशन, ओळख-आधारित प्रवेश, Passpoint आणि OpenRoaming सपोर्ट आणि VLAN-जागरूक अतिथी अलगाव आणि iPSK सारखी नेटवर्क नियंत्रणे प्रदान करते. Purple आपल्या ठिकाणाच्या अतिथी WiFi, ओळख आणि अभ्यागत-डेटा गव्हर्नन्स आवश्यकतांमध्ये कसे बसू शकते याचे पुनरावलोकन करा.
