واحدة من المشاكل التي تنشأ أمام موارد WEB لها حسابات شخصية هي هجوم القوة الغاشمة. نعم ، تعداد بسيط لجميع خيارات كلمة المرور لحساب معين. بغباء؟ ربما ، ولكن مثل هذا الهجوم يمكن أن يؤدي إلى تحميل المورد بشكل كبير. بالإضافة إلى ذلك ، إذا لم يكن هناك تحكم في مدى تعقيد كلمة مرور المستخدم أثناء التسجيل ، فقد تكون ناجحة أيضًا.
في أغلب الأحيان ، يتم حل المشكلة ببساطة نسبيًا. إذا أدخل المستخدم كلمة المرور بشكل غير صحيح عدة مرات ، فسيتم حظر حسابه لبعض الوقت. الحل البديل هو عرض كلمة التحقق. على الفور ، أو بعد عدة محاولات فاشلة. حسنًا ، دعنا لا ننسى إذن 2F ، الذي يكاد يكون غير محصن. يبدو - ربح! ولكن ، ليس كل شيء وردية للغاية ...
دعونا نلقي نظرة على بعض المشاكل الموصوفة:
حظر مؤقت - يتم حظر حساب المستخدم مؤقتًا ولا يمكنه الدخول إلى النظام. يعاني المستخدم الحقيقي أثناء الهجوم من وجع وعذاب. لا يستطيع الدخول في النظام. وعلى الأرجح أنه يقوم بتحميل دعمك. والشيء الأكثر إثارة للاهتمام هو أنه ربما يكون هذا هو هدف المهاجم.
Captcha هو حل جيد وفعال نسبيًا. الحقيقة غير ملائمة للمستخدم ، مما يتطلب منك إدخال شيء هناك أيضًا. يكفي "غير سارة" لتضمينها في التصميم. أوه نعم ... لا يزال هذا الشيء ، اعتمادًا على التنفيذ ، قد يتعرض لهجوم DoS.
2F إذن - كل شيء عظيم. صحيح ... في معظم الأحيان هذا شيء اختياري. تشغيله لمواجهة الهجوم لن ينجح. هي إما هناك أو أنها ليست. وفي بعض الموارد ، أدخل إذن 2F ، دعنا نقول ، أطلق العصافير من الخزان.
أحاول إنشاء خدمات مريحة وموثوقة. لذلك ، قررت أن أجهد عقلي قليلاً. وهذا ما حدث.
إذا كنت تستخدم البريد ، على سبيل المثال mail.ru ، وكان لديك إذن 2F مثبتًا ، فربما لاحظت أن ترخيص 2F مطلوب فقط لـ "جهاز" جديد عند تسجيل الدخول الأول. علاوة على ذلك ، يعتبر الجهاز موثوقًا به. وما عليك سوى إدخال تسجيل الدخول وكلمة المرور الخاصة بك.
شيء ملائم. سهل الاستخدام ، إذا جاز التعبير. يتم تنفيذ هذا من خلال رمزين. المعرف الأول هو "جهاز" (معرّف على أنه معرف) ، والثاني هو معرف جلسة (يعرف باسم جلسة). Devid ، على عكس الجلسة ، لا يفقد أهميته حتى بعد إنهاء المستخدم للجلسة. يتم إرساله في محاولة تسجيل الدخول التالية ، وإذا كان اسم المستخدم / كلمة المرور صحيحًا ، بالإضافة إلى أنه موثوق به تمامًا ، فلن يتم طلب 2F. ولكن ، إذا فشلت محاولة تسجيل الدخول التالية ، فإن الرمز المميز سيفت على الفور. والآن تحتاج إلى اتباع المسار الكامل للتفويض.
تم أخذ هذا النموذج كأساس. أي أدخل الرمز المميز ، والذي سيتم إصداره باستمرار ، مع أي رد من مورد WEB ، بالطبع ، إذا لم يكن في الطلب.
في حالة التفويض 2F ، تم تنفيذ الخوارزمية المذكورة أعلاه بالفعل. وعلى الفور أصبح الجميع سعداء. ت. لا معنى لفحصه بالتفصيل. ولكن "الأجراس والصفير" ، من الأفضل النظر في الرسم التخطيطي مع التفسيرات:
حتى إذا لم يتم تثبيت تفويض 2F ، ولكن كان تسجيل الدخول ناجحًا ، فسيتم وضع علامة على الرمز المميز بأنه موثوق. يبدو أنه من غير المنطقي القيام بذلك دون إذن 2F. لكن ، كل شيء أكثر صعوبة. إذا علمنا أن devid موثوق به ، أي حصل على تسجيل دخول ناجح ، على الأقل نفترض أنه من هذا الجهاز جاء المستخدم الحقيقي. هذه معلومات مهمة جدًا تستخدمها الخوارزمية الموصوفة في عملها في وضع انعكاس الهجوم.
تم اعتماد استراتيجية: لا يمكن أن يحدث أي تفويض إلا إذا كان هناك رمز مميز صالح. يختلف devid الصالح عن موثوق به في أنه غير موثوق به حتى الآن ، أي لم يكن هناك تسجيلات دخول ناجحة منه ، ولكن النظام جاهز لمعالجة طلبات التفويض معها. عدد المحاولات يقتصر على N مرة لكل رمز صالح. في حالة حدوث خطأ في التفويض أكثر من N مرة على التوالي ، يتم تمييز الرمز المميز بأنه "مخترق". يتم تحويلها إلى مجلة منفصلة مع إحصاءات عن الاختيار. الطلبات بمشاركته تستمر في المعالجة ، ولكن ... لم يعد من الممكن تسجيل الدخول معه. كل ما يحدث هو تراكم إحصائيات النشاط.
لذا فإن أكثر الهجمات غباء تقاوم. على سبيل المثال ، إذا حاول مهاجم ، متجاهلاً devid ، تسجيل الدخول إلى النظام ، أو إذا لم يتمكن من فهم منطق devid (كيف يعرف عدد محاولات تسجيل الدخول التي تم تقديمها مع نفس devid؟) ، يتم إنهاء طلباته.
تعرف الجبهة الخاصة أنه بعد محاولات N الفاشلة لتسجيل الدخول من أحد الأجهزة الفاسدة ، تكون بالفعل "فاسدة". تحتاج الآن إلى الحصول على رمز مميز جديد ، قبل محاولة تسجيل الدخول التالية.
يبدو ، أي نوع من الغباء؟ الجبهة لتحقيق محاولة الدخول ... ولكن ، كما قلت أعلاه ، كل شيء أصعب. إذا كان المستخدم يعمل من خلال واجهة قياسية ، فإن احتمال محاولته مهاجمة النظام لا يكاد يذكر. مقترنًا بنظام للتحكم في تعقيد كلمة المرور أثناء تسجيل المستخدم ، هذا غير مجدي تمامًا. على الأرجح ، يحاول المستخدم الحقيقي تذكر كلمة المرور الخاصة به.
إذن ما هي الحيلة؟ في الحقيقة ، على الجانب الخلفي ، ننتج devid صالحًا جدًا مع حد زمني معين. على سبيل المثال ، لا يزيد عن 1000 جهاز كمبيوتر في الدقيقة. إذا تم تجاوز هذا الحد فجأة ، يتم قطع وضع الهجوم. وهنا يمكنك إما الذهاب بشكل جذري وإيقاف الانبعاث البطيء لبعض الوقت ، الأمر الذي سيبرد حماسة المهاجم ، أو يقلل من توليد الجسيمات الصالحة. ويمكنك تمكين نفس كلمة التحقق لجميع الأجهزة الصالحة ، ولكن غير الموثوق بها.
وبالتالي ، يتم الحصول على نظام مرن للتحكم في الهجمات وإدارتها. يتم إنشاء مقاييس موثوقة يمكن من خلالها تشغيل المراقبة تثير إنذارًا. يمكن تحويل الإحصاءات المتراكمة إلى قواعد المنع ، إلخ.
النظام الودود لأن هؤلاء المستخدمين الذين قاموا بتسجيل الدخول إليه مسبقًا ، أي وثقوا devid حتى لم يلاحظوا الهجوم. سيتم تخطيها بواسطة النظام دون أي مشاكل.
ربح الآن. هذه الخوارزمية راسخة جدًا على الموارد ذات الحمولة العالية جدًا. كانت هناك ، في جملة أمور ، محاولات DoS على الخوارزمية نفسها ، ولكن حتى هنا ثبت أنها جديرة بالاهتمام.