فیلتر 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 آن را دوباره اجرا کنید. قالب لاگ همان رابطی است که با آن تطبیق می‌دهید، و یک API پایدار نیست.

جیل‌ها را بر اساس سطح جدا کنید، نه بر اساس دیمن

یک 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 خودش را دارد که ارزش بررسی دارند پیش از اینکه دو محدودکننده نرخ را روی همان پورت بچینید.