security - सबसे अच्छा वितरित ब्रूट फोर्स countermeasure क्या है?




authentication brute-force (12)

  1. अपना सामान्य पासवर्ड दर्ज करने से पहले एक बार पासवर्ड की आवश्यकता के बारे में क्या? इससे यह स्पष्ट हो जाएगा कि मुख्य पासवर्ड अनुमान लगाने के कई मौके मिलने से पहले कोई हमला कर रहा था?

  2. लॉगिन विफलताओं की वैश्विक गणना / दर रखें - यह हमले के संकेतक है - हमले के दौरान लॉगिन विफलताओं के बारे में कठोर होना चाहिए जैसे आईपी को अधिक तेज़ी से प्रतिबंधित करना।

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

मैं सभी सामान्य चाल जानता हूँ:

  1. प्रति आईपी / मेजबान के असफल प्रयासों की सीमा # को सीमित करना और अपराधी पहुंच को अस्वीकार करना (उदाहरण के लिए विफल 2Ban) - जो अब काम नहीं करता है क्योंकि बॉटनेट बेहतर हो गए हैं
  2. ज्ञात 'खराब' आईपी / मेजबान (जैसे डेनिहोस्ट) की एक ब्लैकलिस्ट के साथ उपरोक्त संयोजन - जो # 1 के लिए गिरने वाले बॉटनेट पर निर्भर करता है, जो वे तेजी से नहीं करते हैं
  3. आईपी ​​/ मेजबान श्वेतसूची पारंपरिक लेख के साथ संयुक्त (उदासीन गतिशील आईपी उपयोगकर्ताओं के साथ बेकार और अधिकांश वेबसाइटों पर उच्च मंथन)
  4. एन मिनट / घंटे की अवधि के भीतर असफल प्रयासों पर # साइट पर सीटवाइड सीमा निर्धारित करना, और इसके बाद कई मिनट / घंटों के लिए सभी लॉगिन प्रयासों को थ्रॉटलिंग (निलंबित) (समस्या के साथ जो आप पर हमला करते हैं बीओटीनेट बच्चे के खेल बन जाते हैं)
  5. अनिवार्य डिजिटल हस्ताक्षर (सार्वजनिक कुंजी प्रमाण पत्र) या आरएसए हार्डवेयर टोकन सभी उपयोगकर्ताओं के लिए कोई लॉगिन / पासवर्ड विकल्प नहीं है (प्रश्न के बिना एक रॉक-ठोस समाधान, लेकिन केवल बंद, समर्पित सेवाओं के लिए व्यावहारिक)
  6. लागू अल्ट्रा-मजबूत पासवर्ड योजनाएं (उदाहरण के लिए> प्रतीकों के साथ 25 बकवास वर्ण - फिर से, आकस्मिक उपयोगकर्ताओं के लिए बहुत अव्यवहारिक)
  7. और अंत में, कैप्चा (जो ज्यादातर मामलों में काम कर सकता है, लेकिन उपयोगकर्ताओं के लिए परेशान है और एक निर्धारित, संसाधनकारी हमलावर के खिलाफ लगभग बेकार है )

अब, ये केवल सैद्धांतिक रूप से व्यावहारिक विचार हैं। बहुत सारे कचरे के विचार हैं जो साइट को व्यापक रूप से उड़ाते हैं (उदाहरण के लिए छोटे डीओएस हमलों के लिए)। मैं क्या चाहता हूं कुछ बेहतर है। और बेहतर से, मेरा मतलब है:

  • इसे डीओएस और ब्रूट-फोर्स हमलों के खिलाफ सुरक्षित (+) होना चाहिए, और किसी भी नई भेद्यता को पेश नहीं करना चाहिए जो थोड़ा स्नीकर बॉट रडार के तहत परिचालन जारी रखने की अनुमति दे सकता है

  • इसे स्वचालित होना है। यदि प्रत्येक लॉगिन को सत्यापित करने या संदिग्ध गतिविधि की निगरानी करने के लिए मानव ऑपरेटर की आवश्यकता होती है, तो यह वास्तविक दुनिया परिदृश्य में काम नहीं करेगा

  • इसे मुख्यधारा के वेब उपयोग (यानी उच्च मंथन, उच्च मात्रा, और खुले पंजीकरण के लिए व्यवहार्य होना चाहिए जो गैर-प्रोग्रामर द्वारा किया जा सकता है)

  • यह उस बिंदु पर उपयोगकर्ता अनुभव को बाधित नहीं कर सकता है जहां आकस्मिक उपयोगकर्ता नाराज हो जाएंगे या निराश होंगे (और संभावित रूप से साइट को छोड़ दें)

  • इसमें बिल्ली के बच्चे शामिल नहीं हो सकते हैं, जब तक वे वास्तव में वास्तव में सुरक्षित बिल्ली के बच्चे नहीं होते हैं

