الإقليم ٥ — الجدار والخَتم: Firewall وHTTPS/TLS

المحتوى

النبذة
الدرس
الخلاصة — وصلٌ في الشجرة

النبذة

نظامنا صار متوفّراً، لكنه مكشوف: أي خدمةٍ مفتوحةٍ على أي خادمٍ قابلةٌ للوصول من الإنترنت، وكل حرفٍ بين المستخدم والخادم يسير عارياً يقرؤه أي متنصّتٍ على الطريق. هذا هو Task 2: أضف ثلاثة جدران نارية، وشهادة SSL لتقديم الموقع عبر HTTPS. السؤال المزدوج: كيف نمنع الدخول غير المرغوب، وكيف نمنع التنصّت على المسموح؟

لاحظ

دمج من منهج الشبكات: هناك تعلّمتَ أن NAT ليس جداراً نارياً رغم أنه يتصرّف كأنه واحد. تركنا «الجدار الناري الحقيقي» سؤالاً مفتوحاً — وهذا الإقليم يجيبه. وكل ما يخصّ TCP/ports/المصافحة الثلاثية مبنيٌّ سلفاً؛ سنبني TLS فوقه.

اللغز المستفزّ — جزآن

أ) الجدار: خادمك يشغّل web server على ٤٤٣، و SSH للإدارة على ٢٢، وMySQL على

أيٌّ من هذه يجب أن يصل إليه العالم؟ ولو ترك ٣٣٠٦ مفتوحاً للإنترنت، ماذا يحدث؟

صمّم قاعدةً تسمح بالضروري فقط وتمنع الباقي.

ب) الخَتم: اكتب على ورقةٍ رسالةً، وتخيّل أنها تمرّ عبر عشرة أجهزةٍ وسيطة (routers, ISPs) قبل أن تصل. أي واحدٍ منها يستطيع قراءتها أو تبديلها. بلا أن يلتقي الطرفان مسبقاً ويتبادلا مفتاحاً سرّياً، كيف يتّفقان على سرٍّ لا يعرفه أيٌّ من العشرة؟ هذا اللغز هو بالضبط ما يحلّه TLS — حاوله قبل أن تقرأ.

الدرس

ليش الجدار الناري — التحكّم في من يدخل ويخرج

لاحظ

Firewall: نظامٌ يراقب حركة الشبكة ويسمح أو يمنع وفق قواعد (rules) محدّدة مسبقاً (عادةً حسب الـ IP، الـ port، والاتجاه ingress/egress).

الدافع مباشر: كل portٍ مفتوحٍ هو بابٌ محتمل. خادمك يحتاج فتح ٤٤٣ (HTTPS) للعالم، لكن لا أحد في الإنترنت يحتاج الوصول المباشر لـ MySQL (٣٣٠٦) أو حتى SSH (٢٢) إلا من عناوين الإدارة. الجدار الناري يطبّق قاعدة «ارفض كل شيءٍ افتراضياً، واسمح بالضروري فقط» (default-deny): افتح ٤٤٣ للعالم، اقصر ٢٢ على إدارتك، واسمح بـ ٣٣٠٦ فقط داخل الشبكة بين الـ app server والـ database. ترك ٣٣٠٦ مفتوحاً للإنترنت يعني أنك دعوتَ العالم ليجرّب الدخول على قاعدة بياناتك مباشرةً.

ليش ثلاثة جدران في Task 2؟ المشروع يضع firewall لكل خادم من الثلاثة (مبدأ defense in depth — لا تعتمد على حاجزٍ واحد). كلٌّ يحرس بابَ خادمه: يسمح فقط بما يحتاجه ذلك الخادم بالذات (الموزّع يسمح ٤٤٣ من العالم؛ خوادم الـ backend تسمح فقط بحركة الموزّع؛ قاعدة البيانات تسمح فقط بحركة الـ app servers).

ليش HTTPS — التهديدات الثلاثة على القناة العارية

HTTP عاري. مرور النص الصريح عبر وسطاء لا تثق بهم يفتح ثلاثة تهديدات — اشتقّ الحماية من كلٍّ منها:

التنصّت (eavesdropping): وسيطٌ يقرأ كلمات المرور والبيانات ⟵ نحتاج تشفيراً (confidentiality).
التلاعب (tampering): وسيطٌ يبدّل محتوى الصفحة (يحقن إعلاناً/برمجية) ⟵ نحتاج تكامُلاً (integrity).
الانتحال (impersonation): جهازٌ يدّعي أنه foobar.com ⟵ نحتاج **مصادقةً (authentication)** تثبت أن من تكلّمه هو فعلاً صاحب النطاق.

HTTPS = HTTP فوق TLS، وTLS يقدّم الثلاثة معاً. هذا هو «لماذا تُقدَّم الحركة عبر HTTPS» الذي يسأل عنه المشروع: لتأمين السرّية والتكامل والمصادقة على قناةٍ لا يُوثَق بوسطائها.

ليش الشهادة (SSL certificate) — حلّ لغز السرّ والهوية

اللغز (ب) معضلتان: كيف تتّفق على سرٍّ أمام متنصّت، وكيف تتأكّد أن الطرف الآخر هو من يدّعي؟ TLS يحلّهما بالتسلسل (نبنيه فوق مصافحة TCP التي تعرفها):

