مرشّح Fail2ban لخادم OpenVPN Access Server: real_ip والسجون

لقد نسخت OpenVPN سجنًا من منشور مجتمعي، وأعدت تشغيل fail2ban، ومع ذلك لا يُحجب أي عنوان أبدًا. السبب دائمًا تقريبًا هو تنسيق السجل: فخادم Access Server لا يكتب أسطر فشل المصادقة التي يتوقعها مرشّح جاهز. قبل أن تلمس المرشّح، تأكّد أولًا من وجود السجلات أصلًا، لأن النمط لا يستطيع مطابقة ما لم تسجّله الخدمة قط.

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

تأكّد من وجود سجل الفشل

يكتب خادم Access Server أسطره المنظمة الخاصة إلى /var/log/openvpnas.log، ويوجد عنوان العميل في حقل real_ip بين علامتي اقتباس وليس في بداية سطر syslog. ابحث عن عملية تسجيل دخول فاشلة تعرف أنها حدثت قبل كتابة أي نمط:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

إذا لم يظهر شيء، فإن مستوى السجل هو المشتبه التالي. يمتلك خادم Access Server مفتاح تصحيح لقاعدة بيانات السجل في /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1)، و يجب إعادة تشغيل الخدمة بعد تغييره. تعامل مع ذلك المفتاح كإعداد تشخيصي يُعاد تخفيضه بمجرد أن تحصل على نمطك، وليس كإعداد دائم.

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

ثبّت مرشّحًا واحدًا على real_ip

أبقِ التعبير ضيقًا. فالمرشّح الذي يطالب بأي سطر يحتوي عنوان IP سيحجب الناس بسبب انقطاعات عادية، وعلى خادم مزدحم يكون العرَض الوحيد شكوى المستخدمين من أنهم أُقفلوا خارج النظام لأنهم أغلقوا حاسوبًا محمولًا. طالب بسجل الخطأ والتقط العنوان بين علامتي الاقتباس:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

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

عندما تحتاج دقة لكل سطح، ضيّق أكثر باشتراط علامة السطح (WEB_CLIENT أو WEB_ADMIN أو VPN) في السطر نفسه. فمرشّح واحد بثلاثة أنماط أسهل في التدقيق من ثلاثة مرشّحات تختلف في كلمة واحدة.

اختبر التعبير قبل تفعيل السجن

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

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

قارن عدد المطابقات مع الأعطال التي تحققت منها في الخطوة الأولى. صفر مطابقات يعني أن النمط خاطئ؛ والمطابقات على أسطر ليست أعطال مصادقة تعني أنه واسع جدًا. اقرأ missed.txt حتى تستطيع تفسير كل سطر اخترت عدم المطالبة به.

أجرِ هذا الاختبار على نسخة إذا كان السجل كبيرًا، وأعد إجراءه بعد أي ترقية لخادم Access Server. فتنسيق السجل هو الواجهة التي تطابق ضدها، وهو ليس واجهة برمجية مستقرة.

افصل السجون حسب السطح، لا حسب الخدمة الخفية

يقدّم خادم Access Server واحد عدة أسطح مصادقة: واجهتا العميل والإدارة على 943/tcp، والنفق على 1194/udp أو 443/tcp في معظم عمليات النشر. وسجن واحد يغطيها جميعًا يسمح لمحاولات التخمين على النفق بحجب عنوان هو أيضًا مسار الإدارة لديك، ويخفي أي سطح يتعرض للهجوم فعليًا. أعطِ كل سطح سجنه الخاص بمنفذه وحدوده:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

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

تحقّق من الحجب والخلفية والأضرار الجانبية

بعد إعادة التشغيل، يكون مخرج الحالة أسرع تأكيد على أن السجن موجود ويعدّ:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

ثم تأكّد من أن الحجب يصل إلى الجدار الناري الذي تشغّله فعلًا، لأن سجنًا مضبوطًا على خلفية لا يفرضها أحد لا يحمي شيئًا. مع إجراء iptables تظهر العناوين في سلسلة تحمل اسم السجن (f2b-openvpnas-tunnel)؛ ومع إجراء nftables تهبط في مجموعة داخل جدول fail2ban الخاص. افحص الذي يستخدمه مضيفك بدلًا من الافتراض.

فحصان جانبيان أهم من الحجب نفسه. أولًا، تحقّق من أن real_ip هو عنوان العميل وليس موازن أحمال أو وكيلًا عكسيًا؛ فخلف وكيل ينتهي كل حجب على الوكيل ويجرّ الخدمة بأكملها معه. ثانيًا، اكتب إجراء رفع الحجب، لأن العنوان الذي يتجاوز الحد عند 02:00 عادةً ما يعود للمهندس المناوب: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

أبقِ الحدود في ذهنك أثناء الضبط. فـ Fail2ban محدّد معدل على سطح مصادقة واحد، وليس طبقة تحكّم في الوصول. وهو لا يغني عن MFA ولا عن القيود لكل حساب ولا عن إبعاد واجهة الإدارة عن الإنترنت العام، ولخادم Access Server إعدادات autoban خاصة به يجدر فحصها قبل أن تضع محدّدي معدل على المنفذ نفسه.