ما هو أفضل إجراء مضاد للقوة الغاشمة الموزعة؟

Question

أولاً، خلفية صغيرة:ليس سرًا أنني أقوم بتطبيق نظام مصادقة + مصادقة لـ CodeIgniter، وحتى الآن أنا فائز (إذا جاز التعبير).لكنني واجهت تحديًا غير تافه جدًا (وهو التحدي الذي تفتقده معظم مكتبات المصادقة تمامًا، لكنني أصر على التعامل معه بشكل صحيح):كيفية التعامل بذكاء مع هجمات القوة الغاشمة واسعة النطاق والموزعة بأسماء المستخدمين المتغيرة.

أنا أعرف كل الحيل المعتادة:

1. الحد من عدد المحاولات الفاشلة لكل عنوان IP/مضيف وحرمان الجناة من الوصول (على سبيل المثال.Fail2Ban) - الذي لم يعد يعمل منذ أن أصبحت شبكات الروبوت أكثر ذكاءً
2. الجمع بين ما سبق مع أ القائمة السوداء لعناوين IP/المضيفين "السيئة" المعروفة (على سبيل المثالDenyHosts) - الذي يعتمد على سقوط شبكات الروبوت في المرتبة الأولى، وهو ما لا يفعلونه على نحو متزايد
3. القوائم البيضاء لعنوان IP/المضيف مقترنًا بالمصادقة التقليدية (عديمة الفائدة للأسف مع مستخدمي IP الديناميكيين والاضطراب الشديد في معظم مواقع الويب)
4. الإعداد أ الحد على مستوى الموقع على # من المحاولات الفاشلة خلال فترة N دقيقة/ساعة، وتقييد (تعليق) جميع محاولات تسجيل الدخول بعد ذلك لعدد من الدقائق/الساعات (مع المشكلة المتمثلة في أن هجوم DoS عليك يصبح لعبة أطفال الروبوتات)
5. إلزامي التوقيعات الرقمية (شهادات المفتاح العام) أو رموز أجهزة RSA لجميع المستخدمين الذين ليس لديهم خيار تسجيل الدخول/كلمة المرور (بدون شك، حل قوي للغاية، ولكنه عملي فقط للخدمات المغلقة والمخصصة)
6. فرض مخططات كلمة المرور القوية للغاية (على سبيل المثال>25 حرفًا لا معنى له مع رموز - مرة أخرى، هذا غير عملي جدًا للمستخدمين العاديين)
7. وأخيرا، اختبار CAPTCHA (والتي يمكن أن تعمل في معظم الحالات، ولكنها مزعجة للمستخدمين و عديمة الفائدة تقريبا ضد أ مهاجم مصمم وواسع الحيلة)

الآن، هذه مجرد أفكار قابلة للتطبيق من الناحية النظرية.هناك كثير من الأفكار التافهة التي تفجر الموقع على مصراعيه (على سبيل المثال:لهجمات DoS التافهة).ما أريده هو شيء أفضل.وأعني بالأفضل:

• يجب أن يكون آمنًا (+) ضد DoS وهجمات القوة الغاشمة، وألا يقدم أي ثغرات أمنية جديدة قد تسمح لروبوت أكثر تسللًا بمواصلة العمل تحت الرادار

• يجب أن تكون آلية.إذا تطلب الأمر من عامل بشري التحقق من كل تسجيل دخول أو مراقبة الأنشطة المشبوهة، فلن يعمل هذا في سيناريو العالم الحقيقي

• يجب أن يكون ممكنًا للاستخدام السائد على الويب (على سبيل المثال.زبد مرتفع، حجم كبير، والتسجيل المفتوح الذي يمكن أن يؤديه غير المبرمجين)

• لا يمكن أن يعيق تجربة المستخدم إلى درجة يشعر فيها المستخدمون العاديون بالانزعاج أو الإحباط (وربما يتخلون عن الموقع)

• لا يمكن أن يشمل القطط الصغيرة، إلا إذا كانت كذلك حقا حقا آمنة القطط

(+) بكلمة "آمن"، أعني على الأقل آمنًا مثل قدرة المستخدم المصاب بجنون العظمة على الحفاظ على سرية كلمة المرور الخاصة به

لذلك - دعونا نسمع ذلك! كيف يمكنك أن تفعل ذلك؟هل تعرف أفضل الممارسات التي لم أذكرها (أوه من فضلك قل أنك تفعل ذلك)؟أعترف أن لدي فكرة خاصة بي (تجمع بين الأفكار من 3 و 4)، لكنني سأدع الخبراء الحقيقيين يتحدثون قبل إحراج نفسي؛-)

Answer 1

حسنًا، يكفي مماطلة؛هذا ما توصلت إليه حتى الآن

(آسف، وظيفة طويلة المقبلة.كن شجاعًا يا صديقي، الرحلة تستحق العناء)

الجمع بين الطريقتين 3 و4 من المنشور الأصلي في نوع من القائمة البيضاء "الغامضة" أو الديناميكية، وبعد ذلك - وإليك الحيلة - عدم حظر عناوين IP غير المدرجة في القائمة البيضاء، بل مجرد خنقها والعودة إلى الجحيم.