بعد أن يكتمل TCP، يبدأ TLS handshake. الخادم يقدّم شهادته (certificate): وثيقةٌ تحوي اسم النطاق ومفتاحه العام، موقّعةٌ من سلطة تصديق (CA) يثق بها متصفّحك مسبقاً. توقيع الـ CA هو ما يحلّ الهوية: المتصفّح يتحقّق أن الشهادة صالحةٌ ولاسم النطاق الصحيح وموقّعةٌ من CA موثوقة ⟵ إذاً هذا فعلاً foobar.com.
باستخدام تعميةٍ غير متماثلة (المفتاح العام في الشهادة)، يتّفق الطرفان على مفتاح جلسةٍ متماثلٍ (session key) سرّيٍّ لا يستطيع المتنصّت استنتاجه ⟵ يحلّ السرّ المشترك أمام العيون.
بعدها يُشفَّر كل HTTP بهذا المفتاح المتماثل (أسرع) ⟵ يحلّ السرّية والتكامل لبقية الجلسة.

لا تحفظ خطوات المصافحة بالترتيب الحرفي للامتحان؛ احفظ ما يحلّه كل جزء: الشهادة تثبت الهوية وتحمل المفتاح العام، والمصافحة تشتقّ مفتاح الجلسة، ثم يُشفَّر كل شيء. هذا يكفي تماماً لـ ٣٠ دقيقةٍ على السبورة.

الوجه الآخر: لماذا «إنهاء SSL عند الموزّع» مشكلة (سؤال Task 2)

إعدادٌ شائع: الموزّع يفكّ التشفير (SSL termination) ويمرّر الطلب بنصٍّ صريح إلى الخوادم الخلفية. المشروع يسألك لماذا هذا مشكلة. اشتقّها من تهديدات HTTPS نفسها:

بعد الموزّع، الحركة تسير غير مشفّرة داخل شبكتك (بين الموزّع والـ backends). إن اختُرقت الشبكة الداخلية أو تنصّت أحدٌ عليها، عادت كل التهديدات. التشفير الذي وعدتَ به «من الطرف إلى الطرف» انتهى عند الموزّع، لا عند الخادم الفعلي.
(ثانوي) الموزّع يحمل عبء فكّ التعمية لكل الحركة، وقد يصير اختناقاً.

الجواب المختصر: «End-to-end encryption breaks: traffic past the LB is in cleartext inside the network.» (الحلّ — re-encrypt أو SSL passthrough — تفصيلٌ لا يطلبه المشروع.)

تحليل الأخطاء

«NAT/الموزّع يكفي كجدارٍ ناري.» لا — NAT يخفي العناوين لكنه لا يطبّق سياسة سماح/منع مقصودة (تعلّمتَ هذا في منهج الشبكات). الجدار الناري قرارٌ صريحٌ بالقواعد.
«HTTPS فقط يشفّر.» التشفير واحدٌ من ثلاثة؛ المصادقة (الشهادة) لا تقلّ أهمية — بلا مصادقةٍ يشفّر المتصفّح قناةً مع منتحِل.
«الشهادة تشفّر البيانات.» الشهادة تُثبت الهوية وتحمل المفتاح العام؛ التشفير الفعلي للحركة يتمّ بمفتاح الجلسة المتماثل المُشتقّ بعدها.

التمرين (سبورة)

حدّث مخطّط Task 1 ليصير Task 2 أمنياً: ارسم firewall حول كل خادم (٣)، وضع قفلاً/شهادة على الموزّع يدلّ على HTTPS، وارسم سهم الحركة وقد صار «🔒 مشفّر» من المستخدم. لكل عنصرٍ مضاف اكتب «لماذا أضفته». ثم على ورقة:

ما وظيفة الجدران؟ لماذا الحركة عبر HTTPS؟
اشرح في سطرين دور الشهادة (هوية + مفتاح عام) ثم اشتقاق مفتاح الجلسة.
لماذا إنهاء SSL عند الموزّع مشكلة؟

الخلاصة — وصلٌ في الشجرة

اشتققتَ الجدار الناري من «default-deny»، وأجبتَ بذرة «الجدار الحقيقي» المتروكة في منهج الشبكات، وفهمتَ لماذا ثلاثة (defense in depth، واحدٌ لكل خادم).
اشتققتَ HTTPS/TLS من ثلاثة تهديدات (تنصّت/تلاعب/انتحال) ⟵ تشفير/تكامل/مصادقة، ودور الشهادة (هوية + مفتاح)، وعيب SSL termination عند الموزّع.
بنيتَ TLS فوق TCP بلا إعادة اشتقاق — استمرارٌ للدمج.

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

على السبورة (إنجليزي، مكثّف)

Firewalls allow/deny traffic by rules (IP, port, direction). I add one per server (defense in depth): open 443 to the world, restrict 22 to admins, and only allow MySQL 3306 internally between app and DB. Default-deny everything else.

Traffic is served over HTTPS (HTTP over TLS) to protect it on an untrusted path: confidentiality (encryption), integrity (tamper-proofing), and authentication. The SSL certificate proves the server really owns foobar.com (signed by a trusted CA) and carries the public key used to negotiate a session key; HTTP is then encrypted with that key.

Terminating SSL at the load balancer is an issue: past the LB the traffic is cleartext inside the network, so it's no longer end-to-end encrypted.

وقفة الانضباط: لا تشرح RSA مقابل ECDHE ولا تفاصيل ClientHello ما لم يُسأل. «هوية عبر شهادةٍ موقّعةٍ من CA، ثم مفتاح جلسةٍ مشترك» تكفي.