VPN गेटवे पर Fail2ban: क्या सुधारता है और क्या नहीं

हर खुली सेवा को वही सलाह मिलती है: उस पर fail2ban लगाओ। VPN गेटवे के लिए यह सलाह न गलत है न पर्याप्त, और इसे हार्डनिंग की औपचारिकता मानना ही वह तरीका है जिससे लोग ऐसे jail के साथ रह जाते हैं जो कुछ उपयोगी ब्लॉक नहीं करता। Fail2ban उन विफलता रिकॉर्ड को पढ़ता है जिनकी ओर आप उसे इंगित करते हैं और प्रवर्तन बैकएंड से मिलते-जुलते स्रोतों को प्रतिबंधित करने के लिए कहता है। इसका पूरा मूल्य इस पर है कि किस प्रमाणीकरण सतह ने रिकॉर्ड बनाया, उसमें दिया पता असली क्लाइंट है या नहीं, और उस पते के पीछे बाकी सबके साथ क्या होता है।

यांत्रिक रूप से fail2ban क्या है

फ़िल्टर लॉग की पंक्तियों का मिलान करता है, jail प्रति स्रोत मिलान गिनता है, और क्रिया फ़ायरवॉल बैकएंड के ज़रिए प्रतिबंध लगाती है। तीन चलते भाग, और हर एक स्वतंत्र रूप से गलत हो सकता है।

इनमें से कोई भी प्रमाणीकरण पथ को नहीं छूता: fail2ban घटना के बाद साक्ष्य पर प्रतिक्रिया देता है और कभी स्वयं किसी क्रेडेंशियल को सत्यापित नहीं करता। इसलिए jail साफ़-सुथरा चल सकता है जबकि जिस सतह का वह नाम लेता है वह पहले जितनी ही खुली रहती है।

टनल श्रोता लॉगिन फ़ॉर्म नहीं है

OpenVPN श्रोता अगर tls-auth या tls-crypt से सुरक्षित है, तो सामान्य TLS प्रसंस्करण शुरू होने से पहले नियंत्रण-चैनल सुरक्षा रहित पैकेट गिरा देता है। जिस स्कैनर के पास कभी कुंजी नहीं होती, वह ऐसा कुछ नहीं बनाता जिसे आपका फ़िल्टर गिन सके। प्रमाणपत्र प्रमाणीकरण एक और द्वार जोड़ता है, क्योंकि अनुमान लगाने के लिए कोई पासवर्ड नहीं है। Fail2ban परियोजना सामान्य लॉग-चालित मॉडल का दस्तावेज़ीकरण करता है, और सामान्य VPN फ़िल्टर अपुष्ट पैकेट को अर्थपूर्ण विफलता घटना में नहीं बदलता।

अगर गेटवे केवल प्रमाणपत्र स्वीकार करता है, तो जिस ब्रूट-फ़ोर्स कहानी से आप बचाव कर रहे हैं वह उस पोर्ट पर शायद ही मौजूद हो।

तो आप किस सतह की रक्षा कर रहे हैं?

यही होस्ट अक्सर तीन अलग चीज़ें खोलता है: टनल श्रोता, क्लाइंट-प्रोफ़ाइल या स्व-सेवा पोर्टल, और प्रशासन पृष्ठ। पोर्टल और एडमिन पृष्ठ में पासवर्ड फ़ॉर्म होते हैं और वे ऐसी लॉग पंक्तियाँ बनाते हैं जिन्हें फ़िल्टर गिन सके। टनल शायद केवल हैंडशेक त्रुटियाँ बनाए जिनका अर्थ बिल्कुल अलग हो। jail को उत्पाद नाम से नहीं, सतह से मिलाएँ।

गलत लॉग देखने वाला एक jail किसी भी jail से बुरा है, क्योंकि वह कवरेज के बिना भरोसा बनाता है। लॉगिन फ़िल्टर को टनल की हैंडशेक त्रुटियों पर लगाएँ और काउंटर उन स्कैनरों पर बजेगा जिनके पास कभी कुंजी नहीं थी, जबकि पोर्टल पर पासवर्ड हमला गिना ही नहीं जाएगा। jail के आँकड़े पर भरोसा करने से पहले वह लॉग पंक्ति पढ़ें जिसे फ़िल्टर मिलाता है।

स्रोत का आरोपण कमज़ोर कड़ी है

प्रतिबंध उतना ही अच्छा है जितना उसका लक्ष्य पता। जब सेवा स्थानीय रिवर्स प्रॉक्सी के पीछे बैठी हो, लॉग में क्लाइंट पता प्रॉक्सी का हो सकता है, और उसे प्रतिबंधित करने से सब हट जाते हैं। अविश्वसनीय स्रोत से आए फ़ॉरवर्ड किए हेडर पर भरोसा करना हमलावर को मनमाने पते प्रतिबंधित करने की क्षमता देता है। UDP में स्रोत पते नकली बनाए जा सकते हैं, इसलिए उन्हें गिनना पूर्ण TCP लॉगिन गिनने से अधिक सावधानी माँगता है।

jail के README में स्रोत आरोपण की विधि दर्ज करें, क्योंकि अविश्वसनीय हॉप से आया फ़ॉरवर्ड किया हेडर प्रतिबंध को हथियार बना देता है।

पार्श्व लागत दूसरे लोग हैं

एक कार्यालय NAT के पीछे कई कर्मचारी एक पता साझा करते हैं, इसलिए एक पुराना सहेजा पासवर्ड सीमा पार होते ही पूरे कार्यालय को लॉक कर सकता है। लॉग एक स्रोत और एक खाता दिखाता है जो विफल हुए, पूरे कार्यालय का व्यवधान नहीं।

छोटे प्रतिबंध और संयमित सीमाएँ इसे कम करते हैं, और दस्तावेज़ीकृत अनबैन पथ तब भी होने पर सहायता भार घटाता है। पता एक मोटा संकेत, पहचान नहीं है, और टिकट खोलने वाला व्यक्ति सीमा नहीं, व्यवधान का वर्णन करेगा।

कब अपनाएँ, और कब कुछ और ठीक करें

इसे तब अपनाएँ जब आपके नियंत्रण वाली सतह पर वास्तविक, आरोपणीय, बार-बार होने वाली ऑनलाइन लॉगिन विफलता हो, और जब प्रवर्तन बैकएंड वास्तव में उस सतह को कवर करता हो। कुछ और ठीक करें जब समस्या कमज़ोर क्रेडेंशियल नीति, इंटरनेट पर खुला प्रशासन पृष्ठ, या ऐसा खाता हो जो समझौता किए जाने के कारण सफलतापूर्वक लॉगिन करता है। प्रतिबंध इनमें से कुछ भी ठीक नहीं कर सकता और उस ट्रैफ़िक को सोख नहीं सकता जो पहले ही आपके अपलिंक को संतृप्त कर चुका है। वह अंतिम समस्या ऊपर की ओर है, ऐसे किसी के पास जो पैकेट आप तक पहुँचने से पहले फ़िल्टर कर सके।

हर jail को एक सतह से बाँधे रखें, गलत सकारात्मक की समीक्षा करें, और प्रतिबंधित पतों की संख्या के बजाय बचाए गए प्रमाणीकरण कार्य को मापें।