لاحظ أن هذا التدبير هو فقط يهدف إلى إحباط هذا النوع المحدد جدًا من الهجوم.من الناحية العملية، بطبيعة الحال، ستعمل جنبًا إلى جنب مع أساليب أفضل الممارسات الأخرى للمصادقة:تقييد اسم المستخدم الثابت، والتقييد لكل عنوان IP، وسياسة كلمة المرور القوية التي يتم فرضها بواسطة التعليمات البرمجية، وتسجيل الدخول غير المقيد لملفات تعريف الارتباط، وتجزئة جميع مرادفات كلمات المرور قبل حفظها، وعدم استخدام أسئلة الأمان مطلقًا، وما إلى ذلك.

افتراضات حول سيناريو الهجوم

إذا كان المهاجم يستهدف أسماء مستخدمين متغيرة، فلن يتم تفعيل تقييد اسم المستخدم الخاص بنا.إذا كان المهاجم يستخدم الروبوتات أو لديه إمكانية الوصول إلى نطاق IP كبير، فإن اختناق IP الخاص بنا يصبح عاجزًا.إذا قام المهاجم بحذف قائمة المستخدمين الخاصة بنا مسبقًا (وهذا ممكن عادةً في خدمات الويب للتسجيل المفتوح)، فلن نتمكن من اكتشاف الهجوم المستمر بناءً على عدد أخطاء "لم يتم العثور على المستخدم".وإذا فرضنا تقييدًا مقيدًا على مستوى النظام (جميع أسماء المستخدمين، وجميع عناوين IP)، فإن أي هجوم من هذا القبيل سيؤدي إلى حجب الخدمة عن موقعنا بالكامل طوال مدة الهجوم بالإضافة إلى فترة الاختناق.

لذلك نحن بحاجة إلى القيام بشيء آخر.

الجزء الأول من التدابير المضادة:القائمة البيضاء

ما يمكننا التأكد منه تمامًا هو أن المهاجم غير قادر على اكتشاف عناوين IP الخاصة بعدة آلاف من مستخدمينا (+) وانتحالها ديناميكيًا.مما يجعل القائمة البيضاء ممكن.بعبارة أخرى:لكل مستخدم، نقوم بتخزين قائمة بعناوين IP (المجزأة) التي قام المستخدم بتسجيل الدخول منها مسبقًا (مؤخرًا).

وبالتالي، فإن نظام القائمة البيضاء الخاص بنا سيعمل بمثابة "باب أمامي" مغلق، حيث يجب أن يكون المستخدم متصلاً من أحد عناوين IP "الجيدة" المعترف بها حتى يتمكن من تسجيل الدخول على الإطلاق.سيكون الهجوم بالقوة الغاشمة على هذا "الباب الأمامي" مستحيلًا عمليًا (+).

(+) ما لم "يمتلك" المهاجم الخادم، أو جميع صناديق المستخدمين، أو الاتصال نفسه - وفي تلك الحالات، لم تعد لدينا مشكلة "المصادقة"، بل لدينا عملية سحب حقيقية بحجم امتياز -قم بتوصيل وضع FUBAR

الجزء الثاني من التدابير المضادة:اختناق على مستوى النظام لعناوين IP غير المعترف بها

من أجل جعل القائمة البيضاء تعمل لخدمة ويب التسجيل المفتوح، حيث يقوم المستخدمون بتبديل أجهزة الكمبيوتر بشكل متكرر و/أو الاتصال من عناوين IP الديناميكية، نحتاج إلى إبقاء "باب القطة" مفتوحًا للمستخدمين الذين يتصلون من عناوين IP غير معروفة.وتتمثل الحيلة في تصميم هذا الباب بحيث تتعطل شبكات الروبوت، وبالتالي ينزعج المستخدمون الشرعيون أقل قدر ممكن.

في مخططي، يتم تحقيق ذلك عن طريق تعيين أ جداً الحد الأقصى لعدد محاولات تسجيل الدخول الفاشلة بواسطة عناوين IP غير المعتمدة خلال فترة 3 ساعات، على سبيل المثال (قد يكون من الحكمة استخدام فترة أقصر أو أطول اعتمادًا على نوع الخدمة)، وفرض هذا التقييد عالمي, ، أي.لجميع حسابات المستخدمين.

حتى القوة الغاشمة البطيئة (1-2 دقيقة بين المحاولات) سيتم اكتشافها وإحباطها بسرعة وفعالية باستخدام هذه الطريقة.بالطبع حقا بطيئة لا يزال من الممكن أن تظل القوة الغاشمة دون أن يلاحظها أحد، لكن السرعات البطيئة جدًا تحبط الغرض الأساسي من هجوم القوة الغاشمة.

ما آمل تحقيقه من خلال آلية الاختناق هذه هو أنه إذا تم الوصول إلى الحد الأقصى، فسيتم إغلاق "باب القطة" الخاص بنا لفترة من الوقت، ولكن بابنا الأمامي يظل مفتوحًا للمستخدمين الشرعيين الذين يتصلون بالوسائل المعتادة:

• إما عن طريق الاتصال من أحد عناوين IP المعترف بها
• أو باستخدام ملف تعريف ارتباط تسجيل الدخول الدائم (من أي مكان)

