أساسيات الشبكات لـ DevOps

جدران الحماية وأمن الشبكات

18 دقيقة الدرس 7 من 30

جدران الحماية وأمن الشبكات

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

تصفية الحزم — النموذج الذهني الجوهري

يطبّق كل جدار حماية قراراً على كل حزمة بيانات: ACCEPT (قبول) أو DROP (حذف صامت) أو REJECT (رفض مع إشعار). تُقيَّم القواعد بالترتيب؛ أول تطابق يحسم القرار. في نهاية كل سلسلة توجد سياسة افتراضية. الإعدادات الآمنة الوحيدة في الإنتاج هي DROP على سلسلتَي INPUT و FORWARD، وACCEPT على OUTPUT. البدء بحظر كل شيء والسماح فقط بما هو ضروري مبدأ أساسي في أمن المعلومات — إنه مبدأ الصلاحية الدنيا مُطبَّقاً على حركة البيانات.

تعمل جدران الحماية على طبقات مختلفة. المرشح البسيط (الطبقة 3/4) يفحص فقط عنوان IP المصدر، والوجهة، والبروتوكول، والمنفذ. أما جدار الحماية ذو الحالة فيتتبع أيضاً حالة الاتصالات — هل الحزمة جزء من جلسة قائمة، أم طلب اتصال جديد، أم حزمة غير صالحة خارج السياق. التصفية ذات الحالة هي ما يجعل سياسة OUTPUT المتساهلة آمنة: يسمح جدار الحماية تلقائياً بحركة العودة للاتصالات التي أطلقها المضيف دون الحاجة إلى قواعد واردة صريحة.

حالات تتبع الاتصالات في جدار الحماية ذي الحالة: NEW و ESTABLISHED و RELATED مسموح بها؛ الحزم INVALID تُحذف دائماً.

iptables — تصفية حزم Linux من المبادئ الأولى

iptables هي واجهة جدار الحماية التقليدية في Linux، ولا تزال تعمل على غالبية خوادم Linux في الإنتاج بما في ذلك مضيفي Docker وعُقد Kubernetes قبل الإصدار 1.29. تنظّم القواعد في جداول (filter, nat, mangle, raw) وسلاسل (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING). لأمن المضيف، جدول filter هو كل ما تحتاجه.

# --- مجموعة قواعد iptables مُحكمة للإنتاج على خادم تطبيق ---
# تشغيل بصلاحيات root. الترتيب مهم: القواعد تُقيَّم من الأعلى للأسفل.

# 1. مسح القواعد الموجودة وإعادة ضبط العدادات
iptables -F
iptables -X
iptables -Z

# 2. تعيين السياسات الافتراضية: DROP على INPUT وFORWARD، ACCEPT على OUTPUT
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  ACCEPT

# 3. السماح بحركة الـ loopback (ضروري — تتواصل كثير من التطبيقات عبر 127.0.0.1)
iptables -A INPUT -i lo -j ACCEPT

# 4. السماح بحركة العودة للاتصالات التي أطلقها هذا المضيف (ذات الحالة)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 5. حذف الحزم غير الصالحة فوراً (قبل أي قاعدة ACCEPT)
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# 6. السماح بـ SSH من نطاق الإدارة فقط
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -m conntrack --ctstate NEW -j ACCEPT

# 7. السماح بـ HTTPS الوارد من أي مصدر
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

# 8. السماح بـ ICMP echo (ping) مع تحديد المعدل لتجنب هجمات التضخيم
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/s --limit-burst 10 -j ACCEPT

# 9. تسجيل ثم حذف كل ما تبقى (5 في الدقيقة فقط حتى تبقى السجلات قابلة للإدارة)
iptables -A INPUT -m limit --limit 5/min --limit-burst 10 -j LOG --log-prefix "iptables-DROP: " --log-level 4
iptables -A INPUT -j DROP

# الحفاظ على القواعد عند إعادة التشغيل (Debian/Ubuntu)
apt-get install -y iptables-persistent
netfilter-persistent save

