RADIUS Accounting: सेशन्स, वापर आणि ऑडिट लॉग्स ट्रॅक करणे

हे मार्गदर्शक RADIUS accounting वर एक व्यापक तांत्रिक संदर्भ प्रदान करते — ते WiFi सेशनचे start, stop आणि interim-update डेटा कसा रेकॉर्ड करते, कोणते ॲट्रिब्युट्स कॅप्चर केले जातात आणि सुरक्षा ऑडिटिंग, GDPR अनुपालन आणि क्षमता नियोजनासाठी त्या डेटाचा कसा फायदा घ्यावा. WiFi ऑथेंटिकेशन इव्हेंट्समधून मजबूत ऑडिट ट्रेल्सची आवश्यकता असलेल्या नेटवर्क ऑपरेशन्स आणि सुरक्षा टीम्ससाठी आणि SIEM प्लॅटफॉर्म आणि ॲनालिटिक्स डॅशबोर्डमध्ये सेशन डेटा समाकलित करू इच्छिणाऱ्या व्हेन्यू ऑपरेटर्ससाठी हे वाचन अत्यंत आवश्यक आहे.

📖 9 मिनिट वाचन📝 1,907 शब्द🔧 2 सोडवलेली उदाहरणे❓ 3 सराव प्रश्न📚 9 महत्वाच्या व्याख्या

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा

Purple Technical Briefing मध्ये आपले पुन्हा स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण एंटरप्राइझ WiFi इन्फ्रास्ट्रक्चरच्या एका महत्त्वपूर्ण, तरीही अनेकदा गैरसमज असलेल्या घटकाचा सखोल अभ्यास करणार आहोत: RADIUS Accounting. विशेषतः, आपण सेशन्स कसे ट्रॅक करतो, वापरावर लक्ष कसे ठेवतो आणि मजबूत ऑडिट लॉग्स कसे तयार करतो. जर तुम्ही IT मॅनेजर, नेटवर्क आर्किटेक्ट किंवा व्हेन्यू ऑपरेशन्स डायरेक्टर असाल, तर हे तुमच्यासाठी आहे. आपण शैक्षणिक सिद्धांतांना वगळून थेट व्यावहारिक अंमलबजावणीकडे वळणार आहोत.

चला मूलभूत गोष्टींपासून सुरुवात करूया. ज्या CTO ला ६० सेकंदांची संक्षिप्त माहिती हवी आहे त्यांच्यासाठी: RADIUS accounting म्हणजे काय आणि ते RADIUS ऑथेंटिकेशनपेक्षा कसे वेगळे आहे?

सोप्या शब्दांत सांगायचे तर, ऑथेंटिकेशन म्हणजे दारावरील बाउन्सर जो तुमची ओळख तपासते. Accounting म्हणजे बारटेंडर जो तुम्ही किती वेळ थांबता आणि किती वापर करता याचा मागोवा घेतो. ऑथेंटिकेशन UDP पोर्ट 1812 चा वापर करते आणि नेटवर्क ॲक्सेसचे कोण आणि कसे हाताळते. Accounting UDP पोर्ट 1813 चा वापर करते आणि काय, कधी आणि किती याची बारकाईने नोंद ठेवते. सेशन कधी सुरू होते, कधी संपते, किती बाईट्स ट्रान्सफर झाले आणि क्लायंट डिव्हाइसला कोणता IP ॲड्रेस असाइन केला गेला होता, याचा ते मागोवा घेते.

म्हणजे हा ऑडिट ट्रेल आहे. पण तो हा डेटा नेमका कसा कॅप्चर करतो? त्याची कार्यपद्धती काय आहे?

हे नेटवर्क ॲक्सेस सर्व्हर — सहसा तुमचा ॲक्सेस पॉईंट किंवा वायरलेस कंट्रोलर — कडून RADIUS सर्व्हरला पाठवल्या जाणाऱ्या तीन प्राथमिक पॅकेट प्रकारांवर अवलंबून असते. यांना Accounting-Request पॅकेट्स म्हणतात. प्रथम, तुमच्याकडे Start पॅकेट असते. युजर यशस्वीरित्या कनेक्ट होताच हे पाठवले जाते. हे accounting डेटाबेसमध्ये बेसलाइन रेकॉर्ड स्थापित करते, ज्यामध्ये युजरची ओळख, डिव्हाइसचा MAC ॲड्रेस, असाइन केलेला IP ॲड्रेस आणि युजर ज्या AP शी कनेक्ट झाला आहे तो AP कॅप्चर केला जातो. त्यानंतर, तुमच्याकडे Stop पॅकेट असते, जे युजर डिस्कनेक्ट झाल्यावर पाठवले जाते, ज्यामध्ये संपूर्ण सेशनची अंतिम एकत्रित आकडेवारी असते.

हे अगदी सोपे वाटते. Start आणि Stop. काम संपले.

तसे नाही. केवळ Start आणि Stop पॅकेट्सवर अवलंबून राहणे हा एक मोठा ऑपरेशनल धोका आहे. विचार करा: जर एखादा पाहुणा हॉटेलमध्ये कनेक्ट झाला आणि तीन दिवस कनेक्ट राहिला तर काय होईल? जर तुम्ही फक्त Start आणि Stop वर अवलंबून राहिलात, तर तुम्हाला त्या तीन दिवसांतील त्यांच्या वापराबद्दल कोणतीही माहिती मिळणार नाही. किंवा त्याहून वाईट म्हणजे, जर ॲक्सेस पॉईंटची पॉवर गेली तर काय होईल? ते कधीही Stop पॅकेट पाठवणार नाही आणि तुमच्या डेटाबेसमध्ये एक जुने सेशन शिल्लक राहील जे अनिश्चित काळासाठी सक्रिय असल्याचे दर्शवेल.

मग यावर उपाय काय आहे?

तिसरा पॅकेट प्रकार: Interim-Update. हे अत्यंत महत्त्वाचे आहे आणि RADIUS accounting डिप्लॉयमेंट्समध्ये हा सर्वात जास्त चुकीचा कॉन्फिगर केलेला घटक आहे. तुम्ही सक्रिय सेशन दरम्यान दर १५ मिनिटांनी अपडेट पाठवण्यासाठी वायरलेस कंट्रोलर कॉन्फिगर करता. हे हार्टबीट म्हणून काम करते आणि सध्याच्या वापराचा चालू स्नॅपशॉट प्रदान करते — ट्रान्सफर केलेले बाईट्स, सेशनचा कालावधी आणि पॅकेटची संख्या. जर RADIUS सर्व्हरला एखाद्या विशिष्ट सेशनकडून interim updates मिळणे बंद झाले, तर तुम्हाला समजते की सेशन संपले आहे, जरी तुम्हाला कधीही Stop पॅकेट मिळाले नसले तरीही. येथील ढोबळ नियम सोपा आहे: No Interim, No Insight.

आता आपण प्रत्यक्ष डेटाबद्दल बोलूया. या पॅकेट्समधील कोणते विशिष्ट ॲट्रिब्युट्स आपण पाहत आहोत जे ऑडिट लॉग्स आणि अनुपालन रिपोर्टिंगसाठी इतके मौल्यवान आहेत?

यात अनेक मुख्य घटक आहेत. Acct-Session-Id ही प्रायमरी की आहे जी Start, Interim-Update आणि Stop पॅकेट्सना एका सुसंगत सेशन रेकॉर्डमध्ये एकत्र बांधते. याशिवाय, तुम्ही या तीन पॅकेट प्रकारांचा परस्पर संबंध जोडू शकत नाही. त्यानंतर तुमच्याकडे Calling-Station-Id आहे, जो सामान्यतः क्लायंटचा MAC ॲड्रेस असतो — डिव्हाइसचा हार्डवेअर आयडेंटिफायर. Framed-IP-Address हा त्या सेशनसाठी क्लायंटला असाइन केलेला IP ॲड्रेस आहे. Acct-Input-Octets आणि Acct-Output-Octets क्लायंटकडून प्राप्त झालेल्या आणि पाठवलेल्या डेटाच्या प्रमाणाचा मागोवा घेतात. आणि Stop पॅकेट्समध्ये समाविष्ट असलेले Acct-Terminate-Cause तुम्हाला सेशन का संपले हे सांगते — मग युजरने स्वतः डिस्कनेक्ट केले असो, आयडल टाइमआउट झाला असो किंवा कनेक्शन गमावले (carrier lost) असो.

आपण वास्तविक जगात या ॲट्रिब्युट्सचा वापर कसा करू शकतो? चला GDPR अनुपालन किंवा कायदेशीर इंटरसेप्ट विनंतीचे उदाहरण घेऊया.