المستخدمون الشرعيون الوحيدون الذين قد يتأثرون أثناء الهجوم - أي.أثناء تنشيط التقييد - سيكون المستخدمون الذين ليس لديهم ملفات تعريف ارتباط تسجيل الدخول الدائمة والذين يقومون بتسجيل الدخول من موقع غير معروف أو باستخدام عنوان IP ديناميكي.لن يتمكن هؤلاء المستخدمون من تسجيل الدخول حتى يختفي القيد (وهو الأمر الذي قد يستغرق بعض الوقت، إذا أبقى المهاجم شبكة الروبوتات الخاصة به قيد التشغيل على الرغم من الاختناق).

للسماح لهذه المجموعة الفرعية الصغيرة من المستخدمين بالعبور عبر باب القطط المغلق، حتى بينما كانت الروبوتات لا تزال تدق عليه، سأستخدم نموذج تسجيل دخول "احتياطي" باستخدام اختبار CAPTCHA.لذلك، عندما تعرض الرسالة "عذرًا، لكن لا يمكنك تسجيل الدخول من عنوان IP هذا في الوقت الحالي"، قم بتضمين رابط يقول "تسجيل دخول احتياطي آمن - للبشر فقط (الروبوتات:لا الكذب)".وبغض النظر عن المزاح، عندما ينقرون على هذا الرابط، امنحهم نموذج تسجيل دخول مصادق عليه من خلال reCAPTCHA والذي يتجاوز التقييد على مستوى الموقع.بهذه الطريقة، إذا كانوا بشرًا ويعرفون معلومات تسجيل الدخول + كلمة المرور الصحيحة (وقادرون على قراءة اختبارات CAPTCHA)، فسيفعلون ذلك أبداً سيتم رفض الخدمة، حتى إذا كانوا متصلين من مضيف غير معروف ولا يستخدمون ملف تعريف ارتباط تسجيل الدخول التلقائي.

أوه، وفقط للتوضيح:نظرًا لأنني أعتبر اختبارات CAPTCHA شريرة بشكل عام، فإن خيار تسجيل الدخول "النسخ الاحتياطي" سيكون كذلك فقط يظهر بينما كان الاختناق نشطًا.

ليس هناك من ينكر أن هجومًا مستمرًا مثل هذا سيظل يشكل شكلاً من أشكال هجوم حجب الخدمة، ولكن مع وجود النظام الموصوف، فإنه لن يؤثر إلا على ما أظن أنه مجموعة فرعية صغيرة من المستخدمين، أي الأشخاص الذين لا يستخدمون ملف تعريف الارتباط "تذكرني" ويصادف أنهم يقومون بتسجيل الدخول أثناء حدوث هجوم ولا يقومون بتسجيل الدخول من أي من عناوين IP المعتادة الخاصة بهم والذين لا يمكنهم قراءة اختبار CAPTCHA.فقط أولئك الذين يمكنهم أن يقولوا لا لجميع هذه المعايير - وخاصة الروبوتات و سيئ الحظ حقا الأشخاص المعاقين - سيتم إبعادهم أثناء هجوم الروبوت.

يحرر: في الواقع، فكرت في طريقة للسماح حتى للمستخدمين الذين يواجهون تحديات اختبار CAPTCHA بالمرور أثناء "الإغلاق":بدلاً من تسجيل الدخول الاحتياطي باستخدام CAPTCHA، أو كمكمل له، قم بتزويد المستخدم بخيار إرسال رمز تأمين خاص بالمستخدم للاستخدام مرة واحدة إلى بريده الإلكتروني، والذي يمكنه بعد ذلك استخدامه لتجاوز التقييد.هذا بالتأكيد يتجاوز عتبة "الإزعاج" الخاصة بي، ولكن نظرًا لأنه يستخدم فقط كـ الحل الأخير لمجموعة فرعية صغيرة من المستخدمين، وبما أنه لا يزال يتفوق على حظر الوصول إلى حسابك، فسيكون ذلك مقبولاً.

(لاحظ ذلك أيضًا لا أحد يحدث هذا إذا كان الهجوم أقل تعقيدًا من النسخة الموزعة السيئة التي وصفتها هنا.إذا كان الهجوم قادمًا من عدد قليل من عناوين IP فقط أو من عدد قليل من أسماء المستخدمين فقط، فسيتم إحباطه في وقت أبكر بكثير، ومع لا العواقب على مستوى الموقع)

---

لذا، هذا هو الإجراء المضاد الذي سأقوم بتنفيذه في مكتبة المصادقة الخاصة بي، بمجرد أن أقتنع بأنه سليم وأنه لا يوجد حل أبسط بكثير فاتني.الحقيقة هي أن هناك العديد من الطرق الدقيقة لفعل أشياء خاطئة في مجال الأمن، وأنا لست فوق وضع افتراضات خاطئة أو منطق معيب بشكل ميؤوس منه.لذا يرجى، أي وجميع ردود الفعل والنقد والتحسينات، والدقة وما إلى ذلك.هي محل تقدير كبير.

Answer 2

بعض الخطوات البسيطة:

قم بإدراج بعض أسماء المستخدمين الشائعة في القائمة السوداء، واستخدمها كمصيدة جذب.مشرف، ضيف، الخ..لا تسمح لأي شخص بإنشاء حسابات بهذه الأسماء، لذا إذا حاول شخص ما تسجيل الدخول إليه، فاعلم أنه يفعل شيئًا لا ينبغي له فعله.

