نعود إليكم في الجزء الثاني من درس "كيف تختار سياسة فعّالة للجدار الناري لتأمين خواديمك" لنتحدث عن المزيد من الأمور والنصائح التي يجب أخذها بعين الاعتبار عند إعداد الجدار الناري الخاصّ بخادومك لأوّل مرّة.
سياسات ICMP
هناك آراءٌ مختلفة حول ما إذا كان يجب قبول حِزَم بيانات ICMP القادمة إلى خادومك أم لا.
ICMP هو بروتوكول يستعمل لعدة أشياء، وغالبًا ما يتم إرساله مجددًا، كما رأينا سابقًا، لإعطاء معلومات عن حالة الطلبات التي تستخدم بروتوكولات أخرى. ربّما أبرز مهامه هو إرسال واستقبال نبضات الشبكة (network pings) لفحص قابلية الاتصال بالأجهزة المضيفة البعيدة. هناك عدة استخدامات غير شائغة أخرى لبروتوكول ICMP ولكنها ما تزال مفيدة.
يتم تمييز حزم ICMP عبر "النوع (type)" وبعدها عبر "الشفرة (code)"، حيث يقوم النوع بتحديد معنى الرسالة العام، كمثال، Type 3 يعني أنّ الوجهة غير قابلة للوصول، بينما يتم استخدام "الشفرة" لإعطاء المزيد من المعلومات عن “النوع”. كمثال، "ICMP Type 3 Code 3" يعني أنّ المنفذ الذي تحاول الاتصال من خلاله بوجهتك غير متوفّر، بينما "ICMP Type 3 Code 0" تعني أنّ شبكة الوجهة التي تحاول الاتصال بها غير متوفّرة بالمرّة.
الأنواع التي يمكن دوما حجبها
هناك بعض الأنواع (Types) لبروتوكول ICMP تكون مهملة طوال الوقت، لذا يجب غالبًا حجبها. من بين هذه الأنواع:
- ICMP source quench (النوع 4 و code 0)
- Alternate host (النوع 6)
الأنواع 1, 2, 7 و 15 محفوظة للاستخدام المستقبلي أو المتقدّم وليست مهمّة.
الأنواع التي يمكن حجبها اعتمادا على إعدادات الشبكة
تكون بعض أنواع ICMP مفيدة في إعدادات شبكةٍ معيّنة، ولكن يجب حجبها في بيئةٍ أخرى.
كمثال، رسائل إعادة توجيه ICMP (النوع 5 أو type 5) يمكن أن تكون مفيدة في التقاط تصميم الشبكات السيء. يتم إرسال إعادة توجيه ICMP عندما يكون هناك طريقٌ أفضل متوفّر أمام العميل. لذا إذا استقبل الموجّه (router) حزمة بيانات يجب توجيهها إلى مضيفٍ آخر على نفس الشبكة، فإنّه يقوم بإرسال رسالة إعادة توجيه عبر بروتوكول ICMP لإخبار العميل بأن يقوم بإرسال الحِزَم إلى المضيف الآخر في المستقبل.
سيفيدك هذا إذا كنت تثق بشبكتك المحلية وكنت تريد التقاط أماكن عدم الكفاءة (inefficiencies) في جداول التوجيه (routing tables) أثناء الإعداد الأوّلي (إصلاح التوجيه الخاصّ بك هو حلٌّ أفضل على المستوى البعيد). لكن على شبكة غير موثوقة، يمكن لمستخدم سيء أن يقوم بإرسال رسائل إعادة التوجيه عبر برتوكول ICMP للتلاعب بجداول التوجيه الموجودة على أجهزة المضيفين (hosts).
من أنواع ICMP الأخرى المفيدة في بعض الشبكات والمؤذية في أخرى هي حِزَم ما يعرف بـICMP router advertisement (النوع 9 أو type 9) وrouter solicitation (النوع 10 أو type 10). يتم استخدام حزم الإعلان (advertisement) والحثّ (solicitation) كجزء من IRDP (ICMP Internet Router Discovery Protocol)، وهو نظام يسمح للمضيفين - بعد الإقلاع أو الانضمام لشبكة ما - بأن بكتشفوا تلقائيًا الموجّهات (routers) المتوفّرة.
من الأفضل في معظم الحالات للمضيف أن يمتلك طرق (routes) ثابتة مُعدّة خصيصًا للبوابات التي سيستعملها. يجب أن يتم قبول هذه الحزم في نفس حالات حزم التوجيه من ICMP. في الواقع، بما أنّ المضيف لن يعرف الطرق الأكثر تفضيلًا لنقل التدفّق من بين جميع الطرق المكتشفة، فإنّ رسائل إعادة التوجيه غالبًا ما تكون مطلوبة مباشرةً بعد الاكتشاف. إذا كنت لا تشغل خدمة تقوم بإرسال حزم حثّ التوجيه (router solicitation) أو خدمة تقوم بتعديل الطرق بناءًا على حزم الإعلان (advertisement packets) مثل rdisc، فيمكنك حظر هذه الحزم بأمان.
الأنواع التي من الآمن السماح لها
ستجد أنواع ICMP الآمنة عادةً أدناه، لكن ربّما تريد تعطيلها إذا كنت تريد أن تكون في أمانٍ أكثر.
- Type 8 — Echo request: هذه هي طلبات النبضات (ping requests) الموجّهة إلى خادومك. من الآمن السماح لها بالعمل على خادومك عادةً (منع هذه الحزم لن يخفي خادومك، هناك عدة طرق أخرى أمام المستخدمين ليعرفوا ما إذا كان خادومك يعمل حاليًا أم لا)، ولكن يمكنك منعها أو تحديد عناوين مصدر هذه الحزم وتقليلها إذا كنت تريد ذلك.
- Type 13 — Timestamp request: يمكن استخدام هذه الحزم بواسطة العملاء لجمع معلومات مواجهة الأعطال. يمكن استخدامها أيضًا في بعض تقنيات التقاط بصمات نظام التشغيل، لذا يمكنك منعها إن أردت.
يمكن السماح للأنواع التالية عمومًا دون الحاجة إلى قواعد (rules) خاصّة عبر إعداد جدارك الناري ليسمح بالردود على الطلبات التي قام بإرسالها (عبر استخدام وحدة conntrack للسماح بتدفّق ESATABLISHED وRELATED).
- Type 0 — Echo replies: وهي عبارة عن الردود على طلبات النبضات (pings requests).
- Type 3 — Destination Unreachable: حِزَم بيانات الوجهة الغير متوفّرة العادية هي عبارة عن ردود طلبات تمّ إنشاؤها بواسطة خادومك، وهي تعني أنّه لم يتم توصيل حِزَم البيانات بشكلٍ صحيح.
- Type 11 — Time exceeded: هذا عبارة عن خطأ يتم إرجاعه في حال موت الحِزَم المُنشأة بواسطة خادومك قبل وصولها وجهتها بسبب تعدّيها لقيمة TTL الخاصّة بها.
- Type 12 — Parameter problem: يعني هذا أنّ حزمةً صادرة من خادومك قد تعرضت للتلف في طريقها.
- Type 14 — Timestamp responses: هي عبارة عن الردود على عمليات الاستعلام عن المنطقة الزمنية التي يتم تنفيذها بواسطة خادومك.
حجب تدفّق ICMP بأكمله ما يزال أمرًا مستحسنًا من قبل العديد من خبراء الحماية، ولكن العديد من الناس الآن ينصحون باستخدام سياسات ICMP ذكية بدلًا من منعه بالكامل.
تحديد الاتصال وتحديد التردد
في بعض الخدمات وأنماط التدفّقات (traffic patterns)، ربّما تود السماح بالوصول من قبل جهاز العميل طالما أنّه لا يسيء استخدام هذا الوصول. هناك طريقتان لتقييد استخدام الموارد: تقييد الاتصال (connection limiting) وتقييد التردد أو المعدل (rate limiting).
تقييد الاتصال
يمكن أن يتم تفعيل تقييد الاتصال عبر استخدام امتدادات مثل connlimit للتحقق من عدد الاتصالات النشطة التي قام جهاز العميل بفتحها. يمكن أن يتم استخدام هذا لتقييد عدد الاتصالات المسموحة في وقتٍ واحد. إذا كنت تخطط لاستخدام تقييد الاتصال، فيجب عليك اتخاذ بعض القرارات بخصوص هذا بغض النظر عن طريقة تطبيقك له. هذه القرارات هي:
- هل سيكون التقييد بناءًا على العنوان، الشبكة أم على أمورٍ عامّة أخرى؟
- هل سيكون التقييد لخدمة معينة فقط أم على الخادوم بأكمله؟
يمكن تقييد الاتصالات بناءًا على أجهزة الاستضافة أو شبكة معيّنة عبر استخدام بادئة شبكة ما (network prefix). يمكنك أيضًا تعيين حدٍّ أقصى لعدد الاتصالات المسموح بها لخدمة معيّنة أو للخادوم بأكمله. لا تنسى أيضًا أنّه بمقدورك استخدام جميع هذه الطرق أو بعضٍ منها لتحصل على خليط معقّد من السياسات المستعملة للتحكم في الاتصالات التي تريدها.
تقييد التردد
يسمح لك تحديد التردد أو تحديد المعدل (rate limiting) بإنشاء قواعد (rules) تقوم بإدارة تردد أو معدل التدفّق الذي سيقبله خادومك. هناك عدد من الامتدادات المختلفة التي يمكن استخدامها لتقييد التردد مثل limit، hashlimit وrecent. اختيار الأنسبة من هذه الامتدادات يعتمد على الطريقة التي تريد تقييد التردد خلالها.
سيتسبب الامتداد limit للقاعدة في السؤال بأن يتم مطابقتها إلى حين الوصول إلى الحد الأقصى، بعدها سيتم ترك أيّ حزم بيانات إضافية أخرى. إذا قمت باستخدام حد مثل “5/ثانية/، فإنّ القاعدة ستقوم بالسماح بمطابقة 5 حزم في الثانية الواحدة، بعدها، لن تسمح لأيّ حزم بأن تقوم بعملية المطابقة. هذا جيّد لتحديد الحدّ الأعلى العام لخدمة معيّنة من الحزم.
لكنّ امتداد hashlimit يعتبر أكثر مرونةً، حيث يسمح لك بتحديد بعض القيم التي سيستخدمها iptables لتحقيق عملية المطابقة كذلك. مثلًا، يمكن لـhashlimit أن يتحقق من عنوان المصدر ومنفذه، عنوان الوجهة ومنفذها أو حتّى تشكيلة من هذه القيم الأربعة لمطابقة كل مُدخَلة (entry). يمكنه أيضًا أن يقوم بالتحديد بناءًا على عدد الحزم أو البايتات المتلقاة، وهو ما يوفّر تحديدًا أكثر مرونة على مستتوى العميل أو مستوى الخدمات.
يقوم امتداد recent ديناميكيًا بإضافة عنوان IP العميل إلى قائمة بيضاء أو يتحقق من وجوده في قائمة سوداء عند مطابقة القاعدة. يسمح لك هذا باستخدام منطق أكثر تعقيدًا لإنشاء قواعد متعددة للحصول على نتيجة مبهرة. يمتلك أيضًا القدرة على تحديد العدد والوقت كالامتدادات الأخرى، ولكنه قادر أيضًا على إعادة تعيين مدى الوقت (timerange) في حال رؤية المزيد من تدفّق البيانات، حيث يجبر العميل على وقف التدفّق في حال وصوله إلى الحد الأقصى.
اختيار واحدٍ من هؤلاء لتستعمله على خادومك يعتمد بشكلٍ كامل على السياسة التي تريد تطبيقها في خادومك.
الإدارة كوحدة متكاملة مقابل الإدارة كسلسلة
جميع سياسة iptables مرسّخة في توسيع السلاسل المبنية فيه أساسًا (built-in chains). في الجدران النارية البسيطة، يكون هذا على شكل تغيير السياسة الافتراضية للسلاسل وإضافة القواعد. في الجدران النارية الأكثر تعقيدًا، غالبًا ما يكون من الجيد توسيع إطار عمل الإدارة عبر إضافة المزيد من السلاسل.
السلاسل المكوّنة من طرف المستخدمين (User-created chains) مقيّدة بطبيعتها إلى السلسلة التي تستدعيها. السلاسل المكوّنة من طرف المستخدمين لا تملك أيّ سياسة افتراضية، لذا إذا لم تنجح حزمة بيانات ما في المرور عبر سلسلة مكوّنة من طرف المستخدم، فإنّها ستعود إلى السلسلة وتتابع المطابقة. مع أخذ هذا في عين الاعتبار، تصبح السلاسل المكوّنة بواسطة المستخدم مفيدة جدًا في الأغراض التنظيمية، جعل شروط مطابقة القواعد أكثر وضوحًا ولتحسين قابلية القراءة عبر تقسيم شروط المطابقة.
إذا كنت تكرر عمليّة معينة لعددٍ كبير من القواعد، فحينها قد يكون من المفيد إنشاء "jump rule" مع العملية أو المطابقة والشروط المطلوبة المشتركة في سلسلة جديدة، يمكنك إضافة مجموعة من القواعد دون المطابقة المشتركة ضمن تلك السلسلة.
بغضّ النظر عن التنظيم البسيط، يمكن لهذا أن يفيدك بشكلٍ أكبر. مثلًا، الاستخدام الذكي للسلاسل لمجموعات متشابهة من القواعد يعني أنّ إضافة القواعد في الموقع الصحيح سيكون أسهل وأقل تعرّضًا للأخطاء. ويمكن أن يكون أسهل كذلك في عرض وفهم أجزاء السياسة التي تهتم بها عبر تحديد السلسلة.
الاختيار ما بين تضمين جميع قواعدك في واحدةٍ من السلاسل الموجودة بالفعل في الجدار الناري أو عبر إنشاء وتعديل سلاسل جديدة يعتمد بشكلٍ رئيسي لمدى التعقيد والبساطة والأهداف التي تسعى إلى تحقيقها على خادومك.
خاتمة
الآن، يفترض أنك تمتلك معرفة جيدة حول بعض القرارات التي يجب عليك اتخاذها عند تصميم سياسات الجدار الناري لخواديمك. بشكلٍ عام، الوقت الذي ستستغرقه في إعداد الجدار الناري لأوّل مرّة سيسهل مهام الإدارة عليك لاحقًا. صحيحٌ أنّ العملية ستحتاج الكثير من الوقت والخبرة والتجارب للحصول على أفضل سياسة تلائم خواديمك، ولكن القيام بهذا سيوفّر لك تحكمًا أكبر في حمايتها.
إذا كنت تريد معرفة المزيد عن الجدران النارية و iptables بالتحديد، فيمكنك التحقق من المقالات التالية:
- كيف يعمل جدار iptables الناري.
- إعداد جدار ناري باستخدام iptables على Ubuntu 14.04.
- إعداد جدار ناري باستخدام UFW على Ubuntu 14.04.
ترجمة -وبتصرّف- لـلمقال: How To Choose an Effective Firewall Policy to Secure your Servers لصاحبه Justin Ellingwood.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.