security - वेबसाइटों पर ब्रूट फोर्स लॉग इन को रोकना




login brute-force (9)

हाल ही में ट्विटर अपहर्ताओं और जेफ के डिक्शनरी अटैक पर पोस्ट के जवाब के रूप में, ब्रूट फोर्स लॉगिन हमलों के खिलाफ अपनी वेबसाइट को सुरक्षित करने का सबसे अच्छा तरीका क्या है?

जेफ की पोस्ट प्रत्येक प्रयास किए गए लॉगिन के लिए बढ़ती देरी में शामिल होने का सुझाव देती है, और टिप्पणियों में एक सुझाव दूसरे विफल प्रयास के बाद कैप्चा जोड़ना है।

ये दोनों अच्छे विचारों की तरह लगते हैं, लेकिन आप कैसे जानते हैं कि "प्रयास संख्या" क्या है? आप एक सत्र आईडी पर भरोसा नहीं कर सकते (क्योंकि एक हमलावर इसे हर बार बदल सकता है) या एक आईपी पता (बेहतर, लेकिन बॉटनेट के लिए कमजोर)। बस उपयोगकर्ता नाम के खिलाफ इसे लॉगिंग कर सकते हैं, देरी विधि का उपयोग कर, वैध उपयोगकर्ता को लॉक कर सकते हैं (या कम से कम लॉगिन प्रक्रिया को उनके लिए बहुत धीमा कर दें)।

विचार? सुझाव?


सर्वोत्तम अभ्यास पर विस्तार करने के लिए:

क्या क्रोसेंवोल्ड ने कहा: उपयोगकर्ता तालिका में num_failed_logins और last_failed_time लॉग करें (उपयोगकर्ता को निलंबित करने के अलावा), और एक बार असफल लॉग इन की संख्या एक सीमा तक पहुंच जाती है, तो आप उपयोगकर्ता को 30 सेकंड या एक मिनट के लिए निलंबित करते हैं। यह सबसे अच्छा अभ्यास है।

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

मूल विचार के बारे में याद रखने के लिए एक अतिरिक्त बात यह है कि आपको निश्चित रूप से वैध उपयोगकर्ता को आक्रमण करने की कोशिश करनी चाहिए, भले ही खाते पर हमला किया जा रहा हो और निलंबित हो - यानी, यदि आप वास्तविक उपयोगकर्ता और बॉट को अलग कर सकते हैं।

और आप कम से कम दो तरीकों से कर सकते हैं।

  1. यदि उपयोगकर्ता के पास लगातार लॉगिन है ("मुझे याद रखें") कुकी, बस उसे पार करने दें।

  2. जब आप "मुझे खेद है, तो बड़ी संख्या में असफल लॉगिन प्रयासों के कारण आपका खाता निलंबित कर दिया गया है" संदेश में एक लिंक शामिल है जो " सुरक्षित बैकअप लॉगिन - केवल हंस (बॉट्स: झूठ बोलना नहीं) " कहता है। एक तरफ मजाक करें, जब वे उस लिंक पर क्लिक करते हैं, तो उन्हें एक रीकाप्चा-प्रमाणीकृत लॉगिन फॉर्म दें जो खाते की निलंबन स्थिति को छोड़ देता है। इस तरह, अगर वे मानव हैं और सही लॉगिन + पासवर्ड (और कैप्चा पढ़ने में सक्षम हैं) जानते हैं, तो वे कभी भी देरी से परेशान नहीं होंगे, और आपकी साइट तेजी से आग के हमलों के लिए अभ्यस्त होगी।

केवल दोष: कुछ लोग (जैसे दृष्टि-विकलांग) कैप्चा पढ़ नहीं सकते हैं, और वे अब भी परेशान बॉट-उत्पादित देरी से प्रभावित हो सकते हैं अगर वे ऑटोलॉगिन सुविधा का उपयोग नहीं कर रहे हैं।

कोई कमी नहीं है: कि ऑटोलॉगिन कुकी में समान सुरक्षा उपाय नहीं है। यह कोई कमी क्यों नहीं है, आप पूछते हैं? क्योंकि जब तक आप इसे बुद्धिमानी से कार्यान्वित कर चुके हैं, तो आपके लॉगिन कुकी में सुरक्षित टोकन (पासवर्ड समकक्ष) आपके पासवर्ड के रूप में दोगुनी बिट्स (बिल्ली, दस गुना अधिक बिट्स बनाते हैं!) है, इसलिए इसे क्रूर-फोर्सिंग करना प्रभावी रूप से एक गैर-मुद्दा । लेकिन यदि आप वास्तव में पागल हैं, तो ऑटोलॉगिन सुविधा पर एक-दूसरे की देरी भी सेट करें, बस अच्छे उपाय के लिए।


