أمن الشبكات من منظور الأنظمة
بعد أن ركّزنا على كيفية استخدام لبنات التشفير والمصادقة (authentication) المتاحة لتأمين طبقة النقل بما ينفع جميع التطبيقات، نتحوّل الآن إلى أمثلة على كيفية تأمين الأنظمة الفرعية (subsystems) على حدة.
وتتناول هذه الأمثلة تهديداتٍ محدّدة، مرتبطة بحالات استخدام بعينها، تظلّ قائمة حتى بعد نشر TLS.
والأنظمة الموصوفة في هذا الفصل تقع في طبقاتٍ مختلفة: بعضها مبنيّ داخل التطبيقات، وبعضها يعمل في طبقة IP، وبعضها يؤمّن وصلات الشبكة.
ورغم أنّها تعالج تهديداتٍ مختلفة خاصّةً بكلّ طبقة، فإنّ ما يجمع هذه الأمثلة هو أنها جميعًا تستفيد من المجموعة نفسها من لبنات الأمن.
ورؤية كيفية تجميع هذه اللبنات بطرقٍ مختلفة لبناء حلولّ مختلفة هي القيمة الرئيسة لهذا الفصل.
ولهذا الغرض، تركّز الأقسام التالية على حالة الاستخدام والتهديد المقابل، مع وصفٍ عامّ لكيفية تعامل النظام مع التهديد؛ ولا يلزم أيّ خوارزمياتٍ أو قدراتٍ جوهرية جديدة.
ومن الجدير بالذكر أيضًا أنّ أنظمة الأمثلة هذه، إلى جانب استفادتها من لبنات قائمة، قابلةٌ للتهيئة إلى حدٍّ كبير.
وفكرة جعل نظامٍ أمنيٍّ مستقلًا عن الخوارزمية فكرةٌ جيّدة، لأنّك لا تعرف أبدًا متى قد يثبت أنّ خوارزميتك التشفيرية المفضّلة غير كافيةٍ لأغراضك.
ولاحظ القياسَ بإمكانية تغيير المفاتيح من دون تغيير الخوارزمية؛ فإذا اتضح أنّ إحدى خوارزمياتك التشفيرية معيبة، لكان رائعًا ألّا تحتاج هندستك الأمنية بالكامل إلى إعادة تصميمٍ فورية.
7.1 الخصوصية الجيّدة جدًّا
الخصوصية الجيّدة جدًّا (Pretty Good Privacy, PGP) مقاربةٌ لتوفير المصادقة (authentication) والسرّية وسلامة البيانات وعدم الإنكار في الرسائل البريدية.
وقد ابتكره فيل زيمرمان (Phil Zimmerman) عام 1991، ثمّ تطوّر ليصبح معيارًا في IETF، هو OpenPGP.
وكما رأينا في الفصل 4، فإنّ ما يميّز PGP استعماله نموذج «شبكة الثقة» (web of trust) لتوزيع المفاتيح بدلًا من تسلسلٍ هرميّ شبيه بالشجرة.
والأمر الآخر الجدير بالذكر عن PGP هو أنّه ليس مستعملًا على نطاقٍ واسع، إلى حدٍّ كبيرٍ لأنّ معظم المستخدمين يقرّرون الوثوق بمزوّد بريدهم الإلكتروني (أو بالأحرى لا يقلقون بشأن استخدام بريدهم لأغراض تسويقية).
وبالمقابل، فإنّ PGP خيارٌ للمستخدمين الذين يضعون خصوصيتهم واليقين بهوية من يتبادلون معهم الرسائل في مقدمة أولوياتهم.
وتوفّر برمجيات العميل سهلة الاستخدام جعل هذا الخيار أكثر قابليةً للتحقيق مع مرور الوقت.
وتعتمد سرّية PGP ومصادقة المستقبِل على امتلاك مُرسِل الرسالة مفتاحًا عامًّا (public key) معروفًا له.
ولتوفير مصادقة المُرسِل وعدم الإنكار، يجب أن يملك المُرسِل مفتاحًا عامًّا معروفًا للمُرسَل إليه.
وتُوزَّع هذه المفاتيح العامة مسبقًا باستخدام الشهادات (certificates) وبنية تحتية لمفاتيح عامة قائمة على «شبكة الثقة».
يدعم PGP خوارزميتَي RSA وDSS لشهادات المفاتيح العامة.
وقد تُحدّد هذه الشهادات إضافةً إلى ذلك الخوارزميات التشفيرية التي يدعمها مالك المفتاح أو يفضّلها.
وتوفّر الشهادات روابطً (bindings) بين عناوين البريد الإلكتروني والمفاتيح العامة.
الشكل 15. خطوات PGP في تحضير رسالة ليُرسلها أليس إلى بوب بريديًا.↗
ولننظر المثال التالي على استخدام PGP لتوفير مصادقة المُرسِل والسرّية معًا.
لنفترض أنّ لأليس رسالة تريد إرسالها بالبريد إلى بوب.
يمرّ تطبيق PGP لدى أليس بالخطوات المبيّنة في الشكل 15.
أوّلًا، توقّع أليس الرسالة توقيعًا رقميًّا؛ ومن بين دوالّ التجزئة (hash) التي قد تُستخدَم في التوقيع الرقمي MD5 وSHA-1 وعائلة SHA-2.
ثمّ يولّد تطبيق PGP لدى أليس مفتاح جلسة (session key) جديدًا لهذه الرسالة الواحدة فقط؛ ومن بين شيفرات المفاتيح السرّية المدعومة AES و3DES.
تُشفَّر الرسالة الموقَّعة رقميًّا باستخدام مفتاح الجلسة، ثمّ يُشفَّر مفتاح الجلسة نفسه باستخدام المفتاح العام لبوب ويُلحَق بالرسالة.
ثمّ يذكّر تطبيق PGP لدى أليس مستوى الثقة الذي كانت قد أسندته سابقًا إلى المفتاح العام لبوب، استنادًا إلى عدد الشهادات التي تملكها عن بوب وإلى درجة موثوقية الأشخاص الذين وقّعوا تلك الشهادات.
وأخيرًا، ليس لأسباب أمنية بل لأنّ الرسائل البريدية يتعيّن إرسالها بترميز ASCII، يُطبَّق ترميز base64 على الرسالة لتحويلها إلى تمثيل متوافق مع ASCII.
وعند تلقّي رسالة PGP في رسالة بريدية، يعكس تطبيق PGP لدى بوب هذه العملية خطوةً بخطوة ليحصل على الرسالة الأصلية الصريحة ويؤكّد التوقيع الرقمي لأليس — ويذكّر بوبًا بمستوى ثقته في المفتاح العام لأليس.
وليس PGP خاصًّا بالبريد الإلكتروني فحسب، لكنّ للرسائل البريدية خصائص خاصة تتيح لـ PGP تضمين بروتوكول مصادقة كافٍ في بروتوكول نقل بيانات هذه الرسالة الواحدة.
وهذا يتجنّب الحاجة إلى أيّ تبادل رسائلٍ سابق (ويتجنّب بعض التعقيدات التي وصفناها في الفصل الأسبق).
وتكفي التوقيعُ الرقميّ لأليس لمصادقتها.
ولو لم يكن هناك دليل على أن الرسالة في وقتها، فإنّ البريد الشرعي ليس مضمون التوقيت في وقته أيضًا.
كما لا يوجد دليل على أنّ الرسالة طازجة، لكنّ بوب مستخدِم بريد إلكتروني، ومن المرجّح أنّه إنسان متسامح مع الأخطاء يستطيع التعافي من الرسائل المكرّرة (والتي، مرّةً أخرى، لا يمكن استبعادها في التشغيل الطبيعيّ على أيّ حال).
ويمكن لأليس أن تطمئنّ إلى أنّ بوب وحده هو من يستطيع قراءة الرسالة، لأنّ مفتاح الجلسة شُفِّر بمفتاحه العام.
ولو لم يثبت هذا البروتوكول لأليس أنّ بوب حاضرٌ فعلًا واستقبل الرسالة، فإنّ رسالة بريدية مصادَق عليها من بوب إلى أليس يستطيع ذلك.
وتُعطينا المناقشة السابقة مثالًا جيّدًا على لماذا يمكن لآليّات الأمن في طبقة التطبيق أن تكون مفيدة.
فلا يمكن الاختيار الصحيح بين الهجمات التي يجب الدفاع عنها (مثل البريد المزوّر) وتلك التي يمكن تجاهلها (مثل البريد المؤجَّل أو المُعاد إرساله) إلّا بمعرفةٍ كاملة بكيفية عمل التطبيق.
7.2 الصدفة الآمنة
يوفّر بروتوكول الصدفة الآمنة (Secure Shell, SSH) خدمة دخولٍ عن بُعد، محِلًّا محلّ Telnet الأقلّ أمانًا الذي استُخدم في الأيام الأولى للإنترنت.
ويمكن أيضًا استخدام SSH لتنفيذ الأوامر عن بُعد ونقل الملفات.
وغالبًا ما يُستخدم لتوفير مصادقة قوية بين العميل والخادم وسلامة للرسائل — حيث يعمل عميل SSH على حاسوب المستخدم المحمول مثلًا، ويعمل خادم SSH على جهازٍ بعيدٍ يريد المستخدم تسجيل الدخول إليه — لكنه يوفّر السرّية أيضًا.
ولا يوفّر Telnet أيًّا من هذه القدرات.
ولاحظ أنّ كلمة «SSH» تُستعمل غالبًا للإشارة إلى بروتوكول SSH وإلى التطبيقات التي تستخدمه معًا؛ عليك استنتاج أيّهما من السياق.
ولكي نقدّر أهمية SSH في إنترنت اليوم أكثر، فكّر في سيناريوهين يُستخدم فيهما.
فالعاملون عن بُعد يعتمدون على سلسلةٍ من مزوّدي خدمات الإنترنت للوصول إلى الأجهزة التي يديرها جهة عملهم.
وهذا يعني أنّه حين يسجّل عاملٌ عن بُعد الدخول إلى جهازٍ داخل مركز بيانات جهة عمله، تمرّ كلمات السرّية وجميع البيانات المُرسَلة أو المُستلَمَة، على الأرجح، عبر عددٍ غير محدود من الشبكات غير الموثوقة.
ويوفّر SSH وسيلةً لتشفير البيانات المُرسَلة عبر هذه الاتصالات وتقوية آليّة المصادقة المستخدَمة في تسجيل الدخول.
(ويحدث وضعٌ مشابه حين يتّصل الموظف المذكور بالعمل عبر Wi-Fi العام في مقهى.)
والاستخدام الشائع الثاني لـ SSH هو تسجيل الدخول إلى موجِّهٍ بعيد أو خادمٍ أو آلةٍ افتراضية (VM) بغرض إدارته؛ مثلًا تغيير إعداداته، أو قراءة ملفات سجلّاته، أو تثبيت أحدث البرمجيات.
ومن الواضح أنّ المديرين يريدون التأكّد من أنّهم يستطيعون تسجيل الدخول إلى جهازٍ بعيد بأمان، وأنّ الأطراف غير المصرّح لهم لا يستطيعون تسجيل الدخول ولا اعتراض الأوامر المُرسَلة إلى الجهاز ولا المخرجات المُرسَلة إلى المدير.
وهذه حالة استخدام شائعة بما يكفي ليندمج SSH في برمجيات إدارة أكثر تعقيدًا تؤتمت جانبًا ما من العمليات البعيدة.
وهذا هو الحالُ بشكلٍ متزايد مع الأدوات التي تدعم DevOps السحابي، حيث تُعدّ GitHub وDocker وAnsible وJenkins أمثلة شائعة تستعمل خاصية التنفيذ البعيد في SSH.
وتتألف أحدث نسخة مستقرّة من SSH، وهي الإصدار 2، من ثلاثة بروتوكولات:[1]
-
SSH-TRANS، وهو بروتوكول طبقة النقل
-
SSH-AUTH، وهو بروتوكول المصادقة
-
SSH-CONN، وهو بروتوكول الاتصال
ونركّز على البروتوكولين الأولين، إذ إنّهما مشتبكان في الدخول عن بُعد.
ونناقش بإيجاز الغرض من SSH-CONN في نهاية القسم.
يوفّر SSH-TRANS قناةً مشفّرة بين جهازَي العميل والخادم، ويعمل فوق اتصال TCP.
في كلّ مرّة يستخدم فيها مستخدم تطبيق SSH لتسجيل الدخول إلى جهازٍ بعيد، تكون الخطوة الأولى هي إنشاء قناة SSH-TRANS بين الجهازين.
وأنشئ الجهازان هذه القناة الآمنة أوّلًا عندما يقوم العميل بمصادقة الخادم باستخدام RSA.
وبعد المصادقة، ينشئ العميل والخادم مفتاح جلسة (session key) سيستخدمانه لتشفير أيّ بيانات تُرسَل عبر القناة.
وهذا الوصف العامّ يتخطّى عدّة تفاصيل، منها أنّ بروتوكول SSH-TRANS يتضمّن تفاوضًا على خوارزمية التشفير التي سيستخدمها الطرفان.
فمثلًا يُختار AES عادةً.
كما يتضمّن SSH-TRANS فحصًا لسلامة الرسائل يُطبَّق على جميع البيانات المتبادَلة عبر القناة.
لكنّ المسألة الوحيدة التي لا يمكننا تخطّيها هي كيف حصل العميل على المفتاح العام للخادم الذي يحتاجه لمصادقة الخادم.
ولو بدا ذلك غريبًا، فإنّ الخادم يخبر العميل بمفتاحه العام وقت الاتصال.
وفي أوّل مرّة يتّصل فيها العميل بخادمٍ بعينه، ينبّه تطبيق SSH المستخدم إلى أنّه لم يتحدث قطّ مع هذا الجهاز من قبل، ويسأله إن كان يريد المتابعة.
ولو كان الأمر خطِرًا، إذ إنّ SSH عاجزٌ عمليًا عن مصادقة الخادم، فإنّ المستخدمين يجيبون في كثير من الأحيان بـ «نعم» على هذا السؤال.
وتُعرف هذه العمليّة باسم «الثقة عند أوّل استعمال» (Trust on First Use, TOFU).
ثمّ يحفظ تطبيق SSH المفتاح العام للخادم؛ وفي المرّة التالية التي يتّصل فيها المستخدم بالجهاز نفسه، يقارن هذا المفتاح المحفوظ بالمفتاح الذي يرد به الخادم.
فإن كانا متطابقين، فإنّ SSH يصادق الخادم.
أما إن اختلفا، فإنّ تطبيق SSH ينبّه المستخدم مرّةً أخرى إلى أنّ أمرًا ما غير سليم، وتتاح له حينئذٍ فرصة إلغاء الاتصال.
وكبديلٍ عن الثقة عند أوّل استعمال، يمكن للمستخدم الحَذِر تعلّم المفتاح العام للخادم عبر وسيلةٍ خارج النطاق (out-of-band)، وحفظه على جهاز العميل، وبالتالي ألّا يتحمّل مخاطرة «المرّة الأولى» أبدًا.
فمثالًا على ذلك، توجد خيارٌ لنشر بصمات مفاتيح SSH العامة في DNS، وهو ما يطرح بدوره مسألة الثقة في DNS؛ وسنعود إلى هذا الموضوع في الفصل 8.
وبمجرد وجود قناة SSH-TRANS، تتمثّل الخطوة التالية في أن يسجّل المستخدم دخوله إلى الجهاز فعلًا، أو بكلام أدق، أن يوثّق هويّته للخادم.
ويتيح SSH ثلاث آليّات مختلفة لهذا.
فأوّلًا، لأنّ الجهازين يتواصلان عبر قناةٍ آمنة، من الصائب أن يرسل المستخدم بكلمة سرّه إلى الخادم ببساطة.
وهذا ليس أمرًا آمنًا عند استعمال Telnet، لأنّ كلمة السرّ تُرسَل بنصّها الصريح، أمّا في حالة SSH فتُشفَّر كلمة السرّ داخل قناة SSH-TRANS.
وتستخدم الآليّة الثانية التشفير بالمفتاح العام.
وهذا يتطلّب أن يكون المستخدم قد وضع مفتاحه العام على الخادم من قبل.
وتُسمّى الآليّة الثالثة المصادقة المستنِدة إلى المضيف (host-based authentication)، وهي تعنيBasically أنّ أيّ مستخدم يدّعي أنه شخصٌ بعينه قادمٌ من مجموعةٍ معيّنة من المضيفات الموثوقة يُصدَّق تلقائيًّا على أنّه ذلك المستخدم نفسه على الخادم.
وتتطلّب المصادقة المستنِدة إلى المضيف أن يوثّق العميلُ المضيف (host) نفسه للخادم عند أوّل اتصال؛ أمّا SSH-TRANS القياسيّ فلا يوثّق سوى الخادم افتراضيًّا.
والأمر الرئيسيّ الذي ينبغي أن تأخذه من هذا النقاش هو أنّ SSH تطبيقٌ مباشرٌ إلى حدٍّ كبير للبروتوكولات والخوارزميات التي رأيناها في طول هذا الكتاب.
لكنّ ما يجعل فهم SSH تحدّيًا أحيانًا هو جميع المفاتيح التي على المستخدم إنشاؤها وإدارتها، حيث إنّ الواجهة الدقيقة تعتمد على نظام التشغيل.
فمثالًا، تدعم حزمة OpenSSH التي تعمل على معظم أجهزة Unix (مثل Linux وMacOS) أمرًا (ssh-keygen) يمكن استعماله لإنشاء أزواج المفاتيح العامة والخاصة.
ثمّ تُخزَّن هذه المفاتيح في ملفاتٍ مختلفة داخل دليل في مجلد المستخدم الرئيسي.
فمثلًا، يسجّل الملف ~/.ssh/known_hosts مفاتيح كلّ المضيفات التي سجّل المستخدم دخوله إليها، ويتضمّن الملف ~/.ssh/authorized_keys المفاتيح العامة اللازمة لمصادقة المستخدم عند تسجيل الدخول إلى هذا الجهاز (أي أنّها تُستخدَم في جانب الخادم).
أمّا المفاتيح الخاصة اللازمة لمصادقة المستخدم على الأجهزة البعيدة (أي المفاتيح المستخدَمة في جانب العميل) فتُخزَّن في ملفٍّ يتوقّف اسمُه على الخوارزمية.
فمثلًا، يُخزَّن مفتاح RSA في ملف ~/.ssh/id_rsa، ويُخزَّن مفتاح ECDSA في ~/.ssh/id_edcsa وهكذا.
وملفّات هذه يُشفَّر عادةً بعبارة مرورٍ سرّية (secret passphrase) للحماية من احتمال اختراق المفتاح الخاص على يد مهاجمٍ يحصل على الملف.
الشكل 16. استعمال إعادة توجيه منافذ SSH لتأمين تطبيقاتٍ أخرى قائمة على TCP.↗
وأخيرًا، أثبت SSH نفعه في تأمين الدخول عن بُعد إلى حدٍّ واسع، حتى مُدِّدت تدعم تطبيقاتٍ أخرى أيضًا (مثل إرسال البريد واستقباله).
والفكرة هي تشغيل التطبيقات فوق «نفق SSH» آمن.
وتُسمّى هذه القدرة إعادة توجيه المنافذ (port forwarding)، وتستعمل بروتوكول SSH-CONN.
وتُوضَّح الفكرة في الشكل 16، حيث نرى عميلًا على المضيف A يتواصل، بصورةٍ غير مباشرة، مع خادمٍ على المضيف B عبر إعادة توجيه حركته من خلال اتصال SSH.
وتُسمّى الآليّة إعادة توجيه المنافذ لأنّ الرسائل، حين تصل إلى منفذ SSH المعروف على الخادم، يفكّ SSH أوّلًا محتوى الرسائل ثمّ «يعيد توجيه» البيانات إلى المنفذ الفعليّ الذي يستمع عنده الخادم.
وتنشئ إعادة توجيه المنافذ فعليًّا نفقًا آمنًا يوفّر السرّية والمصادقة.
ومن الممكن توفير نوعٍ من الشبكات الخاصة الافتراضية (VPN) باستعمال أنفاق SSH بهذه الطريقة، لكنّها، بخلاف آليّة VPN الموصوفة في القسم التالي، تُنشئ أنفاق إلى جهازٍ بعيدٍ واحدٍ لا إلى شبكةٍ بعيدة.
والأخير يمنحك وصولًا إلى أيّ جهازٍ على الشبكة المحلية.
وعليًا، أيضًا تحجب جدران حماية الشركات غالبًا المنفذ 22 (منفذ SSH المعروف)، ممّا يحدّ من الحالات التي يعمل فيها SSH كنفقٍ شبيه بـ VPN.
7.3 أمن IP
تُعدّ واحدةٌ من أبكر المحاولات لدمج الأمن في الإنترنت تقع في طبقة IP.
والدعم لـ IPsec، وهو اسم هذه البنية، اختياريّ في الإصدار الرابع من بروتوكول الإنترنت إلزاميّ في الإصدار السادس.
وفعلًا كان الأمن الأفضل أحد الأهداف المعلنة للإصدار السادس من بروتوكول الإنترنت، وإنّما اتضح لاحقًا أنّ الأفكار المركزية نفسها أمكن إلحاقها بالإصدار الرابع من بروتوكول الإنترنت.
ومن الجدير بالذكر أيضًا أنّه، وإن كان القصد الأصلي هو أن يكون IPsec جزءًا من تأمين البنية التحتية للشبكة (كما ناقشنا في الفصل التالي)، فإنّ IPsec يُستعمل اليوم في الغالب لتنفيذ أنفاقٍ آمنة تعمل فوق الإنترنت العام.
وكثيرًا ما تكون هذه الأنفاق جزءًا من شبكةٍ خاصة افتراضية (VPN)، على سبيل المثال وصلة مستخدمٍ بعيدٍ بشبكة مؤسسته «الرئيسية».
وسنحوّل انتباهنا إلى شبكات VPN في القسم التالي.
وIPsec في الحقيقة إطارٌ (بخلاف بروتوكولٍ أو نظامٍ مفرد) لتوفير مجموعةٍ واسعة من الخدمات الأمنية.
وهو يوفّر ثلاث درجات من المرونة.
أوّلًا، هو شديد الوحدات (modular)، إذ يسمح للمستخدمين (أو للمديرين على الأرجح) بالاختيار من بين مجموعةٍ متنوعة من الخوارزميات التشفيرية والبروتوكولات الأمنية المتخصّصة.
ثانيًا، يتيح IPsec للمستخدمين الاختيار من قائمةٍ كبيرة من خصائص الأمن، بما فيها التحكّم بالوصول والسلامة والمصادقة والطزاجة والسرّية.
ثالثًا، يمكن استعمال IPsec لحماية تدفّقاتٍ ضيّقة (مثل الحزم التابعة لاتصال TCP معيّن تُرسَل بين زوجٍ من المضيفات) أو تدفّقاتٍ عريضة (مثل كلّ الحزم المتدفّقة بين زوجٍ من الموجّهات أو المواقع).
وعند النظر إليه من مستوى عالٍ، يتكوّن IPsec من جزأين.
أمّا الجزء الأوّل فهو زوجٌ من البروتوكولات التي تنفّذ الخدمات الأمنية المتوفّرة.
وهما ترويسة المصادقة (Authentication Header, AH)، التي توفّر التحكّم بالوصول وسلامة الرسائل غير المتّصلة والمصادقة والحماية من إعادة الإرسال، وحمولة الأمان المغلَّفة (Encapsulating Security Payload, ESP)، التي تدعم هذه الخدمات نفسها، إضافةً إلى السرّية.
ونادرًا ما يُستعمل AH، لذا نركّز هنا على ESP.
أمّا الجزء الثاني فهو دعم إدارة المفاتيح، وهو يقع تحت بروتوكولٍ شاملٍ (umbrella) معروف باسم بروتوكول جمعيات أمن الإنترنت وإدارة المفاتيح (Internet Security Association and Key Management Protocol, ISAKMP).
والتجريدُ الذي يربط هاتين القطعتين معًا هو جمعية الأمن (security association, SA).
و SA هي وصلةٌ أحاديّ الاتجاه مع خاصيةٍ واحدة أو أكثر من خصائص الأمن المتوفّرة.
وتأمين اتصالٍ ثنائي الاتجاه بين زوجٍ من المضيفات — يقابل مثلًا اتصال TCP — يتطلّب SA اثنتين، واحدة في كلّ اتجاه.
ولو كان IP بروتوكولًا غير متّصل، فإنّ الأمن يعتمد على معلومات حالة الاتصال مثل المفاتيح وأرقام التسلسل.
وعند إنشاء SA يُسنَد إليها الجهاز المستقبِل رقم تعريفٍ يُسمّى فهرس معاملات الأمن (security parameters index, SPI).
وتولّد هذه المجموعة من SPI مع عناوين IP الوجهة تعريفًا فريدًا لـ SA.
وتتضمّن ترويسة ESP قيمة SPI، فيتمكّن المضيف المستقبِل من تحديد SA التي تنتمي إليها الحزمة الواردة، وبالتالي الخوارزميات والمفاتيح التي ينبغي تطبيقها عليها.
وتُنشأ SA ويُتفاوض عليها وتُعدَّل وتُحذف باستخدام ISAKMP.
وهو يعرّف صيغ حزم لتبادل بيانات توليد المفاتيح والمصادقة.
وهذه الصيغ ليست مثيرًا للاهتمام على نحوٍ كبير لأنّها توفّر إطارًا فقط — إذ إنّ الصيغة الدقيقة للمفاتيح وبيانات المصادقة تعتمد على تقنية توليد المفاتيح والشيفرة وآليّة المصادقة المستخدَمة.
وإضافةً إلى ذلك، لا يحدّد ISAKMP بروتوكولًا معيّنًا لتبادل المفاتيح، وإنّما يقترح تبادل مفاتيح الإنترنت (Internet Key Exchange, IKE) بوصفه أحد الاحتمالات، والإصدار الثاني منه هو ما يُستعمل عمليًّا.
وESP هو البروتوكول المستخدَم لنقل البيانات بأمان عبر SA قائمة.
وفي الإصدار الرابع من بروتوكول الإنترنت، تأتي ترويسة ESP بعد ترويسة IP؛ وفي الإصدار السادس فهي ترويسة تمديد.
وتستعمل صيغتها ترويسةً ولاحقةً معًا، كما هو مبيّن في الشكل 17.
ويتيح حقل SPI للمضيف المستقبِل تحديد جمعية الأمن التي تنتمي إليها الحزمة.
ويحمي حقل SeqNum من هجمات إعادة الإرسال.
ويتضمّن حقل PayloadData في الحزمة البيانات التي يصفها حقل NextHdr.
وإذا كانت السرّية مختارة، فإنّ البيانات تُشفَّر باستخدام الشيفرة المرتبطة بـ SA.
يسجّل حقل PadLength مقدار الحشو (padding) الذي أُضيف إلى البيانات؛ ويُحتاج الحشو أحيانًا لأنّ الشيفرة، مثلًا، تتطلّب أن يكون النص الصريح من مضاعفات عددٍ معيّنٍ من البايتات، أو لضمان أن ينتهي النص المشفَّر عند حدٍّ من حدود 4 بايتات.
وأخيرًا، يحمل حقل AuthenticationData بيانات المُوثِّق.
الشكل 17. صيغة ESP في IPsec.↗
يدعم IPsec وضع النفق (tunnel mode) إلى جانب وضع النقل (transport mode) الأكثر وضوحًا.
وتعمل كلّ SA في أحد الوضعين.
وفي SA بوضع النقل، تكون بيانات حمولة ESP ببساطة رسالةً موجَّهة إلى طبقةٍ أعلى مثل UDP أو TCP.
وفي هذا الوضع، يتصرّف IPsec بوصفه طبقة بروتوكولٍ وسيطة، تمامًا كما يفعل SSL/TLS بين TCP وطبقةٍ أعلى.
وعند تلقّي رسالة ESP، تُسلَّم حمولتها إلى البروتوكول الأعلى مستوى.
أمّا في SA بوضع النفق، فإنّ بيانات حمولة ESP هي نفسها حزمة IP، كما في الشكل 18.
قد يكون المصدر والوجهة لهذه الحزمة الداخلية من IP مختلفين عنهما في الحزمة الخارجية.
وعند تلقّي رسالة ESP، تُعاد حمولتها مُوجَّهةً بوصفها حزمة IP عادية.
والطريقة الأكثر شيوعًا لاستخدام ESP هي إنشاء «نفق IPsec» بين موجّهين، وغالبًا ما يكونان جداري حماية.
فمثلًا، إذا أرادت شركةٌ ربط موقعين باستخدام الإنترنت، أمكنها ذلك بفتح زوجٍ من SA بوضع النفق بين موجّه في موقعٍ وموجّه في الموقع الآخر.
وتصير أيّ حزمة IP صادرة من أحد المواقع، عند الموجّه الصادر، حمولةً لرسالة ESP مُرسَلة إلى موجّه الموقع الآخر.
والموجّه المستقبِل يفكّ تغليف حزمة IP المحمّلة ويعيد توجيهها إلى وجهتها الحقيقيّة.
الشكل 18. حزمة IP يتضمّن في داخلها حزمة IP أخرى مغلَّفة باستخدام ESP في وضع النفق. لاحظ أنّ للحزمتين الداخليّة والخارجيّة عناوين مختلفة.↗
كما يمكن تهيئة هذه الأنفاق لتستعمل ESP مع السرّية والمصادقة، فضلًا عن ذلك تمنع الوصول غير المصرّح به إلى البيانات التي تعبر هذه الوصلة الافتراضية وتضمن ألّا تتلقّى الطرفية البعيدة أيّ بيانات زائفة.
وعلاوةً على ذلك، يمكن للأنفاق أن توفّر سرّية الحركة، إذ إنّ مضاعفة عدة تدفّقات عبر نفقٍ واحد تحجب معلومات عن كمّية الحركة المتدفّقة بين نقاط نهاية بعينها.
وكما أشرنا أعلاه، يمكن لشبكةٍ من هذه الأنفاق أن تُستخدم لتنفيذ شبكة خاصة افتراضية كاملة.
لكنّ في شبكات VPN أكثر من آليّات الأنفاق فحسب، كما سنناقش تاليًا.
7.4 الشبكات الخاصة الافتراضية
يمكن بناء شبكةٍ خاصة افتراضية (VPN) باستخدام مجموعةٍ واسعة ومتنوّعة من التقنيات المختلفة، لكنّ أيّ VPN تتطلّب إنشاء اتصال بين مجموعةٍ من نقاط النهاية. ويجب أن توفّر الاتصالات هذه قدرًا من الخصوصية للجهات (principals) التي تتواصل بين نقاط النهاية تلك.
وإضافةً إلى ذلك، لكي تستحقّ صفة الخاصة الافتراضية، تخلق VPN وهمًا بأنها مخصَّصة لمجموعةٍ من المستخدمين، وإنّما البنية التحتية في الواقع مشتركةٌ على نطاقٍ أوسع.
وعليًا، يعني هذا أنّ VPN تُبنى دائمًا تقريبًا بوصفها نوعًا من الطبقات (overlay) فوق بنيةٍ تحتيةٍ مشتركة.
اقتُرح أيضًا الإصدار الثالث من SSH (SSH3)، لكنّه جهدٌ تجريبيّ حاليًّا يغيّر البروتوكولات الأساسية التي يستعملها SSH. فمثلًا، يعمل SSH3 فوق QUIC (القائم على UDP) بدلًا من TCP. ويبقى SSH2 هو المعيار المعتمد على نطاقٍ واسع. ↩︎