لماذا DROP بدلاً من REJECT؟ DROP يتجاهل الحزمة بصمت؛ المُرسل ينتظر حتى انتهاء المهلة. REJECT يُرسل رسالة ICMP "port unreachable" فوراً. على الإنترنت، يُفضَّل DROP للحركة الواردة لأنه لا يعطي المهاجمين تأكيداً بوجود المنفذ. داخل الشبكة الداخلية الموثوقة، يُسرّع REJECT التشخيص بالفشل السريع. استخدم REJECT في سلسلة FORWARD بين القطاعات الداخلية حتى يحصل مطوروك على تغذية راجعة سريعة عند استدعاء الخدمات بإعداد خاطئ.

nftables — البديل الحديث

يأتي nftables افتراضياً على Debian 10+ و RHEL 8+ و Ubuntu 22.04+. يحل محل iptables وip6tables وarptables وebtables بإطار موحد واحد. لغة القواعد أكثر تعبيراً، وأسرع تقييماً باستخدام الخرائط والمجموعات على مستوى النواة (بلا مسح خطي لقوائم IP)، والإعداد ملف واحد متماسك بدلاً من تسلسل أوامر CLI.

# /etc/nftables.conf — مجموعة قواعد مكافئة لمثال iptables أعلاه

flush ruleset