.NET पर्यावरण के लिए

गतिशील आईपी प्रतिबंध

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

दुर्भावनापूर्ण आईपी पते से अनुरोधों को गतिशील रूप से अवरुद्ध करके सेवा हमले के अस्वीकार की संभावनाओं को कम करें

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

अपने वेब सर्वर के पासवर्ड की ब्रूट-फोर्स-क्रैकिंग की संभावनाओं को कम करें

आईआईएस के लिए डायनामिक आईपी प्रतिबंध अनुरोध पैटर्न का पता लगाने में सक्षम है जो वेब सर्वर के पासवर्ड को डीकोड करने का प्रयास करते हैं। मॉड्यूल उन सर्वरों की सूची पर अपमानजनक आईपी रखेगा जिन्हें पूर्व निर्धारित समय तक पहुंच से वंचित कर दिया गया है। ऐसी परिस्थितियों में जहां एक सक्रिय निर्देशिका सेवा (एडीएस) के खिलाफ प्रमाणीकरण किया जाता है, मॉड्यूल एडीएस को प्रमाणीकरण चुनौतियों को जारी करने से बचकर वेब सर्वर की उपलब्धता को बनाए रखने में सक्षम है।

विशेषताएं

  • आईआईएस 7.0 प्रबंधक में निर्बाध एकीकरण।

  • निम्नलिखित मानदंडों के आधार पर आईपी पते से अनुरोधों की गतिशील रूप से अवरुद्ध करना:

    • समवर्ती अनुरोधों की संख्या।

    • समय की अवधि में अनुरोधों की संख्या।

  • डायनामिक आईपी प्रतिबंध फ़िल्टरिंग को बाईपास करने की अनुमति देने वाले आईपी की सूची के लिए समर्थन।

  • अनुरोधों को अवरुद्ध करना वेब साइट या वेब सर्वर स्तर पर कॉन्फ़िगर करने योग्य हो सकता है।

  • कॉन्फ़िगर करने योग्य अस्वीकार क्रियाएं आईटी प्रशासकों को यह निर्दिष्ट करने की अनुमति देती हैं कि ग्राहक को कौन सी प्रतिक्रिया वापस कर दी जाएगी। मॉड्यूल समर्थन रिटर्न स्टेटस कोड 403, 404 या कनेक्शन बंद करना।

  • आईपीवी 6 पते के लिए समर्थन।

  • प्रॉक्सी या फ़ायरवॉल के पीछे वेब सर्वर के लिए समर्थन जो क्लाइंट आईपी पते को संशोधित कर सकता है।

http://www.iis.net/download/DynamicIPRestrictions


आप ऐसा कर सकते हैं जो Google करता है। जो कि एक निश्चित संख्या में ट्रे के बाद होता है, उनके पास कैप्चा दिखाया जाता है। कैप्चा के साथ दो बार के बाद आप उन्हें कुछ मिनट के लिए बंद कर देते हैं।


आप कैप्चा परीक्षण के कुछ रूप जोड़ सकते हैं। लेकिन सावधान रहें कि उनमें से अधिकतर अधिक कठिन आंखों या कानों को प्रभावित करने वाले लोगों तक पहुंच प्रदान करते हैं। कैप्चा का एक दिलचस्प रूप एक सवाल पूछ रहा है,

2 और 2 की राशि क्या है?

और यदि आप अंतिम लॉगिन विफलता रिकॉर्ड करते हैं, तो आप कैप्चा को छोड़ सकते हैं यदि यह पुराना हो। अंतिम विफलता पिछले 10 मिनट के दौरान होती है तो केवल कैप्चा परीक्षण करें।


ऑनलाइन लॉग इन करने वाले बहुत से ऑनलाइन संदेश बोर्ड मुझे खाते में लॉग इन करने के 5 प्रयास देते हैं, उन 5 प्रयासों के बाद खाते को एक घंटे या पंद्रह मिनट तक बंद कर दिया जाता है। यह सुंदर नहीं हो सकता है, लेकिन यह निश्चित रूप से एक खाते पर एक शब्दकोश हमले को धीमा कर देगा। अब एक ही समय में कई खातों के खिलाफ एक शब्दकोश हमले को रोक नहीं रहा है। मैं 5 बार कोशिश करता हूं, एक अलग खाते पर स्विच करता हूं, 5 बार कोशिश करता हूं, फिर वापस सर्कल करता हूं। लेकिन यह निश्चित रूप से हमले को धीमा कर देता है।

