खाता लक बनाम ठेगाना प्रतिबन्ध: 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 ले वास्तवमा नाम दिने सेवा फाइल पढ्नुहोस् र त्यसका समावेश हरफ पछ्याउनुहोस्। धेरै वितरणमा VPN सेवाले साझा फाइल समावेश गर्छ, जसको अर्थ तपाईंले मिलाउनुभएको गणना SSH र स्थानीय लगइनमा पनि लागू हुन्छ।

यदि निर्देशिकाले पहिल्यै लक लागू गर्छ भने उपयोगी प्रश्न यो हो कि PAM संवाद त्यो निर्णयसम्म कसरी पुग्छ र VPN ले त्यसको रिपोर्ट कसरी गर्छ। माथि थपिएको स्थानीय गणना निर्देशिकाको काउन्टर बन्दैन, र दुई नीति खाता कहिले खुल्नेमा सहमत नहुन सक्छन्।

pam_faillock मा एक होइन, तीन कल स्थान छन्

मोड्युलले तीन क्रियाकलाप अलग गर्छ जसलाई एक प्रतिलिपि हरफले सामान्यतः धमिलो बनाउँछ: खाता पहिल्यै लक छ कि जाँच, असफलता अभिलेख र सफलता पछि इतिहास मेट्ने।

पुरानो गणना मोड्युलबाट स्थानान्तरण सामान्यतः यहीँ गल्ती गर्छ। काम गर्ने pam_tally2 उदाहरणबाट हरफ pam_faillock स्ट्याकमा प्रतिलिपि गर्नु नाम परिवर्तन होइन; लिखित सेटअप फरक छ, र गलत ठाउँमा राखिएको कलले असफलताहरू कहिल्यै नजाँची अभिलेख गर्न सक्छ।

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

निरीक्षण उपकरण गणना वास्तविक छ कि देख्ने सबैभन्दा छिटो बाटो हो: यसले खाताका अभिलेखित असफलताहरू देखाउँछ र ती मेट्न सक्छ। यदि नियन्त्रित असफलताले त्यो आउटपुट बदल्दैन भने कलको स्थान गलत छ।

समर्पित सेवा नाम अलगाव होइन

VPN लाई आफ्नै PAM सेवा फाइल दिनुले इच्छित नीति देखिने बनाउँछ, तर प्रभाव सीमित गर्दैन। साझा फाइलको कुनै पनि समावेशले त्यो फाइलले गर्ने सबै ल्याउँछ, सम्पूर्ण प्रणालीका गणनासमेत।

लकले VPN पहुँच मात्र समेट्छ वा एउटै खाता प्रमाणित गर्ने हरेक सेवा समेट्छ भनी स्पष्ट निर्णय गर्नुहोस्। दुवै उत्तर तर्कसंगत छन्; असफलता भनेको एउटा छानें भन्ने विश्वास गर्नु हो जब स्ट्याकले अर्को कार्यान्वयन गर्छ।

त्यसपछि लागत विचार गर्नुहोस्। आक्रमणकारीले लक निम्त्याउन सक्छ, र दुःख पाउने प्रयोगकर्ता त्यो खाताको मालिक हो। सीमा, प्रतीक्षा अवधि र प्रशासनिक पुनःप्राप्ति मार्ग नीतिको भाग हुन्, र घटना हुँदा VPN पुनः कन्फिगरमा पुनःप्राप्ति निर्भर हुनु हुँदैन।

क्रम स्वीकार्नुहोस्, एक अस्वीकृति होइन

स्वीकृत योजना अन्तर्गत तोकिएका पहिचानसँग परीक्षण गर्नुहोस्, र एक घटना नभई शृंखला परीक्षण गर्नुहोस्: वैध खाता प्रमाणित हुन्छ, जानाजान गलत पासवर्डले गणना सार्छ, कन्फिगर गरिएको लक लागू हुन्छ, र लिखित पुनःप्राप्तिले पहुँच फर्काउँछ।

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

सफलताको व्यवहार असफलताको जत्तिकै ध्यान दिएर हेर्नुहोस्। सफल लगइनले इतिहास मेट्दैन भने सामान्य गल्तीको ढिलो संचयपछि खाता लक हुन्छ। हरेक सेवाबाट सबै मेट्छ भने गणना नीतिले भनेभन्दा कमजोर छ।

अन्तमा विजय घोषणा गर्नु अघि निगरानी नभएका क्लाइन्ट रोक्नुहोस्। सुरक्षित प्रमाणले पृष्ठभूमिमा पुनः प्रयास गरी पुनःप्राप्तिको केही मिनेटमै असफलता फेरि सिर्जना गरी खाता फेरि लक गर्छ। स्रोत-आधारित दर सीमा थप नियन्त्रणका रूपमा रहन सक्छ, तर त्यो खाता नीति होइन।