येथेच RADIUS accounting त्याची गुंतवणुकीवरील परतावा (ROI) सिद्ध करते. समजा कायदा अंमलबजावणी यंत्रणेने एका रिटेल चेनशी संपर्क साधला आणि सांगितले: तुमच्या गेस्ट WiFi वरील एका IP ॲड्रेसचा वापर गेल्या मंगळवारी दुपारी २ वाजता दुर्भावनापूर्ण (malicious) सामग्री ॲक्सेस करण्यासाठी केला गेला होता. कोण था? तुमच्याकडे फक्त फायरवॉल लॉग्स असल्यास, तुमच्याकडे फक्त एक IP ॲड्रेस असेल. परंतु DHCP मुळे IP ॲड्रेसेस सतत बदलतात. तुम्हाला तो IP एका विशिष्ट वेळी एका विशिष्ट डिव्हाइसशी जोडणे आवश्यक आहे. म्हणून, तुम्ही तुमच्या RADIUS accounting डेटाबेसची क्वेरी करता. तुम्ही असे सेशन शोधता जिथे Framed-IP-Address फायरवॉल लॉग मधील IP शी मॅच होतो आणि जिथे घटनेचा टाइमस्टॅम्प सेशनच्या Start वेळ आणि Stop वेळेच्या दरम्यान येतो. तो रेकॉर्ड तुम्हाला Calling-Station-Id — म्हणजेच डिव्हाइसचा MAC ॲड्रेस देईल. तुम्ही नुकतेच नेटवर्क लेयरला डिव्हाइस लेयरशी जोडले आहे. हा तुमचा संपूर्ण ऑडिट ट्रेल आहे.

चला दुसरे उदाहरण पाहूया: एक मोठे हॉटेल. हॉस्पिटॅलिटी क्षेत्र येथे विशेषतः संवेदनशील आहे. कॉन्फरन्स सुविधा असलेल्या ३०० खोल्यांच्या हॉटेलमध्ये एकाच वेळी हजारो WiFi सेशन्स असू शकतात. ऑपरेशन्स टीमला क्षमता नियोजनासाठी पीक वापराचे कालावधी समजून घेणे आवश्यक आहे, तर अनुपालन टीमला पाहुण्यांचा डेटा GDPR अंतर्गत योग्यरित्या हाताळला जात असल्याचे सिद्ध करणे आवश्यक आहे.

या वातावरणात, RADIUS accounting दोन्ही गोष्टी प्रदान करते. सेशन डेटा एका WiFi ॲनालिटिक्स प्लॅटफॉर्ममध्ये फीड केला जातो, जो कच्च्या बाईट्स आणि सेशनच्या कालावधीचे फूटफॉल मेट्रिक्स आणि बँडविड्थ वापराच्या ट्रेंड्समध्ये रूपांतर करतो. त्याच वेळी, हाच डेटा एका अनुपालन रिपोर्टिंग मॉड्यूलमध्ये फीड केला जातो जो ऑडिटर्सना नेमका कोणता डेटा गोळा केला गेला, तो किती काळ ठेवला गेला आणि तो कसा सुरक्षित केला गेला हे दाखवू शकतो.

म्हणून, हे सर्व घडवून आणण्यासाठी, आपल्याला हा डेटा RADIUS सर्व्हरमधून बाहेर काढून अशा सिस्टम्समध्ये नेणे आवश्यक आहे जिथे आपण त्यावर क्वेरी करू शकतो आणि कारवाई करू शकतो. टीम्सनी त्या पाइपलाइनचे आर्किटेक्चर कसे तयार केले पाहिजे?

पहिला नियम म्हणजे: RADIUS सर्व्हरवर लॉग्स फ्लॅट टेक्स्ट फाइल्समध्ये तसेच सोडू नका. स्ट्रक्चर्ड रिलेशनल डेटाबेसमध्ये — PostgreSQL किंवा MySQL हे सामान्य पर्याय आहेत — accounting डेटा लिहिण्यासाठी सर्व्हर कॉन्फिगर करा. तिथून, तुमच्याकडे दोन प्राथमिक मार्ग आहेत. प्रथम, Syslog किंवा REST API वापरून तुमच्या SIEM कडे — Splunk, Microsoft Sentinel किंवा IBM QRadar — लॉग्स फॉरवर्ड करा. हे तुमच्या सुरक्षा टीमला WiFi ऑथेंटिकेशन इव्हेंट्सचा फायरवॉल ब्लॉक्स, इंट्रुजन डिटेक्शन अलर्ट्स किंवा डेटा लॉस प्रिव्हेंशन ट्रिगर्सशी परस्पर संबंध जोडण्यास सक्षम करते. दुसरे, डेटा तुमच्या ॲनालिटिक्स प्लॅटफॉर्ममध्ये फीड करा. उदाहरणार्थ, Purple चे WiFi Analytics हा सेशन डेटा इनजेस्ट करू शकते आणि त्याचे फूटफॉल, ड्वेल टाइम आणि क्षमता वापराबद्दलच्या उपयुक्त माहितीमध्ये रूपांतर करू शकते.

आता सामान्य चुकांबद्दल बोलूया. डिप्लॉयमेंट्स कुठे चुकतात?

दोन मुख्य बिघाड प्रकार. प्रथम, आपण चर्चा केल्याप्रमाणे, Interim-Updates अजिबात सक्षम न करणे. हे आश्चर्यकारकरित्या सामान्य आहे. ॲडमिनिस्ट्रेटर्स ऑथेंटिकेशन योग्यरित्या कॉन्फिगर करतात परंतु accounting सेटिंग्जला कधीही स्पर्श करत नाहीत. दुसरे, आणि हे तितकेच नुकसानकारक आहे, ते म्हणजे Interim-Update अंतराल खूप आक्रमकपणे सेट करणे. तुमच्याकडे १०,००० एकाच वेळचे युजर्स असल्यास आणि तुम्ही अंतराल १ मिनिटावर सेट केल्यास, तुम्ही केवळ accounting अपडेट्ससाठी दर मिनिटाला १०,००० डेटाबेस राइट ऑपरेशन्स जनरेट करत आहात. यामुळे तुमच्या RADIUS सर्व्हरची I/O क्षमता खूप लवकर संपेल. बहुतेक एंटरप्राइझ डिप्लॉयमेंट्ससाठी योग्य वेळ १० ते १५ मिनिटे आहे. हे असह्य राइट लोड न तयार करता ऑपरेशनल दृश्यमानतेसाठी पुरेशी अचूकता प्रदान करते.

चला काही जलद प्रसंगांवरून नजर टाकूया.

प्रसंग एक: एक व्हेन्यू मॅनेजर रिपोर्ट करतो की ॲनालिटिक्स डॅशबोर्ड युजर्स ४८ तासांपासून कनेक्टेड असल्याचे दर्शवतो, परंतु व्हेन्यू रात्रीच बंद झाले होते.

ती जुन्या सेशनची (stale session) समस्या आहे. ॲक्सेस पॉईंट्स Stop पॅकेट्स पाठवत नाहीत — बहुधा पॉवर सायकल किंवा नेटवर्क व्यत्ययामुळे — आणि डेटाबेसमध्ये सेशन्स कधीही बंद केले जात नाहीत. यावरील उपाय म्हणजे RADIUS सर्व्हरवर डेड-सेशन क्लीन-अप स्क्रिप्ट लागू करणे. कॉन्फिगर केलेल्या अंतरालाच्या दोन ते तीन पट वेळेत ज्या सेशनला interim update मिळालेले नाही, ते स्वयंचलितपणे बंद केले जावे.

प्रसंग दोन: एका रिटेल चेनची सुरक्षा टीम सांगते की फायरवॉल लॉग्स फक्त IP ॲड्रेसेस दर्शवतात, ज्यामुळे कोणत्या विशिष्ट point-of-sale टर्मिनलने संशयास्पद बाह्य IP मध्ये प्रवेश केला याचे ऑडिट करणे अशक्य होते.

RADIUS accounting पॅकेट्समध्ये Framed-IP-Address ॲट्रिब्युट समाविष्ट करण्यासाठी ॲक्सेस पॉईंट्स कॉन्फिगर केले आहेत याची खात्री करा आणि IP ॲड्रेसचा MAC ॲड्रेसशी परस्पर संबंध जोडण्यासाठी तो RADIUS accounting डेटाबेस SIEM सह समाकलित करा.

प्रसंग तीन: पीक अवर्स दरम्यान RADIUS सर्व्हरवर उच्च CPU लोड येत आहे, ज्यामुळे ऑथेंटिकेशनमध्ये उशीर होत आहे.

प्रथम interim update अंतराल तपासा. जर ते मोठ्या मालमत्तेवर १ किंवा २ मिनिटांवर सेट केले असेल, तर ते १५ मिनिटांपर्यंत वाढवा. तसेच accounting डेटाबेसमध्ये Acct-Session-Id आणि User-Name कॉलम्सवर योग्य इंडेक्स असल्याची खात्री करा. अनइंडेक्स केलेले टेबल्स प्रत्येक राइटवर संपूर्ण टेबल स्कॅन करतील, जे मोठ्या प्रमाणावर अत्यंत घातक ठरेल. आणि तुमचे ऑथेंटिकेशन आणि accounting वर्कलोड्स समर्पित सर्व्हर इन्स्टन्सवर वेगळे करण्याचा विचार करा.

शेवटी, त्यांच्या RADIUS accounting इन्फ्रास्ट्रक्चरची अंमलबजावणी किंवा ऑडिट करणाऱ्या कोणत्याही IT मॅनेजर किंवा नेटवर्क आर्किटेक्टसाठी हे मुख्य मुद्दे आहेत.

पहिले: RADIUS accounting हे ऑथेंटिकेशनपेक्षा वेगळे आहे. ते सेशन डेटाचा मागोवा घेते, ॲक्सेसच्या निर्णयांचा नाही. दोन्ही आवश्यक आहेत, परंतु ते भिन्न ऑपरेशनल आणि अनुपालन उद्दिष्टे पूर्ण करतात.

