دعنا نخبرك قصة رائعة حول كيف حاولت "الأطراف الثالثة" التدخل في عملائنا ، وكيف تم حل هذه المشكلة.
كيف بدأ كل شيء
بدأ كل شيء في صباح يوم 31 أكتوبر / تشرين الأول ، اليوم الأخير من الشهر ، عندما كان الكثيرون بحاجة ماسة إلى الوقت لإغلاق القضايا العاجلة والمهمة.
أفاد أحد الشركاء ، الذي يحتفظ بالعديد من الأجهزة الافتراضية للعملاء الذين يخدمهم في السحابة لدينا ، أنه من 9:10 إلى 9:20 ، لم تقبل العديد من خوادم Windows التي تعمل على موقعنا الأوكراني في وقت واحد الاتصالات بخدمة الوصول عن بُعد ، لم يتمكن المستخدمون من الوصول إلى أجهزة سطح المكتب الخاصة بهم ، ولكن بعد بضع دقائق بدت المشكلة تختفي من تلقاء نفسها.
قمنا برفع إحصائيات قنوات الاتصال ، لكننا لم نعثر على أي اندفاعات أو أعطال في حركة المرور. نظرنا في إحصائيات العبء على موارد الحوسبة - لا توجد حالات شاذة. وماذا كان ذلك؟
ثم أبلغ شريك آخر ، يستضيف مئات الخوادم الأخرى في السحابة الخاصة بنا ، عن نفس المشكلات التي لاحظها بعض عملائهم ، بينما اتضح أن الخوادم بشكل عام متاحة (تستجيب بشكل صحيح لاختبار ping والطلبات الأخرى) ، ولكن الخدمة الوصول عن بعد على هذه الخوادم إما يقبل اتصالات جديدة أو يرفضها ، بينما كنا نتحدث عن خوادم في مواقع مختلفة ، تأتي حركة المرور إليها من قنوات نقل بيانات مختلفة.
دعونا نلقي نظرة على حركة المرور هذه. حزمة مع طلب إنشاء اتصال تصل إلى الخادم:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
يتلقى الخادم هذه الحزمة ، ولكن الاتصال مرفوض:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
هذا يعني أنه من الواضح أن المشكلة ليست ناجمة عن أي خلل في البنية التحتية ، ولكن بسبب شيء آخر. ربما يواجه جميع المستخدمين مشكلات في ترخيص سطح المكتب البعيد؟ ربما نجح نوع من البرامج الضارة في التسلل إلى أنظمتهم ، ويتم تنشيطه اليوم ، كما كان قبل عامين. XData и بيتيا?
أثناء فرزها ، تلقينا طلبات مماثلة من العديد من العملاء والشركاء.
ماذا يحدث بالفعل على هذه الآلات؟
سجلات الأحداث مليئة بالرسائل حول محاولة تخمين كلمة مرور:
عادةً ، يتم تسجيل مثل هذه المحاولات على جميع الخوادم حيث يتم استخدام المنفذ القياسي (3389) لخدمة الوصول عن بُعد ويسمح بالوصول من أي مكان. الإنترنت مليء بالروبوتات التي تفحص باستمرار جميع نقاط الاتصال المتاحة وتحاول تخمين كلمة المرور (وهذا هو السبب في أننا نوصي بشدة باستخدام كلمات مرور معقدة بدلاً من "123"). ومع ذلك ، كانت شدة هذه المحاولات في ذلك اليوم عالية للغاية.
ماذا علي ان افعل؟
هل توصي بأن يقضي العملاء الكثير من الوقت في تغيير إعدادات عدد كبير من المستخدمين من أجل التبديل إلى منفذ مختلف؟ ليست فكرة جيدة ، لن يكون العملاء سعداء. هل توصي بالسماح بالوصول فقط من خلال VPN؟ في عجلة من أمره وذعر ، رفع اتصالات IPSec لأولئك الذين لم يقوموا بتربيتهم - ربما لا تبتسم هذه السعادة للعملاء أيضًا. على الرغم من أنني يجب أن أقول ، هذا أمر خيري على أي حال ، فإننا نوصي دائمًا بإخفاء الخادم في شبكة خاصة ومستعدون للمساعدة في الإعدادات ، وبالنسبة لأولئك الذين يرغبون في اكتشاف ذلك بأنفسهم ، فإننا نشارك التعليمات لإعداد IPSec / L2TP في السحابة الخاصة بنا في موقع إلى موقع أو وضع الطريق - المحارب ، وإذا أراد أي شخص إعداد خدمة VPN على خادم Windows الخاص به ، فهو دائمًا على استعداد لمشاركة النصائح حول كيفية إعداد معيار RAS أو OpenVPN. ولكن بقدر ما كنا رائعين ، لم يكن هذا هو أفضل وقت للقيام بتثقيف العملاء لأننا كنا بحاجة إلى حل المشكلة في أسرع وقت ممكن مع أقل قدر ممكن من الإزعاج للمستخدمين.
كان الحل الذي طبقناه على النحو التالي. قمنا بإعداد تحليل مرور حركة المرور بطريقة تتبع جميع محاولات إنشاء اتصال TCP بالمنفذ 3389 وتحديد العناوين منه التي تحاول إنشاء اتصالات مع أكثر من 150 خادمًا مختلفًا في شبكتنا لمدة 16 ثانية - هذه هي مصادر الهجوم (بالطبع ، إذا كان لدى أحد العملاء أو الشركاء حاجة حقيقية لإنشاء اتصالات بالعديد من الخوادم من نفس المصدر ، فيمكنك دائمًا إضافة هذه المصادر إلى "القائمة البيضاء". علاوة على ذلك ، إذا كان في فئة واحدة شبكة C لهذه الـ 150 ثانية ، تم تحديد أكثر من 32 عنوانًا ، فمن المنطقي حظر الشبكة بالكامل. تم تعيين الحظر لمدة 3 أيام ، وإذا لم يتم إجراء أي هجمات من هذا المصدر خلال هذا الوقت ، فسيتم إزالة هذا المصدر من "القائمة السوداء" تلقائيًا ، ويتم تحديث قائمة المصادر المحظورة كل 300 ثانية.
هذه القائمة متاحة هنا: ، يمكنك بناء قوائم ACL الخاصة بك بناءً عليها.
نحن على استعداد لمشاركة الكود المصدري لمثل هذا النظام ، فلا يوجد شيء معقد فيه (هذه بعض النصوص البسيطة التي تم تجميعها في غضون ساعتين فقط "على الركبة") ، وفي نفس الوقت يمكن تكييفها ولا تستخدم فقط للحماية من مثل هذا الهجوم ، ولكن أيضًا لاكتشاف ومنع أي محاولات لمسح الشبكة:
بالإضافة إلى ذلك ، أجرينا بعض التغييرات على إعدادات نظام المراقبة ، والذي يراقب الآن عن كثب رد فعل مجموعة التحكم من الخوادم الافتراضية في السحابة لدينا لمحاولة إنشاء اتصال RDP: إذا لم يتبع رد الفعل في غضون ثانية ، هذا سبب للانتباه.
اتضح أن الحل فعال للغاية: لم تعد هناك شكاوى من كل من العملاء والشركاء ومن نظام المراقبة. يتم إدراج العناوين الجديدة والشبكات بالكامل في القائمة السوداء بانتظام ، مما يشير إلى استمرار الهجوم ، ولكنه لم يعد يؤثر على عمل عملائنا.
هناك السلامة في الأرقام
علمنا اليوم أن المشغلين الآخرين واجهوا مشكلة مماثلة. لا يزال شخص ما يعتقد أن Microsoft أجرت بعض التغييرات على رمز خدمة الوصول عن بُعد (إذا كنت تتذكر ، فقد اشتبهنا في نفس الشيء في اليوم الأول ، لكننا رفضنا هذا الإصدار قريبًا جدًا) ونعد ببذل كل ما في وسعنا لإيجاد حل بدلاً من ذلك . يتجاهل شخص ما المشكلة وينصح العملاء بالدفاع عن أنفسهم (تغيير منفذ الاتصال وإخفاء الخادم في شبكة خاصة وما إلى ذلك). وفي اليوم الأول ، لم نحل هذه المشكلة فحسب ، بل أنشأنا أيضًا بعض الأعمال الأساسية لنظام أكثر شمولية لاكتشاف التهديدات التي نخطط لتطويرها.
شكر خاص للعملاء والشركاء الذين لم يلتزموا الصمت ولم يجلسوا على ضفاف النهر في انتظار جثة العدو لتطفو على طوله يومًا ما ، لكنهم على الفور لفت انتباهنا إلى المشكلة ، مما أتاح لنا الفرصة القضاء عليه في نفس اليوم.
المصدر: www.habr.com