(+) 'सुरक्षित' से, मेरा मतलब है कि कम से कम एक पागल उपयोगकर्ता के पासवर्ड को गुप्त रखने की क्षमता के रूप में सुरक्षित है

तो - चलो इसे सुनें! आप यह कैसे करेंगे क्या आप एक सर्वोत्तम अभ्यास के बारे में जानते हैं जिसका मैंने उल्लेख नहीं किया है (ओह कृपया आप कहें)? मैं मानता हूं कि मेरे पास अपने बारे में एक विचार है (3 और 4 से विचारों को जोड़ना), लेकिन मैं सच्चे विशेषज्ञों को खुद को शर्मिंदा करने से पहले बोलूंगा ;-)


अगर मैं एमओ ऑफ ब्रूट फोर्स पर सही ढंग से हमला करता हूं, तो एक या अधिक उपयोगकर्ता नाम लगातार प्रयास किए जाते हैं।

दो सुझाव हैं जो मुझे नहीं लगता कि मैंने अभी तक देखा है:

  • मैंने हमेशा सोचा कि मानक अभ्यास प्रत्येक उपयोगकर्ता के लिए प्रत्येक गलत लॉगिन के बाद एक छोटी देरी (एक या तो) होना था। यह क्रूर बल को रोकता है, लेकिन मुझे नहीं पता कि एक दूसरी देरी कितनी देर तक बे में एक शब्दकोश हमला रखेगी। (10,000 शब्दों का शब्दकोश == 10,000 सेकंड == लगभग 3 घंटे। हम्म। पर्याप्त अच्छा नहीं है।)
  • एक साइट-व्यापी धीमी गति के बजाय, उपयोगकर्ता नाम थ्रॉटल क्यों नहीं। थ्रॉटल प्रत्येक गलत प्रयास के साथ तेजी से कठोर हो जाता है (एक सीमा तक, मुझे लगता है कि असली उपयोगकर्ता अभी भी लॉगिन कर सकता है)

संपादित करें : उपयोगकर्ता नाम थ्रॉटल पर टिप्पणियों के जवाब में: यह हमले के स्रोत के संबंध में उपयोगकर्ता नाम विशिष्ट थ्रॉटल है।

यदि उपयोगकर्ता नाम थ्रॉटल किया गया है, तो यहां तक ​​कि एक समन्वित उपयोगकर्ता नाम हमला (बहु आईपी, एकल अनुमान प्रति आईपी, एक ही उपयोगकर्ता नाम) पकड़ा जाएगा। व्यक्तिगत उपयोगकर्ता नाम थ्रॉटल द्वारा संरक्षित होते हैं, भले ही हमलावर टाइमआउट के दौरान किसी अन्य उपयोगकर्ता / पास का प्रयास करने के लिए स्वतंत्र हों।

हमलावरों के दृष्टिकोण से, समय-समय पर आप 100 पासवर्ड पर पहली बार अनुमान लगाने में सक्षम हो सकते हैं, और प्रति खाता एक गलत पासवर्ड तुरंत खोज सकते हैं। आप एक ही समय अवधि के लिए केवल 50 सेकंड अनुमान लगाने में सक्षम हो सकते हैं।

उपयोगकर्ता खाते के दृष्टिकोण से, पासवर्ड को तोड़ने के लिए अनुमानों की औसत औसत संख्या भी होती है, भले ही अनुमान कई स्रोतों से आ रहे हों।

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

