في 1 سبتمبر 2026، تم إصدار CrowdSec 1.8 - وفي WAF مفتوح المصدر، الذي يتم تثبيته على الخادم الخاص بك عبر helm install، جاءت شيئين معًا: بصمة المتصفح وproof-of-work. حتى الآن، كانت جدران PoW تُقابل في البرية بشكل رئيسي على Git-forges وأرشيفات النشرات. الآن يمكن أن يظهر مثل هذا الطبقة على أي موقع لديه خمسمائة زائر يوميًا.
دعونا نفهم ما الذي تغير بالضبط، ولماذا انتقل الكشف إلى اتجاه "ادفع بواسطة المعالج"، والأهم - لماذا يعتبر الهاش في هذه البنية أقل المشاكل.
ما الذي حدث: PoW انتقل من Git-forges إلى المواقع العادية
CrowdSec هو نظام مستضاف ذاتيًا: الوكيل يقرأ السجلات، وWAF يقف أمام التطبيق، و"الباونس" يقومون بالحجب. في الإصدار 1.8، أضاف الفريق إلى WAF آلية لا تجيب على السؤال "هل هذا IP سيء؟"، بل على السؤال "هل هذا في الواقع متصفح بشري أم روبوت يتظاهر بأنه إنسان؟". يتم جمع الإجابة من بصمة المتصفح (خصائص المتصفح وتوقيع TLS) وproof-of-work - مهمة حسابية يجب على العميل حلها قبل أن يرى الخادم الطلب.
يتم صياغة الدافع من قبل المؤلفين بدون دبلوماسية: يأتي الروبوت العادي في عام 2026 مع Chrome حقيقي، وبصمة TLS متسقة، وIP مقيم - ولديه صبر أكثر من المهندس المناوب. هذا الاعتراف من جانب الكشف أغلى من أي تحليل: أصبح العنوان المقيم وTLS النظيف لم يعدا علامة فاصلة. نظرًا لأن الروبوت لم يعد يختلف عن الإنسان من حيث سمعة IP والمصافحة، تبحث الحماية عن علامة تكون رخيصة للمتصفح وغالية لحديقة الآلات.
في الوقت نفسه، ظهرت POWBlock على Hacker News في نفس الأيام - "خدمة proof-of-work لأي خادم". يمكن اعتبار إصدار واحد مصادفة، لكن إشارتين مستقلتين في أسبوع واحد - هي بالفعل اتجاه.
كيف تعمل جدار PoW على مثال Anubis
النموذج المثالي هو Anubis: بروكسي عكسي مكتوب بلغة Go تحت ترخيص MIT، والذي كتبه Xe Iaso تحت علامة Techaro منذ يناير 2025. الفكرة مباشرة من hashcash لآدم باك عام 1997: يقوم العميل بتجربة القيم حتى يعطي SHA-256 هاشًا بالعدد المطلوب من الأصفار البادئة. إذا تم الحل - يحصل على ملف تعريف ارتباط JWT موقّع (techaro.lol-anubis-auth) والوصول المؤقت. إذا لم يتم الحل - فلن يعرف الخادم عنك.
يتم تحديد الصعوبة من قبل المسؤول. بشكل افتراضي، يتحدى Anubis كل ما يبدو كمتصفح - أي كل ما يحتوي على سلسلة Mozilla في User-Agent. ما تكلفته كل مستوى يظهره القياسات:
- الصعوبة 1 - أقل من 100 مللي ثانية.
- الصعوبة 4 (افتراضي) - حوالي 1.35 ثانية على Intel Core Ultra 7 165H، وهذا حوالي 87,600 هاش في الثانية في المتصفح.
- الصعوبة 8 - حوالي 11 ثانية.
- الصعوبة 10 - حوالي 114 ثانية.
بين المستوى الرابع والعاشر، الفرق حوالي 84 مرة. قائمة المنفذين تبدو مثيرة للإعجاب: أرشيف نشر نواة Linux وخادم Git لنواة، sourcehut، FFmpeg، GitLab لمشروع GNOME، Wine، sourceware.org، FreeCAD، ScummVM، Enlightenment، اليونسكو. في جامعة Duke، قطع الطيار في يونيو 2025 أكثر من 4 ملايين طلب HTTP غير مرغوب فيه يوميًا - حوالي 90% من حركة المرور غير المرغوب فيها، - وفي أسبوع واحد، اشتكى 12 شخصًا من المشاكل.
ظهرت هذه الجدران ليس من باب الضرر. في Read the Docs، قام زاحف واحد بتنزيل 73 تيرابايت في شهر واحد؛ بعد الحجب، انخفضت حركة المرور اليومية من 800 غيغابايت إلى 200 غيغابايت، مما وفر حوالي 1500 دولار في الشهر. وصف ديو ديفولت أن القتال مع الزواحف كان يستهلك منه من 20 إلى 100 في المئة من أسابيع معينة. في ظل زيادة حركة المرور الآلية بنسبة 23.51% في عام 2025 ونمو حركة مرور الذكاء الاصطناعي تقريبًا ثلاثة أضعاف خلال العام، بدأ المسؤولون في اتخاذ إجراءات سريعة.
التحول: ضد الزحف الصناعي، PoW لا يعمل تقريبًا
والآن الجزء غير المريح، الذي نادرًا ما يُكتب في البيانات الصحفية. يعتمد proof-of-work على عدم التماثل "رخيص للتحقق، مكلف للحل". في الويب، تم توجيه هذا عدم التماثل في الاتجاه الخطأ.
يعتبر الزائر الشريف الهاش ككود JavaScript بطيء في المتصفح. أما الذي جاء للحصول على البيانات، فيعتبرها كودًا أصليًا. كتب تافيس أورماندي حلاً في 25 سطرًا من C: مهمة الصعوبة 5 تُغلق تقريبًا في 0.017 ثانية - وهذا أسرع بحوالي 200 مرة من SubtleCrypto في المتصفح. الفجوة على GPU أكبر بكثير، حوالي مئة مرة أو أكثر. النتيجة الحسابية بسيطة: بالنسبة لمورد كبير، فإن تجاوز جميع مواقع Anubis يكلف تقريبًا لا شيء.
هذه ليست نظرية. أبلغ Codeberg في أغسطس 2025 أن العديد من روبوتات الزحف تعلمت حل تحديات Anubis. ومع ذلك، لم تصبح الجدار عديمة الفائدة - فقد كانت تقطع الكتلة الرئيسية لعدة أشهر، - لكن كحاجز لمن هو مستعد لاستثمار ليلة واحدة في حل أصلي، فهي لا تصمد.
يدفع الفاتورة، كما هو معتاد، المستخدم الحقيقي. الصعوبة 5 - تستغرق حوالي ثانيتين على MacBook حديث، وعشرات الثواني على جهاز كمبيوتر محمول قديم، وما يصل إلى دقيقتين على الهاتف. في GitLab GNOME، تم تسجيل حالة تجمد لمدة نصف ساعة في Firefox - حالة شاذة، لكنها نموذجية. بالإضافة إلى الاستثناءات الصارمة: بشكل افتراضي، يتطلب Anubis JavaScript، لذا فإن قارئات RSS، curl، wget وLynx ببساطة تتوقف. يقوم المشروع بإصلاح ذلك - في الإصدار 1.20.0، تم إضافة مسار بدون JS عبر meta-refresh، - لكن في 1.22.0 جاء Proof of React، الذي زاد من متطلبات المتصفح.
من المهم أيضًا معرفة مدى استقرار المشروع نفسه: حوالي نصف الكود يتم الالتزام به من قبل شخص واحد، ومن بين أكثر من 80 مساهمًا، تجاوز مطور واحد آخر فقط عشرة التزامات. بالإضافة إلى ذلك، تم دمج خدمة مدفوعة Thoth في Anubis لتصفية GeoIP وBGP - مما يعني أن المشروع المفتوح لديه جار تجاري.
أين يعض PoW حقًا: النسخة التجارية تعمل بشكل مختلف
هنا تكمن الخدعة الرئيسية. تستخدم Kasada وhCaptcha وCloudflare Turnstile أيضًا proof-of-work - لكن ليس بالطريقة نفسها التي يستخدمها Anubis.
في Anubis، اللغز هو الجدار: نفذت JS، حسبت الهاش - مررت. إشارة واحدة، حاجز واحد. في الأنظمة التجارية، يعمل PoW كـ تصديق. في Kasada، تستغرق المهمة بضع مللي ثانية - قليلة جدًا لدرجة أنها بلا معنى كحاجز. المعنى في شيء آخر: لحلها، يجب على العميل تشغيل آلة افتراضية مشوشة، حيث يحدث الكشف الحقيقي. إذا حسبت الهاش، دون تنفيذ كل ما تبقى، فلن تحصل على شيء. تضيف hCaptcha PoW فوق الحكم على الصور، مما يزيد من التكلفة الحسابية للعملاء المشبوهين، بينما تعتبر Turnstile PoW إشارة واحدة بين العديد من اختبارات البيئة.
الفرق جوهري. يتم كسر الجدار المفتوح بواسطة حل أصلي رخيص. يتم كسر التجاري ليس بواسطة الهاش، ولكن بسبب الحاجة إلى تنفيذ الكود المشوش الخاص بالآخرين بصدق وعدم الانكشاف على البيئة - وهذا مكلف، لأن التشويش يتغير بانتظام. CrowdSec 1.8 مثير للاهتمام تمامًا لأنه يجلب مزيجًا من هذه المنطق (بصمة بجانب PoW) إلى عالم مستضاف ذاتيًا، حيث كان الحد الأقصى هو معدل الحد حسب IP.
ما الذي يغيره في الممارسة العملية
إذا كنت تجمع البيانات بشكل قانوني - تراقب الأسعار، تتابع علامتك التجارية، تجري أبحاثًا - فإن الاستنتاجات تكون محددة تمامًا.
- المشكلة ليست في الهاش، بل في طبقة المتصفح. يتم حساب الهاش محليًا في مللي ثانية. لا يتم حساب بصمة المتصفح، الآلة الافتراضية المشوشة والبيئة الصحيحة. التحول العملي: حيث كان يكفي سابقًا عميل HTTP، الآن تحتاج إلى محرك متصفح حقيقي. هذا أغلى من حيث وحدة المعالجة المركزية والذاكرة، ويجب التخطيط لذلك على الفور.
- الاقتصاد ينتقل من حركة المرور إلى الوقت والمعالج. سابقًا، كانت تكلفة الإنتاج تُحسب بناءً على IP والغيغابايت. الآن تُضاف إليها ثوانٍ لكل صفحة وتحميل النوى. يجب قياس التكلفة ليس لكل غيغابايت، بل تكلفة تسجيل ناجح واحد - مع جدار PoW، تتباعد هاتان المقياستان بشكل خاص.
- الجلسة تصبح أصلًا. يمنح Anubis ملف تعريف ارتباط JWT لفترة. إذا قمت بتغيير IP بعد كل طلب، فإنك تدفع ضريبة PoW مرة أخرى على كل صفحة. الجلسات اللاصقة على بروكسيات سكنية هنا تعطي فائدة ليس في "الخصوصية"، بل مباشرة في الحسابات: يتم توزيع حل المهمة على عشرات الصفحات. تتحول الدورات العدوانية في عالم PoW من ممارسة جيدة إلى استهلاك زائد.
- الحل لا يحل محل السلوك. نفس المنطق الذي جعل حلول الكابتشا لم تعد تغلق القضية: أنت تحل مهمة مرئية، بينما يتم إصدار الحكم بناءً على إشارات غير مرئية حولها.
- قلل من التردد - هذا أرخص من أي جدار. نشأت موجة PoW من قصص مثل 73 تيرابايت في شهر واحد من زاحف واحد. التخزين المؤقت، الطلبات الشرطية، الفترات المعقولة والاحترام لـ robots.txt تبعدك عن الرادار قبل أن يبدأ التحدي. عناوين مراكز البيانات الرخيصة بالإضافة إلى headless بأقصى تردد - هو بالضبط ذلك الملف الشخصي الذي يتم وضع الجدران لأجله.
الاستنتاج
CrowdSec 1.8 ليست "نهاية الزحف"، ولم تصبح Anubis كذلك: يحل الحل الأصلي مهمة الصعوبة 5 في 0.017 ثانية، بينما ينتظر الإنسان الحقيقي على هاتف قديم حتى دقيقتين. الخبر الحقيقي في شيء آخر. أولاً، اعترف الكشف بصوت عالٍ أن IP المقيم وTLS النظيف لم يعدا يثبتان شيئًا. ثانيًا، لم يعد طبقة "أثبت أنك متصفح" امتيازًا للمواقع الكبيرة ذات الميزانية على Kasada وانتقلت إلى المصدر المفتوح، الذي يتم تثبيته على المواقع العادية.
يجب الاستعداد ليس للقتال مع الهاشات، بل لما ستتخلى عنه المخطط الرخيص "الكثير من IP بالإضافة إلى عميل HTTP سريع" على أهداف أصغر. الفائز هو التكوين المعاكس: عدد أقل من الطلبات، متصفح حقيقي، جلسات طويلة وعناوين ذات جودة حيث تحتاج إلى مرور موثوق واحد، وليس ألف محاولة رخيصة.