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 सिद्ध करते की विनंती सर्व्हरपर्यंत पोहोचली आणि सामायिक रहस्य जुळले, आणि लोक हाच भाग वगळतात। त्याऐवजी टाइमआउट रहस्य, श्रोता किंवा त्याच्यासमोरच्या फिल्टरकडे निर्देश करतो, आणि ते दुरुस्त होईपर्यंत खालील प्रत्येक सूचना पडताळता येत नाही।
घड्याळाची स्थिती महत्त्वाची आहे कारण सहसंबंध खिडक्या सहमती गृहीत धरतात। काही मिनिटे भरकटलेला गेटवे अन्यथा स्वच्छ सत्र-जुळणी अशक्य दाखवतो, आणि पुनरावलोकक जुळणी भेद करणे थांबेपर्यंत खिडकी रुंदावून भरपाई करतात। नियम संपादित करण्यापूर्वी विचलन तपासा।
नंतर एक नियम निरुपद्रवी चाचणीत चालवा: अनपेक्षित पत्त्यावरून लॉगिन तयार करा, सूचना उमटते याची खात्री करा, प्रतिसादकर्ता सत्र आणि त्याच्या संसाधन घटना ओढू शकतो याची खात्री करा, आणि तिकिट सत्र ओळख वाहते याची खात्री करा। सुसंगत कथा तयार करणारा नियम उत्तीर्ण होतो। लॉग ओळींचा ढीग तयार करणारा नियम अजूनही डॅशबोर्ड आहे। पुढील पुनरावलोकन अंदाजाने नाही, पुराव्याने सुरू व्हावे म्हणून निकाल नियमाजवळ नोंदवा।