दुसरे: नेहमी Interim-Updates सक्षम करा. त्यांच्याशिवाय, तुम्हाला सक्रिय सेशन्सची कोणतीही माहिती मिळत नाही आणि जुने रेकॉर्ड्स शोधण्यासाठी कोणतीही यंत्रणा नसते.

तिसरे: तुम्ही नेहमी कॅप्चर केले पाहिजेत असे तीन ॲट्रिब्युट्स म्हणजे Acct-Session-Id, Framed-IP-Address आणि Calling-Station-Id. हे तिन्ही कोणत्याही अर्थपूर्ण ऑडिट ट्रेलचा पाया तयार करतात.

चौथे: तुमचा accounting डेटा एक्सपोर्ट करा. तो फ्लॅट फाइल्समध्ये सोडू नका. स्ट्रक्चर्ड डेटाबेसमध्ये लिहा, SIEM कडे फॉरवर्ड करा आणि ॲनालिटिक्स प्लॅटफॉर्ममध्ये फीड करा.

पाचवे: मोठ्या प्रमाणासाठी डिझाइन करा. बहुतेक एंटरप्राइझ डिप्लॉयमेंट्ससाठी १५ मिनिटांचे interim update अंतराल हा योग्य समतोल आहे. तुमच्या विशिष्ट अनुपालन आवश्यकता आणि इन्फ्रास्ट्रक्चर क्षमतेच्या आधारे यामध्ये बदल करा.

मुख्य मुद्दा असा आहे: RADIUS accounting ही केवळ एक ऐच्छिक गोष्ट नाही. कोणत्याही नियंत्रित वातावरणात — हॉस्पिटॅलिटी, रिटेल, हेल्थकेअर, सार्वजनिक क्षेत्र — हा तुमच्या WiFi ऑडिट ट्रेलचा पाया आहे. ते योग्यरित्या करा, आणि तुमच्याकडे सुरक्षा, अनुपालन आणि ऑपरेशनल इंटेलिजन्ससाठी एक शक्तिशाली साधन असेल. ते चुकीचे केल्यास, तुमच्या ऑडिट ट्रेलमध्ये एक त्रुटी निर्माण होईल जी खूप महाग पडू शकते.

Purple Technical Briefing ऐकल्याबद्दल धन्यवाद. पुन्हा भेटूया.

महत्वाचे मुद्दे

✓RADIUS accounting (RFC 2866) हे ऑथेंटिकेशनपेक्षा वेगळे आहे: ते ॲक्सेस कंट्रोलचे निर्णय घेण्याऐवजी सेशन वापराचा डेटा — कालावधी, ट्रान्सफर केलेले बाईट्स, IP असाइनमेंट — रेकॉर्ड करते.
✓पूर्ण ऑडिट ट्रेलसाठी Start, Interim-Update आणि Stop — हे तिन्ही पॅकेट प्रकार कॉन्फिगर केलेले आणि कार्यरत असणे आवश्यक आहे. Interim-Updates हे सर्वात जास्त दुर्लक्षित केले जाणारे कॉन्फिगरेशन आहे.
✓Acct-Session-Id, Framed-IP-Address आणि Calling-Station-Id ॲट्रिब्युट्स किमान व्यवहार्य ऑडिट ट्रेल तयार करतात, जे अनुपालन आणि सुरक्षा तपासासाठी IP-ते-डिव्हाइस परस्पर संबंध सक्षम करतात.
✓जुन्या सेशन्सचे (गहाळ Stop पॅकेट्समुळे उद्भवणारे) व्यवस्थापन २.५ पट interim update अंतराल नियमाचा वापर करून डेड-सेशन क्लीनअप स्क्रिप्टद्वारे केले पाहिजे.
✓RADIUS accounting डेटाचे पूर्ण अनुपालन आणि ऑपरेशनल मूल्य मिळवण्यासाठी तो स्ट्रक्चर्ड डेटाबेसमध्ये एक्सपोर्ट केला पाहिजे आणि SIEM आणि ॲनालिटिक्स प्लॅटफॉर्मसह समाकलित केला पाहिजे.
✓PCI DSS, GDPR आणि कायदेशीर इंटरसेप्ट अनुपालनासाठी, विशिष्ट वेळी IP ॲड्रेसला MAC ॲड्रेसशी जोडण्याची क्षमता ही मुख्य आवश्यकता आहे जी RADIUS accounting पूर्ण करते.
✓मोठ्या प्रमाणावर (५,०००+ एकाच वेळचे युजर्स), ऑथेंटिकेशन आणि accounting सर्व्हर इन्स्टन्स वेगळे करा आणि कामगिरी खालावणे टाळण्यासाठी accounting राइट्ससाठी टाइम-सिरीज डेटाबेसचा विचार करा.

📚 आमच्या मुख्य मालिकेचा भाग: Enterprise WiFi Security Guide →

कार्यकारी सारांश

एंटरप्राइझ IT आणि नेटवर्क ऑपरेशन्स टीम्ससाठी, युजर्सना WiFi नेटवर्कवर ऑथेंटिकेट करणे ही केवळ अर्धी लढाई आहे. एकदा डिव्हाइस कनेक्ट झाले की, ते डिव्हाइस काय करते — ते किती वेळ कनेक्ट राहते, किती डेटा वापरते आणि कधी डिस्कनेक्ट होते — हे समजून घेणे सुरक्षा, क्षमता नियोजन (capacity planning) आणि नियामक अनुपालनासाठी (regulatory compliance) अत्यंत महत्त्वाचे आहे. येथेच RADIUS accounting अपरिहार्य ठरते. RADIUS ऑथेंटिकेशन नेटवर्क ॲक्सेसचे कोण आणि कसे हाताळत असताना, RADIUS accounting हे काय, कधी आणि किती याची बारकाईने नोंद ठेवते.

हे मार्गदर्शक RADIUS accounting चा तांत्रिक सखोल अभ्यास प्रदान करते, ज्यामध्ये Start, Stop आणि Interim-Update पॅकेट्सची कार्यपद्धती आणि त्यांना मौल्यवान बनवणाऱ्या ॲट्रिब्युट्सचा शोध घेतला आहे. हे दर्शवते की Hospitality , Retail आणि इतर क्षेत्रांमधील व्हेन्यू ऑपरेटर्स मजबूत ऑडिट ट्रेल्स राखण्यासाठी, GDPR अनुपालन सुनिश्चित करण्यासाठी आणि SIEM प्लॅटफॉर्म किंवा WiFi Analytics सिस्टममध्ये उपयुक्त माहिती फीड करण्यासाठी या डेटाचा कसा फायदा घेऊ शकतात. RADIUS accounting मध्ये प्रभुत्व मिळवून, नेटवर्क आर्किटेक्ट्स कच्च्या (raw) सेशन लॉग्सना धोरणात्मक मालमत्तेत रूपांतरित करू शकतात जे ऑपरेशनल कार्यक्षमता वाढवतात आणि जोखीम कमी करतात.

तांत्रिक सखोल अभ्यास

RADIUS Accounting विरुद्ध RADIUS Authentication

RFC 2865 मध्ये परिभाषित केलेले आणि accounting साठी RFC 2866 मध्ये विस्तारित केलेले RADIUS (Remote Authentication Dial-In User Service), क्लायंट-सर्व्हर मॉडेलवर कार्य करते. एका सामान्य एंटरप्राइझ WiFi डिप्लॉयमेंटमध्ये, ॲक्सेस पॉईंट (AP) किंवा वायरलेस LAN कंट्रोलर (WLC) हा Network Access Server (NAS) — म्हणजेच RADIUS क्लायंट म्हणून काम करतो. RADIUS सर्व्हर (उदा. FreeRADIUS, Cisco ISE, Aruba ClearPass) विनंत्या प्राप्त करतो आणि त्यावर प्रक्रिया करतो.

ऑथेंटिकेशन आणि accounting मधील फरक मूलभूत आहे:

घटक	RADIUS Authentication	RADIUS Accounting
उद्देश	ओळख सत्यापित करणे आणि प्रवेश देणे/नाकारणे	सेशनचा वापर आणि ॲक्टिव्हिटी रेकॉर्ड करणे
UDP पोर्ट	1812	1813
RFC संदर्भ	RFC 2865	RFC 2866
पॅकेटचे प्रकार	Access-Request, Access-Accept, Access-Reject	Accounting-Request (Start/Stop/Interim)
कॅप्चर केलेला डेटा	क्रेडेन्शियल्स, VLAN असाइनमेंट, पॉलिसी	सेशनची वेळ, ट्रान्सफर केलेले बाईट्स, IP ॲड्रेस
अनुपालन भूमिका	ॲक्सेस कंट्रोल	ऑडिट ट्रेल, कायदेशीर इंटरसेप्ट

मोठ्या प्रमाणावर Guest WiFi डिप्लॉय करणाऱ्या टीम्ससाठी, दोन्ही फंक्शन्स आवश्यक आहेत — परंतु accounting हे तुम्हाला अनुपालन आणि सुरक्षितता राखण्यास मदत करते.

तीन मुख्य Accounting पॅकेट प्रकार

RADIUS accounting हे तीन प्राथमिक Accounting-Request पॅकेट प्रकारांवर अवलंबून असते, जे प्रत्येक Acct-Status-Type ॲट्रिब्युटद्वारे परिभाषित केले जातात:

Start (Acct-Status-Type = 1): जेव्हा एखादा युजर यशस्वीरित्या कनेक्ट होतो आणि सेशन सुरू होते तेव्हा NAS द्वारे पाठवले जाते. हे accounting डेटाबेसमध्ये बेसलाइन रेकॉर्ड स्थापित करते, ज्यामध्ये युजरची ओळख, डिव्हाइसचा MAC ॲड्रेस, असाइन केलेला IP ॲड्रेस आणि युजर ज्या AP शी कनेक्ट झाला आहे तो AP कॅप्चर केला जातो.
Interim-Update (Acct-Status-Type = 3): सक्रिय सेशन दरम्यान ठराविक कालावधीने पाठवले जाते. हे पॅकेट्स सध्याच्या वापराचे चालू स्नॅपशॉट्स प्रदान करतात — ट्रान्सफर केलेले बाईट्स, सेशनचा कालावधी आणि पॅकेटची संख्या. सेशन अजूनही सुरू असल्याची पुष्टी करण्यासाठी ते हार्टबीट म्हणून काम करतात आणि डिस्कनेक्शनची वाट न पाहता दीर्घकाळ चालणाऱ्या सेशन्सची माहिती देतात.
Stop (Acct-Status-Type = 2): जेव्हा सेशन समाप्त होते तेव्हा पाठवले जाते — मग ते युजरने स्वतः डिस्कनेक्ट केल्यामुळे असो, AP रीबूट, आयडल टाइमआउट किंवा सेशन टाइमआउटमुळे असो. यामध्ये संपूर्ण सेशनची अंतिम, एकत्रित आकडेवारी असते.

आकृती १: WiFi सेशनमधील RADIUS accounting पॅकेटचे लाइफसायकल.

मुख्य Accounting ॲट्रिब्युट्स

सेशन्स प्रभावीपणे ट्रॅक करण्यासाठी आणि मजबूत ऑडिट लॉग्स तयार करण्यासाठी, NAS विशिष्ट ॲट्रिब्युट्ससह Accounting-Request पॅकेट्स भरते. खालील ॲट्रिब्युट्स ऑपरेशनल दृष्ट्या सर्वात महत्त्वाचे आहेत:

ॲट्रिब्युट	वर्णन	अनुपालन प्रासंगिकता
Acct-Session-Id	NAS द्वारे जनरेट केलेला युनिक सेशन आयडेंटिफायर	Start, Interim आणि Stop रेकॉर्ड्सचा परस्पर संबंध जोडण्यासाठी प्रायमरी की
User-Name	ऑथेंटिकेट केलेली ओळख (युझरनेम किंवा MAC ॲड्रेस)	सेशनला विशिष्ट युजर किंवा डिव्हाइसशी मॅप करते
NAS-IP-Address	रिपोर्टिंग AP किंवा WLC चा IP ॲड्रेस	नेटवर्क सेगमेंट आणि प्रत्यक्ष स्थान ओळखते
Framed-IP-Address	क्लायंट डिव्हाइसला असाइन केलेला IP ॲड्रेस	फायरवॉल आणि वेब प्रॉक्सी लॉग्सशी परस्पर संबंध जोडण्यासाठी अत्यंत महत्त्वाचे
Calling-Station-Id	क्लायंट डिव्हाइसचा MAC ॲड्रेस	ऑडिट ट्रेलसाठी डिव्हाइस-लेयर ओळख
Called-Station-Id	AP आणि SSID चा MAC ॲड्रेस	युजर ज्या विशिष्ट रेडिओ आणि नेटवर्कशी कनेक्ट झाला आहे ते ओळखते
Acct-Input-Octets	क्लायंटकडून प्राप्त झालेले बाईट्स	बँडविड्थ मॉनिटरिंग आणि क्षमता नियोजन
Acct-Output-Octets	क्लायंटला पाठवलेले बाईट्स	बँडविड्थ मॉनिटरिंग आणि क्षमता नियोजन
Acct-Session-Time	सेकंदांमध्ये सेशनचा कालावधी	ड्वेल टाइम (Dwell time) ॲनालिटिक्स आणि बिलिंग
Acct-Terminate-Cause	सेशन संपण्याचे कारण	ट्रबलशूटिंग आणि विसंगती शोधणे (anomaly detection)

802.1X Authentication सोबत काम करणाऱ्या टीम्ससाठी, User-Name ॲट्रिब्युटमध्ये EAP एक्सचेंजमधील ऑथेंटिकेट केलेली ओळख असेल, जी केवळ MAC Authentication Bypass (MAB) पेक्षा अधिक समृद्ध ऑडिट ट्रेल प्रदान करते.

अंमलबजावणी मार्गदर्शक

एक मजबूत RADIUS accounting इन्फ्रास्ट्रक्चर डिप्लॉय करण्यासाठी NAS आणि RADIUS सर्व्हर दोन्ही स्तरांवर काळजीपूर्वक कॉन्फिगरेशन आवश्यक आहे. विश्वासार्ह accounting पाइपलाइन स्थापित करण्यासाठी खालीलप्रमाणे एक वेंडर-न्यूट्रल दृष्टिकोन दिला आहे.

पायरी १: NAS कॉन्फिगर करा (ॲक्सेस पॉईंट्स / कंट्रोलर्स)

NAS कॉन्फिगरेशनमध्येच बहुतेक डिप्लॉयमेंट्स अयशस्वी होतात. ॲडमिनिस्ट्रेटर्स सहसा ऑथेंटिकेशन योग्यरित्या कॉन्फिगर करतात परंतु accounting डीफॉल्ट सेटिंग्जवर सोडतात किंवा पूर्णपणे अक्षम (disabled) करतात.

Accounting सर्व्हर परिभाषित करा: RADIUS सर्व्हरचा IP ॲड्रेस आणि UDP पोर्ट 1813 साठी सामायिक गुपिते (shared secret) निर्दिष्ट करा. हाय-अवेलेबिलिटी डिप्लॉयमेंट्समध्ये, प्रायमरी सर्व्हर अनरीचेबल झाल्यास डेटा गमावणे टाळण्यासाठी दुय्यम (secondary) accounting सर्व्हर कॉन्फिगर करा.
Interim Updates सक्षम करा: ही सर्वात महत्त्वाची कॉन्फिगरेशन पायरी आहे. एक योग्य अंतराल (interval) सेट करा — सामान्यतः एंटरप्राइझ डिप्लॉयमेंट्ससाठी १० ते १५ मिनिटे. लहान अंतराल (उदा. १ मिनिट) अधिक तपशीलवार डेटा प्रदान करतात परंतु मोठ्या प्रमाणावर असह्य राइट लोड (write load) निर्माण करतात; मोठे अंतराल (उदा. ३० मिनिटे) ओव्हरहेड कमी करतात परंतु सक्रिय सेशन्सच्या दृश्यमानतेमध्ये उशीर करतात.
वेळेचे सिंक्रोनाइझेशन सुनिश्चित करा: सर्व NAS डिव्हाइसेस आणि RADIUS सर्व्हरवर NTP कॉन्फिगर करा. ऑडिट लॉग्स आणि SIEM परस्पर संबंधांसाठी अचूक टाइमस्टॅम्प अत्यंत आवश्यक आहेत. कायदेशीर इंटरसेप्टच्या परिस्थितीत ५ मिनिटांचा वेळेतील फरक ऑडिट ट्रेल अवैध ठरवू शकतो.

पायरी २: RADIUS सर्व्हर कॉन्फिगर करा

डेटाबेस इंटिग्रेशन: फ्लॅट टेक्स्ट फाइल्सऐवजी स्ट्रक्चर्ड रिलेशनल डेटाबेसमध्ये (उदा. PostgreSQL, MySQL) accounting डेटा लॉग करण्यासाठी RADIUS सर्व्हर कॉन्फिगर करा. स्ट्रक्चर्ड स्टोरेज कार्यक्षम क्वेरी, इंडेक्सिंग आणि डाउनस्ट्रीम सिस्टम्ससह इंटिग्रेशन सक्षम करते. Acct-Session-Id, User-Name, Framed-IP-Address आणि सेशन सुरू होण्याच्या टाइमस्टॅम्पवर इंडेक्स अस्तित्वात असल्याची खात्री करा.
डेटा रिटेंशन पॉलिसी: तुमच्या अनुपालन आवश्यकतांशी सुसंगत स्वयंचलित आर्काइव्हल किंवा पर्ज स्क्रिप्ट्स लागू करा. GDPR कलम 5(1)(e) नुसार डेटा आवश्यकतेपेक्षा जास्त काळ न ठेवणे आवश्यक आहे; तथापि, अनेक अधिकारक्षेत्रांमधील कायदेशीर इंटरसेप्ट नियम (उदा. यूकेचा इन्व्हेस्टिगेटरी पॉवर्स ॲक्ट २०१६) १२ महिन्यांपर्यंत डेटा ठेवण्याची आवश्यकता दर्शवू शकतात.

पायरी ३: डेटा पाइपलाइन तयार करा

Accounting डेटाचे मूल्य जास्तीत जास्त वाढवण्यासाठी, तो अशा प्लॅटफॉर्मवर एक्सपोर्ट केला पाहिजे जिथे तो क्वेरी, परस्पर संबंधित आणि व्हिज्युअलाइझ केला जाऊ शकतो.

