هذه المقالة هي الرابعة في سلسلة "كيفية التحكم في البنية التحتية لشبكتك". يمكن العثور على محتويات جميع المقالات في السلسلة والروابط هنا.

В الجزء الأول في هذا الفصل، نظرنا إلى بعض جوانب أمن الشبكات في قطاع مراكز البيانات. سيتم تخصيص هذا الجزء لقطاع "الوصول إلى الإنترنت".

الدخول إلى الإنترنت

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

عند تدقيق هذا الجزء يجب الانتباه إلى الجوانب التالية:

• تصميم
• إعدادات بي جي بي
• حماية DOS/DDOS
• تصفية حركة المرور على جدار الحماية

تصميم

كمثال لتصميم هذا القطاع لشبكة المؤسسة، أود أن أوصي به توجيه من سيسكو في الداخل نماذج آمنة.

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

تعليق

في SAFE، يعد مقطع "الوصول عن بعد" جزءًا من مقطع "الوصول إلى الإنترنت". لكن في هذه السلسلة من المقالات سننظر فيها بشكل منفصل.

المجموعة القياسية من المعدات في هذا القطاع لشبكة المؤسسة هي

• أجهزة التوجيه الحدودية
• جدران الحماية

ملاحظة 1

في هذه السلسلة من المقالات، عندما أتحدث عن جدران الحماية، أقصد NGFW.

ملاحظة 2

أتجاهل النظر في أنواع مختلفة من حلول L2/L1 أو تراكب L2 على L3 اللازمة لضمان اتصال L1/L2 وأقتصر فقط على المشكلات الموجودة على مستوى L3 وما فوق. تمت مناقشة قضايا L1/L2 جزئيًا في الفصل "التنظيف والتوثيق".

إذا لم تجد جدار الحماية في هذا الجزء، فلا ينبغي عليك التسرع في الاستنتاجات.

دعونا نفعل الشيء نفسه كما في الجزء السابقلنبدأ بالسؤال: هل من الضروري استخدام جدار الحماية في هذا الجزء في حالتك؟

أستطيع أن أقول أن هذا يبدو المكان الأكثر مبررًا لاستخدام جدران الحماية وتطبيق خوارزميات تصفية حركة المرور المعقدة. في الجزء 1 لقد ذكرنا 4 عوامل قد تتداخل مع استخدام جدران الحماية في قطاع مركز البيانات. ولكن هنا لم تعد ذات أهمية كبيرة.

مثال 1. تأخير

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

مثال 2. أداء

وفي بعض الحالات، قد يظل هذا العامل مهمًا. لذلك، قد يتعين عليك السماح لبعض حركة المرور (على سبيل المثال، حركة المرور من موازنات التحميل) بتجاوز جدار الحماية.

مثال 3. دقة

لا يزال يتعين أخذ هذا العامل في الاعتبار، ولكن مع عدم موثوقية الإنترنت نفسه، فإن أهميته بالنسبة لهذا القطاع ليست بنفس أهمية مركز البيانات.

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

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

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

المهم!

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

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

مثال

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

بالنسبة لـ BGP، ليس من الضروري أن يكون لديك أجهزة توجيه مخصصة، يمكنك استخدام أدوات مفتوحة المصدر مثل كواجا. لذلك ربما كل ما تحتاجه هو خادم أو عدة خوادم ومحول وBGP.

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

يمكن أن يكون لديك العديد من مراكز البيانات ذات الحماية الكاملة (جدران الحماية، وخدمات حماية DDOS التي يقدمها موفرو الإنترنت لديك) وعشرات أو مئات من نقاط التواجد "المبسطة" مع محولات وخوادم L2 فقط.

ولكن ماذا عن الحماية في هذه الحالة؟

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

ماذا لدينا في حالة تصميمنا.

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

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

تكوين BGP

هناك موضوعان هنا.

• الاتصال
• تكوين BGP

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

مثال 1

إذا كنت تقوم بالتبادل، وكانت الفواصل الزمنية التي تقل عن ميلي ثانية مهمة لعملائك، فبالطبع، لا يمكن الحديث عن أي نوع من الإنترنت على الإطلاق.

مثال 2

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

مثال 3

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

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

موارد مفيدة:

ripe.net
bgp.he.net

مثال

سأعطي مثالا واحدا صغيرا فقط.

لنفترض أن مركز البيانات الخاص بك يقع في موسكو، وأن لديك رابطًا واحدًا - Rostelecom (AS12389). في هذه الحالة (المنزل الفردي) لا تحتاج إلى BGP، ومن المرجح أن تستخدم تجمع العناوين من Rostelecom كعناوين عامة.

لنفترض أنك تقدم خدمة معينة، ولديك عدد كاف من العملاء من أوكرانيا، وهم يشكون من التأخير الطويل. أثناء بحثك، اكتشفت أن عناوين IP الخاصة ببعضها موجودة في الشبكة 37.52.0.0/21.

من خلال تشغيل مسار التتبع، رأيت أن حركة المرور كانت تمر عبر AS1299 (Telia)، ومن خلال تشغيل اختبار ping، حصلت على متوسط ​​RTT يتراوح بين 70 إلى 80 مللي ثانية. يمكنك أيضًا رؤية هذا على يبحث الزجاج Rostelecom.

