اكتشاف مواقع الفنادق المزيفة خلف Cloudflare: الطرق التقنية

عندما قمنا بتحليل مئات المواقع الفندقية المزيفة، كانت الصورة التي ظهرت واضحة للغاية: أكثر من ثمانين بالمائة من هذه المواقع كانت مستضافة خلف شبكة توصيل المحتوى (CDN) الخاصة بـ Cloudflare. هذا الاختيار ليس من قبيل الصدفة؛ حيث إن Cloudflare يجعل عمليات الإزالة (takedown) أكثر صعوبة بشكل كبير عن طريق إخفاء عنوان IP الحقيقي للخادم.

لبدء إجراء ضد موقع مزيف، من الضروري الوصول إلى شركة الاستضافة. وللوصول إلى شركة الاستضافة، من الضروري معرفة عنوان IP. عندما يخفي Cloudflare عنوان IP هذا، تبدو العملية وكأنها وصلت إلى طريق مسدود. لكن الظاهر والحقيقي ليسا دائمًا نفس الشيء.

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

تستخدم المواقع الشرعية Cloudflare للحماية من هجمات DDoS وتحسين السرعة والأمان. أما المحتالون فيفضلونه لسبب مختلف: البقاء مجهولين.

عندما يقع موقع خلف وكيل Cloudflare، فإن كل استعلام DNS يتم من الخارج يُظهر فقط عناوين IP الخاصة بـ Cloudflare. لا يظهر عنوان IP الحقيقي للخادم. وهذا يجعل طلبات الإزالة أكثر صعوبة ويعقد تحديد شركة الاستضافة.

يشير خبراء الصناعة إلى أن استخدام المحتالين لـ Cloudflare بهذه الطريقة هو في الواقع إساءة استخدام للمنصة. تمنع سياسات Cloudflare الخاصة هذا الاستخدام؛ لكن النظام لا يتدخل تلقائيًا دون شكوى.

تعمل حماية Cloudflare على طبقة معينة: فهي تخفي حركة مرور HTTP و HTTPS. لكن خادم الويب لا يعمل فقط مع حركة مرور الويب. قد تظل خوادم البريد الإلكتروني وسجلات DNS القديمة وتكوينات النطاقات الفرعية وسلوكيات الخادم خارج هذا القناع.

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

هذا هو الخلل الأكثر شيوعًا والأكثر كفاءة. حتى لو كان النطاق الرئيسي خلف Cloudflare، فقد تشير النطاقات الفرعية مباشرة إلى عنوان IP الخادم بتكوين مختلف.

السبب الفني لذلك هو: لا يمكن توجيه حركة مرور SMTP (البريد الإلكتروني) عبر وكيل Cloudflare. يجب أن تتصل النطاقات الفرعية مثل "mail.sahteotel.com" أو "smtp.sahteotel.com" مباشرة بخادم البريد. عند إجراء استعلام DNS لهذا النطاق الفرعي، يظهر عنوان IP الحقيقي مباشرة.

في إحدى الحالات التي اكتشفناها في بحثنا، بينما كان النطاق الرئيسي محميًا بالكامل بواسطة Cloudflare، كان النطاق الفرعي "info." يشير مباشرة إلى خادم في أوروبا الشرقية. كان نفس الخادم يستضيف 17 موقع حجز مزيفًا مختلفًا.

من بين الأدوات المستخدمة لمسح النطاقات الفرعية Sublist3r و Amass و Subfinder. تحاول هذه الأدوات أسماء نطاقات فرعية شائعة لنطاق ما وتحدد أيها يشير إلى عنوان IP الحقيقي.

• mail.، smtp.، imap.، pop.، mx.، webmail. (البنية التحتية للبريد الإلكتروني)
• ftp.، sftp. (نقل الملفات)
• cpanel.، whm.، plesk.، direct-admin. (لوحات تحكم الاستضافة)
• api.، backend.، admin.، portal. (طبقات التطبيق)
• dev.، staging.، test.، beta. (بيئات التطوير)

لا تستخدم الغالبية العظمى من المواقع المزيفة Cloudflare في البداية. بعد إنشاء الموقع، ينتقلون خلف شبكة CDN للحماية من مخاطر الكشف. تظل سجلات DNS من الفترة التي سبقت هذا الانتقال مخزنة في خدمات أرشيفية مختلفة.

تخزن قواعد بيانات DNS السلبية مثل SecurityTrails و ViewDNS.info عناوين IP وسجلات خادم الأسماء التي استخدمها النطاق في الماضي. عند النظر إلى هذه المحفوظات، يمكن رؤية عنوان IP الحقيقي للخادم المستخدم قبل الانتقال إلى Cloudflare.

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

في سجلات CT، لا يمكن إجراء عمليات البحث على أساس اسم النطاق فحسب، بل يمكن إجراؤها أحيانًا على أساس IP أيضًا. تحصل بعض الخوادم على شهادات SSL لعناوين IP المباشرة الخاصة بها أيضًا.

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

في حالة حقيقية: بعد العثور على عنوان IP لموقع فندق مزيف باستخدام طريقة النطاق الفرعي، اكتشفنا 27 نطاقًا مزيفًا آخر لنفس IP في بحثنا في سجلات CT. كانوا جميعًا جزءًا من نفس العملية.

لمعرفة المزيد حول سجلات شفافية الشهادات، نوصيك بمراجعة مقالتنا حول مراقبة سجلات شفافية الشهادات.

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

يمكن استخدام هذه المعلومات لعدة أغراض مختلفة:

• تحديد شركة الاستضافة التي ينتمي إليها الخادم (معلومات ASN).
• تحديد المواقع الأخرى المستضافة على نفس الخادم.
• ملاحظة الثغرات الأمنية المعروفة في برامج الخادم (دليل داعم في طلبات الإزالة).

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

تنشر بعض خوادم الويب معلومات مفصلة عن الخادم عند نقاط نهاية مثل "/server-status" أو "/server-info" بسبب التكوين الخاطئ. في الخوادم التي بها هذا الخلل، يمكن سرد جميع أسماء المضيفين الظاهريين الذين يستخدمون هذا الخادم.

عند اكتشاف مثل هذا الخلل، تصبح حماية Cloudflare غير فعالة. لأنه من خلال إشعار الخادم نفسه، يتم الكشف عن جميع النطاقات وعلاقة IP. في أحد المواقع المزيفة التي قمنا بتحليلها، واجهنا هذا الخلل بالضبط؛ كان الخادم يستضيف 31 نطاقًا مزيفًا مختلفًا وقدم معلومات عنها جميعًا.

ليس من الضروري فحص كل عنوان URL يدويًا لاكتشاف مثل هذه الثغرات. يمكن للأدوات التلقائية مسح نقاط النهاية هذه بسرعة.

الوصول إلى عنوان IP الحقيقي يجسد عملية الإزالة:

شكوى مباشرة إلى شركة الاستضافة: يمكن تحديد شركة الاستضافة التي ينتمي إليها IP باستخدام استعلام ASN (باستخدام أدوات مثل bgp.he.net أو ipinfo.io). يمكن إرسال إشعار DMCA أو شكوى إساءة استخدام إلى عنوان البريد الإلكتروني الخاص بإساءة الاستخدام الخاص بشركة الاستضافة.

طلب قوي إلى Cloudflare: إن تقديم معلومات الخادم الحقيقية في الشكاوى المقدمة إلى Cloudflare يسرع عملية تقييم الطلب. يمكن لـ Cloudflare قطع الخدمة عن المواقع التي تنتهك سياسة إساءة الاستخدام الخاصة بها.

دليل فني في الطلب إلى مكتب المدعي العام: يعتبر عنوان IP ومعلومات الاستضافة دليلاً فنيًا في الإجراءات الجنائية التركية ويساعد على تسريع التحقيق.

يرسل كل خادم ويب معلومات رأس متنوعة في استجابات HTTP. يمكن أن تحتوي هذه الرؤوس على أدلة حول برامج الخادم أو بيئة التشغيل أو البنية التحتية للاستضافة.

الرؤوس التي يجب الانتباه إليها بشكل خاص:

• Server: يمكن أن يكشف عن برامج الخادم مثل Apache أو Nginx أو LiteSpeed؛ وفي بعض الأحيان يتضمن معلومات الإصدار.
• X-Powered-By: معلومات وقت التشغيل مثل إصدار PHP أو إصدار ASP.NET.
• CF-Cache-Status: حالة ذاكرة التخزين المؤقت لـ Cloudflare - يؤكد ما إذا كان الموقع خلف Cloudflare بالفعل.
• Set-Cookie: تترك بعض منصات الاستضافة بصماتها في رأس ملفات تعريف الارتباط (cPanel، Plesk، إلخ).

للتحقق من هذه الرؤوس، يمكن استخدام أدوات مطور المتصفح (F12 ← علامة التبويب الشبكة). من الممكن أيضًا عرض الرؤوس بتنسيقها الخام باستخدام أمر curl.

في تجربة أحد عملائنا، مكّن "X-Powered-By: PHP/7.4" وتنسيق ملف تعريف ارتباط جلسة خاص من تحديد مزود الاستضافة. حمل هذا المزيج بصمة شركة استضافة معينة، وتم تقديم إشعار إساءة استخدام مباشر إلى تلك الشركة.

تستخدم مواقع الفنادق المزيفة أحيانًا عناوين بريد إلكتروني وظيفية لخلق تصور للواقع. تضيف صفحات الاتصال التي تحتوي على عناوين بريد إلكتروني مثل "[email protected]" مظهرًا شرعيًا للموقع المزيف.

يمكن أن يكشف الاستعلام عن سجل MX (Mail Exchange) لعنوان البريد الإلكتروني هذا عن عنوان IP لخادم البريد. يُظهر استعلام MX الذي يتم إجراؤه باستخدام MXToolbox أو أمر dig إلى أين يتم توجيه حركة مرور البريد. غالبًا ما لا يكون خادم البريد خلف وكيل Cloudflare ويكشف عن عنوان IP الحقيقي.

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

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

1. استعلام سجل DNS (SecurityTrails): هل هناك IP قبل Cloudflare؟
2. مسح النطاقات الفرعية: هل تشير النطاقات الفرعية مثل mail. و smtp. و ftp. و admin. مباشرة إلى IP؟
3. استعلام سجل MX: إلى أين يتصل IP خادم البريد؟
4. بحث سجل CT: هل هناك أي سجلات شهادات أخرى لـ IP الذي تم العثور عليه؟ هل يمكن اكتشاف مواقع أخرى لنفس المشغل؟
5. مسح Shodan: معلومات البرامج والبنية التحتية التي تعمل على IP.
6. تحليل رأس HTTP: أدلة منصة الاستضافة.

عندما نطبق هذا التدفق على موقع مزيف واحد، نقضي في المتوسط 45-90 دقيقة؛ لكن النتائج غالبًا ما توفر معلومات شاملة ليس فقط عن هذا الموقع، ولكن عن عملية التزييف بأكملها.

سؤال شائع: لماذا يستمر Cloudflare في خدمة هذه المواقع المزيفة؟

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

عند تقييم إشعارات إساءة الاستخدام، يبحث Cloudflare عن:

• دليل ملموس على التصيد الاحتيالي (نموذج دفع، شاشة حجز مزيفة، إلخ).
• وثيقة انتهاك العلامة التجارية (تسجيل علامة تجارية أو دليل واضح على ملكية العلامة التجارية).
• إفادات الضحايا (شكاوى المستخدمين التي توثق أنهم ضحايا).

يشير خبراء الصناعة إلى أن قرار Cloudflare بقطع الخدمة يأتي في غضون 3-7 أيام في الإشعارات عالية الجودة الموثقة. في الإشعارات ذات التوثيق الضعيف أو الغامض، قد تستغرق العملية وقتًا أطول أو تظل غير حاسمة.

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

