مؤتمر القبعة السوداء. الدروس المستفادة من النجاة من هجوم DDOS بمقدار 300 جيجابت / ثانية. الجزء 1كان الشيء المثير للاهتمام حول هذا الهجوم أننا لم نجرؤ على الهجوم بشكل مباشر ، بل ذهبنا إلى جانب سلسلة مزودينا. لقد بدأوا في مهاجمة مقدمي خدمات التنقيب عن النفط الذين يقعون فوق CloudFlare ، وكان مصدر الهجوم بالفعل في لندن. في البداية لم أكن متأكدة من ذلك ، لكن بما أن Spamhaus كان في لندن أيضًا ، فربما أراد القراصنة وضعهم في وضع مخزٍ. كما قلت ، بدا أن الملهم التقني للهجوم كان مراهقًا من لندن ، وربما بهذه الطريقة يمكنه تتبع تأثير هجومه بشكل أكثر فعالية. تعرض هذه الشريحة مسار حركة المرور عبر الحدود (BGP) ، والذي تضمن بحد أقصى 30 عقدة عبور للقفزة التالية.
أخفيت امتدادات عناوين مزود النطاق العريض في لندن ، والقفزة الأخيرة هي أحد عناوين Spamhaus IP ، وكانت هناك عدة في شبكتنا. ترى كيف تم توجيه حركة المرور ، من الصعب تحديد المسار الدقيق من البيانات المذكورة أعلاه ، ولكن تم إرسالها إلى أجهزتنا في لندن ، حيث حصلت على 17 مللي ثانية بعد اجتياز عنوان IP الحدودي لشبكتنا ، والتي عملت في لندن.
في البداية ، هاجم المهاجم هذا العنوان المميز بسهم ، وبما أن DNS الموزع يستخدم هنا ، فقد ضرب لندن قليلاً ، إلى أمستردام وفرانكفورت قليلاً ، إلى الولايات المتحدة الأمريكية وآسيا والقليل إلى أستراليا. ثم أدرك القراصنة أن الهجوم كان مبعثرًا وغير فعال ، وقرر تسلق سلسلة التوجيه على أجزاء إضافية من البنية التحتية. لذلك ، بعد عنوان IP الأخير ، انتقل إلى عنوان IP قبل الأخير. مرة أخرى ، إذا كنت لا تعرف كيفية عمل التوجيه والاتصال بالإنترنت ، فسنقول جزئياً أن حركة المرور يتم تبادلها مباشرة بين الشبكات عندما أقوم بتوصيل شبكتي مباشرة بشبكة أخرى. في هذه الحالة بالذات ، تدخل حركة المرور شبكتنا من شبكة Sky ، مروراً بما يعرف بـ London Internet Exchange أو LINX.
بدأ المهاجمون في المرور بأطنان من المرور عبر LINX كميناء. لدينا منفذ في LINX مع إمكانات متواضعة نسبيًا ، لذلك إذا قمت بإرسال 300 gig من حركة المرور إلى منفذ LINX ، فإنك تفرط في تحميل منفذنا والمنافذ الأخرى في هذا التبادل. لذلك كان الحل الأكثر منطقية بالنسبة لنا هو إسقاط الاتصال عبر هذا المنفذ ، بمجرد أن رأينا أنه تعرض للهجوم ، وأن "حركة المرور" تدفقت حوله بطرق أخرى.
كانت المشكلة أن هناك أضرارًا جانبية أضرت بمنافذ LINX الأخرى ، بحيث واجه مقدمو خدمات شبكات الإنترنت الكبيرة الأخرى مشكلات لأننا أسقطنا حركة المرور. كان هذا غير سارة إلى حد ما ، وبعد ذلك عملنا معهم لمساعدتهم على حماية شبكاتهم.
تسبب الهجوم في حدوث انتهاكات إقليمية مؤقتة ، ولكن أتيحت لنا فرصة جيدة لإعادة توجيه حركة المرور إلى العقد الأخرى من أجل خلق القدرة على البقاء على اتصال عبر Spamhaus وجميع عملائنا الآخرين. أثر المهاجمون أيضًا على مزودي خدمات النقل العليا لدينا ، حيث أرسلوا مجموعة كاملة من الزيارات إلى الأشخاص الذين أبرمنا معهم عقودًا لخدمات الشبكة. كان هدفهم هو إحداث أكبر قدر من الإزعاج لعملائنا ، بحيث تأثرت أجزاء من البنية التحتية للشبكة التي لم تكن مرتبطة مباشرة بشبكتنا.
من المحتمل أن تصل الهجمات إلى مستوى أعلى ، ومع ذلك ، ليس لدي بيانات تؤكد ذلك ، لكنها هاجمت أجهزة التوجيه الأساسية التي تعمل في جوهر الشبكات المختلفة. في الواقع ، كان هذا الهجوم بمثابة خدعة عملاقة ليس فقط لشبكتنا ، ولكن أيضًا للشبكات التي أحاطت بنا ، ومقدمي الخدمة الذين استخدمناهم ومقدمي الخدمات الذين استخدموهم. اتضح أنه بفضل هذا الهجوم أجرينا مراجعة نقاط الضعف لدينا. في وقت لاحق ، ذهبنا إلى مختلف عمليات التبادل عبر الإنترنت مثل لندن وقمنا بتنفيذ أفضل الحلول من حيث إنشاء شبكاتهم من أجل زيادة فعالية معارضة مثل هذه الهجمات. لقد وجدنا أنه لا ينبغي توجيه كل حركة مرور المؤسسة الداخلية عبر أجهزة توجيه حافة الشبكة. وبالتالي ، إذا كنت لا ترغب في الدخول في أحد هذه التبادلات داخل شبكة تبادل الإنترنت ، فلا ينبغي توجيه عنوان IP الخاص به من خلال هذه التبادلات. من الناحية المثالية ، يجب عليك استخدام 192.168 ، أحد عناوين RFC 1918 التي لا يمكن حلها والتي لا يمكن توجيهها وتمرير حركة المرور من خلالها ، أي ، شبكة لا تتطلب الوصول الخارجي للعمل. هذا هو أفضل شيء يمكنك القيام به لمواجهة مثل هذا الهجوم.
هناك أشياء أخرى يمكنك القيام بها ، مثل التوجيه الداخلي لـ Next Hop Self ، للتأكد من أن حركة المرور المخصصة للإرسال داخل الشبكة لن تستخدم الحزم الواردة من الخارج. لا ينبغي عليك القيام بهذا فقط لشبكتك الخاصة ، ولكن يجب عليك أيضًا إقناع مقدمي خدمات التنقيب والانتاج بالقيام بالمثل.
هناك شيء آخر مفيد - تصفية الحدود لعنوان IP محدد ، بناءً على فهم كيفية تشغيل تطبيقنا. على سبيل المثال ، يعمل تطبيقنا مع بروتوكولات مختلفة ، وإذا رأينا حزمة UDP غير مخصصة لخادم DNS الخاص بنا ، فقد حدث خطأ ما.
منذ ذلك الحين ، قمنا بتقسيم شبكاتنا بطريقة تختلف عن عناوين IP لخوادم الويب عن عناوين IP لخوادم DNS ، ويمكننا أن نطلب من مزودي خدمات التنقيب عن العمل حظر كتلة جميع زيارات UDP القادمة إلى عنوان IP المحدد هذا لضمان أمن قطاع شبكتنا. هذا الفصل في العناوين سمح لنا بإجراء تصفية أكثر عدوانية لحركة المرور عالية المستوى.
مرشح BGP Flowspec هو صديقنا الحقيقي ؛ إنه البروتوكول الذي اقترحته Cisco. على الرغم من وجود خلل فيه ، فإننا نستخدم هذا البروتوكول ونفضل أن يستخدمه مزودو خدمات النقل أيضًا ، لأنه يسمح لنا بنقل قواعدنا إلى عقد الشبكة البعيدة التي تؤثر على طرقنا. هذا يسمح لك بالرد بسرعة على مثل هذا الهجوم.
تستحق بنية nLayer ثلاثية المستويات إشارة خاصة ، وأود أن أعرب عن امتناني العميق لمبدعيها من GTT ، الذين قاموا بعمل هائل لجعل شبكتهم مقاومة بشكل خاص للهجمات. بمجرد أن رأوا قمم هذا الهجوم ، ضربوا حركة المرور بسرعة حتى من حدود شبكتهم. هل سبق لك أن تساءلت عن مدى روعة أن تكون مزود Tier-1 أو Layer3 أو NTT؟ كل عملهم هو عطلة نهاية أسبوع قوية ، لأن مزودي الدرجة الأولى لا يدفعون أي شخص مقابل الاتصالات ، وهذا يعني أيضًا أنهم لا يستطيعون نقل العبور إلى أي شخص. عندما بدأنا في منع الهجوم عن طريق فصل قطاعات من شبكتنا ، تركز التأثير على عدد صغير من مزودي المستوى 1 الذين كانوا في مركز الهجوم ، و "ثقب أسود" تم تشكيله داخل شبكتهم ، والتي اندفعت إليها جميع حركة المرور ، لأنه لم يكن هناك مكان للذهاب إليه . لذلك كان اختبارًا صعبًا للعديد من مزودي المستوى الأول.
هذا أحد الأسباب التي دفعتك إلى رؤية مشروع Open Resolver Project الذي تم إنشاؤه يوم الاثنين الأول بعد الهجوم. إن اللاعبين من nLayer هم حقًا فريق ماهر في التكنولوجيا وساعدونا كثيرًا. لقد عاملونا بفهم ، ولم يقلوا فقط: "أخرج من هنا ، فأنت تخلق الكثير من المشكلات بالنسبة لنا". لذلك ، قمنا بتطوير خطوات عملية يمكنك اتخاذها للتأكد من أن شبكاتك آمنة.
هذه أربع توصيات ، أولها تبدو سخيفة ، ولكنها واضحة: تأكد أولاً من أنك لست جزءًا من المشكلة! أعتقد أن الكثير من الناس أخبروك بهذا في السنوات الأخيرة. توقف فقط لمدة ثانية على الأقل وتحقق من أن هذين المكونين لا يعملان على شبكتك.
الأول هو محللات مفتوحة. إذا كانت موجودة في مساحة عنوان IP للشركة ، وإذا استخدمها عملاؤك ، فأنت بحاجة إلى حظرها أو الحد من سرعة حركة المرور. من الأفضل تكوين أدوات حل بحيث تقبل فقط حركة المرور التي تأتي مباشرة من شبكتك.
في هذه الشريحة ، ترى مقالتي المفضلة عن السجل ، الذي كتبه تريفور بوت. يطلق عليه "التعرف على أخصائي تكنولوجيا المعلومات: كيف ساعدت أكبر هجوم DDoS."
يكتب تريفور: "اعتقدت أنني كنت أفعل كل شيء بشكل صحيح. لكن اتضح أن لدي محلل مفتوح ، ورأيت من خلال سجلات المرور كيف وصلت الطلبات إلى Spamhouse. " أعلم أن هناك أشخاصًا مسؤولين عن تشغيل شبكات كبيرة جدًا تحتوي على حل DNS مفتوح. من خلال القيام بذلك ، أنت تساهم في خلق المشكلة المذكورة أعلاه ، لذلك أنا أطلب منك أن تقضي حرفيًا ثانية من الوقت والتخلص منها.
ثانياً ، تأكد من أنك تستخدم BCP38. قام الرجال من شبكة iBall بعمل رائع ، ولكن يعتقد الكثير من الأشخاص الذين يقدمون الشبكات الكبيرة هنا أن الشبكة مغلقة إذا لم يسمحوا بالوصول الخارجي.
ومع ذلك ، لنفترض أن لديك خادم WordPress واحد معرض للخطر على شبكتك يمكنه بدء خداع حزم المصادر غير المخصصة لشبكتك ، وسيؤدي ذلك إلى مشكلة كبيرة لبقية الإنترنت.
المشكلة هي حل مفتوح ، فهناك 28 مليون حل ، يزداد عددها كل أسبوع. لا يمكننا هزيمة هذه المشكلة إلا من خلال الجهود المشتركة. يجب عليك تعيين علامات على أجهزة التوجيه الحدودية الخاصة بك والتي تضمن أنها لا تتلقى سوى الحزم من مصادر موثوق بها داخل شبكتك. إذا قمت بذلك ، فحرم المهاجمين من فرصة استغلال هذه الثغرة الأمنية. تكمن الصعوبة في اكتشاف الأجهزة الكبيرة المعرضة للخطر والتي تعمل على الشبكات والتي تسمح بالتحايل.
إذا نظرت إلى هجمات القوة الغاشمة على WordPress ، وهناك هجمات أخرى هناك ، على سبيل المثال ، باستخدام شبكة الروبوتات ، فسيصعب عليك تخمين أن السبب بالتحديد هو القدرة على استخدام الخداع.
توصية أخرى هي استخدام بروتوكولات موثوقة حقا. يمكنك القول: "مرحبًا ، لقد حصلت على عنوان IP هذا وابدأ الخدمة باستخدام UDP ، وتستخدم الخدمة TCP وحركة مرور أخرى عبر ICMP ، وسأربط جميع هذه البروتوكولات مع نفس IP." أريد أن أحذرك من أنه في حالة نشوء مشكلة تحد من قدرتك على الاستجابة بمرونة لهذا النوع من الهجوم ، خاصةً أنه يمكنك بسهولة تقسيم الشبكة بحيث يعمل كل بروتوكول على عنوان IP الخاص به. الأفضل إذا كنت تستطيع تصفية حركة المرور المنبع. ليس الغرض من أي من هذه الهجمات هو إيقاف حركة المرور داخل شبكتك ، ولكن لحظرها في أقرب وقت ممكن من مصدر حركة المرور ، لذلك ، من خلال منح شخص ما فرصة لحظر جميع حركة مرور UDP الموجهة إلى كل IP ، باستثناء العنوان المحدد ، سوف تقلل بشكل كبير من سطح الهجوم. والتي يمكن استخدامها من قبل المهاجم.
وبالتالي ، فإن البروتوكولات المنفصلة لعناوين IP الفردية تعمل بفعالية عند التفاعل مع مقدمي الخدمات الأولية. أنت فقط أسألهم السؤال: "مهلا ، هل يمكنك تنفيذ هذه الأنواع من التصفية؟". بالمناسبة ، أحد أسباب دعمنا لـ Flowspec ، كموردين ، هو أنه يمكننا أن نسألهم بحق: "أيها الرجال ، هل تؤيد Flowspec؟" ، وإذا أجابوا بـ "نعم" ، فإن المحادثة انتهت ، و يمكننا نشر مرشحاتنا الخاصة على حافة الشبكة بأسرع ما نريد.
التوصية الثالثة هي تنفيذ البنية التحتية ACL ، أي استخدام قوائم التحكم في الوصول. أعني ، لا يمكن توجيه حزمة لشبكتك الداخلية إذا كان مصدرها لا ينتمي إلى هذه الشبكة الداخلية. إذا كانت الحزمة تأتي من شبكتك أو تدخل شبكتك من جهاز توجيه حافة ، فيجب ألا "تنتقل" عبر البنية التحتية لشبكتك الداخلية. هناك العديد من الطرق لتنفيذ هذا الحكم. يمكنك تطبيق التصفية لمنع بعض عناوين IP من الوصول إلى حدود الشبكة ، ويمكنك استخدام التوجيه التالي لـ Hop Hop لمنع الوصول إلى بعض العناوين الداخلية ، ويمكنك استخدام بروتوكولات RFC 1918 داخل الشبكة للتأكد من أن عناوين IP الداخلية الخاصة بك ليست كذلك تستخدم لمعالجة من العالم الخارجي.
قد يؤدي هذا بالفعل إلى حدوث صداع إضافي ، لأنه يفرض عليك التحقق من إعدادات جهاز التوجيه ، واستخدام شبكة VPN بالفعل ، بدلاً من التظاهر باستخدامه ، وما إلى ذلك. هذه ليست الحلول الأكثر شيوعًا ، ولكن إذا لم يتم تنفيذها ، فيمكن للمهاجم أن ينظر إلى شبكتك ويستهدف شرائحها الفردية من أجل إلحاق المزيد من الضرر.
التوصية الرابعة هي أنه يجب عليك معرفة حركة المرور في المنبع بشكل جيد. أريد أن أؤكد مرة أخرى أن هذا الهجوم لم يستخدم تطبيقات معقدة أو حزم مزامنة ، كان مجرد رجل الكهوف مع نادي ثقيل. بطريقة ما ، يجب أن يكون لديك عبور أكثر من الرجل السيئ. يمكن أن يولد 300 جيجابت في الثانية من حركة المرور ، وأنا متأكد من أن القليل من الحاضرين يمكنهم التباهي بالشبكات التي تحتوي على مثل هذا الحجم من حركة المرور. هذا يعني أنه يجب أن يكون لديك صديق لديه الكثير من حركة المرور الصادرة ، وجذب له للتعاون ، وتغطي ظهرك من مثل هذا الهجوم. نحن انتقائيون جدًا بشأن حركة المرور الصادرة التي نعمل بها حتى نتمكن من ملاحظة أي هجوم من هذا النوع في الوقت المناسب.
في اليوم الآخر ، تحدثت مع المدير الفني الرئيسي لمزود خدمات النقل العام الرئيسي وسألته عما إذا كان سيبيع لي العبور ، فأجاب - لا يا شباب ، من هذا ، ستحصل فقط على صداع إضافي كعملاء.
ومع ذلك ، فإننا نبحث عن مثل هذه الحركة وحتى ندفع لمزودي العلاوات مكافآت العبور التي نستخدمها ، لأنه عندما تحدث هجمات من هذا النوع ، نريد أن نكون قادرين على الاتصال بهم وطلب المساعدة لتخفيف عواقب الهجوم. لا تحتاج إلى إنشاء شبكات بإنتاجية 3-4-5 تيرابايت ، إذا كان يمكنك توزيع ذروة حركة المرور بين الشبكات الشريكة.
لا يتعين أن تكون هذه شركات تتمتع بحماية قوية لـ DDoS ، بل تحتاج فقط إلى استخدام بنية nLayer للقيام بعملها حقًا ومساعدتك عندما تنشأ مشاكل. العمل عن قرب معهم لتوسيع حدود شبكتك. استخدم سياسة تكوين الشبكة التي تسمح لك بالانضمام إلى حدود شبكاتها ، والمزودون مستعدون للقيام بذلك إذا كان لديك مزودو شبكة مختصون. هذه هي القصة الكاملة حول 300 غيغابت الهجوم ، لدينا حوالي 10 دقائق المتبقية للرد على أسئلتك.
أطلب منك استخدام ميكروفون إذا وافقت على الوقوف في طابور لطرح سؤال. هناك ابتكار آخر نسيت أن أقوله حوله: يريد منظمو Blackhat الحصول على ملاحظات مع المتحدث ، وإذا قمت "بإضاءة" شارتك من الخارج ، فسوف ينقلون معلوماتك إلى NSA ويتلقون أيضًا تعليقات. لقد مزجت عن الجزء الأول ، لكن الثاني قريب وصحيح - يمكنك استخدام الملاحظات ، لذلك يمكنك الاتصال بي احمق وطرح أي أسئلة بشكل عام.
السؤال: ما بروتوكولات التضخيم ، بالإضافة إلى UDP و 53 ، التي واجهتها أثناء تشغيل CloudFlare؟
الإجابة: أنت تسأل ، هل كانت هناك بروتوكولات تضخيم أخرى غير تلك المذكورة؟ ما زلنا نلاحظ استخدام ICMP في تنفيذ هجوم Smurf القديم الجيد ، ولكن لا يوجد ما يشبه حجم الهجوم الذي أخبرتك عنه. لذا ، سنصر في العام المقبل بشكل قاطع على عدم استخدام الأشخاص للمحللات المفتوحة ، ولكنهم يستخدمون خادم DNS شرعيًا ومصرحًا. استخدم CloudFlare أو Bind أو UltraDNS لبدء شبكاتك ، وإذا كنت تستطيع سرد جميع المجالات التي يكون الخادم المعتمد مسؤولاً عنها ، ابحث عن المجالات التي تحتوي على قوائم كبيرة جدًا من الأسماء ، فيمكنك حماية شبكتك ، لأن مثل هذا الخادم يمكن أن يحدد إذا لزم الأمر سرعة المرور. لقد كرسنا الكثير من الوقت لتنفيذ هذا الحل ، وسيسعدني أن أقول ذلك لأولئك المهتمين حقًا.
سؤال: لم يتم استخدام الروبوتات في هذا الهجوم ، لكن هل يمكنك التوصية بالموارد التي تتيح لك اكتشاف ما إذا كانت الشبكات الكبيرة التي تتحكم فيها تستخدم الروبوتات لتنفيذ هجوم DDoS؟
الإجابة: يعتمد ذلك على مكان وجودك - على سبيل المثال ، يمكنك البحث عن هذه الأدوات في المؤسسات التي تراقب سلوك الروبوتات وتجد أداة تناسب احتياجاتك. إذا كنت بحاجة إلى مشروع مفتوح المصدر ، فإنني أوصي بـ Honeypot ، والذي ظهر قبل بضع سنوات. من خلاله ، نقوم بمراقبة جزء كبير من شبكات الروبوتات العالمية بشكل فعال ، ويمكنك تحديد نطاق عناوين IP الخاصة بك وسيظهر ما إذا كانت هناك شبكات خبيثة هناك. هذا هو واحد فقط من العديد من هذه المشاريع. يمكنك ببساطة البحث عن أنماط لحركة المرور غير الطبيعية التي تحدث على شبكتك ، لذلك إذا رأيت غيغابت من حركة المرور التي تذهب إلى عنوان IP نفسه ، وليس هناك سبب معقول وراء حدوث ذلك في وقت معين ، فمن المحتمل أن تأتي هذه الحركة ليس من خادم الويب ، ولكن من شبكة الروبوتات. هذا يجب أن يجعلك مشبوهة.
السؤال: لدى Google أحد أكثر حلول DNS المفتوحة شعبية ، ألا تعتقد أن هذا يمكن أن يسبب مشاكل؟
الإجابة: لقد قاموا بالكثير من العمل للحد من حركة المرور ، وأفضل طريقة للتحقق من ذلك هي استخدام نفس طلب digANY كما أعطيتك كمثال ، واستبدال عنوان IP الخاص بشبكة PCCW بـ 888. أي من الحاضرين يمكنهم إرسال هذا الطلب فقط مرات ، لن يكرر ذلك. . , – UDP, , , , .
: , BGP Flowspec, , , , , , BGP Flowspec?
: , BGP Flowspec, - Cisco, . , , , . , Flowspec , . , Juniper, Flowspec. , 12 Cisco .
: Flowspec CloudFlare?
: , . , , Flowspec. , . , Flowspec, , . , , upstream-.
: CloudFlare, . , - , . , : «, »?
: , , . , , , , . , DDoS- , , 300 / . , Akamai, . , , «», , . , , .
, , , , . , , , . , , Akamai, Amazon, CloudFlare, Google, , , . , , ?
: , BC38, , DNSSec…
: , DNSSec!
: , , DNSSec, , ?
: . , DNSSec , . ? . , , – DNSSec , . , DNSSec, , , DNS-, .
DNSSec, , , , DNSSec. , Cloudflare, DNS, , . DNS- .
: upstream- ? .
: , , , upstream-. , . CloudFlare , , .
, , , - . , DNS DDoS: , , , .
: , DDoS- , , ?
: , !
, , , , .
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المواد المثيرة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30٪ لمستخدمي Habr على تناظرية فريدة من خوادم الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1 جيجابت في الثانية من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر خيارات مع RAID1 و RAID10 ، ما يصل إلى 24 مركزًا وما يصل إلى 40 جيجابايت من ذاكرة DDR4).
VPS (KVM) E5-2650 v4 (6 مراكز) 10GB DDR4 240GB SSD بسرعة 1 جيجابت في الثانية حتى الربيع مجانًا عند الدفع لمدة نصف عام ، يمكنك طلبها
هنا .
ديل R730xd 2 مرات أرخص؟ لدينا فقط
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD بسرعة 1 جيجابت في الثانية 100 TV من 249 دولارًا في هولندا والولايات المتحدة الأمريكية! اقرأ عن
كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