अतिरिक्त परिशोधन:

  • कई खातों का अनुमान लगा रहे आईपी का पता लगाएं - 408 अनुरोध टाइमआउट
  • आईपी ​​का पता लगाएं जो एक ही खाते का अनुमान लगा रहे हैं - 408 बड़े (100 कहें) अनुमानों की संख्या के बाद टाइमआउट का अनुरोध करें।

यूआई विचार (इस संदर्भ में उपयुक्त नहीं हो सकता है), जो उपरोक्त को परिशोधित भी कर सकता है:

  • यदि आप पासवर्ड सेटिंग के नियंत्रण में हैं, तो उपयोगकर्ता को दिखा रहा है कि उनका पासवर्ड कितना मजबूत है ताकि उन्हें बेहतर चुनने के लिए प्रोत्साहित किया जा सके।
  • यदि आप लॉगिन पेज के नियंत्रण में हैं, तो एक छोटे से उपयोगकर्ता नाम के अनुमानों की संख्या (10 कहें) के बाद, एक कैप्चा प्रदान करें।

आप उपयोगकर्ता पासवर्ड की ताकत के आधार पर भी थ्रॉटल कर सकते हैं।

जब कोई उपयोगकर्ता अपना पासवर्ड पंजीकृत करता है या बदलता है तो आप उनके पासवर्ड के लिए एक ताकत रेटिंग की गणना करते हैं, 1 और 10 के बीच कहते हैं।

"पासवर्ड" जैसे कुछ एक स्कोर करते हैं जबकि "c6eqapRepe7et * Awr @ ch" 9 या 10 स्कोर कर सकता है और जितना अधिक स्कोर उतना अधिक होता है जितना कि थ्रॉटलिंग में लात मारता है।


एक छद्म राज्य संक्रमण आरेख / नियमबेस में जेन्स की योजना को सारांशित करने के लिए:

  1. उपयोगकर्ता + पासवर्ड -> प्रविष्टि
  2. उपयोगकर्ता + पासवर्ड -> अस्वीकार कर दिया
  3. उपयोगकर्ता + ज्ञात_आईपी (उपयोगकर्ता) -> फ्रंट दरवाजा, // never throttle
  4. उपयोगकर्ता + अज्ञात_आईपी (उपयोगकर्ता) -> catflap
  5. (#denied> n) catflaps (साइट) के माध्यम से -> थ्रॉटल कैटलफैप्स (साइट) // slow the bots
  6. catflap + थ्रॉटल + पासवर्ड + कैप्चा -> प्रविष्टि // humans still welcome
  7. catflap + थ्रॉटल + पासवर्ड +! कैप्चा -> // a correct guess from a bot अस्वीकार कर दिया

टिप्पणियों:

  • सामने के दरवाजे को कभी थ्रॉटल न करें। एल्बोनियन राज्य पुलिस के पास आपके घर में आपका कंप्यूटर है, लेकिन आपसे पूछताछ करने में असमर्थ हैं। ब्रूट फोर्स आपके कंप्यूटर से एक व्यवहार्य दृष्टिकोण है।
  • यदि आप "अपना पासवर्ड भूल गए हैं?" लिंक, तो आपका ईमेल खाता हमले की सतह का हिस्सा बन जाता है।

इन अवलोकनों में उन लोगों के लिए एक अलग प्रकार का हमला शामिल है जिन्हें आप काउंटर करने का प्रयास कर रहे हैं।


कुछ सरल कदम:

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

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

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


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

मैं आपको यह समझने के लिए प्रोत्साहित करता हूं कि पासवर्ड कितनी तेजी से क्रैक किया जा सकता है, और उपयोगकर्ता इसे जितनी बार बार-बार बदलते हैं। उम्मीद है की यह मदद करेगा।

संपादित करें: यदि आप बहुत आलसी हमलावरों की अपेक्षा करते हैं, तो कई विफल प्रयासों के बाद कुछ कैप्चा की आवश्यकता होती है: यह बार को थोड़ा बढ़ाता है। यदि आप बहुत बुद्धिमान हमलावरों के बारे में चिंतित हैं, तो सुरक्षा सलाहकार को किराए पर लें। ;)


देर से बिट करें लेकिन मैं सोच रहा था, एक कठिन मामला मानते हुए - हमलावर 10,000 यादृच्छिक आईपी, यादृच्छिक उपयोगकर्ता नाम और 10,000 सबसे लोकप्रिय की सूची कहने से चुने गए यादृच्छिक पासवर्ड का उपयोग करता है।

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


