تاريخ عملي لجدار الحماية - الجزء 1: الأيام الأولى

Jody Brazil
الرئيس التنفيذي في FireMon

هذه المقالة ليست مقدمة تعريفية عن جدران الحماية، وليس المقصود منها تقديم صورة شاملة عن تاريخ جدار الحماية. فهناك الكثير من المصادر الجيدة التي تستعرض تاريخ جدار الحماية، ومنها على سبيل المثال ويكيبيديا: https://en.wikipedia.org/wiki/Firewall_(computing). كما أن هناك عددًا كبيرًا من الأشخاص الذين يستحقون التقدير لابتكار جدار الحماية ولم تتم الإشارة إليهم في هذه السلسلة (وإن كنتم مهتمين، فهذه قصة جيدة من Dark Reading: من اخترع جدار الحماية). وينصبّ تركيزي على جدار الحماية التجاري وديناميكيات السوق التي أدّت إلى تبنّي هذه التقنيات.

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

في منتصف التسعينيات، أطلقت Check Point Technologies جدار الحماية القائم على الفحص الحالتي (stateful inspection). وكانت المنافسة الرئيسية في ذلك الوقت تشمل مرشّحات الحزم المدمجة في الموجّهات (مثل قوائم التحكم في الوصول ACL على Cisco IOS) والوكلاء (proxies) (مثل جدار الحماية TIS Gauntlet وجدار الحماية Secure Computing Sidewinder). وقد دارت المعركة الكبرى بين الفحص الحالتي والوكلاء على ثلاث جبهات: الأداء، ودعم البروتوكولات، والأمن.

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

وعلى صعيد دعم البروتوكولات، كان الفحص الحالتي قابلًا للتكيّف بسهولة وغالبًا دون أي تعديلات على الشيفرة المصدرية. أما الوكلاء، فكانوا في المقابل يحتاجون غالبًا إلى مكدسات خاصة بكل بروتوكول لدعم تطبيق جديد. وفي أواخر التسعينيات، لم يكن هناك سوى قدر ضئيل جدًا من التوحيد القياسي. فإذا كتبتم تطبيقًا جديدًا، كنتم غالبًا تنشئون خدمة جديدة (مزيج من البروتوكول/المنفذ - مثل tcp/3192). ولم تكن فكرة استخدام HTTP كوسيلة نقل مشتركة لجميع التطبيقات مقبولة لأسباب كثيرة، منها تبعات الأداء وغياب الاتصال المتزامن في مواصفات HTTP المبكرة. وهذا يعني أن بروتوكولات جديدة كانت تُنشأ وتُنشر بوتيرة سريعة للغاية. ونتيجة لذلك، تجاوز طلب العملاء على دعم هذه البروتوكولات الجديدة قدرة جدران الحماية القائمة على الوكلاء على إضافة الدعم.

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

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

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

الجزء 2: قيمة الإدارة