باستخدام الأداة المساعدة whois (الموجودة على موقع rise.net أو الأداة المساعدة المحلية)، يمكنك بسهولة تحديد أن الكتلة 37.52.0.0/21 تنتمي إلى AS6849 (Ukrtelecom).

التالي بالذهاب إلى bgp.he.net ترى أن AS6849 ليس له علاقة بـ AS12389 (فهم ليسوا عملاء ولا روابط صاعدة لبعضهم البعض، ولا يوجد لديهم نظير). ولكن إذا نظرت إلى قائمة أقرانهم بالنسبة إلى AS6849، سترى، على سبيل المثال، AS29226 (Mastertel) وAS31133 (Megafon).

بمجرد العثور على المظهر العام لهؤلاء المزودين، يمكنك مقارنة المسار وRTT. على سبيل المثال، بالنسبة لشركة Mastertel، ستكون مدة RTT حوالي 30 مللي ثانية.

لذا، إذا كان الفرق بين 80 و30 مللي ثانية مهمًا لخدمتك، فربما تحتاج إلى التفكير في الاتصال، والحصول على رقم AS الخاص بك، وتجمع العناوين الخاص بك من RIPE وتوصيل روابط صاعدة إضافية و/أو إنشاء نقاط تواجد على IXs.

عند استخدام BGP، ليس لديك الفرصة لتحسين الاتصال فحسب، بل ستحافظ أيضًا على اتصالك بالإنترنت بشكل متكرر.

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

حماية DOS/DDOS

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

هناك موارد على الإنترنت يمكنها، بناءً على سجلات المعدات، رسم خرائط هجوم جميلة في الوقت الفعلي.

ومن يمكنك العثور على روابط لهم.

المفضل لدي خريطة من نقطة التفتيش.

عادةً ما تكون الحماية ضد DDOS/DOS متعددة الطبقات. لفهم السبب، عليك أن تفهم ما هي أنواع هجمات DOS/DDOS الموجودة (انظر، على سبيل المثال، هنا أو هنا)

أي أن لدينا ثلاثة أنواع من الهجمات:

• الهجمات الحجمية
• هجمات البروتوكول
• هجمات التطبيقات

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

ولذلك، فإن خط الدفاع الأول هو الحماية ضد الهجمات "الحجمية"، ويجب على مزود الخدمة أو مقدمي الخدمات لديك توفير هذه الحماية لك. إذا لم تكن قد أدركت هذا بعد، فأنت محظوظ الآن.

مثال

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

في هذه الحالة، سيتعين عليك التضحية جزئيًا بالاتصال أثناء الهجوم. لكن

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

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

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

لذلك دعونا نلقي نظرة على كيفية تنظيم خطي الدفاع الثاني والثالث (كإضافة للحماية من المزود).

لذا، فإن خط الدفاع الثاني هو التصفية ومحددات حركة المرور (الشرطة) عند مدخل شبكتك.

مثال 1

لنفترض أنك قمت بتغطية نفسك بمظلة ضد DDOS بمساعدة أحد مقدمي الخدمة. لنفترض أن هذا المزود يستخدم Arbor لتصفية حركة المرور والمرشحات على حافة شبكته.

النطاق الترددي الذي يمكن لـ Arbor "معالجته" محدود، ولا يستطيع المزود بالطبع تمرير حركة مرور جميع شركائه الذين يطلبون هذه الخدمة من خلال معدات التصفية باستمرار. لذلك، في ظل الظروف العادية، لا تتم تصفية حركة المرور.

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

مثال 2

قد لا يكون العدد الكبير بشكل غير طبيعي من حزم SYN نتيجة لهجوم فيضان SYN فقط. لنفترض أنك تقدم خدمة يمكنك من خلالها الحصول على حوالي 100 ألف اتصال TCP (لمركز بيانات واحد) في نفس الوقت.

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

على سبيل المثال، إذا كان عليك تشغيل تأكيد اتصال ssl/tls أعلى هذه الجلسات، والذي يتضمن تبادل الشهادات، فمن وجهة نظر استنفاد الموارد لموازن التحميل الخاص بك، سيكون هذا "DDOS" أقوى بكثير من مجرد "DDOS" فيضان SYN. يبدو أن الموازنين يجب أن يتعاملوا مع مثل هذه الأحداث، لكن... للأسف، نحن نواجه مثل هذه المشكلة.

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

المستوى الثالث من الحماية ضد DDOS/DOS هو إعدادات جدار الحماية الخاص بك.

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

مجلس

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

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

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

تصفية حركة المرور على جدار الحماية

دعونا نواصل المحادثة حول جدار الحماية. عليك أن تفهم أن هجمات DOS/DDOS هي مجرد نوع واحد من الهجمات السيبرانية.

بالإضافة إلى حماية DOS/DDOS، يمكننا أيضًا الحصول على ما يشبه قائمة الميزات التالية:

• جدار الحماية للتطبيق
• منع التهديدات (مكافحة الفيروسات، ومكافحة برامج التجسس، والضعف)
• تصفية URL
• تصفية البيانات (تصفية المحتوى)
• حظر الملفات (حظر أنواع الملفات)

الأمر متروك لك لتقرر ما تحتاجه من هذه القائمة.

أن تستمر

المصدر: www.habr.com