पहला सवाल मैंने आमतौर पर सुना है जब इस सवाल से पूछना बंदरगाहों को बदलना है, लेकिन इसके बारे में भूल जाओ और केवल आईपीवी 4 को अक्षम करें। यदि आप केवल आईपीवी 6 नेटवर्क से ग्राहकों को अनुमति देते हैं तो आप अब सरल नेटवर्क स्कैनिंग के लिए प्रार्थना नहीं कर सकते हैं और हमलावर DNS लुकअप का सहारा लेते हैं। अपने अपाचे (एएएए) / सेंडमेल (एमएक्स-> एएएए) के समान पते पर न चलाएं / आपने सभी को क्या दिया है (एएएए)। सुनिश्चित करें कि आपका ज़ोन xferd नहीं हो सकता है, प्रतीक्षा करें कि आप किसी भी व्यक्ति द्वारा अपने क्षेत्र को डाउनलोड करने की अनुमति दे रहे हैं?

यदि बॉट्स आपके सर्वर को नए होस्टनाम सेट अप करते हैं, तो बस अपने होस्टनाम में कुछ गड़बड़ी तैयार करें, और अपना पता बदलें। पुरानी नामों को छोड़ दें और बॉट नेट के लिए टाइमआउट पर ** हनीपॉट नाम भी सेट करें।

** अपने रिवर्स (पीटीआर) रिकॉर्ड्स का परीक्षण करें (ip6.arpa। के तहत) यह देखने के लिए कि क्या उन्हें शून्य / 4 के शून्य में उपयोग किया जा सकता है जिसमें रिकॉर्ड वीएस / 4 एस नहीं हैं। आईई आमतौर पर ip6.arpa के पास एक पते में ~ 32 "होगा। लेकिन आखिरी कुछ लापता होने की कोशिश करने से नेटवर्क ब्लॉक को हटा दिया जा सकता है जिसमें वीएस अन्य रिकॉर्ड नहीं हैं। यदि आप इसे आगे ले जाते हैं तो पता स्थान के बड़े हिस्सों को छोड़ना संभव हो जाता है।

सबसे बुरे मामले में उपयोगकर्ताओं को आईपीवी 6 सुरंग स्थापित करना होगा, ऐसा नहीं है कि उन्हें डीएमजेड में वीपीएनिंग तक जाना होगा ... हालांकि एक आश्चर्य है कि यह पहला विकल्प क्यों नहीं है।

इसके अलावा केर्बेरोस शांत है, लेकिन आईएमएचओ एलडीएपी उड़ाता है (एनआईएसपीएलस के साथ तकनीकी रूप से गलत क्या है? मैंने पढ़ा है कि सूर्य ने फैसला किया है कि उपयोगकर्ता एलडीएपी चाहते थे और इसके कारण उन्होंने एनआईएस + को छोड़ दिया)। केर्बेरो एलडीएपी या एनआईएस के बिना ठीक काम करता है, बस मेजबान आधार पर होस्ट पर उपयोगकर्ताओं को प्रबंधित करना होगा। केर्बेरोस का उपयोग करना आपको उपयोग करने में आसान बनाता है, अगर स्वचालित नहीं है, तो पीकेआई।


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

जवाब नहीं हो सकता है - लेकिन अगर ऐसा है, तो मुझे आशा है कि आपको किसी प्रकार के सुरक्षा पेशेवर से सहायता मिल रही है; प्रोग्रामिंग कौशल (और स्टैक ओवरफ्लो स्कोर) सुरक्षा के बारे में दृढ़ता से संबंधित नहीं है।


मुझे विश्वास नहीं है कि एक सही जवाब है, लेकिन यदि हमले को महसूस किया जाता है तो रोबोटों को भंग करने की कोशिश करने के आधार पर मैं उससे संपर्क करने के इच्छुक हूं।

मेरे दिमाग के ऊपर से:

एक वैकल्पिक लॉगिन स्क्रीन पर स्विच करें। इसमें एकाधिक उपयोगकर्ता नाम और पासवर्ड रिक्त स्थान हैं जो वास्तव में दिखाई देते हैं लेकिन उनमें से केवल एक ही सही स्थान पर है। फ़ील्ड नाम हैं RANDOM - एक सत्र कुंजी को लॉगिन स्क्रीन के साथ भेजा जाता है, सर्वर तब पता लगा सकता है कि कौन से फ़ील्ड हैं। सफलता प्राप्त करें या फिर इसे विफल कर दें ताकि आप रीप्ले हमले की कोशिश न कर सकें - यदि आप पासवर्ड को अस्वीकार करते हैं तो उन्हें एक नया सत्र आईडी मिलता है।

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

इसके बाद, कैसे एक अलग प्रकार के कैप्चा के बारे में: आपके पास कई प्रश्न हैं जो मानव के लिए समस्याएं नहीं पैदा करेंगे। हालांकि, वे यादृच्छिक नहीं हैं। जब हमला शुरू होता है तो सभी को प्रश्न # 1 दिया जाता है। एक घंटे के प्रश्न # 1 के बाद त्याग दिया जाता है, फिर कभी उपयोग नहीं किया जाता है और हर कोई प्रश्न # 2 और इसी तरह से मिलता है।

हमलावर प्रश्नों की डिस्पोजेबल प्रकृति के कारण अपने रोबोट में डालने के लिए डेटाबेस डाउनलोड करने की जांच नहीं कर सकता है। उसे कुछ भी करने की क्षमता रखने के लिए एक घंटे के भीतर अपने बॉटनेट को नए निर्देश भेजना पड़ता है।


मैंने पहले एक बहुत ही समान प्रश्न का उत्तर दिया था कि मैं PHP में उपयोगकर्ता लॉगिन प्रयासों को कैसे थका सकता हूं । मैं यहां प्रस्तावित समाधान दोहरा दूंगा क्योंकि मेरा मानना ​​है कि आप में से कई को कुछ वास्तविक कोड देखने के लिए जानकारीपूर्ण और उपयोगी लगेगा। कृपया ध्यान रखें कि कैप्चा का उपयोग आजकल कैप्चा बस्टर में उपयोग किए जाने वाले तेजी से सटीक एल्गोरिदम के कारण सबसे अच्छा समाधान नहीं हो सकता है:

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

क्यूं कर? चूंकि हमले आपके थ्रॉटलिंग प्रयासों को छोड़ने के लिए कई आईपी और उपयोगकर्ता खातों का विस्तार कर सकते हैं।

मैंने कहीं और पोस्ट किया है, आदर्श रूप से आपको साइट पर सभी असफल लॉगिन प्रयासों को ट्रैक करना चाहिए और उन्हें टाइमस्टैंप से जोड़ना चाहिए, शायद:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

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

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

किसी दिए गए अवधि के लिए असफल लॉगिन की संख्या खोजने के लिए प्रत्येक असफल लॉगिन प्रयास पर तालिका को क्वेरी करें, 15 मिनट कहें:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

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

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

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


ठीक है, पर्याप्त रुकावट; यहां तक ​​कि मैं अब तक क्या आया हूं

(क्षमा करें, आगे लंबे समय तक पोस्ट करें। बहादुर बनो, दोस्त, यात्रा इसके लायक होगा)

मूल पोस्ट से विधियों 3 और 4 को एक प्रकार की 'अस्पष्ट' या गतिशील श्वेतसूची में जोड़ना, और फिर - और यहां चाल है - नॉन-श्वेतसूची वाले आईपी को अवरुद्ध नहीं करना, उन्हें नरक और पीठ पर थ्रॉटल करना

ध्यान दें कि यह उपाय केवल इस विशिष्ट प्रकार के हमले को विफल करने के लिए है। अभ्यास में, ज़ाहिर है, यह ऑथ के लिए अन्य सर्वोत्तम प्रथाओं के दृष्टिकोण के साथ संयोजन में काम करेगा: फिक्स्ड-यूज़रनेम थ्रॉटलिंग, प्रति-आईपी थ्रॉटलिंग, कोड-लागू बल वाली पासवर्ड पॉलिसी, अनथान कुकी लॉगिन, इन्हें सहेजने से पहले सभी पासवर्ड समकक्ष हैं, कभी नहीं सुरक्षा प्रश्नों का उपयोग आदि