تأكد من أن أي شخص يتمتع بسلطة حقيقية على الموقع لديه كلمة مرور آمنة.مطالبة المسؤولين/المشرفين بالحصول على كلمات مرور أطول تحتوي على مزيج من الأحرف والأرقام والرموز.ارفض كلمات المرور البسيطة التافهة من المستخدمين العاديين مع شرح.

أحد أبسط الأشياء التي يمكنك القيام بها هو إخبار الأشخاص عندما يحاول شخص ما تسجيل الدخول إلى حسابهم، ومنحهم رابطًا للإبلاغ عن الحادث إذا لم يكونوا هم من قام بذلك.رسالة بسيطة عند تسجيل الدخول مثل "حاول شخص ما تسجيل الدخول إلى حسابك في الساعة 4:20 صباحًا يوم الأربعاء بلاه بلاه.انقر هنا إذا لم تكن أنت." فهو يتيح لك الاحتفاظ ببعض الإحصائيات حول الهجمات.يمكنك تكثيف إجراءات المراقبة والأمان إذا رأيت أن هناك زيادة مفاجئة في عمليات الوصول الاحتيالية.

Answer 3

إذا فهمت طريقة تنفيذ هجمات القوة الغاشمة بشكل صحيح، فسيتم تجربة اسم مستخدم واحد أو أكثر بشكل مستمر.

هناك اقتراحان لا أعتقد أنني رأيتهما هنا بعد:

• لقد اعتقدت دائمًا أن الممارسة القياسية هي الحصول على تأخير قصير (ثانية أو نحو ذلك) بعد كل تسجيل دخول خاطئ لكل مستخدم.هذا يردع القوة الغاشمة، لكنني لا أعرف إلى متى يمكن للتأخير لمدة ثانية واحدة أن يمنع هجوم القاموس.(قاموس 10000 كلمة == 10000 ثانية == حوالي 3 ساعات.همم.ليس جيدا بما فيه الكفاية.)
• بدلاً من التباطؤ على مستوى الموقع، لماذا لا يتم خنق اسم المستخدم.يصبح الخانق قاسيًا بشكل متزايد مع كل محاولة خاطئة (إلى الحد الأقصى، أعتقد أنه لا يزال بإمكان المستخدم الحقيقي تسجيل الدخول)

يحرر:ردًا على التعليقات حول خنق اسم المستخدم:هذا هو خانق محدد لاسم المستخدم بغض النظر عن مصدر الهجوم.

إذا تم تقييد اسم المستخدم، فسيتم اكتشاف أي هجوم منسق على اسم المستخدم (عناوين IP متعددة، وتخمين واحد لكل عنوان IP، ونفس اسم المستخدم).تتم حماية أسماء المستخدمين الفردية بواسطة دواسة الوقود، حتى لو كان للمهاجمين الحرية في تجربة مستخدم/تمرير آخر أثناء المهلة.

من وجهة نظر المهاجمين، قد تتمكن خلال المهلة من تخمين 100 كلمة مرور لأول مرة، واكتشاف كلمة مرور واحدة خاطئة لكل حساب بسرعة.قد تتمكن فقط من إجراء تخمينات مدتها 50 ثانية لنفس الفترة الزمنية.

من وجهة نظر حساب المستخدم، لا يزال الأمر يتطلب نفس متوسط ​​عدد التخمينات لكسر كلمة المرور، حتى لو كانت التخمينات تأتي من مصادر متعددة.

بالنسبة للمهاجمين، في أحسن الأحوال، سيكون نفس الجهد لاختراق 100 حساب كما هو الحال مع حساب واحد، ولكن نظرًا لأنك لا تقوم بالاختناق على أساس واسع للموقع، يمكنك زيادة السرعة بسرعة كبيرة.

تحسينات إضافية:

• اكتشاف عناوين IP التي تخمن حسابات متعددة - 408 مهلة الطلب
• اكتشاف عناوين IP التي تخمن نفس الحساب - 408 طلب مهلة بعد عدد كبير (على سبيل المثال 100) من التخمينات.

أفكار واجهة المستخدم (قد لا تكون مناسبة في هذا السياق)، والتي قد تعمل أيضًا على تحسين ما سبق:

• إذا كنت تتحكم في إعداد كلمة المرور، فقم بإظهار المستخدم مدى قوة كلمة المرور الخاصة بهم يشجعهم على اختيار أفضل.
• إذا كنت تتحكم في تسجيل الدخول صفحة, ، بعد عدد صغير (على سبيل المثال 10) من التخمينات لاسم مستخدم واحد، قم بتقديم اختبار CAPTCHA.

Answer 4

هناك ثلاثة عوامل للمصادقة:

1. مستخدم يعرف شيء (أي كلمة المرور)
2. مستخدم لديه شيء ما (على سبيل المثال، سلسلة المفاتيح)
3. مستخدم يكون شيء ما (على سبيل المثال، فحص شبكية العين)

عادةً ما تفرض مواقع الويب السياسة رقم 1 فقط.حتى أن معظم البنوك تطبق السياسة 1 فقط.إنهم يعتمدون بدلاً من ذلك على نهج "يعرف شيئًا آخر" للمصادقة الثنائية.(أي:يعرف المستخدم كلمة المرور الخاصة به واسم والدته قبل الزواج.) إذا كنت قادرًا، فإن طريقة إضافة عامل المصادقة الثاني ليست صعبة للغاية.

