Grav-plugin-admin: प्रवेश पृष्ठ पाशविक बल के हमले की चपेट में है

मैं केवल एक त्रुटि संदेश का उपयोग कुछ इस तरह बताते हुए करूंगा: Incorrect username or password. वे परिवर्तन (भूल गए पासवर्ड स्ट्रिंग परिवर्तन शामिल) किसी भी रूप में उपयोगकर्ता नामों का अनुमान लगाना असंभव बना देंगे।

मैं आईपी द्वारा पहुंच को सीमित नहीं करूंगा, लेकिन कैप्चा को एक विकल्प के रूप में जोड़ना एक बुरा विचार नहीं है।

मुझे वास्तव में कैप्चा विकल्प पसंद नहीं है, लेकिन अगर इसे जोड़ा जाना चाहिए, तो क्या कम से कम हम इसे कुछ असफल प्रयासों (जैसे 3, या कुछ) के बाद ही सक्रिय कर सकते हैं?

लॉग-इन प्रयासों के बीच देरी - अधिमानतः बढ़ रही है, शायद घातीय रूप से, प्रत्येक प्रयास के साथ एक निश्चित सीमा तक - ब्रूट-फोर्स हमलों को प्रभावी ढंग से अवरुद्ध करता है। देरी और सीमा को पैरामीटर के रूप में सेट किया जा सकता है।

पासवर्ड भूल गए कार्यक्षमता को लॉगिन प्लगइन के बीटा संस्करण में संशोधित किया गया है। यह अब केवल ईमेल पते लेता है।

साथ ही, https://github.com/getgrav/grav-plugin-login/commit/3e7c20fd66639123cfb2894d9298d4ccfb861af9 में उसी संदेश को प्रिंट करने के लिए संपादित किया गया है।

असफल प्रयासों को लॉग करना भी असफल 2ban आदि के लिए अच्छा होगा :)

एक निश्चित समय अवधि में गलत लॉगिन प्रयासों की संख्या को सीमित करने के तरीके के बारे में क्या?

लॉग इन प्लगइन में अब इसे नियंत्रित करने के लिए इसके कॉन्फ़िगरेशन में एक सुरक्षा अनुभाग है: https://github.com/getgrav/grav-plugin-login/commit/590f188189c8453afb5992e7ec385795336ee711

कैप्चा के लिए विकल्प भी रखना अभी भी अच्छा होगा। इसके अलावा, बाढ़ सुरक्षा बिल्कुल भी काम नहीं करती है।
सुरक्षा सुविधाओं के सक्षम होने पर भी Grav आपको और पासवर्ड डालने से कभी नहीं रोकता है। न ही यह लॉगिन प्रयासों के बीच का समय बढ़ाता है।

क्या मैं कुछ गलत कर रहा हूँ या प्लगइन बस टूट गया है?

असल में लॉगिन प्लगइन ब्रूट फोर्स प्रोटेक्शन एडमिन पर लागू नहीं होता है (यहां इसके विपरीत लिखने में मेरा बुरा)। व्यवस्थापक में, आपके पास वेबसर्वर-स्तरीय सुरक्षा (जैसे Apache में htaccess/htpasswd) जोड़ने और IP श्रेणी द्वारा सीमित करने का विकल्प होता है, जब तक कि यह सुविधा व्यवस्थापक में भी नहीं आ जाती।

समझा। हाँ, मुझे लगता है कि तब तक यही समझदारी की बात है।
वर्तमान में, यह एक स्पष्ट सुरक्षा दोष की तरह लगता है, यदि उपयोगकर्ताओं को कम से कम यह चेतावनी नहीं मिलती है कि उन्हें व्यवस्थापक पृष्ठ को सुरक्षित करना चाहिए।

साथ ही, जैसा कि पहले ही सुझाव दिया गया है: डैशबोर्ड में असफल लॉगिन प्रयासों के लिए चेतावनी बहुत अच्छी होगी।

इस पर जल्द ही एक अपडेट की उम्मीद है :)

संपादित करें: .htaccess समाधान व्यवस्थापक पृष्ठ पर सभी सीएसएस को काफी हद तक मारता है। जो कमोबेश इसे अनुपयोगी बना देता है।

वर्तमान में, बेहतर व्यवस्थापक सुरक्षा के लिए आप जो सबसे अच्छा कर सकते हैं, वह है व्यवस्थापक पृष्ठ का नाम बदलकर छिपाना, जैसे:
https://learn.getgrav.org/admin-panel/faq#custom -admin-url
मैं वास्तव में आशा करता हूं कि व्यवस्थापक के लिए एक लॉगिन सुरक्षा जल्द ही आएगी, क्योंकि यह मुझे कॉर्पोरेट साइट पर इसका उपयोग करने से रोकता है।

असल में लॉगिन प्लगइन ब्रूट फोर्स प्रोटेक्शन एडमिन पर लागू नहीं होता है (यहां इसके विपरीत लिखने में मेरा बुरा)। व्यवस्थापक में, आपके पास वेबसर्वर-स्तरीय सुरक्षा (जैसे Apache में htaccess/htpasswd) जोड़ने और IP श्रेणी द्वारा सीमित करने का विकल्प होता है, जब तक कि यह सुविधा व्यवस्थापक में भी नहीं आ जाती।

ऐसा लगता है कि मेरे व्यवस्थापक लॉगिन पृष्ठ पर ब्रूट फोर्स सुरक्षा काम कर रही है। यह डॉक्स में भी है। क्या यह टिप्पणी पुरानी है या मैं गलत समझ रहा हूँ?

क्या किसी को भी पता है कि ग्रैव को फेल 2बान के साथ कैसे काम करना है?

मेरा वैकल्पिक समाधान केवल तभी काम करता है जब आपके पास अपने सभी सर्वर/होस्टिंग तक एफ़टीपी पहुंच हो।

आप .htaccess को केवल अपने विशिष्ट IP पते को /admin/ फ़ोल्डर को पढ़ने की अनुमति देने के लिए संपादित कर सकते हैं। कोई अन्य आईपी (और बाद के बॉट) किसी भी फ़ोल्डर सामग्री को लोड करने में सक्षम नहीं होंगे।

मैं इस पद्धति का उपयोग सभी को अस्वीकार करने के लिए करता था, लेकिन मेरा अपना आईपी पता ... यह जांचने के लिए कि कोई बिल्ड वेबसाइट काम कर रही है या नहीं, इसे लॉन्च करने से पहले। इससे पहले कि आप स्थानीय वेबसर्वर चला सकें। शायद यह अभी भी उन कुछ उपयोगकर्ताओं के लिए काम करता है जो डरते हैं और केवल अपने आईपी से कुल नियंत्रण चाहते हैं।