एक शब्दकोश हमले के खिलाफ सबसे अच्छा बचाव यह सुनिश्चित करना है कि पासवर्ड एक शब्दकोश में नहीं हैं !!! असल में कुछ प्रकार की पासवर्ड नीति सेट करें जो अक्षरों के खिलाफ एक शब्दकोश की जांच करती है और पासवर्ड में संख्या या प्रतीक की आवश्यकता होती है। यह संभवतः एक शब्दकोश हमले के खिलाफ सबसे अच्छा बचाव है।


पुरानी पोस्ट लेकिन मुझे 2016 के आखिर में जो कुछ है, उसे पोस्ट करने दें। उम्मीद है कि यह अभी भी मदद कर सकता है।

यह एक आसान तरीका है लेकिन मुझे लगता है कि लॉगिन हमले को रोकने के लिए यह शक्तिशाली है। कम से कम मैं हमेशा इसे अपने हर वेब पर उपयोग करता हूं। हमें कैप्चा या किसी अन्य तीसरे पक्ष के प्लगइन्स की आवश्यकता नहीं है।

जब उपयोगकर्ता पहली बार लॉगिन करता है। हम एक सत्र बनाते हैं

$_SESSION['loginFail'] = 10; // any number you prefer

यदि लॉगिन सफलता है, तो हम इसे नष्ट कर देंगे और उपयोगकर्ता लॉगिन कर देंगे।

unset($_SESSION['loginFail']); // put it after create login session

लेकिन यदि उपयोगकर्ता विफल रहता है, जैसा कि हम आम तौर पर उन्हें त्रुटि संदेश भेजते हैं, उसी समय हम सत्र को 1 से कम करते हैं:

$_SESSION['loginFail']-- ; // reduce 1 for every error

और यदि उपयोगकर्ता 10 बार विफल रहता है, तो हम उन्हें अन्य वेबसाइट या किसी भी वेब पेज पर निर्देशित करेंगे।

if (!isset($_SESSION['loginFail'])) { 

     if ($_SESSION['login_fail'] < 1 ) {

     header('Location:https://google.com/'); // or any web page

     exit();

}
}

इस तरह, उपयोगकर्ता अब हमारे लॉगिन पेज को नहीं खोल सकता या नहीं जा सकता है, क्योंकि यह अन्य वेबसाइट पर रीडायरेक्ट हो गया है।

उपयोगकर्ताओं को ब्राउजर को बंद करना होगा (सत्र लॉगिन को नष्ट करने के लिए जिसे हमने बनाया है), हमारे लॉगिन पेज को फिर से देखने के लिए इसे 'फिर से' खोलें।

क्या यह सहायक है?


मेरी आंखों में कई संभावनाएं हैं, प्रत्येक में विपक्ष और पेशेवर हैं:

सुरक्षित पासवर्ड मजबूर करना

  • प्रो : शब्दकोश हमलों को रोक देगा
  • कॉन : लोकप्रियता को भी रोक देगा, क्योंकि अधिकांश उपयोगकर्ता जटिल पासवर्ड याद रखने में सक्षम नहीं हैं, भले ही आप उन्हें समझाएं, उन्हें आसानी से याद रखें। उदाहरण के लिए वाक्यों को याद करके: "मैंने मॉल में 5 सेंट के लिए 1 ऐप्पल खरीदा" "आईबी 1 एएफ 5 सीआईटीएम" की ओर जाता है।

कई प्रयासों के बाद लॉकआउट्स

  • प्रो : स्वचालित परीक्षण धीमा कर देगा
  • कॉन : उपयोगकर्ताओं को तीसरे पक्ष के लिए लॉक करना आसान है
  • Con : डेटाबेस में लगातार उन्हें बनाने के परिणामस्वरूप ट्विटर या तुलनीय जैसी बड़ी सेवाओं में बहुत सी प्रक्रियाएं हो सकती हैं।

कैप्चा

  • प्रो : वे स्वचालित परीक्षण को रोकते हैं
  • Con : वे कंप्यूटिंग समय उपभोग कर रहे हैं
  • Con : उपयोगकर्ता अनुभव को धीमा कर देगा
  • विशाल कान : वे बाधा मुक्त नहीं हैं

सरल ज्ञान जांच करता है

  • प्रो : स्वचालित परीक्षण को रोक देगा
  • कॉन : दर्शक की आंख में "सरल" है।
  • Con : उपयोगकर्ता अनुभव को धीमा कर देगा