हमले परिदृश्य के बारे में धारणाएं

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

तो हमें कुछ और करने की ज़रूरत है।

Countermeasure का पहला हिस्सा: Whitelisting

हम किस बारे में काफी यकीन कर सकते हैं, यह है कि हमलावर हमारे हजारों उपयोगकर्ताओं (+) के आईपी पते को पहचानने और गतिशील रूप से खराब करने में सक्षम नहीं है। जो whitelisting व्यवहार्य बनाता है। दूसरे शब्दों में: प्रत्येक उपयोगकर्ता के लिए, हम (हैश) आईपी की एक सूची संग्रहीत करते हैं जहां से उपयोगकर्ता ने पहले (हाल ही में) लॉग इन किया है।

इस प्रकार, हमारी श्वेतसूची योजना लॉक 'फ्रंट दरवाजा' के रूप में कार्य करेगी, जहां लॉग इन करने के लिए उपयोगकर्ता को अपने किसी मान्यता प्राप्त 'अच्छे' आईपी से कनेक्ट होना चाहिए। इस 'फ्रंट दरवाजे' पर एक क्रूर बल का हमला व्यावहारिक रूप से असंभव होगा (+)।

(+) जब तक हमलावर का मालिक या तो सर्वर, हमारे सभी उपयोगकर्ता के बक्से, या कनेक्शन स्वयं नहीं होते - और उन मामलों में, हमारे पास अब 'प्रमाणीकरण' समस्या नहीं है, हमारे पास एक वास्तविक फ़्रैंचाइज़ी आकार का पुल है- -प्लग फूबर स्थिति

Countermeasure का दूसरा भाग: अपरिचित आईपी के सिस्टम-व्यापी थ्रॉटलिंग

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

मेरी योजना में, यह 3 घंटे की अवधि के दौरान अस्वीकृत आईपी द्वारा असफल लॉगिन प्रयासों की बहुत ही सीमित अधिकतम संख्या निर्धारित करके हासिल किया जाता है (सेवा के प्रकार के आधार पर कम या लंबी अवधि का उपयोग करना बुद्धिमान हो सकता है), और उस प्रतिबंध को वैश्विक बनाते हैं, यानी। सभी उपयोगकर्ता खातों के लिए।

यहां तक ​​कि एक धीमी गति (प्रयासों के बीच 1-2 मिनट) ब्रूट फोर्स का पता लगाया जाएगा और इस विधि का उपयोग करके जल्दी और प्रभावशाली ढंग से विफल हो जाएगा। बेशक, वास्तव में एक धीमी क्रूर बल अभी भी अनजान रह सकता है, लेकिन बहुत धीमी रफ्तार ब्रूट फोर्स अटैक के बहुत ही उद्देश्य को हरा देती है।

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

  • या तो उनके एक मान्यता प्राप्त आईपी से कनेक्ट करके
  • या एक सतत लॉगिन कुकी का उपयोग करके (कहीं से भी)

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

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

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

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

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

(साथ ही, ध्यान दें कि इनमें से कोई भी तब नहीं होता है जब हमले ने यहां वर्णित गंदे वितरित संस्करण से कम परिष्कृत किया हो। अगर हमला केवल कुछ आईपी से आ रहा है या केवल कुछ उपयोगकर्ता नामों को मार रहा है, तो यह बहुत पहले समाप्त हो जाएगा , और साइट के व्यापक परिणामों के साथ)

तो, यह प्रतिद्वंद्विता है कि मैं अपनी लेख पुस्तकालय में कार्यान्वित करूँगा, एक बार मुझे विश्वास है कि यह आवाज है और यह कि एक बहुत आसान समाधान नहीं है जिसे मैंने याद किया है। तथ्य यह है कि सुरक्षा में चीजों को गलत करने के लिए बहुत सारे सूक्ष्म तरीके हैं, और मैं झूठी मान्यताओं या निराशाजनक रूप से दोषपूर्ण तर्क बनाने से ऊपर नहीं हूं। तो कृपया, किसी भी और सभी प्रतिक्रिया, आलोचना और सुधार, subtleties आदि की अत्यधिक सराहना की है।





brute-force