إذا كان بإمكانك إنشاء حوالي 256 حرفًا من العشوائية، فيمكنك هيكلة ذلك في جدول 16 × 16، ثم اطلب من المستخدم أن يعطيك القيمة في جدول الخلية A-14، على سبيل المثال.عندما يقوم المستخدم بالتسجيل أو تغيير كلمة المرور الخاصة به، أعطه الجدول واطلب منه طباعته وحفظه.

تكمن صعوبة هذا النهج في أنه عندما ينسى المستخدم كلمة المرور الخاصة به، كما يفعل، لا يمكنك فقط تقديم المعيار "الإجابة على هذا السؤال ووضع كلمة مرور جديدة"، نظرًا لأن ذلك عرضة للقوة الغاشمة أيضًا.وأيضًا، لا يمكنك إعادة تعيينه وإرسال بريد إلكتروني جديد إليهم، نظرًا لأن بريدهم الإلكتروني قد يتعرض للاختراق أيضًا.(يرى:Makeuseof.com ونطاقهم المسروق.)

هناك فكرة أخرى (تتضمن القطط الصغيرة)، وهي ما تسميه BOA SiteKey (أعتقد أنهم قاموا بتسجيل الاسم كعلامة تجارية).باختصار، تطلب من المستخدم تحميل صورة عند التسجيل، وعندما يحاول تسجيل الدخول، اطلب منه اختيار صورته من بين 8 أو 15 صورة عشوائية (أو أكثر).لذا، إذا قام المستخدم بتحميل صورة لقطته الصغيرة، فمن الناحية النظرية، فهو فقط يعرف بالضبط الصورة التي يملكها من بين جميع القطط الأخرى (أو الزهور أو أي شيء آخر).إن الضعف الحقيقي الوحيد الذي يواجهه هذا النهج هو هجوم الرجل في الوسط.

هناك فكرة أخرى (ولكن ليس هناك قطط صغيرة)، وهي تتبع عناوين IP التي يصل المستخدمون إلى النظام من خلالها، ومطالبتهم بإجراء مصادقة إضافية (رمز التحقق، واختيار قطة، واختيار مفتاح من هذا الجدول) عند تسجيل الدخول من عنوان لديهم ليس من قبل.أيضًا، على غرار GMail، يسمح للمستخدم بمشاهدة المكان الذي قام بتسجيل الدخول منه مؤخرًا.

تعديل فكرة جديدة:

هناك طريقة أخرى للتحقق من صحة محاولات تسجيل الدخول وهي التحقق مما إذا كان المستخدم قد جاء من صفحة تسجيل الدخول الخاصة بك أم لا.لا يمكنك التحقق من المُحيلين، حيث يمكن تزييفهم بسهولة.ما تحتاجه هو تعيين مفتاح في _SESSION var عندما يعرض المستخدم صفحة تسجيل الدخول، ثم التحقق للتأكد من وجود هذا المفتاح عند إرسال معلومات تسجيل الدخول الخاصة به.إذا لم يرسل الروبوت من صفحة تسجيل الدخول، فلن يتمكن من تسجيل الدخول.يمكنك أيضًا تسهيل ذلك من خلال إشراك جافا سكريبت في العملية، إما عن طريق استخدامها لتعيين ملف تعريف الارتباط، أو إضافة بعض المعلومات إلى النموذج بعد تحميله.أو يمكنك تقسيم النموذج إلى إرسالين مختلفين (على سبيل المثال، يقوم المستخدم بإدخال اسم المستخدم الخاص به، ثم الإرسال، ثم في صفحة جديدة يُدخل كلمة المرور الخاصة به ثم يرسل مرة أخرى.)

والمفتاح، في هذه الحالة، هو الجانب الأكثر أهمية.إحدى الطرق الشائعة لإنشاء هذه البيانات هي الجمع بين بيانات المستخدم وعنوان IP الخاص به ووقت إرسالها.

Answer 5

يجب أن أسأل ما إذا كنت قد أجريت تحليل التكلفة والعائد لهذه المشكلة؛يبدو أنك تحاول حماية نفسك من مهاجم لديه ما يكفي من التواجد على الويب لتخمين عدد من كلمات المرور، وإرسال ربما 3-5 طلبات لكل عنوان IP (بما أنك رفضت تقييد IP).ما هي التكلفة (تقريبًا) لهذا النوع من الهجوم؟هل هي أغلى من قيمة الحسابات التي تحاول حمايتها؟كم عدد شبكات الروبوت العملاقة التي تريد ما لديك؟

قد تكون الإجابة لا -- ولكن إذا كان الأمر كذلك، أتمنى أن تحصل على مساعدة من متخصص أمني من نوع ما؛لا ترتبط مهارات البرمجة (ونتيجة StackOverflow) بقوة بالدراية الأمنية.

Answer 6

