खाते लॉकआउट विरुद्ध पत्ता बंदी: OpenVPN प्रत्यक्षात कुठे मोजते

पत्ता ब्लॉक करणे आणि खाते लॉक करणे या दोन वेगवेगळ्या काउंटर यंत्रणा आहेत, आणि त्या विरुद्ध दिशांनी अपयशी ठरतात. पत्ता बंदी एक स्रोत थांबवते आणि लक्ष्यित खाते इतर कुठूनही पोहोचण्यायोग्य ठेवते. खाते लॉक ती ओळख सर्वत्र थांबवते, त्या वैध वापरकर्त्याच्या स्वतःच्या लॅपटॉपवरूनही. संघ अनेकदा एक तैनात करून दुसऱ्याचे वर्णन करतात, आणि घटनेच्या वेळी फरक शोधतात जेव्हा चुकीची गोष्ट संरक्षित झालेली असते.

PAM कडे प्रमाणीकरण सोपवणाऱ्या VPN साठी काउंटर तोच असतो जो PAM स्टॅक गाठतो, लिसनरने नोंदवलेला नाही. हे दोन वेगळे करणे ही पहिली उपयुक्त पायरी आहे.

दोन काउंटर, दोन वेगळे बळी

रेट लिमिटर स्रोताकडे पाहते आणि विचारते की त्यातून अलीकडे किती प्रयत्न आले. लॉकआउट ओळखीकडे पाहते आणि विचारते की त्या खात्याने किती अपयशे जमा केली. पहिले सेवेची उपलब्धता वाचवते; दुसरे क्रेडेन्शियल वाचवते. एक दुसऱ्याची जागा घेत नाही, आणि फक्त पहिले असलेल्या तैनातीने खाते अजिबात संरक्षित केलेले नाही.

म्हणूनच “पाच अपयशांनंतर आम्ही IP ब्लॉक करतो” हे क्रेडेन्शियल-स्टफिंग अहवालाचे उत्तर नाही. हल्लेखोर स्रोत बदलतो, प्रत्येकाला थोडे प्रयत्न मिळतात, आणि खाते कधीच मोजले जात नाही. उलट, कोणत्याही स्रोत नियंत्रणाशिवाय लॉकआउट धोरण हल्लेखोराला हेतुपुरस्सर अपयश देऊन खाते अनिश्चित काळ लॉक ठेवू देतो, जे त्यांना काहीच खर्च न करणारी सेवा-नकार आहे.

या दोन्ही नियंत्रणांच्या पुनर्प्राप्तीच्या कथा वेगळ्या आहेत. पत्ता बंदी अशा टाइमरवर संपते ज्याचा कोणी विचार करायची गरज नाही. खाते लॉकसाठी प्रशासक, नोंदवलेला प्रतीक्षा कालावधी किंवा स्वयं-सेवा रीसेट लागू शकते, आणि त्यातील प्रत्येक हा धोरणाचा निर्णय आहे जो पहिल्या लॉकआउटपूर्वी अस्तित्वात असणे आवश्यक आहे.

आधीच मोजणी ठेवणारे साठवण शोधा

काहीही जोडण्यापूर्वी, अपयशाचे साठवण आधीच अस्तित्वात आहे का ते शोधा. स्थानिक Linux खाते, डिरेक्टरी सेवा आणि बाह्य ओळख प्रदाता प्रत्येकजण स्वतःची नोंद ठेवतो, आणि त्यांच्यासमोर जोडलेले PAM मॉड्यूल पहिल्याचा विस्तार करण्याऐवजी दुसरी नोंद तयार करते.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

VPN प्रत्यक्षात ज्या सेवा फाइलचे नाव देते ती वाचा, आणि तिच्या include ओळींचा मागोवा घ्या. अनेक वितरणांमध्ये VPN सेवा सामायिक common फाइल समाविष्ट करते, याचा अर्थ तुम्ही जी नोंद सुरळीत करणार आहात ती SSH आणि स्थानिक लॉगिनांनाही लागू होते. ते स्वीकार्य असू शकते, आणि ते बदलाच्या उद्देशाच्या अगदी उलट असू शकते.

डिरेक्टरी आधीच लॉकआउट लागू करत असेल, तर उपयुक्त प्रश्न हा आहे की PAM संवाद त्या निर्णयापर्यंत कसा पोहोचतो आणि VPN तो कसा नोंदवते. वर स्थानिक मोजणी जोडल्याने ती डिरेक्टरीचा काउंटर होत नाही, आणि दोन धोरणे खाते कधी उघडेल याबाबत वेगळी मत देऊ शकतात.

