لماذا أحصل على الكثير من عمليات البحث من مواقع صينية؟

هناك عدد أكبر بكثير من ذلك في القائمة، هل لديك أي أفكار؟

رأيت هذا اليوم في سجلات أحد عملائنا، لذا فإن الأمر أكثر من مجرد مصادفة.

تعديل: لا، أعتقد أنه مصادفة. البحث عن ymwears.cn يُظهر المزيد من الشكاوى بشأن البريد العشوائي للإحالات، على سبيل المثال هذه (أقدم من عام واحد): Relevanssi shows weird search queries on my page | WordPress.org و Block specific referrer or agent to enter url | WordPress.org

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

مثير للاهتمام، هل تعلمون أي حل قد يعمل دون الحاجة للعبث بالخادم نفسه..

@pfaffman @RGJ

يُعد البريد العشوائي للمرجع (Referrer spam) مشكلة كبيرة حتى الشركات الكبرى (أي Google Analytics) لا تحاربها بنجاح بنسبة 100%. في الوقت الحالي، كل ما يمكنني التفكير فيه هو إزالة هذه الإدخالات يدويًا.

بما أن هذه المواقع تبدو - على الأقل جزئيًا - متطابقة عبر مواقع Discourse مستقلة متعددة (نظرًا لأن لقطات الشاشة الخاصة بنا تُظهر قائمة متشابهة جدًا)، فربما تكون القائمة السوداء (الديناميكية) فكرة جيدة؟ @codinghorror هل لديك اقتراح؟

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

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

إليك مقتطفًا من جزء من الكود الذي نستخدمه على أحد مواقعنا كمثال:

$user_agents = explode('|',$string_of_bad_user_agents,-1);
$hide_content_useragent = $_SERVER['HTTP_USER_AGENT'];
$IS_A_BAD_BOT = FALSE;

foreach($user_agents as $hcag) {
    trim($hcag);
    if (preg_match("/$hcag/i", "$hide_content_useragent")) {
        $IS_A_BAD_BOT = TRUE;
        break;
    }
}

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

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

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

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

على مدى السنوات القليلة الماضية، أثبت الحظر بناءً على سلسلة وكيل المستخدم أنه الطريقة الأكثر موثوقية (أحيانًا بالاقتران مع معلومات GeoIP، وأحيانًا لا)؛ ولكن بالطبع، يبدأ المحتالون ومديرو الروبوتات ووكلاؤهم أيضًا في إخفاء سلاسل وكيل المستخدم كما فعلوا مع عناوين IP (لسنوات عديدة).

أتمنى أن يكون هذا مفيدًا.

تحياتي وحظًا موفقًا في صيد الروبوتات!

نعم، أنا أتفق تمامًا على أن حظر عناوين IP ليس فعالًا.

يبدو أن حظر وكيل المستخدم يعمل بشكل جيد إلى حد ما، إلا عندما يقوم مرسلو البريد العشوائي بتغييره باستمرار.

لهذا السبب توجهت أفكاري نحو مجرد إدراج عنوان URL الفعلي الذي يتعرض لرسائل البريد العشوائي المرجعية في القائمة السوداء.

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

أفكار ممتازة.

لا توجد حل واحد يناسب الجميع لوقف البوتات الخارجة عن السيطرة والخبيثة؛ بل يجب على كل موقع تقييم الضوابط التي تناسبه أفضل.

على غرار ذلك…

المواقع التي تعتمد بشكل أساسي على القوائم السوداء وقواعد بيانات الرسائل غير المرغوب فيها أو البوتات الخارجة عن السيطرة قد تواجه مشاكل أيضًا. فلنفترض أن شخصًا ما لا يحب الموقع www.our-arch-rival.com لأن هذا الموقع منافس (أو ببساطة أثار غضبنا أو أساء إلينا). حينها قد يقوم بعض الأشخاص بإرسال الموقع www.our-arch-rival.com إلى قائمة سوداء أو قاعدة بيانات، مما يؤدي إلى تصفية مواقع أخرى شرعية نتيجة لهذا النوع من “النتائج السيئة” الناتجة عن طريقة إدراج قواعد البيانات في القوائم السوداء.

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

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

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

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

جاهز، لاعب واحد!

وهو ما يُعدّ سببًا آخر لتجنب الحظر بناءً على عناوين IP: فمرسلي الرسائل المزعجة سيعرفون أنك تتخذ إجراءات.

أعتقد أنه يمكنني حظر معظم المرسلي البريد العشوائي عبر Cloudflare، لكنني لست متأكدًا مما يجب وضعه في القواعد الخاصة بـ User-Agent للمتصفح.

@neounix، ماذا تقصد بـ “UA strings”؟ وكيف يمكن استخدامها في قواعد جدار الحماية في Cloudflare؟

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

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

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

إزعاج المراجع لا يقوم أبدًا بأي شيء؛ فهو مصمم فقط للظهور في التقارير.

@Yassine_Yousfi

إليك ما تحتاجه…

في بروتوكول HTTP، تُستخدم سلسلة User-Agent غالبًا في التفاوض على المحتوى، حيث يختار الخادم الأصلي المحتوى أو معاملات التشغيل المناسبة للاستجابة. على سبيل المثال، قد يستخدم خادم الويب سلسلة User-Agent لاختيار المتغيرات بناءً على القدرات المعروفة لنسخة معينة من برامج العميل. تم دمج مفهوم تخصيص المحتوى في معيار HTTP في RFC 1945 “لغرض تخصيص الاستجابات لتجنب قيود معينة في وكيل المستخدم”.

تُعد سلسلة User-Agent أحد المعايير التي قد تُستبعد بها عناكب الويب من الوصول إلى أجزاء معينة من موقع الويب باستخدام معيار استبعاد الروبوتات(ملف robots.txt).

مثل العديد من رؤوس طلبات HTTP الأخرى، تساهم المعلومات في سلسلة “User-Agent” في المعلومات التي يرسلها العميل إلى الخادم، نظرًا لأن السلسلة قد تختلف اختلافًا كبيرًا من مستخدم إلى آخر.[5]

مرجع:

@Yassine_Yousfi، هناك مراجع لا حصر لها على الإنترنت حول سلاسل وكيل المستخدم (UA) في بروتوكول HTTP وكيفية استخدامها بطرق مختلفة، بما في ذلك استخدامها كمستشعر عند اكتشاف الروبوتات وأنشطة الإنترنت الخبيثة الأخرى.

استمتع بالصيد!

ملاحظات:

  1. يمكنك عرض نظرة Discourse لوكلاء مستخدمين من نوع الروبوت هنا (تم اختصار بعض سلاسل UA):
https://discourse.your-great-domain.com/admin/reports/web_crawlers
  1. لا يمكن لخوارزمية اكتشاف واحدة اكتشاف جميع الروبوتات بدقة 100%.

  2. يمكنك أيضًا الحصول على سلاسل UA من ملفات سجلات خادم الويب الخاص بك وطرق أخرى.

انظر أيضًا: