Sophos Firewall: لا توجد CVEs، ولكنها مليئة بالأخطاء البرمجية (من v21.5 إلى v22)

3 مارس 2026 • 21 min read

جدول المحتويات

إذا كنت تعمل حاليًا في مجال جدران الحماية (Firewalls)، فغالبًا ما ستجد نفسك تكافح أحد شرين رئيسيين: إما أنك تحت ضغط مستمر بسبب الثغرات الأمنية الحرجة (CVEs، كما هو الحال حاليًا مع Fortinet) وتقضي لياليك في تطبيق التصحيحات (Patching) - أو أن الأنظمة تضع العديد من العقبات في طريقك أثناء العمليات اليومية المنتظمة بسبب البرامج الثابتة (Firmware) غير المستقرة والأخطاء البرمجية المزعجة (كما يحدث حاليًا مع Sophos) لدرجة أنك لا تستطيع إنجاز أي شيء آخر.

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

في حين يبدو أن المنافسين مثل Fortinet يصدرون إشعارات PSIRT جديدة أسبوعيًا، مما يبقي مسؤولي النظام (Administrators) يدورون في حلقة مستمرة من تطبيق التصحيحات، فإن Sophos تستهلك وقتنا بشكل هائل. ليس بسبب الثغرات الأمنية التي تتصدر عناوين الأخبار، ولكن بسبب أخطاء برمجية يومية عادية جدًا، ولكنها بالغة الأهمية في العمليات اليومية.

تنويه (Disclaimer)، حتى لا يبدو هذا وكأنني أقارن التفاح بالبرتقال: أدرك تمامًا أن Fortinet تكافح أيضًا مع أخطاء برمجية ضخمة (فكر في Conserve Mode وتسرب الذاكرة (Memory Leaks) في FortiOS 7.2/7.4/7.6) وأن Sophos كان لديها أيضًا نصيبها من ثغرات CVE الخطيرة في الماضي. ومع ذلك، في مرحلة v21.5/v22 الحالية، هذا الموقف بالذات هو ما يؤلمنا: مع بائع واحد، يتمثل الأمر في تطبيق تصحيحات CVE باستمرار؛ أما مع Sophos، فهو عمل تشغيلي (Ops-Work) غير ضروري ناتج عن مشاكل الاستقرار.

سياق الإصدار (باختصار)

فقط لتوضيح أنني لا أكتب عن إصدار v19 قديم يعلوه الغبار، بل عن ما يقوم العديد بتشغيله حاليًا باعتباره “مُحَدَّثًا”:

SFOS 21.5 GA (02.06.2025): ملاحظات الإصدار: SFOS 21.5
SFOS 21.5 MR2 (Build 323, 18.02.2026): وفقًا لملاحظات الإصدار، هذا هو أحدث إصدار 21.5 في هذه الفترة الزمنية.
SFOS 22.0 GA (ديسمبر 2025) و v22 GA Re-Release (Build 411, 20.01.2026): ملاحظات الإصدار: SFOS 22.0

هذه إصدارات توفر عام (GA) وإصدارات صيانة (Maintenance Releases)، وليست إصدارات ليلية (Nightlies) عشوائية.

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

Fortinet: ثغرات FortiOS CVE منذ نوفمبر 2025 (اعتبارًا من 26.02.2026)

الإطار الزمني: 01.11.2025 إلى 26.02.2026 (تاريخ النشر). المصدر: إشعارات Fortinet PSIRT (نظرة عامة على PSIRT).

أنا أتعمد عدم إدراج “كل شيء يخص Fortinet” هنا، ولكن فقط الإشعارات ذات الصلة بـ FortiOS/FortiGate في هذه الفترة، لأنه في الممارسة العملية، هنا تكمن المعاناة: يجب عليك التصحيح، التخطيط، الاختبار.

نقاط CVSS ليست كل شيء، لكنها تجعل التباين التشغيلي مرئيًا: غالبًا ما يمكن التخطيط لمستوى متوسط (Medium) بنقاط 5.x، في حين يصبح مستوى 9.x بسرعة سيناريو “اترك كل شيء وطبق التصحيح”.

نُشر في 10 فبراير 2026 (إشعارات متعددة في نفس اليوم)

FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): تهريب الطلبات (Request smuggling) في واجهة المستخدم الرسومية لـ FortiOS. أمر مزعج أيضًا لأنه يتضمن “طلبات غير مسجلة (unlogged requests)”.
FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): مشكلة سلسلة التنسيق (Format-String) في وضع تجاوز الفشل السريع CAPWAP (Admin/Config كمحفز).
FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): تجاوز مصادقة LDAP في Agentless VPN/FSSO (الحل البديل (Workaround) في الممارسة غالبًا: تعطيل الربط غير المصادق عليه (unauthenticated bind) على خادم LDAP).
FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): تجاوز تصحيح استمرار الارتباط الرمزي (Symlink Persistence) لـ SSL VPN. مهم للسياق: وفقًا للإشعار، يتطلب الأمر اختراقًا مسبقًا عبر ثغرة أمنية أخرى على مستوى نظام الملفات.
FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): تجاوز السياسة في وكيل خدمات المحطة الطرفية FSSO (الإصلاح عبارة عن مجموعة من إصدار FortiOS والحد الأدنى لإصدار وكيل TS).

يناير 2026

FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4)، نُشر في 27.01.2026: تجاوز مصادقة SSO الإدارية لـ FortiCloud. يصف الإشعار أيضًا الاستغلال في البرية (in the wild) والتدابير المضادة المحددة.
FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4)، نُشر في 13.01.2026: تجاوز سعة المخزن المؤقت المستند إلى الكومة (Heap-based buffer overflow) في البرنامج الخفي cw_acd (FortiOS/FortiSwitchManager).

نُشر في 9 ديسمبر 2025

FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): تجاوز مصادقة تسجيل الدخول إلى FortiCloud SSO عبر رسالة SAML تم التلاعب بها (الميزة ليست إلزامية افتراضيًا، ولكنها حقيقية في الميدان).
FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): انتهاء صلاحية الجلسة بشكل غير كافٍ في SSL VPN (عمر الجلسة/حالة الحافة لتغيير كلمة المرور).
FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): تنتهي المعلومات الحساسة في سجلات REST API (إذا كان تسجيل REST API نشطًا).
FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): يمكن للمسؤول قراءة المفتاح الخاص (Private key) (خطأ في إدارة المفاتيح، يمكن إصلاحه عبر مستوى التصحيح).

نُشر في 18 نوفمبر 2025

FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): تجاوز سعة المخزن المؤقت للمكدس (Stack buffer overflow) في البرنامج الخفي CAPWAP.
FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): تجاوز سعة المخزن المؤقت للمكدس في البرنامج الخفي CAPWAP آخر.
FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): تجاوز المضيفين الموثوق بهم (Trusted hosts) عبر SSH (حالة حافة CLI).

نعم، هذا كثير. ونعم، يمكنك إدارة ذلك من خلال العمليات (نوافذ التصحيح (Patch Window)، التجهيز (Staging)، إدارة التغيير (Change Management)، نوافذ الصيانة).

ثم يأتي الجانب الآخر.

Sophos: لا توجد عناوين رئيسية، ولكن العمليات (Operations) تشتعل فيها النيران

مع Sophos، نتحدث بالطبع عن الأمان أيضًا. ولكن ما يلتهم وقتنا حقًا في الوقت الحالي هو مجرد الأخطاء البرمجية (Bugs).

لدينا حاليًا الكثير من العمل غير الضروري في الشركة لأن جدار الحماية (Firewall) يسبب مشاكل ببساطة. وفي مرحلة ما، تجد نفسك تطرح سؤالاً سخيفًا في الواقع:

ما الذي أفضله: جدار حماية به ثغرة أمنية ولكنه يعمل بشكل مستقر، أم جدار حماية بدون عناوين رئيسية كبيرة لثغرات CVE ولكنه لا يعود للعمل بعد إعادة التشغيل (Boot)؟

هذا ليس نقاشًا أكاديميًا. هذا هو واقع العمليات (Operations). للأسف، أنا الآن أفضل تقريبًا وجود ثغرة أمنية نظرية قد يتم استغلالها في وقت ما على عميل تتعطل شبكته بالكامل لعدة ساعات بسبب خطأ برمجي (Bug) تافه.

نقاط الألم الحالية لدينا (نعم، كلها في وقت واحد)

وللتوضيح: هذه مجرد الأخطاء البرمجية التي واجهناها عدة مرات وعلى أنظمة مختلفة في الأشهر الأخيرة. إنه أمر مرهق ومحبط عندما تتحول العمليات اليومية إلى مشروع بحد ذاته. خاصة عندما ينتهي بك المطاف في دوامة دعم Sophos مرة أخرى، حيث يحبون التظاهر بأنك “العميل الأول والوحيد في جميع أنحاء العالم الذي يواجه هذه المشكلة بالضبط”. لا، لسنا كذلك.

في بعض الأحيان لا يعمل جدار الحماية بشكل نظيف بعد إعادة التشغيل.
ينهار تجمع التوافر العالي (HA-Cluster) أو يتصرف مثل الدماغ المنقسم (Split-Brain).
يصبح التسجيل (Logging) فجأة غير موثوق (أو يختفي تمامًا).
لا يتم تجديد شهادات Let’s Encrypt، ويجب عليك متابعتها يدويًا في الليل.
اختفاء واجهة (Interface) أو عدم ظهورها فجأة في واجهة المستخدم الرسومية (GUI).
محركات الأقراص ذات الحالة الصلبة (SSD) تموت (أجهزة مكسورة).
تسجيل دخول WebAdmin يضرب عن العمل تمامًا - لم يعد بإمكانك تسجيل الدخول، وغالبًا ما تساعد إعادة التشغيل فقط.
تختفي الواجهات فجأة تمامًا من التكوين (Config).
يمتلئ قرص السجل (Log-Disk)، مما يتسبب في ظهور رسائل خطأ أو توقف الخدمات المتأثرة مباشرة.

ماذا يقول المجتمع (أنت لست وحدك!)

إذا نظرت حولك في مجتمع Sophos (اعتبارًا من أوائل عام 2026)، فإن صورة انخفاض الجودة تتوافق للأسف مع تجاربنا. بالإضافة إلى مشاكلنا، يواجه مستخدمون آخرون عقبات (Showstoppers) أشد قسوة في v21.5 / v22:

ملفات تعريف SSL-VPN مكسورة (v22.0 Build 411): أبلغ بعض المستخدمين أنه بعد الترقية إلى أحدث إصدار v22، يفشل إنشاء ملفات تعريف SSL-VPN. اضطروا أحيانًا إلى التراجع (Rollback) إلى v21.5 لأن الإصدار الجديد مليء بالأخطاء بكل بساطة.
تعطل SNAT / الوصول إلى خادم الويب (v22.0 Build 365): هناك تقارير تفيد بأنه بعد التحديث، ينقطع الوصول إلى خوادم الويب الداخلية من الخارج. غالبًا ما يضرب توجيه الإنترنت (Internet-Routing) عن العمل تمامًا حتى يتم إعادة تعيين SNAT يدويًا إلى خيار MASQ الافتراضي.
بريد مزعج في CLI / “Invalid rule id”: تظهر تحذيرات ضخمة مثل “Invalid rule id or family for update” في وحدة التحكم (Console). (يبدو أن هذا “مجرد” خطأ في العرض، ولكنه يغمر السجلات بلا معنى).

والجزء المرير في كل هذا: كل واحد من هذه الأشياء ليس مزعجًا فحسب، بل يمثل خطرًا هائلاً. إذا كانت السجلات مفقودة، فأنت تطير أعمى. إذا كان التوافر العالي (HA) مهتزًا، فستفقد الثقة في تجاوز الفشل (Failover). إذا لم يتم تجديد الشهادات، فإنك تبني حلولاً بديلة (Workarounds). والحلول البديلة هي أرض خصبة للحوادث اللاحقة.

أخطاء Sophos البرمجية (v21.5 إلى v22): ما يضرب أعراضك مباشرة

أقوم هنا عمدًا بإدراج معرفات NC (NC-IDs) محددة من ملاحظات الإصدار (Release Notes) الرسمية أو المشكلات المعروفة (Known Issues) الموثقة رسميًا حتى تتمكن، كمسؤول نظام، من تتبع ذلك بوضوح.

باختصار (TL;DR): العرض -> ماذا تقول الملاحظات

العرض في العمليات (Ops)	أمثلة من ملاحظات الإصدار / المشكلات المعروفة
التمهيد/إعادة التشغيل (Boot/Restart) لا يعمل بشكل نظيف	NC-151715, NC-152641, NC-123910
التوافر العالي (HA) يهتز أو يصاب بالذعر أثناء تجاوز الفشل	NC-142962, NC-132291, NC-147307, NC-147739, NC-149039
السجلات/التقارير مفقودة أو غير موثوقة	NC-158526, NC-160962, NC-157663, NC-169237, NC-135594, NC-175936, NC-170292, NC-166381
Let’s Encrypt/WAF يسبب ضغطًا	NC-148937, NC-152022, NC-140663, NC-141062, NC-152540, NC-146082, NC-159041
Entra SSO/Captive Portal/VPN Portal تتصرف بغرابة	NC-167126, NC-157635, NC-167130, NC-167128
VPN/IPsec لا يعمل أو ينقطع التوافق (Interop)	NC-136352, NC-128116
انقطاع حركة المرور (Traffic Drops) بدون سبب واضح في القواعد	NC-169842 (وضع في اعتبارك IPS/Snort كسبب بعد الترقيات)
واجهة “مفقودة” (UI)	مشكلة معروفة: أسماء الواجهات التي تنتهي بـ 10 أرقام أو أكثر تجعل الواجهات غير مرئية في عرض WebAdmin

قصة محبطة من واقع العمليات

نجلس هناك في الصباح نفعل ما تفعله دائمًا: العمل على التذاكر، التخطيط للتغييرات، قراءة المراقبة (Monitoring).

ثم يطرق جدار الحماية الباب، دون أن يطرق.

ليس من خلال ثغرة CVE، وليس من خلال “تحذير حرج” (Critical Advisory). بل من خلال الحياة اليومية.

القهوة الأولى، أول إعادة تشغيل، والسؤال في رأسك: هل سيعمل مرة أخرى أم لا؟

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

التوافر العالي (HA). وسادتك الهوائية (Airbag). وفي بعض الأحيان يبدو الأمر وكأن الوسادة الهوائية تنتفخ أثناء ركن السيارة.

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

ثم تأتي العقبة الكبرى (Showstopper): WAF، الوكيل العكسي (Reverse Proxy)، Let’s Encrypt.

أنت لا تريد حتى أن تكون مبهرجًا. كل ما تريده هو أن يتم تجديد الشهادات وألا تصرخ مواقع الويب الخاصة بك “connection refused” في الساعة 02:13 صباحًا.

وكعلاوة، “تختفي” واجهة. لم تختفِ حقًا، لقد اختفت فقط في واجهة المستخدم (UI). ربما لا تزال حركة المرور (Traffic) تعمل، لكنك لا تستطيع رؤية ما تحتاج إلى تصحيح أخطائه (Debug).

في مرحلة ما، تطرح على نفسك هذا السؤال السخيف في الواقع:

ما الذي أفضله: جدار حماية به ثغرة أمنية ولكنه يعمل بشكل مستقر، أم جدار حماية بدون عناوين رئيسية كبيرة لثغرات CVE ولكنه يحرق ثقوبًا جديدة في أرضيتي التشغيلية كل أسبوع؟

1) التمهيد، إعادة التشغيل، الترقية: “إنه حي، لكنه لا يعمل”

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

بعض الأمثلة من ملاحظات إصدار SFOS 21.5:

Failsafe أثناء إعادة التشغيل: NC-151715 (إدارة البرامج الثابتة): انتقل الجهاز المساعد (Auxiliary) إلى حالة Failsafe أثناء إعادة التشغيل؛ فشلت إعادة التشغيل.
تتوقف حركة المرور بعد الترقية: NC-152641 (إدارة البرامج الثابتة): بعد الترقية (من 21.0 MR1 Build 237)، لم تعد تتم معالجة أي حركة مرور (تغييرات تكوين ذاكرة SWAP).
ذعر النواة (Kernel Panic): NC-123910 (جدار الحماية): مشكلة ذعر النواة.

ونعم: يقدم SFOS 22.0 عامل ترقية إضافيًا: يشير Sophos في ملاحظات الإصدار إلى أن الإصدار v22 يجلب تغييرات معمارية وأنه في حالات نادرة قد تكون هناك حاجة لخطوات يدوية إضافية. هذا هو بالضبط نوع حالة حافة الترقية (Upgrade-Edge-Case) الذي يؤلم في العمليات.

2) HA: الوسادة الهوائية التي تنتفخ أثناء الركن

التوافر العالي (HA) هو شبكة الأمان الخاصة بك. وهذا هو بالضبط سبب الألم الشديد عندما تتصاعد حالات الحافة هناك بالضبط.

من ملاحظات إصدار SFOS 21.5 (مختارات):

يتوقف تتبع أحداث HA عند عمليات إعادة التشغيل المتزامنة: NC-142962 (HA).
يتوقف تحميل البرامج الثابتة على الجهاز السلبي (Passive): NC-132291 (HA).
يؤدي تجاوز الفشل (Failover) إلى حلقة إعادة تشغيل (Restart Loop): NC-147307 (HA) (مذكور بوضوح في الملاحظات، على سبيل المثال XGS 2300).
فشل المزامنة (Sync) بعد انقطاع التيار الكهربائي (Power Outage): NC-147739 (HA).
حالة HA ترفرف (Flapped)، تفريغ الأعطال (Crash Dump) على الرابط المخصص: NC-149039 (HA).

3) التسجيل والتقارير: عندما تطير أعمى

بالنسبة لي، هذا هو السبب الحقيقي وراء كون “الأخطاء البرمجية” ليست مجرد مسألة “تشغيلية”. عندما يكون التسجيل/إعداد التقارير مهتزًا، فهذه مشكلة أمنية.

من ملاحظات إصدار SFOS 21.5 (مختارات):

يتوقف التسجيل/إعداد التقارير بشكل متقطع؛ حدوث coredump لـ Garner بشكل متكرر: NC-158526 (إطار عمل التسجيل).
توقف Garner و fwcm-heartbeatd: NC-160962 (إطار عمل التسجيل).
بعد الترقية: لا توجد المزيد من التقارير: NC-157663 (إطار عمل التسجيل).
يفقد Log Viewer الأحداث بسبب تلف قاعدة البيانات (DB Corruption): NC-169237 (إطار عمل التسجيل).
تلف واصف ملف Syslog (fd)، تذهب البيانات إلى FD خاطئ: NC-135594 (إطار عمل التسجيل).

بالإضافة إلى ذلك، ستجد بعض العناصر في قائمة المشكلات المعروفة (KIL) الخاصة بـ Sophos والتي تسبب نفس القدر من الألم في الحياة اليومية:

لا يُظهر Log Viewer بيانات جديدة (active.db مفقود): NC-175936 (إطار عمل التسجيل). في بعض أنظمة 21.5.1، قد يكون ملف active.db ضمن مسار /tmp/eventlogs/ مفقودًا. ثم “يتجمد” Log Viewer، على الرغم من استمرار عمل وظائف حركة المرور والأمان. وفقًا لـ KIL، تم إصلاح هذا في v22 ويجب تضمينه في إصلاح 21.5 MR2.
إيجابية كاذبة (False Positive) لـ “advanced threat detected” في HA: NC-170292 (إطار عمل التسجيل). يمكن لـ Sophos Central إرسال تنبيه في عمليات نشر HA، بما في ذلك السجلات الأولية (Raw logs) في الوصف. الحل البديل (Workaround) وفقًا لـ KIL: أعد تشغيل خدمة Garner. قاعدة المعرفة KBA: https://support.sophos.com/support/s/article/KBA-000043672
يُظهر ReportDB_v9 حالة STOPPED (يبدو الأمر دراماتيكيًا، لكنه ليس كذلك): NC-166381 (التقارير). بعد الترقية إلى v21.0 GA أو أحدث، تظهر الخدمة كـ STOPPED بعد فترة زمنية محددة للغاية. وفقًا لـ KIL، هذا متوقع وليس له تأثير تشغيلي لأنه يؤثر فقط على التقارير القديمة (Legacy) قبل الإصدار v21.

وهنا يأتي “عامل Sophos Central”: إذا كنت تستخدم Central كلوحة زجاجية واحدة (Single Pane of Glass) لإدارتك، فإن مشكلة التسجيل تؤلم بشكل مضاعف. إذا سقط خط أنابيب التسجيل المحلي (Garner/DB)، فقد يفشل التحميل إلى Central Firewall Reporting (CFR) أيضًا أو يتوقف. وعلى أي حال، CFR ليس دائمًا “بالوقت الفعلي” (Realtime). المعنى: في أسوأ الحالات، لا تفتقر إلى السجلات المحلية فحسب، بل تفتقر أيضًا إلى العرض المركزي الدقيق الذي كنت ترغب فعليًا في الاعتماد عليه في الحياة اليومية.

4) WAF و Let’s Encrypt: خدمة عامة، ولكن بدون دراما من فضلكم

عندما لا يتم تجديد الشهادات ويخرج الوكيل العكسي (Reverse Proxy) عن السيطرة، فهذا ليس “خطأ برمجيًا صغيرًا”. هذا تأثير مباشر على العملاء (Customer Impact).

في ملاحظات إصدار SFOS 21.5، ستجد عائلة كاملة من مشاكل WAF/Let’s Encrypt:

فشل إنشاء شهادة Let’s Encrypt: NC-148937 (WAF).
يفشل طلب LE بسبب عدم وجود Auto-Firewall-Rule: NC-152022 (WAF).
يؤدي تكوين LE غير الصالح إلى إعادة تشغيل الوكيل العكسي باستمرار: NC-140663 (WAF).
لا تُصدر ACME شهادات لعناوين IP: NC-141062 (WAF).
يتم تشغيل/إيقاف قاعدة WAF تلقائيًا: NC-152540 (WAF).

ثم هناك مواضيع “تبدو كأخطاء برمجية، ولكنها مقايضة أمنية (Security-Tradeoff)”. مثال من KIL:

الشرطات المائلة المشفرة (%2F) في عناوين URL: يعرض WAF خطأ 404: NC-159041 (WAF). إذا كان تطبيقك يستخدم شرطات مائلة مشفرة في عنوان URL، فإن Apache يحظر هذا افتراضيًا (يتم تعيين التوجيه AllowEncodedSlashes افتراضيًا على No) وترى 404، على الرغم من أن الواجهة الخلفية تمتلك المسار “فعليًا”. الخلفية: يمكن للشرطات المائلة المشفرة تجاوز قيود المسار (المثال الكلاسيكي: .../something%2F..%2Fadmin). التفاصيل: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

وإذا كنت تريد أن تعرف كيف يبدو هذا في الميدان: في موضوع المجتمع (Community Thread) هذا، يصف شخص ما أنه بعد الترقية إلى 21.5.x، “اختفت” شهادات التجديد التلقائي، ولم يبدأ WAF، وماتت مواقع الويب مع ظهور خطأ ERR_CONNECTION_REFUSED. كان الحل في النهاية هو: تنظيف قواعد حماية الويب (Web Protection Rules) وحذف طلبات توقيع شهادة (CSR) لـ LE المعطلة، وبعد ذلك عمل النظام مرة أخرى. (الموضوع: فشل WAF/Let’s Encrypt بعد الترقية، ERR_CONNECTION_REFUSED).

وأحيانًا لا يكون حتى “خطأً برمجيًا” (Bug)، بل هو عملية: في مجتمع Sophos، كانت هناك أيضًا حالات تم فيها تمييز شروط خدمة Let’s Encrypt (Terms of Service) منتهية الصلاحية في WebAdmin وكان لا بد من قبولها مرة أخرى. (الموضوع: Let’s Encrypt Terms of Service have expired).

لعبة “فخ ترقية (Upgrade-Trap)” كلاسيكية إضافية من قائمة المشكلات المعروفة (KIL): يمكن أن تفشل الترقية إذا كانت الشهادة المدمجة (Onboard-Zertifikat) تحمل بالفعل نفس اسم شهادات Let’s Encrypt التي تم إدخالها حديثًا في متجر CA (رقم الخطأ NC-146082).

5) “واجهة مفقودة” (أو مخفية فقط)

هذا هو نوع الخطأ الذي يبدو جافًا في ملاحظات الإصدار، ولكنه يجبرك على الطيران الأعمى (Blind flight) في الممارسة العملية.

موثق رسميًا كـمشكلة معروفة (Known Issue):

إذا كانت واجهة مادية أو منطقية في SFOS 21.5 GA والإصدارات الأحدث تحمل تسمية تنتهي بـ 10 أرقام أو أكثر (مثال في الملاحظات: VLAN_1234567890)، فإن الواجهات المادية لا تظهر في WebAdmin ضمن الشبكة > الواجهات، أو لا يمكن توسيع الواجهات المنطقية. هام: وفقًا لملاحظات الإصدار، لا تتأثر الوظيفة نفسها، بل العرض فقط في وحدة تحكم WebAdmin.

استنتاج مؤقت (حتى هنا): التمهيد/الترقية، التوافر العالي (HA)، التسجيل/إعداد التقارير، WAF/Let’s Encrypt، وحتى واجهة المستخدم (UI) يمكن أن تعرقلك جميعها في نفس الوقت. من هنا تأتي الموضوعات التي تبدو في البداية وكأنها “تفاصيل الشبكة” ولكنها مكلفة من الناحية التشغيلية بنفس القدر: Entra SSO، توافق VPN (Interop)، والانقطاعات التي تبدو عشوائية في حركة المرور.

6) الهوية/تسجيل الدخول الموحد (Entra) والبوابة المقيدة (Captive Portal): عندما يبدو الوصول “عشوائيًا”

هذه هي فئة الأخطاء البرمجية الغادرة بشكل خاص في العمليات: بالنسبة للمستخدم، يبدو الأمر وكأن “حسابي يتصرف بغرابة”. بالنسبة لك، يبدو “أنها مجرد مشكلة SSO”. في الواقع، غالبًا ما يكون جدار الحماية هو الذي يقف في المنتصف.

بعض المشكلات المفتوحة من KIL إذا كان Microsoft Entra ID (Azure AD) موجودًا في مزيج تقنياتك:

Sophos Connect VPN: الوصول المشروط (Conditional Access) غير مدعوم بالكامل: NC-167126 (المصادقة). بعد تحدي MFA الأولي عند تسجيل الدخول الأول، لا يتم بالضرورة تشغيل فحوصات الوصول المشروط في كل اتصال لاحق. وفقًا لـ KIL، لا يتم تطبيق السياسة مرة أخرى حتى يسجل المستخدم الخروج يدويًا في عميل Sophos Connect.
VPN SSO: يختلف UPN والبريد الإلكتروني، وينكسر تسجيل الدخول: NC-157635 (المصادقة). إذا كان معرّف البريد الإلكتروني (Email-ID) و UPN في Entra مختلفين، فيمكن للمستخدمين الوصول إلى بوابة VPN، ولكن ليس إلى بوابة SSL VPN أو IPsec. السبب وفقًا لـ KIL: يوفر رأس OAuth البريد الإلكتروني، والذي يتم تفسيره بعد ذلك على أنه UPN.
البوابة المقيدة (Captive Portal): يحتاج مستخدمو Entra SSO إلى المجموعة الأساسية (Primary Group) في القاعدة: NC-167130 (المصادقة). لا يعمل الوصول إلى الإنترنت إلا إذا كنت تستخدم المجموعة الأساسية في مطابقة قاعدة جدار الحماية (المجموعات الثانوية لا تحسب هنا). الإصلاح وفقًا لـ KIL في “إصدارات الصيانة التالية”؛ الحل البديل (Workaround): مطابقة المجموعة الأساسية صراحةً أو استخدام القواعد القائمة على المستخدم.
أخطاء عرضية بـ “no permission” (لا يوجد إذن) مع Entra SSO: NC-167128 (المصادقة). يمكن أن يحدث عند استخدام مصادقة Entra ID ومصادقة On-Prem AD بالتوازي (إعادة استخدام الرمز المميز Token-Reuse). الحلول البديلة وفقًا لـ KIL: مسح ملفات تعريف الارتباط (Cookies) للمتصفح أو “فرض إعادة تسجيل الدخول (force re-logon)” في عميل Sophos Connect. بدلاً من ذلك، استخدم طريقة مصادقة واحدة باستمرار.

7) توافق VPN/IPsec (Interop): غالبًا ما تفشل الترقيات بسبب “الخصم”

موضوعان من KIL لم يبدأوا بـ 21.5 فقط، لكنهما يظلان وثيقي الصلة بـ 21.5/v22 بمجرد أن يكون لديك عملاء قدامى أو أطراف بعيدة (Remote peers) في الميدان:

IPsec IKEv2: النفق (Tunnel) لا يعمل (التجزئة Fragmentation/PMTU): NC-136352 (IPsec). اعتبارًا من الإصدار 20.0 MR1، يمكن لملف تعريف IKEv2 الافتراضي إنشاء حزم أكبر (المزيد من الحقول الافتراضية)، وأحيانًا أكثر من 1500 بايت. إذا كانت التجزئة/PMTU في المسار سيئة (يتم إسقاط الأجزاء)، فلن يعمل نفق S2S. التخفيف وفقًا لـ KIL: تقليل مجموعات DH (DH Groups) في ملف تعريف IPsec (الحد الأدنى 4) أو تكوين المجموعات التي يستخدمها الطرف البعيد بالضبط.
SSL VPN/OpenVPN 2.6.0: عدم التوافق مع عملاء EoL أو UTM9: NC-128116 (SSLVPN). اعتبارًا من 20.0 MR1، أصبح OpenVPN على الإصدار 2.6.0. يؤدي هذا إلى كسر شبكات SSL VPN من موقع إلى آخر (Site-to-site) مع إصدارات SFOS القديمة (18.5 والأقدم)، وعملاء SSL VPN القدامى (EoL) ونظام التشغيل UTM9 OS، من بين أمور أخرى. التوصية وفقًا لـ KIL: ترقية كلا الجانبين أو التبديل إلى IPsec/RED؛ عن بُعد: استخدم Sophos Connect أو عملاء OpenVPN الحاليين.

8) انقطاع حركة المرور (Traffic Drops) دون إصابة القاعدة: Accurate ECN كسبب خبيث

عندما يبدو أن حركة المرور تسقط “بشكل عشوائي”، فإن أول شيء تتحقق منه هو القواعد (Rules)، و IPS، وفحص TLS (TLS Inspection)، والتوجيه (Routing). وبعد ترقيات البرامج الثابتة، يضاف شيء كلاسيكي إلى القائمة: يصبح محرك IPS (Snort) أو التوقيعات (Signatures) أكثر صرامة، ويحظر حركة المرور المشروعة، ولا تجد على الفور حدث سجل واضح لذلك. ثم تقضي ساعات في تصحيح “التوجيه” أو “القواعد”، على الرغم من أنه في النهاية عمل يتعلق بالسياسة أو الضبط (Tuning).

ومع ذلك، يوجد لدى KIL أيضًا مرشح يمكن أن يبقيك مشغولاً لفترة طويلة جدًا إذا لم تكن تضعه في حسبانك:

يتم إسقاط حركة المرور بسبب بتات Accurate ECN: NC-169842 (جدار الحماية). يعين Accurate ECN بتات TCP (ECE/CWR/NS) بشكل مختلف (RFC 7560). وفقًا لـ KIL، يفسر النواة (Kernel) هذا على أنه “مجموعة بتات محجوزة (reserved bit set)” ويسقط حركة المرور. لتضييق نطاق هذا، قد تساعد نظرة على جانب العميل: في الممارسة العملية، قد يلاحظ هذا أكثر مع أنوية Linux الأحدث أو عملاء Apple، لأنهم يميلون إلى استخدام RFC 7560/Accurate ECN بشكل أكثر نشاطًا (“لماذا يتم طرد أجهزة MacBooks فقط؟”). RFC: https://www.rfc-editor.org/rfc/rfc7560

9) إعادة إصدار v22 GA (Build 411): لماذا كان مطلوبًا في المقام الأول

في 20 يناير 2026، أصدرت Sophos الإصدار v22 GA كإعادة إصدار (Build 411) لإصلاح “المشكلات النادرة والمعزولة”. تُقرأ القائمة وكأنها أفضل الأغاني لـ “العمل غير الضروري في نافذة التغيير” (المصدر: منشور مدونة مجتمع Sophos حول إعادة الإصدار):

NC-171003: لا يمكن الوصول إلى WebAdmin عبر واجهة Bridge مع تصفية VLAN.
NC-170987: سجل بريد مزعج في CLI “Invalid rule id or family for update”.
NC-170970: تفشل حركة مرور DNAT إذا كان لقاعدة DNAT واجهة خروج (outbound interface) محددة.
NC-171600: أداة SSL/TLS وبيانات مخطط الجلسة (Session Chart) غير صحيحة/فارغة.
NC-172197: لا يمكن إضافة أي تكوين SNMP.

منشور المدونة: v22 GA re-release (Build 411) is now available.

الضرر الحقيقي: الأخطاء البرمجية تجعل الأمن أكثر تكلفة

لا تكمن النقطة في أن “الأخطاء البرمجية أسوأ من CVEs” أو العكس.

النقطة هي: عندما تهتز عملياتك، يتدهور الأمان تلقائيًا.

تقوم بتأخير الترقيات لأنك تخشى خطأ التراجع (Regression-Bug) التالي.
تقوم بتعطيل الميزات (“لسنا بحاجة إليها الآن”) لأنها تسبب التوتر.
تفقد قابلية الملاحظة (السجلات - Logs)، وهو ما يعني التأخير في الاستجابة.
تستثمر وقتك في إطفاء الحرائق (Firefighting) بدلاً من التقسيم (Segmentation)، وعمل النسخ الاحتياطية (Backups)، وإنشاء قواعد نظيفة (Clean rules).

وهناك نقطة يتم التقليل من شأنها تمامًا في الممارسة العملية وهي: Time-to-Resolution (الوقت المستغرق للحل). مع ثغرة CVE، عادة ما يكون لديك إشعار (Advisory)، وتخفيف (Mitigation)، وإصلاح (Fix). أما مع الخطأ البرمجي (Bug)، فيقع عبء الإثبات بسرعة على عاتق المسؤول (Admin): tcpdump، وسجلات CTR، والتصدير المتقدم لـ Shell، “هل جربت إيقاف التشغيل وإعادة التشغيل مرة أخرى؟” - كل ذلك بينما تحترق بيئة الإنتاج (Production). وبعد ذلك فقط تصل إلى دوامة الدعم: تصعيد المشكلة (Escalating)، أو انتظار إصلاح عاجل (Hotfix)، أو MR التالي. يستهلك هذا وقتًا تشغيليًا إضافيًا لم تخطط له.

وهذا هو بالضبط السبب وراء كون السؤال “هل الأفضل وجود ثغرة أمنية ولكن مع نظام مستقر؟” هو سؤال إنساني، ولكنه في الحقيقة طريق مسدود:

ليست “الثغرة الأمنية” وحدها هي المشكلة الأمنية. “جدار الحماية غير المستقر” هو أيضًا مشكلة أمنية.

ما الذي نتعلمه من هذا (حتى لا تتصاعد الأمور تمامًا)

بعض الأشياء التي تساعدنا في الحد من الجنون دون الحاجة إلى إعادة اختراع العجلة كل أسبوع:

فحوصات ما قبل الترقية (Upgrade-Preflight) (قبل أن تبدأ)

تعامل مع النسخ الاحتياطية (Backups) وكأنها عمليات استعادة (Restores): قم بتصدير التكوين (Config)، واحتفظ بنسخة احتياطية في وضع عدم الاتصال (Offline)، واختبر عملية الاستعادة مرة واحدة على الأقل.
حالة HA “خضراء” لا تكفي - اختبر تجاوز الفشل (Failover)! وفقًا لـ GUI، كانت المزامنة (Sync) لدينا جيدة ونبض القلب (Heartbeat) نظيفًا. ولكن في حالات الطوارئ، لم يستحوذ الجهاز المساعد (Auxiliary Appliance) على تجاوز الفشل بسلاسة. العلامة الخضراء في WebAdmin حاليًا، وللأسف، ليست ضمانًا بأنه سيعمل أثناء نافذة التغيير (Change-Window).
التحقق من التسجيل (Logging): يتلقى Syslog/Collector الخارجي الأحداث، ولا توجد فجوات في السجلات، والوقت/NTP صحيح.
التحقق من الشهادات/WAF: تواريخ انتهاء الصلاحية، التحقق من Let’s Encrypt، وشهادة احتياطية (Fallback) كخطة بديلة (Plan B).
اختبر حقًا SSO/VPN: تسجيل الدخول إلى Entra، و Captive Portal، و Sophos Connect، و SSL VPN، و IPsec S2S (بما في ذلك تجاوز الفشل) جميعها تمثل حالات اختبار (Test cases) بحد ذاتها.
كن مستعدًا لكسر الزجاج (Break-Glass): وحدة التحكم (Console)/وصول Out-of-band، والمسؤولين المحليين (Local admins)، وصور البرامج الثابتة (Firmware-Images) للعودة إلى الحالة السابقة (Rollback).
لا تنس التشغيل المزدوج (Dual-Boot) (ولا تبالغ في تقديره): يحتوي Sophos على قسمين للبرامج الثابتة (Firmware-Partitionen). إذا سارت الترقية بشكل خاطئ، فغالبًا ما يكون التراجع إلى 21.5 مجرد إعادة تشغيل مع اختيار القسم الآخر. ولكن: هناك أيضًا حالات لا يقوم فيها القسم الثاني بالتمهيد بشكل نظيف أيضًا، وحينها فقط تساعد إعادة تثبيت الصورة (Reimage) (والتي يبدو أن الدعم يطلبها بسرعة كبيرة). وحتى إعادة تثبيت الصورة لا تحل دائمًا السبب الجذري الحقيقي.

أثناء الترقية (إذا كان HA متضمنًا)

السلبي/الثانوي (Passive/Secondary) أولاً، ثم تجاوز الفشل (Failover)، ثم النشط (Active).
تحقق باختصار بعد كل خطوة: حركة المرور، VPN، DNS، التسجيل، WAF/الوكيل العكسي.

في العمليات الجارية (Ongoing Operations)

اختبر HA، ولا تقم بتكوينه فقط: تدريبات تجاوز الفشل (Failover drills) ومعايير واضحة حول متى يجب تقسيم (Split) مجموعة (Cluster).
تعامل مع التسجيل (Logging) كمنتج: تنبيهات عند وجود فجوات في السجل، صحة الخدمة (Service Health)، تصدير الطوارئ (Emergency export) عبر CLI إذا بدأت واجهة المستخدم في التصرف بغرابة.
مراقبة الشهادات بفاعلية: التجديد (Renewal) ليس أمرًا “من الجيد امتلاكه (Nice to have)"، ولكنه خطر تشغيلي. تعامل مع تغييرات شروط الخدمة (ToS) تمامًا مثل التغييرات (Changes) في البنية التحتية.
فحص الصحة (Health Check) كتلميح، وليس كمؤشر أداء رئيسي (KPI): في الإصدار v22، قدمت Sophos فحص الصحة (التفاصيل في مقالتي نظرة عامة كاملة على Sophos Firewall v22 Health Check ). هذا جيد كقائمة مراجعة لأفضل الممارسات، ولكنه يبدو أحيانًا وكأنه “تحويل مفاتيح النظام البيئي إلى اللون الأخضر”. مثال من الممارسة العملية: يقوم العديد من الأشخاص بتنشيط إخلاء المسؤولية عن تسجيل الدخول (Login Disclaimer) فقط للحصول على العلامة الخضراء في الفحص الصحي. ما أفتقده هناك هو المؤشرات التشغيلية الصعبة مثل “هل قاعدة بيانات التسجيل/التقارير سليمة؟” أو “ما هي حالة SSD؟” - خاصة لأن بعض الأجهزة واجهت مشاكل في التخزين أسرع مما كان متوقعًا.

الخاتمة: عندما تصبح الأداة بحد ذاتها خطرًا

في نهاية المطاف، نحن جميعًا في نفس القارب. نحن ندير بنية تحتية حيوية ويجب أن نكون قادرين على الاعتماد على الأدوات التي من المفترض أن تحمينا من الفوضى، وألا تتسبب هي نفسها في حدوث هذه الفوضى. بالنظر إلى جودة البرامج الثابتة الحالية (v21.5 / v22)، فإن لدى Sophos بالتأكيد الكثير من الواجبات المنزلية التي يتعين عليها القيام بها. لقد تلقت الثقة في “الإصدارات المستقرة (Stable Releases)” ضربة قوية بالنسبة لنا وللعديد من الأشخاص الآخرين في المجتمع.

أنا لا أريد جدار حماية يكون “إما آمنًا أو مستقرًا”. أريد – لا، أنا أحتاج – إلى جدار حماية يجمع بين الاثنين.

إلى أن تسيطر Sophos على عيوب الجودة هذه، لم يتبق لنا في قسم العمليات سوى خيار واحد: يجب أن نصبح أكثر انضباطًا، ونتوقف عن الاهتمام بـ “العلامة الخضراء” في واجهة المستخدم، وأن نتعامل مع الأخطاء البرمجية (Bugs) التافهة في تخطيط النشر (Deployment) بنفس الجدية التي نتعامل بها مع ثغرات CVE الحرجة.

حتى المرة القادمة،
Joe