يتطلب تطبيق هذه الطرق واحدة تلو الأخرى معرفة فنية ويستغرق وقتًا. في بحثنا، استغرق الوصول إلى عنوان IP الحقيقي لبعض المواقع المزيفة ساعات.

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

في بحثنا، تبين أن الفنادق التي تصل إلى عنوان IP الحقيقي تزيل المواقع المزيفة في المتوسط في غضون 4 أيام. في الحالات التي لا يمكن فيها تحديد عنوان IP الحقيقي، ارتفع هذا الوقت إلى 3-6 أسابيع؛ وخلال هذه الفترة، استمر الموقع المزيف في جمع الأموال من الضيوف. اكتشاف IP ليس مسألة راحة؛ إنه يخلق فرقًا في الكفاءة يمكن قياسه مباشرة بالخسارة الاقتصادية.

بالإضافة إلى بحث سجل DNS، تعد مراقبة سجل CT أيضًا تقنية تكميلية قوية في مرحلة اكتشاف IP الحقيقي. يمكنك تعلم كيفية مراقبة جميع شهادات SSL التي تم الحصول عليها باسم فندقك من خلال سجلات شفافية الشهادات في هذا الدليل. بالإضافة إلى ذلك، تعد منصات SecurityTrails و Shodan مصادر مجانية يتم الرجوع إليها بشكل متكرر في اكتشاف IP.

هل من القانوني اكتشاف موقع خلف Cloudflare؟ نعم. يعد الاستعلام عن DNS السلبي وبحث سجل CT ومسح الأرشيف تقنيات قانونية تمامًا. تستخدم هذه الطرق البيانات المتاحة للجمهور. الإجراءات التي تشكل وصولاً غير مصرح به أو هجومًا مباشرًا على النظام ليست قانونية؛ لكن الطرق الموضحة في هذا الدليل لا تندرج في هذه الفئة.

ما هي أسرع طريقة لتجاوز Cloudflare؟ يعطي بحث سجل DNS (SecurityTrails، PassiveDNS) واستعلام سجل CT (crt.sh) نتائج في غضون دقائق قليلة في معظم الحالات. يمكن أن توفر النطاقات الفرعية الخاصة بالموقع أو رؤوس البريد الإلكتروني القديمة أيضًا اكتشافًا سريعًا لعنوان IP. على الرغم من عدم وجود ترتيب محدد، تزداد نسبة النجاح بشكل كبير عند استخدام هاتين الطريقتين معًا.

ما هي المعلومات التي يوفرها Shodan؟ يسرد Shodan المنافذ المفتوحة والخدمات قيد التشغيل واللافتات على عنوان IP معين عن طريق مسح المنافذ المفتوحة. يُظهر البلد الذي يوجد فيه IP، ومزود الاستضافة الذي يستخدمه، وخدمات الويب المفتوحة. تعمل هذه المعلومات كدليل فني ملموس عند إعداد إشعار إساءة استخدام إلى مزود الاستضافة.

هل يمكن بدء عملية إزالة دون عنوان IP حقيقي؟ نعم. حتى لو لم يكن عنوان IP الحقيقي معروفًا، يمكن تقديم شكوى ICANN إلى مسجل النطاق وإشعار تصيد احتيالي إلى Cloudflare. ومع ذلك، يوفر اكتشاف IP ميزة مهمة للقدرة على التقدم بطلب مباشر إلى مزود الاستضافة والحصول على نتائج أسرع. يعد إزالة مستوى النطاق وإغلاق الخادم الذي يتتبع IP الحقيقي استراتيجيتين متكاملتين.

استخدم أداة المسح التلقائي من RuuSafe لاكتشاف البنية التحتية الحقيقية للمواقع المزيفة المتعلقة بفندقك خلف Cloudflare. الفحص الأول مجاني ويعطي نتائج في غضون دقائق قليلة.