كشف تسريب عنوان IP عبر WebRTC: من خلل إلى ميزة

صُمِّمت تقنية WebRTC — أي التواصل الآني عبر الويب (Web Real-Time Communication) — لتمكين مكالمات الفيديو ومشاركة الملفات ونقل البيانات مباشرةً بين الأقران داخل المتصفح. ولإنشاء هذه الاتصالات، تحتاج المتصفحات إلى اكتشاف واجهات شبكتها الخاصة والتفاوض على الاتصال مع الأقران البعيدين. تشمل هذه العملية خوادم STUN (أدوات اجتياز الجلسة لعبور NAT) وخوادم TURN (الاجتياز باستخدام المُرحِّلات حول NAT)، التي تساعد المتصفحات على اكتشاف عناوين IP العامة الخاصة بها وعبور جدران NAT النارية.

الأثر الجانبي لهذا قوي: حتى عندما يتصل المستخدم عبر شبكة VPN، قد تكشف منظومة WebRTC في المتصفح عن عنوان IP الحقيقي خلف النفق. ويحدث ذلك لأن مرشّحات ICE (إنشاء الاتصال التفاعلي) في WebRTC تتضمّن عناوين واجهات الشبكة المحلية التي لا تُخفيها شبكة VPN.

كيف يحدث التسريب

عندما ينشئ المتصفح اتصال RTCPeerConnection ويجمع مرشّحات ICE، فإنه يستعلم من خوادم STUN لاكتشاف عنوان IP الظاهر للعامة. لكنه يُعدّد أيضًا واجهات الشبكة المحلية — بما في ذلك عنوان IP الخاص للمحوّل الفيزيائي. فإذا كانت شبكة VPN تنقل حركة المرور عبر نفق على طبقة IP فقط، دون أن تُهيّئ منظومة WebRTC في المتصفح لاستخدام واجهة النفق حصريًا، فإن عنوان IP الحقيقي يتسرّب عبر مرشّح المضيف.

في tracio.ai، نفحص هذا السلوك بعناية. ينشئ نظام ذكاء العناوين (IP Intelligence) لدينا طلب STUN مضبوطًا ويحلّل مرشّحات ICE التي يُعيدها المتصفح. وعندما يختلف عنوان IP العام الوارد من STUN عن العنوان الذي نراه على خادمنا، نرفع علامة على وجود VPN أو بروكسي. وعندما يكشف عنوان IP للواجهة المحلية عن نطاق شبكة خاصة يتناقض مع الموقع الجغرافي المفترض، نرفع درجة الاشتباه.

من خلل إلى إشارة كشف

قامت معظم المتصفحات المهتمّة بالخصوصية بترقيع هذا التسريب — إذ يشترط Chrome إذنًا صريحًا من المستخدم لاستخدام WebRTC، ويوفّر Firefox إعدادات لتعطيل حركة UDP غير المارّة عبر البروكسي. لكن سباق التسلّح مستمر: بعض عملاء VPN لا يُهيّئون WebRTC على النحو الصحيح، وتبقى إصدارات المتصفحات الأقدم عرضة للخطر، كما أن النمط السلوكي لاستجابة WebRTC «المُرقَّعة» مقابل «المُسرِّبة» يمثّل بحدّ ذاته إشارة مفيدة.

يتعامل نهجنا مع استجابة WebRTC كإشارة مركّبة: وجود مرشّحات المضيف، وعدد مرشّحات ICE المُعادة، وأنواع المرشّحات (host وsrflx وrelay)، وتوقيت الاستجابة، كلها تسهم في بصمة الجهاز. وحتى عندما لا يتسرّب أي عنوان IP، يظل نمط سلوك WebRTC مميّزًا.

فحص خادم TURN

إلى جانب STUN، نفحص أيضًا سلوك خادم TURN. تُستخدَم مُرحِّلات TURN عادةً عندما تفشل الاتصالات المباشرة بين الأقران — وهو أمر شائع في الشبكات المؤسسية خلف جدران نارية صارمة. تكشف استجابة تخصيص TURN معلومات عن مسار المُرحِّل: بروتوكول النقل (UDP مقابل TCP مقابل TLS)، وعنوان المُرحِّل، ومدّة صلاحية التخصيص.

يُرسل نظام SignalProbe لدينا طلبات تخصيص TURN مُصاغة بعناية إلى خوادم المُرحِّل الخاصة بنا. ويختلف زمن الاستجابة وأنواع النقل المدعومة وأنماط نجاح/فشل التخصيص باختلاف بيئة الشبكة، مما يوفّر تنوّعًا إضافيًا في الإشارات لأغراض بصمة الجهاز.

اعتبارات الخصوصية

نودّ أن نكون واضحين: لا تستغلّ tracio.ai تسريبات WebRTC لكشف هوية المستخدمين. يكتشف نظامنا استخدام شبكة VPN ويُبلّغ عنه كإشارة خطر. ولا نُخزّن عنوان IP المُسرَّب أو نكشفه أبدًا. فالإشارة ثنائية: «تم كشف VPN مع تعارض في WebRTC» أو «سلوك WebRTC متّسق مع اتصال مباشر».

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