pam_faillock ला एक नाही, तीन कॉल स्थाने आहेत

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

जुना टॅली मॉड्यूलवरून स्थलांतर सहसा जिथे चूक करते तो भाग हाच आहे. कार्यरत pam_tally2 उदाहरणातील ओळ pam_faillock स्टॅकमध्ये कॉपी करणे म्हणजे नुसते नाव बदलणे नाही; नोंदवलेली रचना वेगळी आहे, आणि चुकीच्या ठिकाणचा कॉल असा स्टॅक तयार करू शकतो जो अपयशे नोंदवतो पण कधीच तपासत नाही, किंवा प्रमाणीकरणाचा मार्ग कधीच न पोहोचणाऱ्या टप्प्यावर ती तपासतो.

faillock --user alice
faillock --user alice --reset

काउंटर खरा आहे का हे पाहण्याचा सर्वात जलद मार्ग म्हणजे तपासणी साधन: ते खात्यासाठी नोंदवलेली अपयशे दाखवते आणि ती पुसू शकते. नियंत्रित अपयशाने तो निर्गम बदलत नसेल, तर रचना कशी वाचली जाते याचा प्रश्न न राहता कॉल स्थान चुकीचे आहे.

समर्पित सेवा नाव म्हणजे अलगाव नाही

VPN ला स्वतःची PAM सेवा फाइल दिल्याने इच्छित धोरण दिसते, आणि त्यामुळे परिणाम स्वतःच मर्यादित होत नाही. सामायिक फाइलचा कोणताही include ती फाइल जे करते ते आत ओढतो, यासह संपूर्ण प्रणालीवर लागू होणाऱ्या नोंदी.

लॉकआउट फक्त VPN प्रवेशावर असावा की त्याच खात्याचे प्रमाणीकरण करणाऱ्या प्रत्येक सेवेवर, हे स्पष्टपणे ठरवा. दोन्ही उत्तरे समर्थनीय आहेत; अयशस्वी पद्धत म्हणजे तुम्ही एक निवडले असे वाटणे आणि स्टॅक दुसरेच अमलात आणणे. उत्तर सेवा फाइलच्या शेजारी लिहून ठेवा जेणेकरून पुढचा बदल ते गुपचूप उलटणार नाही.

मग किंमत विचारात घ्या. लॉकआउट हल्लेखोरामुळेही घडू शकतो, आणि त्रास तोच भोगतो ज्याचे ते खाते आहे. उंबरठा, प्रतीक्षा कालावधी आणि प्रशासकीय पुनर्प्राप्ती मार्ग हे सर्व धोरणाचा भाग आहेत, आणि पुनर्प्राप्ती मार्ग घटनेच्या वेळी VPN पुन्हा संरचित होण्यावर अवलंबून नसावा.

एकच नाकारणे नाही, क्रम स्वीकारा

मंजूर आराखड्यानुसार नियुक्त ओळखींसह चाचणी करा, आणि एका घटनेऐवजी साखळीची चाचणी करा. वैध खात्याने प्रमाणीकरण होणे आवश्यक आहे; हेतुपुरस्सर चुकीच्या पासवर्डने काउंटर हलले पाहिजे; त्यानंतर संरचित लॉक अमलात यायला हवा; आणि नोंदवलेल्या पुनर्प्राप्तीने प्रवेश परत मिळायला हवा.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

यशाचे वर्तन अपयशाच्या वर्तनाइतकेच काळजीपूर्वक तपासा. यशस्वी लॉगिनने इतिहास पुसत नसेल, तर सामान्य चुकांच्या संचयानंतर खाते लॉक होईल. ते प्रत्येक सेवेतील सर्व काही पुसत असेल, तर काउंटर धोरण दावा करते त्यापेक्षा कमकुवत आहे.

शेवटी, विजय जाहीर करण्यापूर्वी लक्ष न देता चालणारे क्लायंट थांबवा. पार्श्वभूमीत पुन्हा प्रयत्न करणारे साठवलेले क्रेडेन्शियल पुनर्प्राप्तीच्या काही मिनिटांतच अपयशे पुन्हा निर्माण करेल आणि खाते पुन्हा लॉक करेल, जे चुकीच्या संरचनेच्या क्लायंटऐवजी तुटलेला पुनर्प्राप्ती मार्ग वाटेल. स्रोत-आधारित रेट लिमिटिंग अतिरिक्त नियंत्रण म्हणून कायम राहू शकते, पण ते खाते धोरण नाही आणि तसे वर्णन करू नये.