قفل الحساب مقابل حجب العنوان: أين يحسب OpenVPN فعلياً

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

بالنسبة إلى VPN يفوّض المصادقة إلى PAM، العدّاد هو ما تصل إليه حزمة PAM، لا ما سجّله المستمع.

عدّادان، ضحيتان مختلفتان

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

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

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

اعثر على المخزن الذي يملك العدّاد أصلاً

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

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

اقرأ ملف الخدمة الذي يذكره VPN فعلاً ثم تتبّع أسطر التضمين. في كثير من التوزيعات تضمّ خدمة VPN ملفاً مشتركاً، ما يعني أن العدّاد الذي ستضبطه ينطبق أيضاً على SSH وعلى عمليات الدخول المحلية.

إذا كان الدليل يفرض قفلاً بالفعل، فالسؤال المفيد هو كيف تصل محادثة PAM إلى ذلك القرار وكيف يبلّغ عنه VPN. إضافة عدّ محلي فوقه لا تصبح عدّاد الدليل، وقد تختلف السياستان حول وقت فتح الحساب.

pam_faillock له ثلاثة مواضع استدعاء، لا واحد

تفصل الوحدة ثلاث عمليات غالباً ما يطمسها سطر منسوخ واحد: التحقق من أن الحساب مقفل بالفعل، وتسجيل فشل مصادقة، ومسح سجل الفشل بعد نجاح.

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

faillock --user alice
faillock --user alice --reset

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

اسم خدمة مخصص ليس عزلاً

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

قرّر صراحة هل يغطي القفل وصول VPN فقط أم كل خدمة تصادق الحساب نفسه. الجوابان مقبولان، ونمط الفشل هو الاعتقاد بأنك اخترت أحدهما بينما تنفّذ الحزمة الآخر. اكتب الجواب بجانب ملف الخدمة.

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

اقبل التسلسل، لا رفضاً واحداً

اختبر بهويات مخصصة وفق خطة معتمدة، واختبر سلسلة لا حدثاً واحداً: حساب صالح يصادق، وكلمة مرور خاطئة متعمدة تحرّك العدّاد، والقفل المضبوط يصبح ساري المفعول، والتعافي الموثق يعيد الوصول.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

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

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