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

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

كانت الدافع لبناء هذا البرنامج الوسيط ناشئاً عن مشكلة حقيقية ومكلفة. كان تطبيق كبير يستهلك نطاق ترددي وموارد خادم بمعدلات لم تتطابق مع قاعدة المستخدمين الفعلية. كشفت سجلات الوصول عن كميات هائلة من الطلبات من وكلاء المستخدمين يدّعون أنهم Googlebot و Bingbot وغيرهم من الزحافات الشرعية. أكد التحقيق أن الأغلبية من هذه كانت مزيفة، تنشأ من موفري الاستضافة السحابية بدلاً من محركات البحث التي ادّعت تمثيلها. كل طلب مزيف استهلك نفس موارد الخادم كطلب حقيقي: نفس وقت تنفيذ PHP، نفس استعلامات قاعدة البيانات، نفس تخصيص الذاكرة، نفس النطاق الترددي للرد. مضروباً عبر آلاف الطلبات المزيفة كل ساعة، كانت التكلفة كبيرة. تم تصميم حل البرنامج الوسيط للقضاء على هذا الهدر بإيقاف الزحافات المزيفة قبل استهلاك أي موارد تطبيق على الإطلاق.

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

منطق القرار وراء الحظر على طبقة الوسيط

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

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

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

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

ما يحدث للطلبات التي يتم حظرها

حظر زاحفة مزيفة ليس ببساطة مسألة إرجاع رد 403 والمتابعة. يجب تسجيل قرار الحظر وسياقه للتحليل. كل طلب محظور يمثل نقطة بيانات حول من يحاول الوصول إلى الموقع، ما يدّعون أنهم، وأين يأتون. مع مرور الوقت، يكشف هذا السجل عن أنماط تبلغ القرارات الأمنية الأوسع. ربما ASN محدد مسؤول عن حصة غير متناسبة من الزحافات المزيفة. ربما تارة الطلبات المزعومة من Googlebot المزيفة في أوقات محددة من اليوم. ربما مسار عنوان URL محدد يجذب زحافات مزيفة أكثر من غيرها، مما يقترح أن البوتات تستهدف محتوى محدد.

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

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

التحقق المتزامن مقابل غير المتزامن

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

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

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

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

التأثير القابل للقياس للحظر عند الباب

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

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

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

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