تتعامل شبكة VPN على مستوى النظام مع جهاز Mac كمُرسِل واحد: كل تطبيق يخرج عبر النفق نفسه وعنوان الخروج نفسه، وللنفق نفسه استثناءات حوّلتها أبحاث منشورة إلى تسريبات. أما التوجيه لكل تطبيق على حدة، الذي يتيحه macOS عبر الوكلاء الشفافة في إطار Network Extension، فيجعل التطبيقَ وحدةَ القرار. تقارن هذه المذكرة بين النموذجين استنادًا إلى وثائق المطوّرين لدى Apple ودليل tor ودراسة نُشرت في مؤتمر USENIX Security عام 2023، وتحدّد ثلاث نقاط يمكن أن يتسرّب منها موجّه Tor لكل تطبيق: ما يحدث للاتصال حين لا يكون Tor جاهزًا، وأين تذهب استعلامات DNS، وما يحدث للحركة التي ليست TCP. وتختم بكيفية تعامل TorAi، وهو تطبيق من HisnLabs لنظام macOS، مع كل نقطة، بما في ذلك ثغرة في DNS أغلقها الإصدار 0.1.0.
الخلفية
ترسل معظم برامج VPN «كل الحركة» إلى النفق بتعديل جدول التوجيه في نظام التشغيل. وقد ردّ Xue وزملاؤه فئة من التسريبات إلى «خلل تصميمي واسع الانتشار في الطريقة التي تهيّئ بها البرامج نظام التشغيل لتوجيه كل الحركة عبر نفق VPN» [1]. فالأنفاق الكاملة تحتاج إلى استثناءات، عادةً للشبكة المحلية ولخادم VPN نفسه؛ وقد بيّن الباحثون أن مهاجمًا يدير نقطة الوصول اللاسلكية أو يزيّف ردود DNS يستطيع استغلال هذه الاستثناءات ليجعل الضحية ترسل حركتها نصًا صريحًا خارج النفق. وأجروا 248 تجربة على 67 من أكثر مزوّدي VPN تمثيلًا على Windows وmacOS وiOS وLinux وAndroid [1].
ولإطار Apple استثناءاته الثابتة أيضًا. فمع الإعداد الأكثر صرامة includeAllNetworks، وهو معطّل افتراضيًا، يظل النظام يستثني دائمًا حركة DHCP وحركة بوابات الدخول (captive portal) وبعض الخدمات الخلوية والحركة نحو الأجهزة المرافقة [5]. أما تجاوز الشبكة المحلية للنفق فإعداد منفصل هو excludeLocalNetworks، وقيمته الافتراضية false على macOS وtrue على iOS [6].
النتائج
نفق واحد يضع كل التطبيقات خلف هوية واحدة
مع نفق واحد، يخرج البريد والمحادثة والتحديثات والتصفح كلها من عنوان واحد في الوقت نفسه. فخادم يرى اثنين من هذه التطبيقات، أو مراقب عند المخرج، يستطيع الربط بينهما. ويستطيع Tor الفصل بينها، لكن بشرط أن يُبلَّغ بانتماء كل تدفق: فمع الخيار IsolateSOCKSAuth، وهو «مفعّل افتراضيًا»، لا «يشارك tor الدوائر مع تدفقات قُدّمت لها بيانات مصادقة SOCKS مختلفة» [9]. لذا فإن موجّهًا يرسل كل تطبيق ببيانات SOCKS خاصة به يحصل على دائرة واحدة، ومخرج واحد، لكل تطبيق.
الوكيل الشفاف يرى أي تطبيق فتح الاتصال
يستقبل NETransparentProxyProvider، المتاح منذ macOS 11، الاتصالات من التطبيقات ويقرّر ما يفعله بكل منها [2]. ويحمل كل تدفق بيانات وصفية عن مصدره: sourceAppSigningIdentifier، وهو مطابق لمعرّف الحزمة في التطبيقات الموقّعة بالطريقة المعتادة [7]. أما الحركة التي تصل إلى الوكيل أصلًا فتحدّدها قواعد الشبكات المشمولة والمستثناة، وللاستثناءات الأولوية [3]. ويتيح ذلك كله للموجّه أن يقرّر بحسب التطبيق لا بحسب الوجهة.
الاتصالات غير المعالَجة تمرّ افتراضيًا
التفصيل الحاسم هو ما يحدث لتدفق لا يأخذه الوكيل. فوثائق Apple تنصّ على أنه حين يرفض المزوّد تدفقًا جديدًا، يمضي التدفق «للتواصل مباشرة مع الوجهة النهائية للتدفق، بدلًا من إغلاقه بخطأ “رفض الاتصال”» [2]. فموجّه Tor الذي يكتفي برفض التدفقات أثناء بدء تشغيل Tor، أو بعد توقفه، يرسل تلك التطبيقات مباشرة إلى الإنترنت بعنوانها الحقيقي. والإغلاق عند الفشل يقتضي أن يقبل الوكيل هذه التدفقات ثم يرفضها بنفسه.
DNS يسلك مسارًا منفصلًا
التطبيقات التي تتصل بالاسم عبر URLSession أو إطار Network «لا تولّد استعلامات DNS، بل يُدرج اسم المضيف الوجهة… في معلومات نقطة النهاية» للتدفق [8]، وتنقله الخاصية remoteHostname إلى الوكيل [4]. ويستطيع الوكيل تسليم هذا الاسم إلى Tor ليحلّه المخرج. أما التطبيقات التي تحلّ الاسم أولًا عبر واجهات منخفضة المستوى مثل DNSServiceGetAddrInfo فتتصرف بشكل مختلف: إذ تذهب استعلاماتها إلى محلِّل النظام كتدفقات DNS منفصلة [8]، والوكيل الشفاف يتجاهل إعدادات DNS التي تستخدمها شبكة VPN لإعادة توجيهها [2]. وما لم يلتقط الموجّه هذه الاستعلامات أيضًا، فإن محلِّل الشبكة يعرف الأسماء. ويوفّر tor لهذا الغرض المنفذ DNSPort، الذي «لا يعالج إلا طلبات A وAAAA وPTR»، والخيار AutomapHostsOnResolve، «المفيد لجعل عناوين “.onion” تعمل مع التطبيقات التي تحلّ العنوان ثم تتصل به» [9]. والاستعلامات التي تصل إلى Tor يراها محلِّل المخرج؛ وقد وجد Greschbach وزملاؤه أن محلِّلًا عامًا واحدًا رصد ما يقارب 40 في المئة من طلبات DNS الخارجة من شبكة Tor [10].
Tor يحمل TCP لا UDP
صُمّم Tor لحمل تدفقات TCP [11]. أما QUIC، الذي تستخدمه تطبيقات ومتصفحات كثيرة اليوم لبروتوكول HTTP/3، فيعمل فوق UDP. وأمام الموجّه لكل تطبيق خياران صادقان لحركة UDP الصادرة من تطبيق موجّه: أن يحجبها فيعود التطبيق إلى TCP، أو أن يتركها تمرّ مباشرة فتتسرّب. وتركها تمرّ بصمت يُفسد الغاية من التوجيه.
| الخاصية | VPN للجهاز كله | وكيل شفاف لكل تطبيق إلى Tor |
|---|---|---|
| وحدة القرار | الجهاز كله، مع استثناءات بحسب الوجهة | التطبيق، بمعرّف التوقيع |
| هوية الخروج | عنوان واحد لكل التطبيقات | دائرة لكل تطبيق، إذا فُصلت |
| التجاوزات الموثّقة | استثناءات الشبكة المحلية والخادم؛ واستثناءات ثابتة في النظام | التدفقات التي يرفضها الوكيل تمرّ مباشرة |
| DNS | يمكن إعادة توجيهه بإعدادات DNS في VPN | الأسماء داخل التدفقات تذهب إلى Tor؛ والاستعلامات منخفضة المستوى تحتاج إلى التقاط منفصل |
| UDP وQUIC | تحملها معظم بروتوكولات VPN | لا يحملها Tor؛ ويجب حجبها |
الآثار على مستخدمي Mac
«تمرير تطبيق عبر Tor» لا يكون أقوى من معالجته للحالات الحدّية. والنقاط التي تستحق الفحص في أي أداة، ومنها أداتنا، نقاط محدّدة: ما إذا كانت تحجب التطبيق الموجّه أثناء بدء تشغيل Tor أم تتركه يمرّ، وما إذا كانت تلتقط الاستعلامات التي تجريها التطبيقات قبل الاتصال، وما إذا كانت تحجب QUIC وغيره من حركة UDP الصادرة من التطبيقات الموجّهة، وما إذا كانت تمنح كل تطبيق دائرته الخاصة. والأداة التي تُخفق في أيّ منها تسرّب شيئًا، حتى لو مرّ الاتصال الرئيسي عبر Tor. وتظل شبكة VPN للجهاز كله مفيدة لأهداف أخرى، كإخفاء الحركة عن شبكة Wi-Fi غير موثوقة، لكنها لا تناسب هدفًا من قبيل «ألّا تكشف هذه التطبيقات الثلاثة عنواني وألّا يُربط بعضها ببعض».
التوصيات
- اختر التوجيه لكل تطبيق حين يكون الهدف فصل تطبيقات بعينها، وأبقِ كل تطبيق على دائرته الخاصة.
- فضّل الأدوات التي تُغلق عند الفشل: ينبغي أن يفقد التطبيق الموجّه اتصاله لا حمايته حين لا يكون Tor جاهزًا.
- تحقّق من وجهة DNS، للأسماء الممرّرة داخل الاتصالات وللاستعلامات التي تُجرى قبل الاتصال على حدّ سواء.
- احجب QUIC وغيره من حركة UDP للتطبيقات الموجّهة كي تعود إلى TCP عبر Tor.
- لا تفترض أن خيار «كل الحركة» في VPN يشمل كل شيء: فالنظام والبرنامج كلاهما يحتفظان باستثناءات.
- تحقّق من النتيجة من داخل التطبيق الموجّه نفسه، مثلًا بصفحة الفحص التابعة لمشروع Tor.
صلة ذلك بـ TorAi
TorAi تطبيق من HisnLabs لنظام macOS، وقد صدر الإصدار 0.1.0، وهو أول إصدار عام له. تصف صفحته «Split Mesh» بثلاثة أوضاع: متوقف، وتطبيقات مختارة، وكل الحركة؛ ودائرة Tor لكل تطبيق، تتبعها العمليات المساعدة للتطبيق؛ وتصميمًا يُغلق عند الفشل، فتُحجب التطبيقات الموجّهة حين لا يكون Tor جاهزًا؛ وحمل TCP وDNS فقط، مع حجب بقية حركة UDP، ومنها QUIC؛ وإبقاء الشبكة المحلية مباشرة؛ وقواعد للمضيفين بحسب النطاق. التفاصيل في صفحة TorAi.
كانت ثمة ثغرة واحدة مفتوحة في نسخ التطوير من TorAi، وقد أغلقها الإصدار 0.1.0. ففي تلك النسخ، وفي وضع «تطبيقات مختارة»، كان الاسم الذي يستعلم عنه تطبيق موجّه عبر محلِّل النظام في macOS، ومنه أسماء .onion، يُرسَل إلى محلِّل الشبكة: كان الاتصال نفسه يمرّ عبر Tor، ويحلّ المخرج الاسم من جديد، لكن المحلِّل المحلي كان يرى الاسم. ويضيف TorAi 0.1.0 وكيل DNS إلى امتداد النظام نفسه، يرى كل استعلام مع التطبيق الذي أجراه. فاستعلامات التطبيقات الموجّهة، وكل استعلام .onion، تذهب إلى منفذ DNS في tor؛ أما استعلامات كل تطبيق آخر فتذهب إلى محلِّلها المعتاد ولا تنتظر Tor أبدًا. ولأن إعدادات الشبكة في macOS نفسه تُسقط استعلامات .onion ما لم يُضبط محلِّل لنطاق onion، يضبط TorAi محلِّلًا لهذا النطاق وحده ما دام التوجيه مفعّلًا. وفي وضع «كل الحركة» يُوجَّه المحلِّل أيضًا. وكما مع أي أداة Tor، تظل تسجيلات الدخول والبصمات تكشف هويتك، ويرى المخرج الحركة غير المشفّرة، ولا دفاع ضد الربط بين الطرفين.
القيود
تصف هذه المذكرة السلوك الموثّق لأُطر Apple ولبرنامج tor؛ ولا تختبر منتجات VPN بعينها، والدراسة المستشهد بها اختبرت البرامج كما كانت عام 2023، وقد أُصلح بعضها منذ ذلك الحين. ووثائق Apple تصف السلوك المقصود، وقد يتغيّر بين إصدارات macOS. ورقم رصد DNS يعود إلى عام 2016. ووصف سلوك TorAi مأخوذ من ملاحظات إصداره ومن اختبارات HisnLabs نفسها، لا من تدقيق مستقل، وHisnLabs هي التي تصنع TorAi، وهذا ما ينبغي للقارئ أن يضعه في الحسبان. للاستزادة: درسا جامعة FireAI عن VPN وTor والوكلاء ومن يرى استعلامات DNS الخاصة بك، والمقالان ما بعد VPN وما الذي يخفيه Tor وما الذي لا يخفيه، ومدخل مرشّحات Network Extension في رادار FireAI.
دور FireAI وHisnLabs
يستخدم FireAI إطار Network Extension نفسه في macOS لمهمة مختلفة: فهو لا يمرّر أي شيء عبر نفق، بل يُظهر أي تطبيق يفتح أي اتصال ويتيح لك السماح بكل اتصال أو حجبه، وهي طريقة مفيدة لمعرفة التطبيقات التي تريد وضعها خلف Tor.
FireAI هو منتج HisnLabs نفسها: جدار حماية بذكاء اصطناعي يعمل على جهاز Mac مباشرة. يعرض بلغة واضحة كل اتصال تجريه تطبيقاتك، ويترك لك القرار فيما يخرج من جهازك — ذكاؤه الاصطناعي يعمل محليًا، فلا يُرسَل ترافيكك إلينا ولا إلى أي جهة أخرى أبدًا. فريق أبحاث الأمن في HisnLabs هو من يحافظ على دقة هذه القرارات: يصنّف النطاقات بين قياس عن بُعد عادي وخدمة حقيقية، ويتتبّع بلد وشبكة كل اتصال، ويدرّب النموذج المحلي (ميزة FireAI Pilot) على حركة اتصال حقيقية، دون أن يغادر أي شيء جهاز Mac.
يمكنك الاطلاع على القرارات التقنية وراء ذلك، أو تجربة FireAI لمدة 17 يومًا، على FireAI من HisnLabs.