SIEM इंटिग्रेशन: Syslog किंवा REST API वापरून तुमच्या SIEM (उदा. Splunk, Microsoft Sentinel, IBM QRadar) कडे लॉग फॉरवर्ड करण्यासाठी RADIUS सर्व्हर किंवा मूळ डेटाबेस कॉन्फिगर करा. हे सुरक्षा टीम्सना WiFi ऑथेंटिकेशन इव्हेंट्सचा फायरवॉल ब्लॉक्स, इंट्रुजन डिटेक्शन अलर्ट्स किंवा डेटा लॉस प्रिव्हेंशन ट्रिगर्सशी परस्पर संबंध जोडण्यास सक्षम करते.
ॲनालिटिक्स इंटिग्रेशन: कच्च्या बाईट्स आणि MAC ॲड्रेसेसचे फूटफॉल, ड्वेल टाइम आणि पीक वापर कालावधी यासंबंधीच्या उपयुक्त माहितीमध्ये रूपांतर करण्यासाठी Purple च्या WiFi Analytics सारख्या प्लॅटफॉर्ममध्ये सेशन डेटा फीड करा. हे विशेषतः Retail आणि Hospitality ऑपरेटर्ससाठी मौल्यवान आहे ज्यांना प्रत्यक्ष वापर पद्धतींनुसार कर्मचारी आणि इन्फ्रास्ट्रक्चरमधील गुंतवणूक सुसंगत करावी लागते.

आकृती २: ॲक्सेस पॉईंट्सपासून SIEM आणि ॲनालिटिक्स प्लॅटफॉर्मपर्यंतची RADIUS accounting डेटा पाइपलाइन.

सर्वोत्तम पद्धती

नेहमी Interim Updates वापरा. केवळ Start आणि Stop पॅकेट्सवर अवलंबून राहिल्याने ऑपरेशनल त्रुटी निर्माण होतात. ड्रॉप झालेले कनेक्शन किंवा AP पॉवर फेल्युअरमुळे Stop पॅकेट पाठवण्यापासून रोखले जाऊ शकते, ज्यामुळे डेटाबेसमध्ये एक जुने (stale) सेशन अनिश्चित काळासाठी राहू शकते. Interim updates हे जुने सेशन्स शोधण्यासाठी आणि बंद करण्यासाठी यंत्रणा प्रदान करतात. ढोबळ नियम: जर एखाद्या सेशनने कॉन्फिगर केलेल्या अंतरालाच्या दोन ते तीन पट वेळेत interim update पाठवले नसेल, तर ते समाप्त झाले आहे असे समजा.

RADIUS Accounting चा DHCP लॉग्सशी परस्पर संबंध जोडा. RADIUS accounting हे Framed-IP-Address प्रदान करते, परंतु काही वातावरणात DHCP लीज वेळा सेशनच्या कालावधीपेक्षा कमी असू शकतात. RADIUS लॉग्ससह DHCP लॉग्स राखणे अधिक लवचिक ऑडिट ट्रेल प्रदान करते, विशेषतः उच्च-घनता (high-density) असलेल्या ठिकाणी जिथे IP ॲड्रेस रिसायकलिंग वारंवार होते.

RadSec सह ट्रान्सपोर्ट सुरक्षित करा. पारंपारिक RADIUS ट्रॅफिक कमीत कमी एन्क्रिप्शनसह UDP वर ट्रान्समिट केले जाते — केवळ युजर पासवर्ड FIELD अस्पष्ट (obfuscated) केले जाते. डिस्ट्रिब्युटेड डिप्लॉयमेंट्समध्ये, विशेषतः एकापेक्षा जास्त साइट्स किंवा क्लाउड-होस्ट केलेल्या RADIUS सर्व्हरवर पसरलेल्या डिप्लॉयमेंट्समध्ये, ट्रान्झिटमधील accounting डेटा सुरक्षित करण्यासाठी RadSec (RFC 6614 मध्ये परिभाषित केलेले RADIUS over TLS) किंवा IPsec टनेल्स वापरा. कार्डधारक डेटा हाताळणाऱ्या कोणत्याही नेटवर्कसाठी PCI DSS 4.0 अंतर्गत ही एक आवश्यकता आहे.

Accounting क्यू (Queue) मॉनिटर करा. जर RADIUS सर्व्हर अनरीचेबल झाला, तर NAS डिव्हाइसेस स्थानिक पातळीवर accounting पॅकेट्स क्यूमध्ये ठेवतील. या क्यूच्या लांबीवर लक्ष ठेवा; पूर्ण भरलेल्या क्यूमुळे पॅकेट्स ड्रॉप होतील आणि ऑडिट डेटा गमावला जाईल. क्यूच्या खोलीवर (depth) अलर्टिंग कॉन्फिगर करा आणि हाय-अवेलेबिलिटी डिप्लॉयमेंट्ससाठी दुय्यम accounting सर्व्हर लागू करा.

मोठ्या प्रमाणावर ऑथेंटिकेशन आणि Accounting सर्व्हर्स वेगळे करा. ५,००० पेक्षा जास्त एकाच वेळच्या (concurrent) युजर्सच्या डिप्लॉयमेंट्समध्ये, accounting मधील राइट लोड ऑथेंटिकेशन रिस्पॉन्स वेळेला धीमे करू शकतो. स्वतंत्र डेटाबेस इन्स्टन्ससह समर्पित accounting सर्व्हर्स ही समस्या टाळतात.

ट्रबलशूटिंग आणि जोखीम कमी करणे

जुन्या सेशनची (Stale Session) समस्या

लक्षण: RADIUS डेटाबेस दर्शवतो की एखादा युजर ४८ तासांपासून कनेक्टेड आहे, परंतु व्हेन्यू रात्रीच बंद झाले होते.

मूळ कारण: NAS द्वारे Stop पॅकेट पाठवण्यात अपयश आले — सामान्यतः पॉवर फेल्युअर, AP रीबूट किंवा नेटवर्क व्यत्ययामुळे — आणि हे पॅकेट RADIUS सर्व्हरला कधीही मिळाले नाही.

उपाय: RADIUS सर्व्हरवर डेड-सेशन क्लीन-अप स्क्रिप्ट लागू करा. या स्क्रिप्टने ठराविक कालावधीने अशा सक्रिय सेशन्स स्कॅन केल्या पाहिजेत जिथे शेवटचे प्राप्त झालेले पॅकेट (Start किंवा Interim-Update) परिभाषित थ्रेशोल्डपेक्षा (उदा. २.५ पट interim update अंतराल) जुने आहे. या थ्रेशोल्डपेक्षा जास्त काळ चालणारे सेशन्स कृत्रिम (synthetic) Stop रेकॉर्डसह सक्तीने बंद केले जावेत, ज्यामध्ये समाप्तीचे कारण 'Lost-Carrier' किंवा 'Admin-Reset' म्हणून नोंदवले जावे.

उच्च RADIUS सर्व्हर CPU आणि I/O लोड

लक्षण: पीक अवर्स दरम्यान ऑथेंटिकेशन रिस्पॉन्स वेळ कमी होतो; RADIUS सर्व्हर उच्च CPU आणि डिस्क I/O रिपोर्ट करतो.

मूळ कारण: हजारो APs वर अत्यंत आक्रमक interim update अंतराल (उदा. १ मिनिट) डेटाबेस राइट्सचे प्रचंड प्रमाण निर्माण करते जे हाताळणे अशक्य होते.

उपाय: interim update अंतराल १५ मिनिटांपर्यंत वाढवा. accounting डेटाबेसमध्ये योग्य इंडेक्स असल्याची खात्री करा. ऑथेंटिकेशन आणि accounting समर्पित सर्व्हर इन्स्टन्सवर वेगळे करण्याचा विचार करा. मोठ्या प्रमाणातील accounting डेटासाठी रिलेशनल डेटाबेसपेक्षा टाइम-सिरीज डेटाबेस (उदा. InfluxDB) अधिक योग्य आहे का याचे मूल्यांकन करा.

Accounting रेकॉर्ड्समध्ये Framed-IP-Address गहाळ असणे

लक्षण: RADIUS accounting रेकॉर्ड्स अस्तित्वात आहेत, परंतु Framed-IP-Address फील्ड रिकामे आहे किंवा अनुपस्थित आहे, ज्यामुळे IP-ते-MAC परस्पर संबंध जोडणे अशक्य होते.

मूळ कारण: DHCP ने क्लायंटला IP ॲड्रेस असाइन करण्यापूर्वीच NAS कदाचित Start पॅकेट पाठवत असेल. DHCP एक्सचेंज पूर्ण झाल्यानंतरच IP उपलब्ध होतो.

उपाय: जर प्लॅटफॉर्म त्याला सपोर्ट करत असेल, तर DHCP असाइनमेंट होईपर्यंत Start पॅकेट पाठवण्यास उशीर करण्यासाठी NAS कॉन्फिगर करा. पर्यायी म्हणून, Interim-Update पॅकेट्सवर अवलंबून रहा, जे DHCP असाइनमेंटनंतर पाठवले जातात आणि ज्यामध्ये Framed-IP-Address समाविष्ट असेल. जर Start रेकॉर्डमध्ये IP नसेल, तर Interim-Update रेकॉर्ड्स तपासून तुमच्या ऑडिट क्वेरीमध्ये याची नोंद घेतली जाईल याची खात्री करा.

