المقدمة
استخدام جدار ناري يتعلق بقدرتك على اتخاذ قرارات سياسات ذكية بقدر ما يتعلق بتعلم الصيغة. الجدران النارية مثل iptables مصممة لفرض السياسات من خلال تفسير القواعد التي حددها المسؤول. ومع ذلك، كمسؤول، تحتاج إلى معرفة أنواع القواعد التي تُحسن بنية البنية التحتية الخاصة بك.
في حين تركز الأدلة الأخرى على الأوامر اللازمة للبدء في التشغيل، سنناقش في هذا الدليل بعض القرارات التي ستضطر لاتخاذها عند تنفيذ جدار ناري. ستؤثر هذه الاختيارات على كيفية سلوك جدار النار الخاص بك، وعلى مدى إغلاق الخادم الخاص بك، وعلى كيفية استجابته لظروف متنوعة تحدث. سنستخدم iptables كمثال محدد، ولكن معظم المفاهيم ستكون قابلة للتطبيق على نطاق واسع.
اتخاذ قرار بشأن السياسة الافتراضية
عند بناء جدار حماية، إحدى القرارات الأكثر أهمية هي السياسة الافتراضية. تحدد هذه السياسة ما يحدث عندما يتم عدم تطابق حركة المرور مع أي قواعد أخرى. بشكل افتراضي، يمكن لجدار الحماية أن يوافق على أي حركة مرور غير مطابقة مع القواعد السابقة، أو يمكنه إسقاط تلك الحركة.
الإسقاط الافتراضي مقابل القبول الافتراضي
A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.
البديل هو سياسة افتراضية للإسقاط. وهذا يعني أن أي حركة مرور غير مطابقة لقاعدة صريحة لن يسمح بها. يجب أن يتم السماح صراحة بكل خدمة، والتي قد تبدو وكأنها كمية كبيرة من التكوين الأولي. ومع ذلك، فهذا يعني أن سياستك تميل نحو الأمان وأنك تعرف بالضبط ما يسمح بتلقي حركة المرور على خادمك. أيضًا، تتبع تقريبًا جميع السياسات المُعدة مسبقًا هذا النهج، مما يعني أنه يمكنك الاعتماد على القيم الافتراضية الموجودة.
سياسة الإسقاط الافتراضية مقابل قاعدة الإسقاط النهائي
اختيار سياسة الإسقاط الافتراضية يؤدي إلى قرار آخر ذو طابع خفي. باستخدام “iptables” وبرامج الحماية الأخرى المماثلة، يمكن تعيين السياسة الافتراضية باستخدام وظيفة السياسة المدمجة في جدار الحماية، أو تنفيذها عن طريق إضافة قاعدة إسقاط عالمية في نهاية قائمة القواعد.
الفرق بين هذين الأسلوبين يعتمد على ماذا سيحدث إذا تم تفريغ قواعد جدار الحماية.
إذا تم تعيين وظيفة السياسة المدمجة في جدار الحماية الخاص بك على القيمة “DROP” وتم تفريغ قواعد جدار الحماية (إعادة التعيين)، أو إذا تمت إزالة بعض قواعد المطابقة، فسوف تصبح خدماتك غير متاحة عن بُعد فورًا. وهذه فكرة جيدة في كثير من الأحيان عند ضبط السياسة للخدمات غير الحرجة، حتى لا يتعرض الخادم الخاص بك لحركة مرور ضارة إذا تمت إزالة القواعد.
العيب في هذا النهج هو أن خدماتك ستكون غير متاحة تمامًا لعملائك حتى تعيد تأسيس قواعد الاستضافة. يمكن أن تؤدي إلى قفل نفسك خارج الخادم إذا لم يكن لديك وصول محلي أو عن بُعد عبر الويب كبديل.
البديل لضبط سياسة الإسقاط باستخدام وظيفة السياسة المدمجة هو ضبط السياسة الافتراضية لجدار الحماية الخاص بك على القيمة “ACCEPT” ثم تنفيذ سياسة الإسقاط بواسطة قواعد منتظمة. يمكنك إضافة قاعدة جدار حماية عادية في نهاية سلسلة القواعد الخاصة بك التي تتطابق وترفض جميع حركة المرور غير المتطابقة.
في هذه الحالة، إذا تم تفريغ قواعد جدار الحماية الخاص بك، ستكون خدماتك متاحة ولكن بدون حماية. يعتمد ذلك على خيارات الوصول المحلي أو البديل، وقد يكون هذا الأمر ضروريًا لضمان إمكانية إعادة الدخول إلى الخادم في حالة تفريغ القواعد. إذا قررت استخدام هذا الخيار، تأكد من أن القاعدة العامة التي ترفض جميع حركة المرور المتبقية تبقى دائمًا آخر قاعدة في مجموعة القواعد الخاصة بك.
الإسقاط مقابل رفض حركة المرور
هناك عدة طرق لمنع الحزمة من الوصول إلى وجهتها المقصودة. الاختيار بين هذه الطرق يؤثر على كيفية إدراك العميل لمحاولة الاتصال وعلى مدى سرعته في تحديد أن طلبه لن يتم خدمته.
أول طريقة يمكن أن تُرفض فيها الحزم هي باستخدام DROP. يمكن استخدام “الإسقاط” كسياسة افتراضية أو كهدف لقواعد المطابقة. عندما تتم إسقاط الحزمة، تُلقي iptables ببساطة بعيدًا. لا ترسل أي رد على العميل الذي يحاول الاتصال ولا تعطي أي إشارة بأنها استلمت الحزم على الإطلاق. وهذا يعني أن العملاء (مهما كانوا شرعيين أو غير شرعيين) لن يتلقوا أي تأكيد بتلقي حزمهم.
بالنسبة لمحاولات الاتصال ببروتوكول TCP (مثل الاتصالات التي يقوم بها متصفح الويب)، سيتوقف الاتصال حتى يتم الوصول إلى حد الانتهاء من المهلة الزمنية. أما بالنسبة لعملاء UDP، فإن عدم الحصول على رد لاستفساراتهم أكثر غموضًا. في الواقع، عدم استلام حزمة UDP إشارة غالبًا ما يكون دليلاً على قبول الحزمة. إذا كان العميل UDP يهتم بتلقي حزمه، سيتعين عليه إعادة إرسالها لمحاولة تحديد ما إذا كانت قد تم قبولها، أو فقدت أثناء النقل، أو تم إسقاطها. يمكن أن يؤدي ذلك إلى زيادة الوقت الذي قد يضطر فيه الفاعل الخبيث للإنفاق للحصول على معلومات حول حالة منافذ الخادم الخاص بك، ولكن قد يسبب أيضًا مشاكل في حركة المرور الشرعية.
بديل لإسقاط حركة المرور هو رفض الحزم التي لا تسمح بها صراحة. بروتوكول التحكم في رسائل الإنترنت، المعروف باسم ICMP، هو بروتوكول ميتا يستخدم عبر الإنترنت لإرسال رسائل الحالة والتشخيص والأخطاء بين الخوادم كقناة خارج النطاق تعتمد على البروتوكولات التواصل التقليدية مثل TCP أو UDP. عند استخدام الهدف REJECT بدلاً من الهدف DROP، يتم رفض الحركة ويتم إرجاع حزمة ICMP إلى المُرسِل لإعلامه بأن حركتهم تم استلامها ولكن لن تكون مقبولة. يمكن أيضًا تضمين رسالة حالة لتوفير سبب.
هذا ينطوي على عدد من النتائج. بافتراض أن حركة ICMP مسموح بها للوصول إلى العميل، سيتم إبلاغهم على الفور بأن حركتهم تم حظرها. بالنسبة للعملاء المشروعين، يعني ذلك أنهم يمكنهم الاتصال بالمسؤول أو التحقق من خيارات اتصالهم للتأكد من أنهم يتصلون بالمنفذ الصحيح. بالنسبة للمستخدمين الخبيثين، يعني ذلك أنهم يمكنهم إكمال فحوصاتهم ورسم المنافذ المفتوحة والمغلقة والمصفاة في فترة زمنية أقصر.
هناك الكثير للاعتبار عند اتخاذ قرار بشأن إسقاط أو رفض حركة المرور. أحد الاعتبارات المهمة هو أن معظم حركة المرور الخبيثة ستكون في الواقع من تنفيذ النصوص الآلية. نظرًا لعدم إشراف هذه النصوص عادة، فإن إسقاط حركة المرور غير المشروعة لن يثني بشكل فعال عنها، وسيكون له آثار سلبية على المستخدمين المشروعين. يمكن العثور على المزيد حول هذا الموضوع على موقع بيتر بيني على الويب.
جدول الاستجابة للإسقاط مقابل رفض
الجدول أدناه يوضح كيف سيتفاعل الخادم المحمي بجدار ناري مع طلبات مختلفة اعتمادًا على السياسة المُطبَّقة على منفذ الوجهة.
| Client Packet Type | NMap Command | Port Policy | Response | Inferred Port State |
|---|---|---|---|---|
| TCP | nmap [-sT | -sS] -Pn <server> | Accept | TCP SYN/ACK | Open |
| TCP | nmap [-sT | -sS] -Pn <server> | Drop | (none) | Filtered |
| TCP | nmap [-sT | -sS] -Pn <server> | Reject | TCP RESET | Closed |
| UDP | nmap -sU -Pn <server> | Accept | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Drop | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Reject | ICMP Port Unreachable | Closed |
تشير العمود الأول إلى نوع الحزمة التي يرسلها العميل. يحتوي العمود الثاني على أوامر nmap التي يمكن استخدامها لاختبار كل سيناريو. يشير العمود الثالث إلى سياسة المنفذ المُطبَّقة على المنفذ. العمود الرابع هو الاستجابة التي سيرسلها الخادم، والعمود الخامس هو ما يمكن للعميل استنتاجه حول المنفذ بناءً على الاستجابة التي تلقاها.
سياسات ICMP
كما هو الحال مع قرار ما إذا كان يجب إسقاط أم رفض حركة المرور المرفوضة، لديك الخيار لقبول أو رفض حزم ICMP المتجهة إلى خادمك.
بروتوكول ICMP يُستخدم لأغراض كثيرة. كما هو مذكور، يُرسل غالبًا لتقديم معلومات حالة حول الطلبات باستخدام بروتوكولات أخرى. إحدى وظائفه الأكثر شيوعًا هي إرسال والرد على استجوابات الشبكة للتحقق من القدرة على الاتصال بالمضيفين عن بُعد. هناك العديد من الاستخدامات الأخرى لبروتوكول ICMP التي ليست معروفة بشكل واسع، ولكنها لا تزال مفيدة.
تنظم حزم بروتوكول التحكم في رسائل الإنترنت (ICMP) حسب “النوع” ثم بشكل أدق حسب “الكود”. يحدد النوع المعنى العام للرسالة. على سبيل المثال، يعني النوع 3 أن الوجهة غير قابلة للوصول. يستخدم الكود في كثير من الأحيان لتقديم مزيد من المعلومات حول النوع. على سبيل المثال، يعني نوع ICMP 3 الكود 3 أن منفذ الوجهة غير متاح، في حين يعني نوع ICMP 3 الكود 0 أن الشبكة الوجهة غير قابلة للوصول.
بعض أنواع ICMP قديمة ويمكن حظرها دون قيد أو شرط. ومن بين هذه نجد إشارة المصدر ICMP (نوع 4، كود 0) والمضيف البديل (نوع 6). الأنواع 1، 2، 7 والنوع 15 وما فوق هي جميعًا قديمة أو محفوظة للاستخدام المستقبلي أو تجريبية. ستتعامل الكثير من قوالب جدران الحماية الأمامية تلقائيًا مع هذا الأمر.
الأنواع التي يجب حظرها حسب تكوين الشبكة
بعض أنواع ICMP مفيدة في تكوينات الشبكة البعينة ولكن يجب حظرها في تكوينات أخرى.
على سبيل المثال، يمكن أن تكون رسائل إعادة توجيه ICMP (النوع 5) مفيدة لإلقاء الضوء على تصميم الشبكة السيء. يتم إرسال رسالة ICMP للإعادة التوجيه عندما يكون هناك مسار أفضل مباشرة إلى العميل. لذا إذا استقبلت جهاز توجيه حزمة يجب توجيهها إلى جهاز آخر على نفس الشبكة، يرسل راوتر رسالة ICMP للإعادة التوجيه لإخبار العميل بإرسال الحزم من خلال الجهاز الآخر في المستقبل.
هذا مفيد إذا كنت تثق في شبكتك المحلية وترغب في رصد عدم الكفاءة في جداول التوجيه أثناء التكوين الأولي. على شبكة غير موثوقة ، يمكن للمستخدم الخبيث إرسال تحويلات ICMP بشكل محتمل للتلاعب في جداول التوجيه على الأجهزة.
أنواع ICMP الأخرى التي قد تكون مفيدة في بعض الشبكات وقد تكون ضارة في البعض الآخر هي إعلان الموجّه ICMP (النوع 9) وطلب الموجّه (النوع 10) . يُستخدم حزم إعلان الموجّه والطلب للموجّه كجزء من بروتوكول اكتشاف الموجّه عبر الإنترنت (IRDP) ، وهو نظام يتيح للمضيفين ، عند تشغيل النظام أو الانضمام إلى شبكة ، اكتشاف الموجّهات المتاحة ديناميكيًا.
في معظم الحالات ، من الأفضل أن يكون لدى المضيف مسارات ثابتة مكونة للبوابات التي سيستخدمها. يجب أن تكون هذه الحزم مقبولة في نفس الحالات التي تكون فيها حزم التحويل ICMP مقبولة. في الواقع ، نظرًا لأن المضيف لن يعرف المسار المفضل لحركة المرور عبر أي مسار تم اكتشافه ، فإن رسائل التحويل غالبًا ما تكون مطلوبة مباشرة بعد الاكتشاف. إذا لم تكن تقوم بتشغيل خدمة ترسل حزم الاستفسار عن الموجّه أو تعدل مساراتك استنادًا إلى حزم الإعلان (مثل rdisc) ، يمكنك حجب هذه الحزم بأمان.
الأنواع التي يمكن بشكل آمن السماح بها غالبًا
أنواع ICMP التي عادةً ما يمكن السماح بها بشكل آمن هي كما يلي ، ولكن قد ترغب في تعطيلها إذا كنت ترغب في أن تكون حذرًا إضافيًا.
- النوع 8 — طلب الصدى: هذه طلبات البنج الموجهة إلى خادمك. من المعتاد أن تكون آمنة عادةً (حيث أن حظر هذه الحزم لا يخفي خادمك، حيث يوجد العديد من الطرق الأخرى التي يمكن للمستخدمين من خلالها معرفة ما إذا كان مضيفك قائمًا)، ولكن يمكنك حظرها أو تقييد عناوين المصدر التي تستجيب لها إذا كنت ترغب في ذلك.
- النوع 13 — طلب الطابع الزمني: يمكن استخدام هذه الحزم من قبل العملاء لجمع معلومات التأخير. يمكن استخدامها في بعض تقنيات بصمات النظام الجميلة، لذا يمكنك حظرها أو تقييد نطاق العناوين التي تستجيب لها.
يمكن عادة السماح بالأنواع أدناه دون قواعد صريحة عن طريق تكوين جدار حمايتك للسماح بالردود على الطلبات التي قام بها (من خلال استخدام وحدة conntrack للسماح بحركة المرور ESTABLISHED و RELATED).
- النوع 0 — ردود الصدى: هذه هي الردود على طلبات الصدى (البنج).
- النوع 3 — وجهة غير قابلة للوصول: الحزم الشرعية للوجهة غير القابلة للوصول هي ردود على الطلبات التي تم إنشاؤها بواسطة خادمك تشير إلى أن الحزمة لا يمكن تسليمها.
- النوع 11 — انتهت الوقت: هذا هو خطأ تشخيصي يتم إرجاعه إذا كانت الحزمة التي تم إنشاؤها بواسطة خادمك قد ماتت قبل الوصول إلى الوجهة بسبب تجاوز قيمة TTL.
- النوع 12 — مشكلة المعلمة: يعني ذلك أن الحزمة الصادرة من خادمك كانت غير صحيحة.
- النوع 14 — ردود الطابع الزمني: هذه هي الردود على استفسارات الطابع الزمني التي تم إنشاؤها بواسطة خادمك.
قد يظل من الأمور المُوصَى بها من قِبَل بعض خبراء الأمان حجب جميع حركة المرور الواردة بواسطة بروتوكول ICMP، ومع ذلك، يشجع العديد من الأشخاص اليوم على تبني سياسات ذكية لقبول حركة ICMP. هذه المواضيع الاثنتين في Stackexchange تحتوي على مزيد من المعلومات.
تحديد الاتصال وتحديد معدل الحركة
قد ترغب في السماح بالوصول فقط لبعض الخدمات وأنماط حركة المرور، طالما أن العميل لا يسيء استخدام هذا الوصول. هناك طريقتان لتقييد استخدام الموارد، وهما تحديد الاتصال وتحديد معدل الحركة.
تحديد الاتصال
يمكن تنفيذ تحديد الاتصال باستخدام تمديدات مثل connlimit لفحص عدد الاتصالات الفعّالة التي فتحها العميل. يمكن استخدام ذلك لتقييد عدد الاتصالات المسموح بها في وقت واحد. إذا قررت فرض قيود على الاتصال، ستكون لديك بعض القرارات التي يجب اتخاذها:
- هل تقوم بتحديد الحد على أساس فردي، أو على أساس الشبكة، أو على أساس عام؟
- هل تتناسب وتقيد حركة المرور لخدمة معينة أم للخادم ككل؟
يمكن تقييد الاتصالات على أساس مضيف فردى بمضيف، أو يمكن تعيين حد لشبكة معينة عن طريق توفير بادئة الشبكة (مثل نطاق عناوين IP لمؤسسة بأكملها). يمكنك أيضاً تعيين الحد الأقصى العام لعدد الاتصالات لخدمة معينة أو للجهاز بأكمله. تذكر أنه من الممكن خلط وتطابق هذه الإعدادات لإنشاء سياسات أكثر تعقيدًا للتحكم في أرقام الاتصالات.
تحديد معدل الحد
يتيح لك تحديد معدل الحد إنشاء قواعد تحكم في معدل أو تكرار قبول حركة المرور من قبل الخادم الخاص بك. هناك عدة تمديدات جدار الحماية المختلفة يمكن استخدامها لتحديد معدل الحد بما في ذلك limit، hashlimit، و recent. اختيار التمديد الذي تستخدمه سيعتمد إلى حد كبير على الطريقة التي تريد بها تحديد حركة المرور.
سيؤدي تمديد limit إلى مطابقة القاعدة المعنية حتى يتم الوصول إلى الحد، بعد ذلك يتم إسقاط المزيد من الحزم. سيسمح الحد مثل 5/ثانية بمطابقة 5 حزم في الثانية، بعد ذلك لا تتطابق القاعدة بعد ذلك. يعتبر ذلك مناسبًا لتحديد الحد العام لمعدل الخدمة. يمكنك أيضاً نشر خدمة إضافية مثل Fail2ban لحظر محاولات الاتصال المتكررة.
تمتد الإضافة hashlimit بمرونة أكبر، مما يتيح لك تحديد بعض القيم التي ستقوم iptables بتجزئتها لتقييم التطابق. على سبيل المثال، يمكنها النظر إلى عنوان المصدر، ومنفذ المصدر، وعنوان الوجهة، ومنفذ الوجهة، أو مجموعة من تلك القيم الأربعة لتقييم كل إدخال. يمكنها تحديد الحد بالحزم أو بالبايتات المستلمة. يوفر هذا التحديد المرن لتحديد معدل الحد لكل عميل أو خدمة.
تضيف الإضافة recent عناوين IP للعملاء ديناميكيًا إلى قائمة أو تفحص ضد قائمة موجودة عندما يتطابق القاعدة. يسمح هذا لك بنشر منطق الحدود الخاص بك عبر عدد من القواعد المختلفة لأنماط معقدة. لديه القدرة على تحديد عدد الضربات ونطاق زمني مثل المحدودين الآخرين، ولكن يمكنه أيضًا إعادة تعيين نطاق الوقت إذا تم رؤية حركة مرور إضافية، مما يجبر العميل على إيقاف جميع حركة المرور إذا كانوا محدودين.
الإدارة المتماسكة مقابل القائمة القائمة
جميع سياسات جدار الحماية iptables و nftables تستند أساسًا إلى توسيع القوائم المدمجة. في البداية، يعني هذا عادة تغيير السياسة الافتراضية للقوائم الموجودة وإضافة القواعد. لجدران حماية أكثر تعقيدًا، فمن المفيد غالبًا توسيع إطار الإدارة من خلال إنشاء قوائم إضافية.
السلاسل التي ينشئها المستخدم تُسمى ثانويًا ومرتبطة بشكل طبيعي بـ “سلسلة الاستدعاء” التي تنبع منها. لا تحتوي السلاسل التي ينشئها المستخدم على سياسة افتراضية، لذا إذا سقط حزمة من خلال سلسلة تم إنشاؤها بواسطة المستخدم، فسوف تعود إلى سلسلة الاستدعاء وتستمر في التقييم. وبهذا الصدد، تكون السلاسل التي ينشئها المستخدم مفيدة بشكل أساسي لأغراض التنظيم، لجعل شروط تطابق القواعد أكثر صيانة، ولتحسين قابلية القراءة عن طريق تقسيم شروط التطابق.
إذا وجدت نفسك تكرار معايير تطابق معينة لعدد كبير من القواعد، قد يكون من المفيد إنشاء قاعدة قفزة مع معايير التطابق المشتركة إلى سلسلة جديدة. داخل السلسلة الجديدة، يمكنك إضافة هذه المجموعة من القواعد مع تجاهل المعايير التطابق المتكررة.
القرار بشأن ما إذا كان يجب تجميع جميع القواعد الخاصة بك في إحدى السلاسل المدمجة أم إنشاء واستخدام سلاسل إضافية سيعتمد على مدى تعقيد مجموعة القواعد الخاصة بك.
الختام
يجب أن تكون الآن لديك فهم أفضل للقرارات التي ستضطر إلى اتخاذها عند تصميم سياسات الجدار الناري لخوادمك. عادةً ما يميل الاستثمار الزمني المتعلق بالجدران النارية بشكل كبير نحو الإعداد الأولي. على الرغم من أنه قد يستغرق بعض الوقت والتجربة لوضع سياسة تخدم احتياجاتك بشكل أفضل، إلا أن ذلك سيمنحك مزيدًا من السيطرة على أمان خادمك.
إذا كنت ترغب في معرفة المزيد عن الجدران النارية و iptables بشكل خاص، يمكنك التحقق من المقالات التالية:
يمكن أن تساعدك الأدلة التالية في تنفيذ سياساتك. اختر الدليل الذي يتوافق مع جدار الحماية الخاص بك للبدء: