سنخبرك بقصة رائعة حول كيفية محاولة "الأطراف الخارجية" التدخل في عمل عملائنا ، وكيف تم حل هذه المشكلة.
كيف بدأ كل شيء
بدأ كل شيء في صباح يوم 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 و
Petya قبل عامين؟
أثناء فرزها ، تلقوا طلبات مماثلة من العديد من العملاء والشركاء.
وما يحدث على هذه الآلات؟
سجلات الأحداث مليئة بالرسائل حول محاولة العثور على كلمة مرور:
عادةً ما يتم تسجيل مثل هذه المحاولات على جميع الخوادم حيث يتم استخدام المنفذ القياسي (3389) لخدمة الوصول عن بُعد ويسمح بالوصول من أي مكان. الإنترنت مليء بالبوتات التي تفحص باستمرار جميع نقاط الاتصال المتاحة وتحاول العثور على كلمة مرور (لهذا السبب ، نوصي بشدة باستخدام كلمات مرور معقدة بدلاً من "123"). ومع ذلك ، كانت شدة هذه المحاولات في ذلك اليوم مرتفعة للغاية.
ماذا تفعل؟
أنصح العملاء بتخصيص الكثير من الوقت لتغيير إعدادات عدد كبير من المستخدمين النهائيين للتبديل إلى منفذ آخر؟ ليست فكرة جيدة ، لن يكون العملاء سعداء. يوصي للسماح بالوصول فقط من خلال VPN؟ في عجلة من الذعر والهلع ، لرفع اتصالات IPSec ، والذين لا يتم رفعهم منها - ربما ، هذه الابتسامة لا تبتسم للعملاء أيضًا. على الرغم من أنني يجب أن أقول ، إن هذا أمر خيري على أي حال ، إلا أننا نوصي دائمًا بإخفاء الخادم على شبكة خاصة ونحن مستعدون للمساعدة في الإعدادات ، وبالنسبة لأولئك الذين يرغبون في الفرز ، سنقوم بمشاركة إرشادات إعداد IPSec / L2TP بشكل مستقل في السحابة لدينا من موقع إلى موقع أو وضع طريق -المحارب ، وإذا كان أي شخص يريد رفع خدمة VPN على خادم ويندوز الخاص بهم ، فهم مستعدون دائمًا لمشاركة النصائح حول كيفية رفع RAS قياسي أو OpenVPN. ولكن ، بغض النظر عن مدى روعتنا ، لم يكن هذا هو أفضل وقت لإجراء العمل التعليمي بين العملاء ، حيث كان من الضروري حل المشكلة بأقل قدر ممكن من الضغط للمستخدمين في أسرع وقت ممكن.
كان الحل الذي طبقناه على النحو التالي. قمنا بإعداد تحليل لحركة مرور المرور بطريقة لمراقبة كل محاولات تأسيس اتصال TCP إلى المنفذ 3389 وحدد منها أنه في غضون 150 ثانية حاول إنشاء اتصالات مع أكثر من 16 خادمًا مختلفًا على شبكتنا - هذه هي مصادر الهجوم ( بالطبع ، إذا كان أحد العملاء أو الشركاء لديه حاجة حقيقية لإقامة اتصالات مع العديد من الخوادم من نفس المصدر ، يمكنك دائمًا إضافة هذه المصادر إلى "القائمة البيضاء". علاوة على ذلك ، إذا كان في شبكة فئة C واحدة لهذه الـ 150 تم الكشف عن أكثر من 32 عنوانًا ، ومن المنطقي حظر الشبكة بالكامل ، حيث يتم تعيين الحظر لمدة 3 أيام ، وإذا لم تحدث أي هجمات من هذا المصدر خلال هذا الوقت ، فسيتم إزالة هذا المصدر تلقائيًا من القائمة السوداء ، ويتم تحديث قائمة المصادر المحظورة كل 300 ثانية.
تتوفر هذه القائمة هنا على هذا العنوان:
https://secure.tucha.ua/global-filter/banned/rdp_ddos ، يمكنك إنشاء قوائم ACL الخاصة بك على أساسها.
نحن على استعداد لمشاركة الكود المصدري لهذا النظام ، لا يوجد شيء معقد للغاية (هذه بعض النصوص البسيطة المكتوبة حرفيًا في بضع ساعات "على الركبة") ، وفي الوقت نفسه يمكن تكييفها واستخدامها ليس فقط للحماية من مثل هذا الهجوم ، ولكن أيضًا لتحديد وحظر أي محاولات فحص الشبكة:
اتبع هذا الرابط.بالإضافة إلى ذلك ، قمنا بإجراء بعض التغييرات على إعدادات نظام المراقبة ، والتي تراقب عن كثب الآن رد فعل مجموعة التحكم في الخوادم الافتراضية في السحابة الخاصة بنا لمحاولة تأسيس اتصال RDP: إذا لم يتبع التفاعل لثانية واحدة ، فهذه مناسبة للفت الانتباه.
تبين أن الحل فعال للغاية: لم تعد هناك شكاوى من العملاء والشركاء ، وكذلك من نظام المراقبة. تتضمن "القائمة السوداء" بانتظام عناوين جديدة وشبكات كاملة ، مما يشير إلى أن الهجوم مستمر ، ولكنه لم يعد يؤثر على عمل عملائنا.
وحده في هذا المجال ليس محارب
علمنا اليوم أن المشغلين الآخرين واجهوا مشكلة مماثلة. لا يزال هناك شخص ما يعتقد أن Microsoft أجرت بعض التغييرات على رمز خدمة الوصول عن بُعد (إذا كنت تتذكر ، فقد شككنا في نفس الشيء في اليوم الأول ، لكننا رفضنا هذا الإصدار قريبًا جدًا) ونتعهد ببذل كل ما في وسعنا ل ايجاد حل قريبا. يتجاهل شخص ما المشكلة ببساطة وينصح العملاء بحماية أنفسهم (تغيير منفذ الاتصال ، وإخفاء الخادم على شبكة خاصة ، وما إلى ذلك). وفي اليوم الأول ، لم نحل هذه المشكلة فحسب ، بل أنشأنا أيضًا بعض الأسس لنظام عالمي أكثر للكشف عن التهديدات ، نخطط لتطويره.
شكر خاص للعملاء والشركاء الذين لم يلتزموا الصمت ولم يجلسوا على ضفة النهر توقعًا أن تطفو جثة العدو عليها ذات يوم ، وحولت انتباهنا على الفور إلى المشكلة ، التي أتاحت لنا الفرصة للقضاء عليها في نفس اليوم.