ROI आणि व्यावसायिक प्रभाव

मजबूत RADIUS accounting लागू केल्याने तीन घटकांमध्ये मोजता येण्याजोगे व्यावसायिक मूल्य मिळते:

अनुपालन आणि कायदेशीर जोखीम कमी करणे. सुरक्षा घटना घडल्यास, GDPR अंतर्गत डेटा सब्जेक्ट ॲक्सेस विनंती किंवा कायदेशीर इंटरसेप्ट ऑर्डर आल्यास, अचूक accounting लॉग्स विशिष्ट वेळी कोणत्या युजर किंवा डिव्हाइसकडे विशिष्ट IP ॲड्रेस होता हे ओळखण्यासाठी आवश्यक ऑडिट ट्रेल प्रदान करतात. याशिवाय, संस्थांना GDPR अंतर्गत संभाव्य नियामक दंड (जागतिक वार्षिक उलाढालीच्या ४% पर्यंत) आणि प्रतिष्ठेचे नुकसान सहन करावे लागू शकते. योग्य accounting इन्फ्रास्ट्रक्चर लागू करण्याचा खर्च हा एका नियामक अंमलबजावणी कारवाईच्या खर्चाच्या अगदी लहान भाग आहे.

क्षमता नियोजन आणि इन्फ्रास्ट्रक्चर ROI. काळानुसार Acct-Input-Octets आणि Acct-Output-Octets च्या ट्रेंड्सचे विश्लेषण करून, नेटवर्क आर्किटेक्ट्स बँडविड्थ वापराचे पॅटर्न, पीक वापराचे कालावधी आणि सर्वाधिक लोड निर्माण करणारे विशिष्ट APs किंवा SSIDs ओळखू शकतात. हा डेटा थेट WAN अपग्रेड निर्णय आणि AP प्लेसमेंट धोरणांना माहिती देतो, ज्यामुळे इन्फ्रास्ट्रक्चरमधील गुंतवणूक योग्य ठिकाणी केली जाईल याची खात्री होते. Transport हब्स आणि मोठ्या व्हेन्यूजसाठी, यामुळे भांडवली खर्चात (capital expenditure) लक्षणीय बचत होऊ शकते.

वर्धित ॲनालिटिक्स आणि व्हेन्यू इंटेलिजन्स. जेव्हा RADIUS सेशन डेटा Purple च्या WiFi Analytics आणि Sensors सारख्या प्लॅटफॉर्मसह एकत्रित केला जातो, तेव्हा कच्च्या accounting डेटाचे व्हेन्यू इंटेलिजन्समध्ये रूपांतर होते. सेशनच्या कालावधीवरून मिळणारे ड्वेल टाइम मेट्रिक्स, Calling-Station-Id च्या इतिहासावरून वारंवार येणाऱ्या अभ्यागतांची ओळख आणि एकाच वेळच्या सेशनच्या संख्येवरून पीक ऑक्युपन्सी विश्लेषण हे सर्व उपलब्ध होते. Hospitality ऑपरेटर्ससाठी, हा डेटा थेट स्टाफिंग मॉडेल्स, F&B प्लेसमेंट आणि मार्केटिंग वैयक्तिकीकरण धोरणांना माहिती देतो. WiFi इन्फ्रास्ट्रक्चर या क्षमतांना कसे पूरक ठरते याच्या अधिक संदर्भासाठी, Wireless Access Points आणि Modern Hospitality WiFi Solutions वरील आमचे मार्गदर्शक पहा.

महत्वाच्या व्याख्या

RADIUS Accounting

युजरच्या नेटवर्क रिसोर्स वापराविषयी डेटा गोळा करण्याची आणि रेकॉर्ड करण्याची प्रक्रिया, ज्यामध्ये सेशन सुरू आणि संपण्याची वेळ, ट्रान्सफर केलेल्या डेटाचे प्रमाण आणि IP ॲड्रेस असाइनमेंट समाविष्ट आहे. RFC 2866 मध्ये परिभाषित.

कोणत्याही एंटरप्राइझ WiFi डिप्लॉयमेंटमध्ये बिलिंग, क्षमता नियोजन, GDPR अनुपालन आणि सुरक्षा ऑडिट ट्रेल्स राखण्यासाठी आवश्यक.

Acct-Status-Type

एक RADIUS ॲट्रिब्युट (ॲट्रिब्युट ID ४०) जे accounting पॅकेटचा उद्देश दर्शवते. मूल्यांमध्ये Start (१), Stop (२) आणि Interim-Update (३) समाविष्ट आहेत.

नवीन सेशन रेकॉर्ड तयार करायचे, अस्तित्वात असलेले अपडेट करायचे की बंद करायचे हे ठरवण्यासाठी RADIUS सर्व्हरद्वारे वापरले जाते. कोणत्याही accounting पॅकेटमधील सर्वात मूलभूत ॲट्रिब्युट.

Interim-Update

सध्याची वापर आकडेवारी रिपोर्ट करण्यासाठी सक्रिय सेशन दरम्यान NAS द्वारे पाठवले जाणारे ठराविक कालावधीचे RADIUS accounting पॅकेट, ज्यामध्ये ट्रान्सफर केलेले बाईट्स आणि सेशनचा कालावधी समाविष्ट असतो.

दीर्घकाळ चालणारे सेशन्स ट्रॅक करण्यासाठी आणि क्लायंटने Stop पॅकेट न पाठवता अनपेक्षितपणे डिस्कनेक्ट केल्यास जुने सेशन्स शोधण्यासाठी अत्यंत महत्त्वाचे.

Acct-Session-Id

विशिष्ट युजर कनेक्शन इन्स्टन्स ओळखण्यासाठी NAS द्वारे जनरेट केलेली युनिक स्ट्रिंग. हे मूल्य एकाच सेशनसाठी सर्व accounting पॅकेट्समध्ये (Start, Interim-Update, Stop) सुसंगत असते.

एकाच सेशनशी संबंधित सर्व accounting रेकॉर्ड्सचा परस्पर संबंध जोडण्यासाठी वापरली जाणारी प्रायमरी की. याशिवाय, संपूर्ण सेशनचा इतिहास पुनर्रचित करणे अशक्य आहे.

NAS (Network Access Server)

डिव्हाइस — सामान्यतः वायरलेस ॲक्सेस पॉईंट किंवा वायरलेस LAN कंट्रोलर — जे नेटवर्कवर प्रत्यक्ष प्रवेश नियंत्रित करते आणि RADIUS क्लायंट म्हणून काम करते, जे accounting पॅकेट्स जनरेट करते आणि पाठवते.

accounting डेटाच्या अचूकतेसाठी आणि पूर्णतेसाठी NAS जबाबदार आहे. NAS स्तरावरील चुकीचे कॉन्फिगरेशन (उदा. अक्षम केलेले accounting, गहाळ ॲट्रिब्युट्स) RADIUS सर्व्हर स्तरावर दुरुस्त केले जाऊ शकत नाही.

Framed-IP-Address

सेशनच्या कालावधीसाठी क्लायंट डिव्हाइसला असाइन केलेला IP ॲड्रेस, जो RADIUS accounting पॅकेट्समध्ये समाविष्ट असतो.

RADIUS accounting लॉग्सचा फायरवॉल, वेब प्रॉक्सी किंवा DNS लॉग्स सारख्या इतर नेटवर्क लॉग्सशी परस्पर संबंध जोडण्यासाठी अत्यंत महत्त्वाचे. या ॲट्रिब्युटच्या अनुपस्थितीमुळे IP-ते-डिव्हाइस परस्पर संबंध जोडणे अशक्य होते.

Calling-Station-Id

सामान्यतः नेटवर्कशी कनेक्ट होणाऱ्या क्लायंट डिव्हाइसचा MAC ॲड्रेस, जो कोलन-विभक्त हेक्साडेसिमल स्ट्रिंग म्हणून फॉरमॅट केलेला असतो (उदा. AA:BB:CC:DD:EE:FF).

असाइन केलेल्या IP ॲड्रेसचा विचार न करता, विशिष्ट हार्डवेअर डिव्हाइस ओळखण्यासाठी वापरले जाते. ऑडिट ट्रेलचा डिव्हाइस-लेयर अँकर.

Acct-Terminate-Cause

Stop पॅकेट्समध्ये समाविष्ट असलेले एक ॲट्रिब्युट जे सेशन संपण्याचे कारण निर्दिष्ट करते. सामान्य मूल्यांमध्ये User-Request, Lost-Carrier, Idle-Timeout, Session-Timeout आणि Admin-Reset समाविष्ट आहेत.

कनेक्टिव्हिटी समस्यांचे ट्रबलशूटिंग आणि विसंगती शोधण्यासाठी (anomaly detection) मौल्यवान — उदाहरणार्थ, विशिष्ट AP वर Lost-Carrier टर्मिनेशन्सचा उच्च दर हार्डवेअर किंवा इंटरफेरन्स समस्या दर्शवू शकतो.

RadSec

RFC 6614 मध्ये परिभाषित केलेले RADIUS over TLS (Transport Layer Security). पारंपारिक UDP-आधारित ट्रान्सपोर्टऐवजी RADIUS पॅकेट्ससाठी एन्क्रिप्टेड आणि ऑथेंटिकेट केलेले ट्रान्सपोर्ट प्रदान करते.