table inet filter {

    # مجموعة مسماة لعناوين IP لإدارة الشبكة (بحث O(1)، بلا مسح سلسلة)
    set mgmt_cidrs {
        type ipv4_addr
        flags interval
        elements = { 10.0.0.0/8, 172.16.0.0/12 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept                                        comment "loopback مسموح دائماً"
        ct state established,related accept                  comment "حركة العودة"
        ct state invalid drop                                comment "حذف الحالة غير الصالحة"

        ip protocol icmp icmp type echo-request limit rate 5/second accept

        tcp dport 22 ip saddr @mgmt_cidrs ct state new accept  comment "SSH من الإدارة فقط"
        tcp dport 443 ct state new accept                       comment "HTTPS من أي مصدر"

        limit rate 5/minute log prefix "nft-DROP: " drop    comment "تسجيل قبل الحذف النهائي"
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

ممارسة احترافية: في Google وشركات مماثلة، تُستخدم مجموعات nftables للحفاظ على قوائم حظر IP الديناميكية (قوائم سمعة IP) التي يُحدّثها نظام الأتمتة دون المساس بقواعد السلسلة نفسها. الأمر nft add element inet filter blocklist { 1.2.3.4 } يضيف عنوان IP للمجموعة بشكل ذري دون إعادة تحميل القواعد — توقف صفري، أثر فوري.

مجموعات الأمان السحابية — التصفية ذات الحالة كخدمة

مجموعات الأمان في AWS (Security Groups) وقواعد جدار الحماية في GCP وNSG في Azure هي المكافئ السحابي الأصيل لجدار الحماية ذي الحالة. تُطبَّق على مستوى المحاكي الافتراضي (hypervisor) — الحركة التي تحظرها مجموعة الأمان لا تصل إلى المثيل أبداً، ولا حتى إلى بطاقة الشبكة. هذا يعني أنه لا يمكن تجاوزها بتكوين iptables خاطئ داخل الجهاز الافتراضي.

خصائص مجموعات الأمان في AWS التي تُوقع المهندسين في المتاعب:

ذات حالة بطبيعتها. إذا سمحت بالمنفذ 443 وارداً، يُسمح تلقائياً بحركة العودة — لا تحتاج لقاعدة صادرة لردود المنفذ 443.
للسماح فقط. لا توجد قاعدة حظر في مجموعة الأمان. لحظر حركة بعينها يجب استخدام قائمة التحكم في الشبكة (NACL) وهي عديمة الحالة وتدعم الحظر الصريح.
مرتبطة بالواجهات الشبكية (ENI) لا بالمثيلات. مثيل بواجهتين شبكيتين يمكنه امتلاك مجموعتي أمان مختلفتين — مهم لتصميمات البراكس والـ bastion متعددة الاتصالات.
المصدر يمكن أن يكون معرّف مجموعة أمان أخرى. بدلاً من ترميز نطاقات IP التي تتغير مع التوسع، أشر مباشرة إلى مجموعة الأمان للطبقة المُستدعِية: sg-0abc123 (app-servers) ← sg-0def456 (rds-mysql) على المنفذ 3306. يتوسع تلقائياً.

تصميم AWS ثلاثي الطبقات بمجموعات الأمان: كل طبقة تقبل فقط الحركة من مجموعة الأمان الخاصة بالطبقة التي فوقها، لا من نطاقات IP خام.

التصفية ذات الحالة مقابل عديمة الحالة — متى تستخدم كل منهما

قوائم التحكم في الشبكة (NACLs) في AWS عديمة الحالة: يجب كتابة قواعد صريحة للاتجاهَين. كما تُقيَّم القواعد بترتيب رقمي (100, 200, 300…) وتتوقف عند أول تطابق بما في ذلك الحظر الصريح. NACLs هي قائمة الحظر الملاذ الأخير — استخدمها لحظر نطاقات CIDR بعينها على حدود الشبكة الفرعية عندما تعجز مجموعة الأمان عن التعبير عن حظر. عملياً، معظم الفرق تستخدم Security Groups لمنطق قائمة السماح، وNACLs فقط لحظر نطاقات IP واسعة (أرقام AS ذات سمعة سيئة، أو الحجب الجغرافي).

فخ الإنتاج — المنافذ المؤقتة (Ephemeral Ports): تتضمن اتصالات TCP منفذ الخادم (443) ومنفذاً مؤقتاً تختاره العميل (عادة 1024–65535). جدران الحماية عديمة الحالة (NACLs وبعض الأنظمة المحلية) يجب أن تسمح صراحة بنطاق المنافذ المؤقتة على حركة العودة. نسيان ذلك أحد أكثر أسباب "يعمل صادراً، يفشل عائداً" شيوعاً. الحل: السماح بحركة TCP العائدة على المنافذ 1024–65535 من الوجهة. جدران الحماية ذات الحالة تتعامل مع هذا تلقائياً — وهذا سبب إضافي لتفضيلها.

أنماط الأعطال الشائعة وكيفية تشخيصها

خطأ في ترتيب القواعد: ACCEPT واسع قبل DROP محدد يعني أن الـ DROP لن يُطبَّق أبداً. ضع القواعد المحددة دائماً قبل العامة. في iptables، استخدم iptables -L -n -v --line-numbers لفحص الترتيب وعدادات الإصابات.
سلسلة مخصصة غير مرتبطة: إنشاء سلسلة مخصصة بـ iptables -N my-chain لا يفعل شيئاً ما لم تقفز إليها من INPUT بـ -j my-chain. نسيان القفزة يجعلها صامتة تماماً.
مجموعة أمان متساهلة جداً: 0.0.0.0/0 على المنفذ 22 هو أكثر أخطاء الإعداد السحابي شيوعاً في تقارير الاختراقات الإنتاجية. استبدله بـ CIDR لشبكة VPN أو خادم bastion.
Docker يكتب فوق iptables: يُدرج Docker قواعد في سلسلة FORWARD وسلسلتَي DOCKER وDOCKER-USER. إذا أفرغت iptables يدوياً، تفقد الحاويات التي يديرها Docker اتصالها بالشبكة. أضف قواعدك المخصصة إلى سلسلة DOCKER-USER التي لا يكتب عليها Docker أبداً.

ممارسة احترافية: في البيئات الكبيرة الحجم، عامل قواعد جدار الحماية كرمز برمجي. خزّن nftables.conf أو موارد Terraform الخاصة بمجموعات الأمان في نظام التحكم بالإصدارات، وفرض مراجعة الأقران على التغييرات، وشغّل فحوصات الامتثال الآلية (قواعد AWS Config، أو سياسات opa) التي تُنبّه عند ظهور 0.0.0.0/0 على المنافذ الحساسة. التغييرات اليدوية على جدار الحماية في الإنتاج ممارسة مضادة لإدارة التغيير.