لقد أجبت سابقًا على سؤال مشابه جدًا في كيف يمكنني خنق محاولات تسجيل دخول المستخدم في PHP.سأكرر الحل المقترح هنا لأنني أعتقد أن الكثير منكم سيجده مفيدًا ومفيدًا لرؤية بعض التعليمات البرمجية الفعلية.يرجى أن تضع في اعتبارك أن استخدام اختبار CAPTCHA قد لا يكون الحل الأفضل نظرًا للخوارزميات المتزايدة الدقة المستخدمة في منتهكي اختبار CAPTCHA في الوقت الحاضر:

لا يمكنك ببساطة منع هجمات DoS عن طريق تقييد التحكم وصولاً إلى عنوان IP واحد أو اسم مستخدم واحد.يا إلهي، لا يمكنك حتى منع محاولات تسجيل الدخول السريعة باستخدام هذه الطريقة.

لماذا؟ لأن الهجوم يمكن أن يمتد عبر عناوين IP وحسابات مستخدمين متعددة من أجل تجاوز محاولات الاختناق.

لقد رأيت منشورًا في مكان آخر مفاده أنه من الأفضل أن تقوم بتتبع جميع محاولات تسجيل الدخول الفاشلة عبر الموقع وربطها بطابع زمني، ربما:

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);

---

إذا كان عدد المحاولات خلال فترة زمنية معينة يتجاوز الحد المسموح به، فإما فرض التقييد أو إجبار جميع المستخدمين على استخدام كلمة التحقق (على سبيل المثال.reCaptcha) حتى يصبح عدد المحاولات الفاشلة خلال الفترة الزمنية المحددة أقل من الحد الأدنى.

// 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;
    }
}

إن استخدام reCaptcha عند عتبة معينة من شأنه أن يضمن حدوث هجوم من جبهات متعددة مصغر ولن يواجه مستخدمو الموقع العاديون تأخيرًا كبيرًا في محاولات تسجيل الدخول الفاشلة المشروعة.لا يمكنني ضمان الوقاية، حيث تم بالفعل توسيع نطاق إمكانية اختراق اختبار CAPTCHA.هناك حلول بديلة، ربما البديل من "اسم هذا الحيوان"، والتي يمكن أن تعمل بشكل جيد كبديل.

Answer 7

لتلخيص مخطط Jens في مخطط/قاعدة قواعد انتقالية للحالة الزائفة:

1. المستخدم + كلمة المرور -> الإدخال
2. تم رفض المستخدم +! كلمة المرور ->
3. المستخدم +known_IP(المستخدم) -> الباب الأمامي، // never throttle
4. المستخدم + غير معروف IP (المستخدم) -> كاتفلاب
5. (#denied > n) عبر catflaps(site) -> خنق catflaps(site) // slow the bots
6. كاتفلاب + خنق + كلمة المرور + رمز التحقق -> الدخول // humans still welcome
7. catflap + throttle + كلمة المرور + !captcha -> تم رفضه // a correct guess from a bot

الملاحظات:

• لا تخنق الباب الأمامي أبدًا.شرطة ولاية إلبونيا لديها جهاز الكمبيوتر الخاص بك في منزلك، لكنها غير قادرة على استجوابك.القوة الغاشمة هي طريقة قابلة للتطبيق من جهاز الكمبيوتر الخاص بك.
• إذا قدمت "نسيان كلمة المرور الخاصة بك؟" الرابط ، ثم يصبح حساب بريدك الإلكتروني جزءًا من سطح الهجوم.

تغطي هذه الملاحظات نوعًا مختلفًا من الهجمات عن تلك التي تحاول مواجهتها.

Answer 8

يبدو أنك تحاول الدفاع ضد القوة الغاشمة الموزعة ببطء.ليس هناك الكثير مما يمكنك فعله حيال ذلك.نحن نستخدم PKI ولا توجد تسجيلات دخول بكلمة مرور.إنه مفيد، ولكن إذا كان عملاؤك يجربون محطات العمل بين الحين والآخر، فهذا لا ينطبق بشكل كبير.

Answer 9

تنصل:أنا أعمل في شركة ذات عاملين، ولكنني لست هنا لسد هذا الأمر.وهنا بعض الملاحظات.

يمكن سرقة ملفات تعريف الارتباط باستخدام XSS وثغرات المتصفح.عادةً ما يقوم المستخدمون بتغيير المتصفحات أو مسح ملفات تعريف الارتباط الخاصة بهم.

تكون عناوين IP المصدر متغيرة ديناميكيًا وقابلة للتحايل في نفس الوقت.

كلمة التحقق مفيدة، ولكنها لا تتحقق من هوية شخص معين.

يمكن الجمع بين طرق متعددة بنجاح، ولكن الذوق الجيد هو بالتأكيد في محله.

يعد تعقيد كلمة المرور أمرًا جيدًا، وأي شيء يعتمد على كلمة المرور يعتمد بشكل حاسم على أن تحتوي كلمات المرور على إنتروبيا كافية.IMHO، كلمة المرور القوية المكتوبة في مكان فعلي آمن أفضل من كلمة المرور الضعيفة في الذاكرة.يعرف الناس كيفية تقييم أمان المستندات الورقية بشكل أفضل بكثير من معرفتهم بكيفية تحديد الإنتروبيا الفعالة في اسم كلبهم عند استخدامه ككلمة مرور لثلاثة مواقع ويب مختلفة.فكر في منح المستخدمين القدرة على طباعة صفحة كبيرة أو صغيرة مليئة برموز مرور الاستخدام لمرة واحدة.

الأسئلة الأمنية مثل "ما هو رمز مدرستك الثانوية" هي في الغالب شكل رديء آخر من "شيء تعرفه"، ومعظمها يمكن تخمينها بسهولة أو متاحة بشكل مباشر في المجال العام.

كما لاحظت، يعد تقييد محاولات تسجيل الدخول الفاشلة بمثابة مقايضة بين منع هجمات القوة الغاشمة وسهولة DoSing للحساب.قد تعكس سياسات الإغلاق العدوانية عدم الثقة في إنتروبيا كلمة المرور.

أنا شخصياً لا أرى فائدة فرض انتهاء صلاحية كلمة المرور على موقع الويب على أي حال.يحصل المهاجم على كلمة المرور الخاصة بك مرة واحدة، ويمكنه تغييرها بعد ذلك والامتثال لهذه السياسة بنفس السهولة التي تستطيعها.ربما تكون إحدى الفوائد هي أن المستخدم قد يلاحظ عاجلاً إذا قام المهاجم بتغيير كلمة مرور الحساب.والأفضل من ذلك هو أن يتم إخطار المستخدم بطريقة أو بأخرى قبل أن يتمكن المهاجم من الوصول.رسائل مثل "N محاولات فاشلة منذ آخر تسجيل دخول" مفيدة في هذا الصدد.

يأتي أفضل أمان من عامل المصادقة الثاني الذي يكون خارج النطاق مقارنة بالعامل الأول.كما قلت، تعد الرموز المميزة للأجهزة في "الشيء الذي تملكه" رائعة، ولكن العديد منها (وليس كلها) لديها حمل إداري حقيقي مرتبط بتوزيعها.لا أعرف أي حلول بيومترية "شيء أنت عليه" جيدة لمواقع الويب.تعمل بعض الحلول ذات العاملين مع موفري خدمات openid، وبعضها يحتوي على PHP/Perl/Python SDKs.

Answer 10

أعلى توصيتي هي ببساطة التأكد من أنك إبقاء المستخدمين على اطلاع من محاولات تسجيل الدخول السيئة لحساباتهم- من المحتمل أن يأخذ المستخدمون قوة كلمة المرور الخاصة بهم بجدية أكبر إذا تم تقديم أدلة على أن شخصًا ما يحاول فعليًا الدخول في حسابه.

لقد قبضت بالفعل على شخص اخترق حساب ماي سبيس الخاص بأخي لأنه حاول الدخول إلى حساب Gmail الذي قمت بإعداده له واستخدم ميزة "إعادة تعيين كلمة المرور الخاصة بي عبر البريد الإلكتروني"...الذي ذهب إلى صندوق الوارد الخاص بي.

Answer 11

1. ماذا عن طلب كلمة مرور لمرة واحدة قبل إدخال كلمة المرور العادية؟وهذا من شأنه أن يجعل من الواضح جدًا أن شخصًا ما كان يهاجم قبل أن تتاح له العديد من الفرص لتخمين كلمة المرور الرئيسية؟

2. احتفظ بإحصاء/معدل عالمي لحالات فشل تسجيل الدخول - وهذا هو مؤشر الهجوم - أثناء الهجوم، كن أكثر صرامة بشأن حالات فشل تسجيل الدخول، على سبيل المثال.حظر عناوين IP بسرعة أكبر.

Answer 12

لا أعتقد أن هناك إجابة مثالية ولكنني سأميل إلى التعامل معها على أساس محاولة إرباك الروبوتات في حالة استشعار الهجوم.

من أعلى عقلي:

قم بالتبديل إلى شاشة تسجيل دخول بديلة.يحتوي على العديد من الفراغات لاسم المستخدم وكلمة المرور والتي تظهر بالفعل ولكن واحدًا منها فقط في المكان الصحيح.أسماء الحقول هي عشوائي--يتم إرسال مفتاح الجلسة مع شاشة تسجيل الدخول، ويمكن للخادم بعد ذلك معرفة الحقول الموجودة.يتم بعد ذلك تجاهل النجاح أو الفشل حتى لا تتمكن من تجربة هجوم إعادة التشغيل - إذا رفضت كلمة المرور، فسيحصلون على معرف جلسة جديد.

يُفترض أن أي نموذج يتم إرساله مع بيانات في حقل خاطئ هو من روبوت - فشل تسجيل الدخول، وفترة زمنية، وتم تقييد عنوان IP هذا.تأكد من أن أسماء الحقول العشوائية لا تتطابق أبدًا مع أسماء الحقول الشرعية حتى لا يتم تضليل أي شخص يستخدم شيئًا يتذكر كلمات المرور.

بعد ذلك، ماذا عن نوع مختلف من رموز التحقق:لديك سلسلة من الأسئلة التي لن تسبب مشاكل للإنسان.ومع ذلك، هم لا عشوائي.عندما يبدأ الهجوم، يُطرح على الجميع السؤال رقم 1.وبعد مرور ساعة، يتم تجاهل السؤال رقم 1، ولن يتم استخدامه مرة أخرى مطلقًا ويحصل الجميع على السؤال رقم 2 وهكذا.

لا يستطيع المهاجم محاولة تنزيل قاعدة البيانات لوضعها في الروبوت الخاص به بسبب طبيعة الأسئلة التي يمكن التخلص منها.يجب عليه إرسال تعليمات جديدة إلى شبكة الروبوتات الخاصة به في غضون ساعة حتى تكون لديه القدرة على فعل أي شيء.

Answer 13

نظرًا لأن العديد من الأشخاص قاموا بتضمين اختبار CAPTCHA كآلية بشرية احتياطية، فأنا أقوم بإضافة سؤال وموضوع سابق حول StackOverflow حول فعالية اختبار CAPTCHA.

هل تم اختراق / اختراق reCaptcha / التعرف الضوئي على الحروف / هزيمته / كسره؟

استخدام اختبار CAPTCHA لا يحد من التحسينات من الاختناق والاقتراحات الأخرى، ولكن أعتقد أن عدد الإجابات التي تتضمن اختبار CAPTCHA كإجراء احتياطي يجب أن تأخذ في الاعتبار الأساليب البشرية المتاحة للأشخاص الذين يتطلعون إلى كسر الأمان.

Answer 14

يمكنك أيضًا الاختناق بناءً على قوة كلمة مرور المستخدمين.

عندما يقوم المستخدم بتسجيل أو تغيير كلمة المرور الخاصة به، فإنك تقوم بحساب تصنيف قوة لكلمة المرور الخاصة به، على سبيل المثال بين 1 و10.

شيء مثل "password" يسجل 1 بينما "c6eqapRepe7et*Awr@ch" قد يسجل 9 أو 10 وكلما ارتفعت النتيجة كلما استغرق الاختناق وقتًا أطول.

Answer 15

الإجابة الأولى التي أسمعها عادةً عند طرح هذا السؤال هي تغيير المنافذ، لكن انسَ ذلك وقم فقط بتعطيل IPv4.إذا سمحت للعملاء من شبكات IPv6 فقط، فلن تطالب بعد الآن بإجراء فحص بسيط للشبكة وسيلجأ المهاجمون إلى عمليات بحث DNS.لا تعمل على نفس عنوان Apache(AAAA)/Sendmail(MX->AAAA)/ما الذي قدمته للجميع (AAAA).تأكد من أن منطقتك لا يمكن أن تكون xferd، انتظر هل تسمح لأي شخص بتنزيل منطقتك؟

إذا عثرت الروبوتات على أسماء مضيفين جديدة لإعداد الخادم الخاص بك، فما عليك سوى إضافة بعض المعلومات غير المفهومة إلى أسماء المضيفين الخاصة بك، وتغيير عنوانك.اترك الأسماء القديمة وحتى قم بإعداد ** أسماء المصائد لشبكة الروبوت حتى تنتهي المهلة.

** اختبر سجلاتك العكسية (PTR) (ضمن ip6.arpa.) لمعرفة ما إذا كان من الممكن استخدامها للتركيز على /4 التي تحتوي على سجلات مقابل /4s التي لا تحتوي عليها.أي.عادةً ما يكون لـ ip6.arpa ~32 "."s في العنوان، لكن محاولة استخدام الأجزاء القليلة الأخيرة المفقودة قد تفلت من كتل الشبكة التي تحتوي على سجلات مقابل السجلات الأخرى التي لا تحتوي عليها.إذا أخذت ذلك أبعد من ذلك، يصبح من الممكن تخطي أجزاء كبيرة من مساحة العنوان.

في أسوأ الحالات، سيتعين على المستخدمين إعداد نفق IPv6، ليس الأمر وكأنهم سيضطرون إلى الذهاب إلى أبعد من VPN في المنطقة المجردة من السلاح...على الرغم من أن المرء يتساءل لماذا هذا ليس الخيار الأول.

كما أن Kerberos رائع أيضًا، لكن IMHO LDAP ينفخ (ما الخطأ الفني في NISPlus؟لقد قرأت أن Sun قررت أن المستخدمين يريدون LDAP ولهذا السبب أسقطوا NIS+).يعمل Kerberos بشكل جيد بدون LDAP أو NIS، ما عليك سوى إدارة المستخدمين على أساس مضيف على حدة.يمنحك استخدام Kerberos وسيلة سهلة لاستخدام PKI، إن لم تكن آلية.

Answer 16

لقد تأخرت بعض الشيء هنا ولكني كنت أفكر، بافتراض حالة صعبة - يستخدم المهاجم الكثير من عناوين IP العشوائية وأسماء المستخدمين العشوائية وكلمة مرور عشوائية تم اختيارها من قائمة تضم أكثر 10000 كلمة شعبية.

هناك شيء واحد يمكنك القيام به، خاصة إذا بدا أن النظام يتعرض للهجوم حيث أن هناك الكثير من محاولات كلمة المرور الخاطئة على النظام وخاصة إذا كانت كلمة المرور منخفضة الإنتروبيا، وهو طرح سؤال ثانوي مثل ما هو الاسم الأول لوالديك، على سبيل المثال .إذا نجح أحد المهاجمين في الوصول إلى مليون حساب محاولًا استخدام كلمة المرور "password1"، فهناك احتمال كبير أن يحصل على الكثير، لكن احتمالات حصوله أيضًا على الأسماء الصحيحة ستقلل من النجاحات بشكل كبير.