अशा कोणत्याही डिप्लॉयमेंटमध्ये आवश्यक जिथे RADIUS ट्रॅफिक असुरक्षित नेटवर्कवरून जाते (उदा. इंटरनेट-कनेक्टेड क्लाउड RADIUS सर्व्हर्स). कार्डधारक डेटा वातावरणासाठी PCI DSS 4.0 द्वारे वाढत्या प्रमाणात अनिवार्य केले जात आहे.

सोडवलेली उदाहरणे

कॉन्फरन्स सुविधा असलेले ३०० खोल्यांचे हॉटेल नवीन गेस्ट WiFi नेटवर्क डिप्लॉय करत आहे. IT मॅनेजरला हे सुनिश्चित करणे आवश्यक आहे की हे डिप्लॉयमेंट डेटा मिनिमायझेशन आणि ऑडिट ट्रेलच्या पूर्णतेसाठी GDPR आवश्यकता पूर्ण करते, तसेच मार्केटिंग टीमला ड्वेल टाइम आणि रिपीट व्हिजिटर ॲनालिटिक्स देखील प्रदान करते. हॉटेल क्लाउड-होस्ट केलेले RADIUS सर्व्हर आणि Cisco Meraki APs वापरते.

डिप्लॉयमेंट खालीलप्रमाणे कॉन्फिगर केले जावे. Meraki डॅशबोर्डवर, Network-wide > RADIUS servers वर जा आणि मजबूत सामायिक गुपितासह (shared secret) पोर्ट १८१३ वर क्लाउड RADIUS सर्व्हर जोडा. accounting सक्षम करा आणि interim update अंतराल १५ मिनिटांवर सेट करा. RADIUS सर्व्हरवर, खालील स्कीमासह PostgreSQL डेटाबेसमध्ये लिहिण्यासाठी accounting कॉन्फिगर करा: session_id (primary key), user_name, nas_ip, framed_ip, calling_station_id, called_station_id, session_start, session_end, input_octets, output_octets, terminate_cause. हॉटेलच्या GDPR रेकॉर्ड ऑफ प्रोसेसिंग ॲक्टिव्हिटीजमध्ये दस्तऐवजीकरण केल्यानुसार, १२ महिन्यांपेक्षा जुने रेकॉर्ड स्वयंचलितपणे कोल्ड स्टोरेजमध्ये संग्रहित करणारी आणि २४ महिन्यांपेक्षा जुने रेकॉर्ड काढून टाकणारी डेटा रिटेंशन पॉलिसी लागू करा. सेशन डेटा इनजेस्ट करण्यासाठी Purple WiFi Analytics इंटिग्रेशन कॉन्फिगर करा, ज्यामुळे मार्केटिंग टीमला ड्वेल टाइम रिपोर्ट्स आणि रिपीट व्हिजिटर फ्रिक्वेन्सी डॅशबोर्ड्स ॲक्सेस करता येतील. सर्व Meraki APs आणि RADIUS सर्व्हरवर NTP १ सेकंदाच्या आत सिंक्रोनाइझ केले असल्याची खात्री करा.

परीक्षकाचे भाष्य: हा प्रसंग RADIUS accounting चे दुहेरी उद्दिष्ट दर्शवतो: अनुपालन आणि ॲनालिटिक्स. १५ मिनिटांचे interim update अंतराल हॉटेलच्या वातावरणासाठी योग्य आहे जिथे सेशन्स अनेक दिवस चालू शकतात. PostgreSQL स्कीमा डिझाइन हे सुनिश्चित करते की अनावश्यक डेटा गोळा करणे टाळून सर्व GDPR-संबंधित फील्ड्स कॅप्चर केले जातील. १२/२४ महिन्यांची रिटेंशन पॉलिसी यूके इन्व्हेस्टिगेटरी पॉवर्स ॲक्टच्या आवश्यकता आणि GDPR डेटा मिनिमायझेशन तत्त्वांमध्ये समतोल राखते.

१५० स्टोअर्स असलेल्या रिटेल चेनला नेटवर्क ॲक्सेस मॉनिटरिंगसाठी PCI DSS 4.0 आवश्यकतांचे पालन करणे आवश्यक आहे. त्यांचे पॉइंट-ऑफ-सेल टर्मिनल्स WiFi नेटवर्कवर MAC Authentication Bypass (MAB) वापरतात. सुरक्षा टीमला त्यांच्या QSA (Qualified Security Assessor) कडून केवळ फायरवॉल लॉग मधील सोर्स IP ॲड्रेस आणि टाइमस्टॅम्प वापरून, कोणत्याही विशिष्ट वेळी कोणत्या विशिष्ट POS टर्मिनलने पेमेंट नेटवर्कमध्ये प्रवेश केला हे ते ओळखू शकतात हे दाखवण्याची विनंती प्राप्त झाली आहे.

या सोल्यूशनसाठी तीन-घटक इंटिग्रेशन आवश्यक आहे. प्रथम, सर्व वायरलेस LAN कंट्रोलर्स RADIUS accounting पॅकेट्समध्ये Framed-IP-Address ॲट्रिब्युट समाविष्ट करण्यासाठी कॉन्फिगर केले आहेत याची खात्री करा. हे नेहमी डीफॉल्टनुसार सक्षम नसते आणि स्पष्टपणे कॉन्फिगर केले जाणे आवश्यक आहे. दुसरे, SIEM प्लॅटफॉर्म (उदा. Splunk) सह RADIUS accounting डेटाबेस समाकलित करा. Splunk मध्ये एक लुकअप टेबल तयार करा जे Framed-IP-Address आणि सेशनच्या वेळेच्या श्रेणींना Calling-Station-Id (MAC ॲड्रेस) शी मॅप करते. तिसरे, एक Splunk सेव्हड सर्च तयार करा जे सोर्स IP आणि टाइमस्टॅम्प इनपुट म्हणून स्वीकारते आणि RADIUS accounting रेकॉर्ड्समधून संबंधित MAC ॲड्रेस, NAS-IP-Address (स्टोअर आणि AP ओळखणारे) आणि User-Name परत करते. त्यानंतर QSA ला हा वर्कफ्लो दाखवला जाऊ शकतो: विशिष्ट तारखेला १४:२३:०७ वाजता सोर्स IP १०.५.१२.४४ दर्शवणारी फायरवॉल लॉग एंट्री दिल्यास, सर्च POS टर्मिनलचा MAC ॲड्रेस, ते ज्या AP शी कनेक्ट होते तो AP आणि स्टोअरचे स्थान दर्शवते.

परीक्षकाचे भाष्य: हा प्रसंग नेटवर्क-लेयर ओळख (IP ॲड्रेस) आणि डिव्हाइस-लेयर ओळख (MAC ॲड्रेस) मधील अंतर कमी करण्यासाठी Framed-IP-Address ॲट्रिब्युटच्या महत्त्वपूर्ण भूमिकेवर प्रकाश करतो. या प्रकारच्या परस्पर संबंधासाठी SIEM लुकअप टेबल दृष्टिकोन ही उद्योग-मानक पद्धत आहे. लक्षात ठेवा की अत्यंत कमी DHCP लीज वेळ असलेल्या वातावरणात, परस्पर संबंधासाठी पॉईंट-इन-टाइम लुकअपऐवजी टाइम-रेंज क्वेरी वापरली पाहिजे, कारण एकाच IP कमी कालावधीत अनेक डिव्हाइसेसना असाइन केला गेला असू शकतो.

सराव प्रश्न

Q1. हॉटेलच्या IT मॅनेजरच्या लक्षात आले की लॉबी आणि रेस्टॉरंटमध्ये गर्दी असूनही WiFi ॲनालिटिक्स डॅशबोर्ड दिवसा खूप कमी सक्रिय युजर्स दर्शवतो. तथापि, मागील दिवसाचे ऐतिहासिक रिपोर्ट डेटा वापरामध्ये मोठी वाढ दर्शवतात. RADIUS सर्व्हर लॉग्स पुष्टी करतात की Start पॅकेट्स प्राप्त होत आहेत, परंतु डेटाबेसमध्ये खूप कमी Interim-Update रेकॉर्ड्स दिसत आहेत. सर्वात संभाव्य चुकीचे कॉन्फिगरेशन कोणते आहे आणि तुम्ही त्याचे निराकरण कसे कराल?

टीप: सक्रिय सेशन दरम्यान डेटा वापर कसा रिपोर्ट केला जातो विरुद्ध डिस्कनेक्शनच्या वेळी कसा रिपोर्ट केला जातो याचा विचार करा.

नमुना उत्तर पहा

सर्वात संभाव्य कारण म्हणजे वायरलेस LAN कंट्रोलरवर Interim-Updates अक्षम (disabled) आहेत किंवा कॉन्फिगर केलेले नाहीत. interim updates शिवाय, जेव्हा युजर कनेक्ट होतो तेव्हा RADIUS सर्व्हरला फक्त Start पॅकेट मिळते आणि जेव्हा ते डिस्कनेक्ट होतात तेव्हा Stop पॅकेट मिळते. ॲनालिटिक्स डॅशबोर्ड सध्याचा वापर प्रदर्शित करू शकत नाही कारण सेशनमधील कोणताही डेटा रिपोर्ट केला जात नाही. एकदा युजर्स निघून गेले आणि डिस्कनेक्ट झाले की, एकूण जमा झालेल्या डेटासह Stop पॅकेट्स येतात, ज्यामुळे ऐतिहासिक रिपोर्टमध्ये उशिराने वाढ दिसून येते. याचे निराकरण करण्यासाठी WLC वर Interim-Updates सक्षम करा आणि योग्य अंतराल सेट करा — हॉटेलच्या वातावरणासाठी १५ मिनिटे शिफारसीय आहे. सक्षम केल्यानंतर, Acct-Status-Type = 3 असलेले रेकॉर्ड्स तपासून RADIUS सर्व्हरला Interim-Update पॅकेट्स मिळत असल्याची खात्री करा.

