2010-01-29 14 views
11

मैं वास्तव में एक PHP प्रोजेक्ट पर काम कर रहा हूं जिसमें एक उपयोगकर्ता सिस्टम (लॉग इन, रजिस्टर, ईमेल पर खोया पासवर्ड भेजें, ..) और मुझे लगता है कि यह बहुत कमजोर हो सकता है ब्रूट फोर्स हमलों और/या स्पैम (किसी के ईमेल को 1000 बार जैसे पासवर्ड भेजें, आदि। अपनी कल्पना का उपयोग करें) ।PHP: एंटी-फ्लड/स्पैम सिस्टम

  • क्या आज के वेबसर्वर (अपाचे, आईआईएस) में ब्रूट फोर्स के खिलाफ अंतर्निहित रक्षा है?
  • एंटी स्पैम/बाढ़ प्रणाली को लागू करने का सबसे अच्छा तरीका क्या होगा यदि मैं उदाहरण: एक पृष्ठ को एक मिनट में दो बार से अधिक नहीं कहा जा सकता है, हालांकि एक और पृष्ठ 100 बार तक कॉल किया जा सकता है एक मिनट या तो।

    • मैं निश्चित रूप से स्टोर करने के लिए आईपी पतों, समय था जब वे पिछले एक पेज और कहीं यात्राओं की संख्या का दौरा होता है - लेकिन यह एक पाठ-फ़ाइल/डेटाबेस में भंडारण के लिए पर्याप्त कुशल होगा (MySQL)

    • क्या मुझे खोए गए पासवर्ड को पंजीकृत/पुनर्प्राप्त करने जैसी चीजों के लिए कैप्चा का उपयोग करना चाहिए?

    • क्या "टेक्स्ट" कैप्चा व्यवहार्य हैं? (कुछ "5 प्लस 9 शून्य 2 क्या है?")

    • पृष्ठ का उपयोग कई उपयोगकर्ताओं (100-200) द्वारा नहीं किया जाएगा, क्या मुझे वास्तव में इन सभी चीजों को लागू करना है?

उत्तर

19

कैप्चा के संबंध में: मैं आपको तब तक कैप्चा का उपयोग करने की सलाह दूंगा जब तक कि आपको वास्तव में इसकी आवश्यकता न हो। क्यूं कर?

  1. यह बदसूरत है।
  2. यह आपके उपयोगकर्ताओं के लिए परेशान है। आपको अपनी साइट का उपयोग करने के लिए उन्हें हुप्स के माध्यम से कूदना नहीं चाहिए।

हैं कुछ विकल्प है जो बहुत सरल हैं, बहुत प्रभावी हो सकता है और पूरी तरह (लगभग सभी) उपयोगकर्ताओं के लिए पारदर्शी है।

  1. Honeypot क्षेत्रों: "वेबसाइट" की तरह एक आम नाम के साथ अपने रूपों के लिए एक क्षेत्र में जोड़ें। इसके अलावा, "इस बॉक्स में न लिखें" के प्रभाव में कुछ कहकर एक लेबल जोड़ें। जावास्क्रिप्ट का उपयोग इनपुट और लेबल छुपाएं। जब आप फॉर्म सबमिशन प्राप्त करते हैं, यदि फ़ील्ड में कुछ भी है, तो इनपुट को अस्वीकार करें।

    जेएस वाले उपयोगकर्ता इसे नहीं देख पाएंगे और ठीक होंगे। जेएस के बिना उपयोगकर्ताओं को बस सरल निर्देश का पालन करना होगा। स्पैम्बॉट इसके लिए गिरेंगे और खुद को प्रकट करेंगे।

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

    जेएस वाले उपयोगकर्ता इसे नहीं देख पाएंगे और ठीक होंगे। जेएस के बिना उपयोगकर्ताओं को बस सरल निर्देश का पालन करना होगा। स्पैमबॉट्स नहीं जान पाएंगे कि क्या करना है और आप उनके इनपुट को अनदेखा कर सकते हैं।

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


ब्रूट फोर्स अवरुद्ध के बारे में: सर्वर-साइड समाधान इस स्पष्ट रूप से करने के लिए केवल व्यवहार्य तरीका है। मेरी वर्तमान परियोजनाओं में से एक के लिए, मैंने आपके द्वारा वर्णित एक समान बल बल सुरक्षा प्रणाली लागू की है। यह केकपीएचपी के लिए इस Brute Force Protection plugin पर आधारित था।

