VPN लगइन सूचनाहरू घुसपैठ सूचना होइनन्: सत्र हेर्नुहोस्
असामान्य साइन-इन समीक्षाको कारण हो, फैसला होइन। घुसपैठ भन्नुअघि प्रमाणीकरण रेकर्डलाई सत्रसँग, त्यसपछि सत्रले छोएको कुरासँग जोड्नुहोस्।
नयाँ देशमा बज्ने VPN सूचना निर्णायक देखिन्छ, र सामान्यतया हुँदैन। प्रमाणीकरण भन्छ कि एउटा प्रयास स्वीकारियो; सत्र भन्छ कुन जडानले त्यो बोक्यो; स्रोत रेकर्डहरू भन्छन् त्यो जडानभित्र के भयो। प्रत्येकले फरक प्रश्नको उत्तर दिन्छ। तीनैलाई मिलाउने नियमले सोमबार तीस टिकट बनाउँछ र शुक्रबार वास्तविक घटना छुटाउँछ।
विदेशी ठेगाना प्रश्न हो, उत्तर होइन
यात्रा, अर्को देशबाट बाहिरिने मोबाइल अपरेटरहरू, कर्पोरेट वेब प्रोक्सी र पुनःवितरण गरिएको carrier-grade NAT पूल — सबै आक्रमणकारीलाई नसारी देखिने स्रोत सार्छन्। साइन-इन रेकर्डले जडान नेटवर्कमा कहाँबाट प्रवेश गर्यो देखाउँछ, कसले उपकरण समातेको थियो भन्ने होइन।
उल्टो असफलता बढी नराम्रो छ किनकि त्यो शान्त छ। प्रयोगकर्ताकै शहरबाट प्रयोग गरिएको चोरिएको पासवर्डले भूगोल जाँचमा अघिल्ला सबै लगइनसँग मिल्ने लगइन बनाउँछ।
भूगोललाई फैसला मान्नको नाप्न सकिने लागत छ। यात्रा गर्ने ल्यापटपहरूले स्थिर समीक्षा प्रवाह बनाउँछन्, समीक्षकहरू नपढी बन्द गर्न सिक्छन्, र वास्तविक घटना त्यही लाइनमा नआएसम्म यो बानी टिक्छ।
तीन प्रकारका रेकर्डले तीन फरक प्रश्नको उत्तर दिन्छन्
तैनाथ उत्पादनहरूले वास्तवमै के निकाल्छन् त्यहाँबाट सुरु गर्नुहोस्, उत्पादन ब्रोसरले के निकाल्न सक्छन् भन्ने संकेतबाट होइन। प्रमाणीकरण निर्णयले दाबी गरिएको पहिचान, विधि र नतिजाको नाम दिन्छ। सत्र जीवनचक्रले जडान, गेटवे र तोकिएको ठेगानाको नाम सुरुदेखि रोकिएसम्म दिन्छ।
| Record | Question it answers | What it cannot prove |
|---|---|---|
| Authentication decision | Which identity was accepted or rejected, by which method, at what time | That the person operating the device was the account owner |
| Session lifecycle | Which connection, gateway and assigned address were active, and for how long | What the session did with that access |
| Resource event | Which read, write or denied operation a service observed | Which human behind the session triggered it |
| Policy change | Whether an administrator altered the rule that governs the access | Whether the change was reviewed or intended |
खाली कक्ष संकलनको खाडल हो, सफाइ होइन। स्रोत घटनाहरू कहिल्यै नआए सन्दिग्ध पढाइको अनुपस्थितिको अर्थ पाइपलाइनसँग रिपोर्ट गर्न केही छैन, र शान्त ड्यासबोर्डले नेटवर्क होइन, पाइपलाइन वर्णन गर्छ। तिनीहरूमा निर्भर नियमको वाचा गर्नुअघि तैनाथीले वास्तवमै कुन रेकर्ड बनाउँछ लेख्नुहोस्, र हरेक हराएको फिडको मालिकको नाम दिनुहोस्।
लेखा विवरण त्यो ठाउँ हो जहाँ सत्रहरू जाँचयोग्य बन्छन्। RFC 2866 मा वर्णन गरिएको RADIUS लेखाले सत्र पहिचानसँग जोडिएका सुरु, रोकिएका र बीचका अद्यावधिक बोक्छ, त्यसैले सुरु भएको तर रोकिएको नभएको सत्र रहस्य होइन, तपाईंले नाम दिन सक्ने खाडल हो।
प्रयोगकर्ता नाममा होइन, सत्रमा जोड्नुहोस्
एउटा खाताले कानुनी रूपमा एकैचोटि धेरै सत्र राख्छ: ल्यापटप, फोन, रातभर जोडिएको राखिएको प्रयोगशाला मेसिन। त्यो प्रयोगकर्ता नामका हरेक घटना जोड्दा तीन उपकरण एउटै कथामा पग्लिन्छन् र त्यसपछि संयोजनलाई सम्झौता भनेर पढिन्छ। तोकिएका ठेगानाहरू पनि पुनःप्रयोग हुन्छन्, त्यसैले सत्र सकिएपछि पनि ठेगानासँग मिल्ने जोडाइले गत महिनाको उपकरण आजको घटनामा तान्छ। ठेगानाको छेउमा सत्र कुञ्जी राख्नुहोस् र मिलानलाई सत्रले वास्तवमै ढाकेको समय खिड्कीमा सीमित गर्नुहोस्।
सेवाले देख्नुअघि अनुवादले मूल स्रोत हटाउने ठाउँमा, त्यो सीमामा टिक्ने पहिचान प्रयोग गर्नुहोस्, जस्तै पारस्परिक TLS विषय वा एकल साइन-अन दाबी। ठेगाना र व्यक्तिबीच एक-एक मिलान रचना गर्नु थप कदमसहित त्यही गल्ती हो।
मालिक नभएको सूचना ड्यासबोर्ड हो
हरेक नियमलाई सर्त, त्यो उत्पन्न गर्ने निर्दोष व्याख्या, संकलन गर्नुपर्ने प्रमाण र कार्य गर्ने व्यक्ति चाहिन्छ। बारम्बार अस्वीकृत प्रशासनिक कार्य, असफल पासवर्डको विस्फोट र शान्त संकलक तीन फरक घडी भएका तीन फरक घटना हुन्।
सूचना नियन्त्रण होइन, र वितरण सूचीले केही सीमित गर्दैन। जीवित सत्र बदल्न त्यो गर्न सक्ने घटक चाहिन्छ, जडान खसाल्ने गेटवे होस् वा सत्र रद्द गर्ने पहिचान प्रदायक होस्। पुराना फिड र हराएका रोकिएका रेकर्ड पनि नियमको पाठमा पर्छन्, किनकि एक दिन केही नपठाएको संकलक ड्यासबोर्डबाट ठ्याक्कै शान्त नेटवर्कजस्तै देखिन्छ। फरक पाइपलाइनमै मात्र देखिन्छ।
शान्त हप्तामा विश्वास गर्नुअघि संकलन मार्ग जाँच्नुहोस्
एउटा पनि नियम ट्युन गर्नुअघि पाइपलाइन सुरुदेखि अन्त्यसम्म प्रमाणित गर्नुहोस्। तलका आदेशहरूले प्रमाणीकरण र लेखा श्रोताहरू सक्रिय छन्, परीक्षण प्रमाणपत्र सही कारणले अस्वीकृत हुन्छ र सत्र घटनाहरू अझै आइरहेका छन् भनी पुष्टि गर्छन्:
ss -uanp | grep -E ':(1812|1813)\b' radtest alice 'not-the-password' 127.0.0.1 0 testing123 journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated' timedatectl | grep -E 'System clock|synchronized'
परीक्षणबाट आएको Access-Reject ले अनुरोध सर्भरसम्म पुग्यो र साझा गोप्य मिल्यो भनी प्रमाणित गर्छ, र मानिसहरूले छोड्ने भाग त्यही हो। बरु टाइमआउटले गोप्य, श्रोता वा त्यसको अगाडिको फिल्टरतर्फ संकेत गर्छ, र त्यो सुधार नभएसम्म तलको हरेक सूचना प्रमाणित गर्न सकिँदैन।
घडीको अवस्था महत्त्वपूर्ण छ किनकि सहसम्बन्ध खिड्कीहरूले सहमति मान्छन्। केही मिनेट बिचलित गेटवेले अन्यथा सफा सत्र जोडाइलाई असम्भव देखाउँछ, र समीक्षकहरूले जोडाइले भेद गर्न छोडेसम्म खिड्की फराकिलो बनाएर क्षतिपूर्ति गर्छन्। नियम सम्पादन गर्नुअघि विचलन जाँच्नुहोस्।
त्यसपछि एउटा नियमलाई निर्दोष परीक्षणमा चलाउनुहोस्: अप्रत्याशित ठेगानाबाट लगइन बनाउनुहोस्, सूचना बज्ने पुष्टि गर्नुहोस्, प्रतिक्रियाकर्ताले सत्र र त्यसका स्रोत घटनाहरू तान्न सक्ने पुष्टि गर्नुहोस्, र टिकटले सत्र पहिचान बोक्ने पुष्टि गर्नुहोस्। सुसंगत कथा बनाउने नियम उत्तीर्ण हुन्छ। लग लाइनको थुप्रो बनाउने नियम अझै ड्यासबोर्ड हो। नतिजा नियमको छेउमा लेख्नुहोस् ताकि अर्को समीक्षा अनुमानबाट होइन, प्रमाणबाट सुरु होस्।