Q2. सुरक्षा घटनेच्या तपासादरम्यान, तुमच्या SIEM ने फ्लॅग केले आहे की गेस्ट WiFi नेटवर्कवरील एका IP ॲड्रेसने विशिष्ट तारखेला ०९:४७:२३ वाजता एका ज्ञात कमांड-अँड-कंट्रोल सर्व्हरमध्ये प्रवेश केला. तुम्हाला यासाठी जबाबदार असलेले प्रत्यक्ष डिव्हाइस ओळखणे आवश्यक आहे. तुमची DHCP लीज वेळ ३० मिनिटांवर सेट आहे. डिव्हाइस ओळखण्यासाठी तुम्ही RADIUS accounting डेटाबेसवर वापरत असलेले अचूक क्वेरी लॉजिक स्पष्ट करा.

टीप: IP ॲड्रेसेस स्थिर नसतात. तुम्ही पॉईंट-इन-टाइम लुकअपऐवजी टाइम-रेंज क्वेरी वापरली पाहिजे आणि DHCP लीज रिसायकलिंगचा विचार केला पाहिजे.

नमुना उत्तर पहा

तुम्ही अशा सेशन्ससाठी RADIUS accounting डेटाबेस क्वेरी केली पाहिजे जिथे: (१) Framed-IP-Address फ्लॅग केलेल्या IP ॲड्रेसइतका असेल, आणि (२) session_start टाइमस्टॅम्प ०९:४७:२३ पूर्वीचा किंवा त्याइतका असेल, आणि (३) एकतर session_end टाइमस्टॅम्प ०९:४७:२३ नंतरचा किंवा त्याइतका असेल, किंवा session_end NULL असेल (क्वेरीच्या वेळी सेशन अजूनही सक्रिय आहे). जर एकापेक्षा जास्त सेशन्स मॅच होत असतील (३० मिनिटांच्या DHCP लीजसह शक्य आहे), तर ०९:४७:२३ वाजता कोणते सेशन सक्रियपणे वापर रिपोर्ट करत होते याची पुष्टी करण्यासाठी Interim-Update रेकॉर्ड्सचे पुनरावलोकन करा. मॅच होणाऱ्या सेशन रेकॉर्डमध्ये Calling-Station-Id (डिव्हाइसचा MAC ॲड्रेस) आणि User-Name (ऑथेंटिकेट केलेली ओळख, जर 802.1X वापरले गेले असेल) समाविष्ट असेल. प्रत्यक्ष डिव्हाइस आणि त्याचा मालक ओळखण्यासाठी तुमच्या डिव्हाइस इन्व्हेंटरी किंवा DHCP सर्व्हर लॉग्ससह MAC ॲड्रेसचा क्रॉस-रेफरन्स तपासा.

Q3. तुम्ही एका कॉन्फरन्स सेंटरचे नेटवर्क आर्किटेक्ट आहात जे ८,००० पर्यंत एकाच वेळच्या WiFi युजर्ससह इव्हेंट्स आयोजित करते. तुमच्या सध्याच्या RADIUS सर्व्हरला पीक इव्हेंट्स दरम्यान डेटाबेस राइट सॅच्युरेशनचा सामना करावा लागत आहे, ज्यामुळे ऑथेंटिकेशनमध्ये ३-५ सेकंदांचा उशीर होत आहे. तुमचे सध्याचे interim update अंतराल २ मिनिटांवर सेट आहे. तात्काळ कामगिरीची समस्या आणि मूळ आर्किटेक्चरल जोखीम या दोन्हीचे निराकरण करणारी बहु-पायरी निवारण योजना स्पष्ट करा.

टीप: कॉन्फिगरेशन बदल आणि आर्किटेक्चरल बदल या दोन्हीचा विचार करा. उद्दिष्ट राइट लोड कमी करताना ऑडिट ट्रेलची पूर्णता राखणे हे आहे.

नमुना उत्तर पहा

निवारण योजनेने तीन स्तरांवर काम केले पाहिजे. प्रथम, तात्काळ उपाय म्हणून, सर्व वायरलेस कंट्रोलर्सवर interim update अंतराल २ मिनिटांवरून १५ मिनिटांपर्यंत वाढवा. यामुळे accounting राइट लोड अंदाजे ८७% कमी होतो (प्रति सेशन दर २ मिनिटांनी एका राइटवरून दर १५ मिनिटांनी एक राइट), ज्यामुळे डेटाबेस I/O वरील ताण त्वरित कमी होईल. दुसरे, ऑथेंटिकेशन आणि accounting वर्कलोड्स समर्पित सर्व्हर इन्स्टन्सवर वेगळे करा. ऑथेंटिकेशन सर्व्हर Access-Request/Accept/Reject पॅकेट्स हाताळतो, तर समर्पित accounting सर्व्हर Accounting-Request पॅकेट्स हाताळतो आणि स्वतंत्र डेटाबेसमध्ये लिहितो. हे accounting राइट लोडमुळे ऑथेंटिकेशन रिस्पॉन्स वेळेवर परिणाम होण्यापासून रोखते. तिसरे, मूळ आर्किटेक्चरल जोखमीसाठी, accounting वर्कलोडसाठी रिलेशनल डेटाबेसपेक्षा टाइम-सिरीज डेटाबेस (उदा. InfluxDB किंवा TimescaleDB) अधिक योग्य आहे का याचे मूल्यांकन करा. टाइम-सिरीज डेटाबेस उच्च-प्रमाणातील सिक्वेन्शियल राइट्स आणि टाइम-रेंज क्वेरींसाठी ऑप्टिमाइझ केलेले असतात, जे अचूकपणे accounting डेटा पॅटर्नशी जुळतात. अनुपालन रिपोर्टिंग क्वेरींसाठी रिलेशनल डेटाबेस राखून ठेवत असताना, accounting राइट्स टाइम-सिरीज डेटाबेसमध्ये स्थलांतरित करा.

या मालिकेमध्ये पुढे वाचा

Guest आणि Staff WiFi नेटवर्क्ससाठी RADIUS Authentication कॉन्फिगर करणे

हे तांत्रिक संदर्भ मार्गदर्शक एंटरप्राइझ guest आणि staff WiFi नेटवर्क्ससाठी RADIUS authentication च्या आर्किटेक्चर, कॉन्फिगरेशन आणि डिप्लॉयमेंटची रूपरेषा स्पष्ट करते. हे नेटवर्क आर्किटेक्ट्स आणि IT मॅनेजर्सना सुरक्षित, स्केलेबल वायरलेस ॲक्सेस कंट्रोल सिस्टम्स तयार करण्यासाठी आवश्यक असलेले अचूक प्रोटोकॉल्स, सुरक्षा मानके आणि ट्रबलशूटिंग पद्धती प्रदान करते.

Passpoint आणि OpenRoaming: संपूर्ण मार्गदर्शक

हे तांत्रिक संदर्भ मार्गदर्शक एंटरप्राइझ WiFi नेटवर्कमधील Passpoint (Hotspot 2.0) आणि WBA OpenRoaming फ्रेमवर्कचे सर्वसमावेशक विश्लेषण प्रदान करते. हे सुरक्षित, विनाव्यत्यय अतिथी कनेक्टिव्हिटी स्थापित करण्यासाठी आवश्यक असणारे मूलभूत ऑथेंटिकेशन प्रोटोकॉल, आर्किटेक्चरल घटक आणि डिप्लॉयमेंट धोरणांचे सविस्तर वर्णन करते. नेटवर्क आर्किटेक्ट्स आणि IT लीडर्स एंटरप्राइझ-दर्जाची सुरक्षा राखून मॅन्युअल लॉगिनचे अडथळे दूर करण्यासाठी या मानकांची रचना, अंमलबजावणी आणि ट्रबलशूटिंग कसे करावे हे शिकतील.

WPA2 Personal विरुद्ध Enterprise: फरक काय आहे आणि तुम्ही कोणते वापरावे?

हे तांत्रिक संदर्भ मार्गदर्शक WPA2 Personal आणि WPA2 Enterprise वायरलेस सुरक्षा मानकांमधील अधिकृत तुलना प्रदान करते. हे IT प्रमुखांना त्यांचे एंटरप्राइझ नेटवर्क सुरक्षित करण्यासाठी आवश्यक असणारे अंतर्गत क्रिप्टोग्राफिक हँडशेक, आर्किटेक्चरल आवश्यकता आणि उपयोजन पद्धती सविस्तरपणे स्पष्ट करते. अनुपालन फ्रेमवर्कचे पालन करण्यासाठी आणि अंतर्गत धोके कमी करण्यासाठी सामायिक पासफ्रेजेसकडून वैयक्तिकृत, प्रमाणपत्र - आधारित प्रमाणीकरणाकडे कसे जावे हे वाचक शिकतील.