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

जो VPN प्रमाणीकरण PAM को सौंपता है, उसके लिए गणना वह है जहाँ 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'

सफलता के व्यवहार को उतनी ही सावधानी से देखें जितनी विफलता के। यदि सफल लॉगिन इतिहास साफ़ नहीं करता, तो सामान्य गलतियों के धीमे संचय के बाद खाता लॉक हो जाएगा। यदि यह हर सेवा से सब कुछ साफ़ करता है, तो गणना नीति के दावे से कमज़ोर है।

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

संबंधित लेख