एल्गोरिदम काफी सरल है, लेकिन शुरुआत में थोड़ा उलझन में है। DELETE * FROM brute_force WHERE expires < NOW()

  • रन::

    1. उपयोगकर्ता कुछ कार्रवाई (पासवर्ड रीसेट, उदाहरण के लिए)
    2. रन का अनुरोध करता है

      SELECT COUNT(*) FROM brute_force 
      WHERE action = 'passwordReset' 
      AND ip = <their ip address> 
      
    3. तो गिनती है X से बड़ा तो उन्हें थोड़ी देर प्रतीक्षा करने के लिए बता ।
    4. अन्यथा, चलाएँ:

      INSERT INTO brute_force (ip, action, expires) 
      VALUES (<their ip address>, 'passwordReset', NOW() + Y minutes) 
      
    5. रीसेट पासवर्ड समारोह के साथ आगे बढ़ें।

    यह उपयोगकर्ताओं को केवल वाई मिनट में पासवर्ड X बार रीसेट करने का प्रयास करने की अनुमति देगा। जैसा कि आप फिट देखते हैं इन मानों को ट्विक करें। शायद 5 मिनट में 3 रीसेट? इसके अतिरिक्त, आपके पास प्रत्येक क्रिया के लिए अलग-अलग मान हो सकते हैं: कुछ चीजों के लिए (उदाहरण के लिए: एक पीडीएफ उत्पन्न करें), तो आप इसे 10 मिनट में 10 तक सीमित करना चाहेंगे।

  • +1

    +1 निक बाहर चिल्लाने के लिए धन्यवाद! :) – alex

    5
    1. हाँ, एक आईपी पता भंडारण, अंतिम अभिगमन और एक डेटाबेस में पहुँचा बार ठीक होगा।
    2. पंजीकरण/पुनर्प्राप्ति पासवर्ड के लिए कैप्चा का उपयोग करने की सलाह दी जाती है ताकि ई-मेल पते को स्पैम नहीं किया जा सके। ब्रूट फोर्सिंग को रोकने के लिए भी।
    3. हां, पाठ कैप्चा संभव है, हालांकि उत्तर को स्वचालित करने के लिए किसी व्यक्ति को क्रैक करने और लिखने के लिए कहीं अधिक आसान है। एक मुफ्त कैप्चा के लिए, मैं Recaptcha की सिफारिश करता हूं।
    4. यह वास्तव में इस बात पर निर्भर करता है कि आप सुरक्षा के बारे में कितना ख्याल रखते हैं। मैं निश्चित रूप से एक कैप्चा का उपयोग करने की सिफारिश करता हूं क्योंकि वे लागू करने के लिए सरल हैं।
    +0

    मैं अपने # 4 प्रतिक्रिया के साथ सहमत हैं। उपयोगकर्ताओं की एक सीमित संख्या इसका उपयोग कर सकती है, लेकिन यदि स्पैमर/हमलावर साइट पर कोई दोष खोजता है, तो वे उपरोक्त सिस्टम में मिलने वाली किसी भी भेद्यता का उपयोग कर सकते हैं। –

    -1

    आईपी पते संग्रह करना लॉगिंग और ट्रैकिंग के लिए अच्छा अभ्यास है, लेकिन मुझे लगता है कि सिर्फ एक कैप्चा स्पैमिंग, क्रूर बल के हमलों और बाढ़ को रोक देगा।

    रिकैप्चा वास्तव में एक अच्छा समाधान है।

    0

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

    -1

    सुनिश्चित करें, आपकी लक्षित दर्शक बड़े नहीं हो सकता है लेकिन अगर यह सार्वजनिक डोमेन में है तो यह कमजोर है, इन दिनों मुझे विश्वास है

    पाठ कैप्चा का आसानी से फटा रहे

    एक एंटी-स्पैम/बाढ़ आप प्रणाली के लिए

    आईपी ​​एड्रेसेशंस (MySQL अधिमानतः) लॉग इन कर सकते हैं और एक समय सीमा लॉगिन रीट्री

    1

    सभी को लागू करने की कोशिश न करें अपने PHP में तर्क - आपके ढेर में निचले स्तर पर आप इसे कार्यान्वित कर सकते हैं, इसे अधिक कुशलतापूर्वक निपटाया जा सकता है।

    अधिकांश फ़ायरवॉल (बीएसडी/लिनक्स पर iptables सहित) कनेक्शन थ्रॉटलिंग है। इसके अलावा, डीडीओएस/ब्रूट फोर्स आक्रमण रोकथाम के लिए mod_security पर एक नज़र डालें।

    आप अपने आवेदन को इस विचार के चारों ओर डिज़ाइन करना चाहिए कि इस प्रकार के हमले ऐप पर हमलावर पहुंच नहीं देंगे - दिन के अंत में आप किसी भी प्रकार के डॉस हमले को रोक नहीं सकते हैं, हालांकि आप इसे सीमित कर सकते हैं प्रभावशीलता।

    आपके हमलावर से एक सतत आईपी पते पर भरोसा करने में बहुत अधिक मूल्य नहीं है - इसके आसपास होने के कई तरीके हैं।

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

    HTH

    सी

    संबंधित मुद्दे