اختبار تغييرات جدار الحماية دون أن تُغلق الباب على نفسك

تُطبَّق القاعدة، ويظل الطرفية المفتوحة لديك تجيب، ثم يُرفض تسجيل الدخول التالي. هذه الفجوة هي كل صعوبة اختبار تغيير في جدار الحماية عبر الاتصال الذي تغيّره. يقرّر تتبّع الاتصالات مرة واحدة ثم يكفّ عن النظر، لذا فإن التدفّق القائم هو الفحص الوحيد الذي لا يستطيع رؤية السياسة الجديدة. يقارن ما يلي بين طرق العودة الثلاث، ثم يثبّت الترتيب الذي تُغيَّر به القواعد وتُفحص.

لماذا تكون الجلسة الناجية أضعف دليل

يقيّم جدار الحماية ذو الحالة أول حزمة في التدفّق ويحتفظ بهذا الحكم ما دام السجل قائمًا. القواعد المضافة بعده تسري على التدفّقات التي تبدأ لاحقًا، ولهذا تبقى النافذة التي تكتب فيها صالحة بينما يُرفض الجميع سواها. وما تتعلمه منها يصف السياسة التي كانت قائمة قبل دقائق. وحتى الالتقاط المأخوذ على ذلك التدفّق يُظهر قرارًا اتخذته الآلة من قبل.

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

ثلاث طرق للعودة، مرتبة بحسب ما تعتمد عليه كل واحدة

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

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

تغيير واحد، ثم اتصال يجب تقييمه

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

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

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

العدّادات والحالة والملف تجيب عن أسئلة مختلفة

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

ss -tn state established

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

استعد من مجموعة القواعد المحفوظة، ثم اجعل الملف متوافقًا

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

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