VPN गेटवेमा Fail2ban: के सुधार्छ र के सुधार्दैन

हरेक खुला सेवाले एउटै सल्लाह पाउँछ: त्यसमा fail2ban राख्नुहोस्। VPN गेटवेका लागि त्यो सल्लाह न गलत हो न पर्याप्त, र यसलाई हार्डनिङको टिकका रूपमा लिनु नै मानिसहरू केही उपयोगी कुरा नरोक्ने jail सँग बस्ने कारण हो। Fail2ban तपाईंले देखाउनुभएको असफलता रेकर्ड पढ्छ र मिल्ने स्रोतहरू प्रतिबन्ध गर्न कार्यान्वयन backend लाई भन्छ। यसको सम्पूर्ण मूल्य कुन प्रमाणीकरण सतहले रेकर्ड बनायो, त्यसमा भएको ठेगाना साँचो ग्राहक हो कि होइन, र त्यो ठेगाना पछाडिका सबैलाई के हुन्छ भन्नेमा निर्भर छ।

यान्त्रिक रूपमा fail2ban के हो

फिल्टरले लगका लाइनहरू मिलाउँछ, jail ले स्रोतअनुसार मिलान गन्छ, र कार्यले फायरवाल backend मार्फत प्रतिबन्ध लागू गर्छ। तीन चल्ने भाग, र हरेक स्वतन्त्र रूपमा गलत हुन सक्छ।

ती तीनमध्ये कुनैले पनि प्रमाणीकरण मार्ग छुँदैन: fail2ban घटना पछि प्रमाणमा प्रतिक्रिया दिन्छ र कहिल्यै आफैं प्रमाणपत्र प्रमाणित गर्दैन। त्यसैले jail सफा रूपमा चल्न सक्छ, जबकि यसले नाम दिने सतह पहिलेजस्तै खुला रहन्छ।

टनेल श्रोता लगइन फारम होइन

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

यदि गेटवेले प्रमाणपत्र मात्र स्वीकार गर्छ भने, तपाईं जसबाट बचाउ गर्दै हुनुहुन्छ त्यो ब्रुट-फोर्स कथा त्यो पोर्टमा पटक्कै नहुन सक्छ।

त्यसो भए तपाईं कुन सतहको रक्षा गर्दै हुनुहुन्छ?

एउटै होस्टले प्रायः तीन फरक कुरा खोल्छ: टनेल श्रोता, ग्राहक-प्रोफाइल वा स्वयं-सेवा पोर्टल, र प्रशासन पृष्ठ। पोर्टल र प्रशासन पृष्ठमा पासवर्ड फारम हुन्छन् र फिल्टरले गन्न सक्ने लग लाइन उत्पादन गर्छन्। टनेलले पूर्ण रूपमा अर्कै अर्थ लाग्ने ह्यान्डशेक त्रुटि मात्र उत्पादन गर्न सक्छ। jail लाई उत्पादनको नामसँग होइन, सतहसँग मिलाउनुहोस्।

गलत लग हेर्ने एउटा jail कुनै jail नभएभन्दा नराम्रो हुन्छ, किनकि यसले कभरेज बिना आत्मविश्वास सिर्जना गर्छ। लगइन फिल्टरलाई टनेलको ह्यान्डशेक त्रुटितर्फ फर्काउनुहोस् र काउन्टर कहिल्यै कुञ्जी नभएका स्क्यानरमा बज्छ, जबकि पोर्टलमाथिको पासवर्ड आक्रमण गनिँदैन। jail को संख्यामा विश्वास गर्नुअघि फिल्टरले मिलाउने लग लाइन पढ्नुहोस्।

स्रोत श्रेय कमजोर कडी हो

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

jail को README मा स्रोत श्रेय विधि लेख्नुहोस्, किनकि अविश्वसनीय हपबाट आएको फर्वार्ड हेडरले प्रतिबन्धलाई हतियार बनाउँछ।

पार्श्व लागत अरू मानिस हुन्

एउटा कार्यालय NAT पछाडि धेरै कर्मचारीले एउटै ठेगाना साझा गर्छन्, त्यसैले एउटा पुरानो सुरक्षित पासवर्डले सीमा नाघ्नेबित्तिकै सम्पूर्ण कार्यालय लक गर्न सक्छ। लगले असफल भएको एउटा स्रोत र एउटा खाता देखाउँछ, सम्पूर्ण कार्यालयको अवरोध होइन।

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

कहिले अपनाउने, र कहिले अरू केही सुधार्ने

तपाईंले नियन्त्रण गर्ने सतहमा वास्तविक, श्रेय दिन सकिने, दोहोरिने अनलाइन लगइन असफलता हुँदा र कार्यान्वयन backend ले त्यो सतह साँच्चै ढाक्दा यसलाई अपनाउनुहोस्। समस्या कमजोर प्रमाणपत्र नीति, इन्टरनेटमा खुला प्रशासन पृष्ठ, वा सम्झौता भएकै कारण सफलतापूर्वक लगइन हुने खाता भए अरू केही सुधार्नुहोस्। प्रतिबन्धले तीमध्ये केही पनि सुधार्न सक्दैन र तपाईंको अपलिंक पहिले नै संतृप्त गरिसकेको ट्राफिक सोस्न सक्दैन। त्यो अन्तिम समस्या माथि, प्याकेट तपाईंसम्म पुग्नुअघि फिल्टर गर्न सक्ने कसैको हो।

हरेक jail लाई एउटा सतहसँग बाँधेर राख्नुहोस्, गलत सकारात्मकको समीक्षा गर्नुहोस्, र प्रतिबन्धित ठेगानाको संख्याको सट्टा बचाइएको प्रमाणीकरण कार्य माप्नुहोस्।