अलग लॉगिन और उपयोगकर्ता नाम

  • प्रो : यह एक तकनीकी है, जिसे शायद ही देखा जाता है, लेकिन मेरी आंखों में ब्रूट फोर्स हमलों को रोकने के लिए एक बहुत अच्छी शुरुआत है।
  • Con : दो नामों के उपयोगकर्ताओं की पसंद पर निर्भर करता है।

पासवर्ड के रूप में पूरे वाक्यों का प्रयोग करें

  • प्रो : संभावनाओं की खोज योग्य जगह के आकार को बढ़ाता है।
  • प्रो : अधिकांश उपयोगकर्ताओं के लिए याद रखना आसान है।
  • Con : उपयोगकर्ताओं की पसंद पर निर्भर करता है।

जैसा कि आप देख सकते हैं, "अच्छे" समाधान सभी उपयोगकर्ताओं की पसंद पर निर्भर करते हैं, जो फिर से उपयोगकर्ता को श्रृंखला के सबसे कमजोर तत्व के रूप में प्रकट करता है।

कोई अन्य सुझाव?


मैं अन्य टिप्पणियों के साथ सहमत हूं:

  • एक्स विफल पासवर्ड प्रयासों के बाद लॉक करें
  • उपयोगकर्ता नाम के खिलाफ असफल प्रयासों की गणना करें
  • वैकल्पिक रूप से कैप्चा का उपयोग करें (उदाहरण के लिए, 1-2 प्रयास सामान्य हैं, 3-5 प्रयासों को कैप्चा किया जाता है, 15 मिनट के लिए अवरुद्ध प्रयास)।
  • वैकल्पिक रूप से ब्लॉक को हटाने के लिए खाता स्वामी को एक ई-मेल भेजें

जो मैं इंगित करना चाहता था वह यह है कि आपको "मजबूत" पासवर्ड को मजबूर करने के बारे में बहुत सावधान रहना चाहिए, क्योंकि इसका मतलब यह है कि वे केवल पोस्ट / इसे मॉनीटर से जुड़े एक पोस्ट पर ही लिखे जाएंगे। साथ ही, कुछ पासवर्ड नीतियां अधिक अनुमानित पासवर्ड ले जाती हैं। उदाहरण के लिए:

यदि पासवर्ड किसी भी पिछले इस्तेमाल किए गए पासवर्ड नहीं हो सकता है और इसमें एक संख्या शामिल होनी चाहिए, तो इसके बाद एक अनुक्रमिक संख्या वाला कोई सामान्य पासवर्ड होगा। यदि आपको हर 6 महीने में अपना पासवर्ड बदलना है, और एक व्यक्ति वहां दो साल रहा है, संभावना है कि उनका पासवर्ड पासवर्ड 4 जैसा कुछ है।

मान लें कि आप इसे और भी प्रतिबंधित करते हैं: कम से कम 8 वर्ण होने चाहिए, कोई अनुक्रमिक अक्षर नहीं हो सकता है, एक अक्षर, एक संख्या और एक विशेष चरित्र होना चाहिए (यह एक वास्तविक पासवर्ड नीति है जिसे कई सुरक्षित मानेंगे)। जॉन क्विंसी स्मिथ के खाते में तोड़ने की कोशिश कर रहे हैं? पता है कि वह 6 मार्च को पैदा हुआ था? एक अच्छा मौका है कि उसका पासवर्ड jqs0306 जैसा कुछ है ! (या शायद jqs0306 ~ )।

अब, मैं यह नहीं कह रहा हूं कि आपके उपयोगकर्ताओं को पासवर्ड पासवर्ड देना एक अच्छा विचार है, बस अपने आप को यह सोचने के लिए न कि अपने मजबूर "सुरक्षित" पासवर्ड सुरक्षित हैं।


मुझे लगता है कि दिए गए खाते (1-5 मिनट) के लिए डेटाबेस-लगातार छोटी लॉकआउट अवधि इसे संभालने का एकमात्र तरीका है। आपके डेटाबेस में प्रत्येक userid में एक समय timeOfLastFailedLogin और numberOfFailedAttempts । जब numbeOfFailedAttempts > X आप कुछ मिनट के लिए लॉकआउट।

इसका मतलब है कि आप कुछ समय के लिए userid को लॉक कर रहे हैं, लेकिन स्थायी रूप से नहीं। इसका मतलब यह भी है कि आप प्रत्येक लॉगिन प्रयास के लिए डेटाबेस अपडेट कर रहे हैं (जब तक कि यह लॉक न हो), जो अन्य समस्याओं का कारण बन सकता है।

एशिया में कम से कम एक पूरा देश है, इसलिए आईपी का इस्तेमाल किसी भी चीज़ के लिए नहीं किया जा सकता है।





brute-force