كيفية اكتشاف طلبات HTTP الواردة المرسلة بشكل مجهول عبر TOR؟

Question

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

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

أعلم أنه من الممكن اكتشاف حركة المرور TOR كما هو الحال عند تثبيتها فيداليا مع امتداد Firefox ، قدمت لي google.com مع captcha.

لذا ، كيف يمكنني اكتشاف مثل هذه الطلبات؟

(موقع الويب الخاص بي في ASP.NET MVC 2 ، لكنني أعتقد أن أي نهج يستخدم هنا سيكون مستقلًا للغة)

Answer 1

أنا أقوم بتطوير موقع ويب وأنا حساس لفحص الأشخاص الذين يقومون بتخليص بياناتي

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

سأقوم بنشر تدابير مضادة لأي أفكار تقترح الإجابات المستقبلية.

Answer 2

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

تم إساءة استخدام Google من قبل مستخدمي Tor ومعظم عقد الخروج على قائمة Google Black ولهذا السبب تحصل على Captcha.

دعني اكون واضحا تماما: لا يوجد شيء يمكنك القيام به لمنع شخص ما من تجريف موقعك.

Answer 3

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

ربما كان السلوك الذي رأيته مع Google ناتجًا عن إجراء أمان مختلف. تكتشف Google ما إذا كان المستخدم المسجل في IP ، ويعرض captcha فقط في حالة منع الاعتراض الضار وكذلك السماح باستمرار الجلسة إذا غير مستخدم مصادق عليه عن IP (عن طريق إعادة السد إلى ISP ، وما إلى ذلك).

Answer 4

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

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

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

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

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

إذا كان موقعك أكثر من خدمة ذات محتوى ديناميكي ، فهذا قصة أخرى كاملة. أنا في الواقع كشط الكثير من المواقع مثل هذا "لسرقة" كميات ضخمة من البيانات الملكية المنظمة ، ولكن هناك خيارات لجعل الأمر أكثر صعوبة. يمكنك الحد من الطلب لكل IP ، ولكن من السهل الالتفاف على الوكلاء. بالنسبة لبعض الحماية الحقيقية ، يقطع شوط طويل نسبيًا. إذا حاولت القيام بشيء مثل Screap Google Results أو قم بتنزيل مقاطع الفيديو من YouTube ، فستجد أن هناك الكثير لعكس المهندس. أفعل كلاهما ، لكن 99 ٪ من الأشخاص الذين يحاولون الفشل لأنهم يفتقرون إلى المعرفة للقيام بذلك. يمكنهم كشط الوكلاء للالتفاف على حدود IP ولكنهم لا يكسرون أي تشفير.

على سبيل المثال ، بقدر ما أتذكر صفحة نتائج Google تأتي مع javscript المفرطة التي يتم حقنها في DOM على تحميل الصفحة ، ثم يتم تعيين نوع من الرموز حتى يتعين عليك تحليلها. ثم هناك طلب Ajax مع تلك الرموز التي تُرجع JS أو JSON التي تم فك تشفيرها لبناء النتائج وما إلى ذلك. هذا ليس من الصعب القيام به في نهايتك كمطور ، لكن الغالبية العظمى من اللصوص المحتملين لا يمكنهم التعامل معها. معظم الذين لا يمكن أن يبذلوا الجهد. أقوم بذلك لالتفاف خدمات قيمة حقًا ، لكن بالنسبة لمعظم الخدمات الأخرى ، أنتقل فقط إلى بعض الفاكهة المعلقة في مزودي مختلفين.

آمل أن يكون هذا مفيدًا لأي شخص يقابله.

Answer 5

أعتقد أن التركيز على كيفية "مستحيل" لمنع مستخدم محدد وذكي من الناحية الفنية من تجريف موقع ويب يعطى الكثير من الأهمية. ينص Drew Noakes على أن موقع الويب يحتوي على معلومات عندما يتم أخذها في Compregate بعض "القيمة". إذا كان لدى موقع ويب تجميع البيانات التي يمكن الوصول إليها بسهولة من قبل المستخدمين المجهولين غير المقيدين ، فعندئذ نعم ، قد يكون منع الكشط "مستحيلًا".

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

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

1] حسابات المستخدم/الوصول - لا ينبغي لأحد الوصول إلى جميع البيانات في فترة زمنية معينة (بيانات/مجال محددة). يجب أن يكون المستخدمون قادرين على الوصول إلى البيانات ذات الصلة بهم ، ولكن من الواضح من السؤال ، لن يكون لدى أي مستخدم هدف مشروع للاستعلام عن جميع البيانات الإجمالية. دون معرفة تفاصيل الموقع ، أظن أن المستخدم الشرعي قد يحتاج فقط إلى مجموعة فرعية صغيرة من البيانات خلال فترة زمنية معينة. اطلب أن يتم حظر احتياجات المستخدم النموذجية بشكل كبير أو خلطها بدلاً من ذلك ، وذلك لجعل الكشط يستغرق وقتًا طويلاً للوقت والبيانات المحملة التي يحتمل أن تكون قديمة.

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

وبالمثل ، فإن طلبات المستخدمين للحصول على بيانات بكميات أكبر بكثير من المعيار يمكن أن تساعد في تحديد الأفراد الذين من المحتمل أن يكونوا يخضعون للبيانات ؛ يمكن أن يكون مثل هذا النهج مؤتمراً وحتى تمديده بشكل أكبر للنظر عبر حسابات متعددة عن الأنماط التي تشير إلى التخلي. يقوم المستخدم 1 بإخلاص 10 ٪ ، يقوم المستخدم 2 بإخلاص 10 ٪ التالية ، وتجزير المستخدم 3 10 ٪ التالية ، وما إلى ذلك ... يمكن أن توفر أنماط من هذا القبيل (وغيرها) مؤشرات قوية للاستخدام الخبيث للنظام من قبل فرد أو مجموعة واحدة حسابات متعددة

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

دمج حسابات المستخدم في الموقع ، وإنشاء خطوط أساس الاستخدام للمستخدمين ، وتحديد واختناق المستخدمين (أو غيرها من أساليب التخفيف) التي تنحرف بشكل كبير عن أنماط الاستخدام النموذجية ، وإنشاء واجهة لطلب نتيجة معالجة/هضم ستخلق مجموعات (بيانات إجمالية RAW) تعقيدات مهمة للأفراد الخبيثين الذين يعتزمون سرقة بياناتك. قد يكون من المستحيل منع إلغاء بيانات موقع الويب ، ولكن "الاستحالة" يعتمد على البيانات الإجمالية التي يمكن الوصول إليها بسهولة للمكشطة. لا يمكنك كشط ما لا يمكنك رؤيته. لذلك ، ما لم تكن بياناتك الإجمالية هي نص غير معالج (على سبيل المثال كتب المكتبة الإلكترونية) ، يجب ألا يتمكن المستخدمون النهائيون من الوصول إلى بيانات RAW الإجمالية. حتى في مثال الكتاب الإلكتروني للمكتبة ، يجب حظر أو اختناق أو اختناقه أو اختناقه.

Answer 6

يمكنك اكتشاف مستخدمي Tor باستخدام Tordnsel - https://www.torproject.org/projects/tordnsel.html.en.

يمكنك فقط استخدام سطر الأوامر/المكتبة - https://github.com/assafmo/istorexit.