OpenVPN Access Server کے لیے Fail2ban فلٹر: real_ip اور jail

آپ نے کمیونٹی پوسٹ سے ایک OpenVPN jail کاپی کیا، fail2ban دوبارہ شروع کیا، اور کوئی پتہ کبھی بلاک نہیں ہوتا۔ وجہ تقریباً ہمیشہ لاگ فارمیٹ ہوتی ہے: Access Server وہ تصدیقی ناکامی کی سطریں نہیں لکھتا جن کی اسٹاک فلٹر توقع کرتا ہے۔ فلٹر کو چھونے سے پہلے تصدیق کریں کہ ریکارڈ موجود ہیں بھی، کیونکہ پیٹرن اس چیز سے میل نہیں کھا سکتا جو سروس نے کبھی لاگ نہ کی ہو۔

یہ وہ رن بک ہے جس پر میں Access Server ہوسٹ پر عمل کرتا ہوں: ریکارڈ کی شکل کی تصدیق کریں، ایک اینکر شدہ اظہار لکھیں، اسے اصل لاگ پر پرکھیں، پھر حملے کی سطح کے مطابق jail تقسیم کریں اور جانچیں کہ بلاک فائر وال تک پہنچتا ہے۔

تصدیق کریں کہ ناکامی کا ریکارڈ موجود ہے

Access Server اپنی ساختہ سطریں /var/log/openvpnas.log میں لکھتا ہے، اور کلائنٹ کا پتہ syslog سطر کے شروع میں نہیں بلکہ اقتباس کے اندر real_ip فیلڈ میں ہوتا ہے۔ کوئی بھی پیٹرن لکھنے سے پہلے وہ ناکام لاگ ان تلاش کریں جس کے بارے میں آپ جانتے ہیں کہ ہوا تھا:

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

اگر کچھ نظر نہ آئے تو اگلا مشتبہ لاگ کی سطح ہے۔ Access Server میں /usr/local/openvpn_as/etc/as.conf میں لاگ ڈیٹا بیس کا ڈیبگ سوئچ ہے (DEBUG_LOGDB=1)، اور اسے تبدیل کرنے کے بعد سروس دوبارہ شروع کرنی پڑتی ہے۔ اس سوئچ کو ایک تشخیصی ترتیب سمجھیں جسے پیٹرن تیار ہونے پر دوبارہ نیچے کیا جائے گا، مستقل ترتیب نہیں۔

فائل میں رہتے ہوئے غور کریں کہ کون سی سطحیں اس میں لکھتی ہیں۔ کلائنٹ پورٹل، ایڈمن انٹرفیس اور ٹنل تصدیق کی ناکامیاں ایک ہی فائل میں مختلف مارکر کے ساتھ آتی ہیں، اور یہی تفصیل بعد میں jail کی ترتیب طے کرتی ہے۔

real_ip پر ایک فلٹر اینکر کریں

اظہار کو تنگ رکھیں۔ IP پتہ رکھنے والی ہر سطر کا دعویٰ کرنے والا فلٹر لوگوں کو عام منقطع ہونے پر بلاک کرے گا، اور مصروف سرور پر واحد علامت یہ ہے کہ صارفین شکایت کرتے ہیں کہ لیپ ٹاپ بند کرنے پر انہیں لاک کر دیا گیا۔ ناکامی کا ریکارڈ دعویٰ کریں اور اقتباس کے اندر کا پتہ پکڑیں:

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

شروع کا خلا سجاوٹ نہیں ہے۔ Access Server اپنے ریکارڈ اندر دھکیلتا ہے، اور اس پر اینکر کرنا پیٹرن کو اس فائل میں لکھنے والی غیر متعلقہ سروسز کی سطروں کا دعویٰ کرنے سے روکتا ہے۔ اگر آپ کے ریکارڈ کے شروع میں اس کے بجائے وقت کی مہر ہو تو اس سابقے سے میل کریں، لیکن اس چیز پر اینکر کریں جو آپ کے دعویٰ کرنے والے ہر ریکارڈ میں واقعی موجود ہو۔

جب سطح کے مطابق درستگی درکار ہو تو اسی سطر میں سطح کا مارکر (WEB_CLIENT، WEB_ADMIN یا VPN) مانگ کر مزید تنگ کریں۔ ایک لفظ سے مختلف تین فلٹرز کے مقابلے میں تین پیٹرن والا ایک فلٹر جانچنا آسان ہے۔

jail فعال کرنے سے پہلے اظہار پرکھیں

جس فلٹر کو آپ نے پروڈکشن لاگ پر نہ چلایا ہو اسے کبھی فعال نہ کریں۔ دستاویزی امتحان فلٹر کو دو بار گزرتا ہے، ایک بار لوڈ کرنے اور ایک بار لاگو کرنے کے لیے، اور چھوٹی ہوئی سطروں کی رپورٹ ہی پڑھنے کے قابل حصہ ہے:

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 نہیں ہے۔

jail کو سطح کے مطابق تقسیم کریں، ڈیمون کے مطابق نہیں

ایک Access Server کئی تصدیقی سطحیں پیش کرتا ہے: 943/tcp پر کلائنٹ اور ایڈمن ویب انٹرفیس، اور زیادہ تر تعیناتیوں میں 1194/udp یا 443/tcp پر ٹنل۔ سب کو ڈھکنے والا ایک jail ٹنل پر اندازے کی کوششوں کو ایسا پتہ بلاک کرنے دیتا ہے جو آپ کا ایڈمن راستہ بھی ہے، اور چھپاتا ہے کہ کون سی سطح پر واقعی حملہ ہو رہا ہے۔ ہر سطح کو اس کا اپنا پورٹ اور حدوں والا الگ jail دیں:

# /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 کے پیچھے ہر صارف کو سزا دیتی ہے، اور ٹنل سطح پر جارحانہ بلاک ان جائز کلائنٹس کو منقطع کرتا ہے جن کی محفوظ اسناد راتوں رات ختم ہو گئیں۔

بلاک، backend اور ضمنی نقصان کی جانچ کریں

دوبارہ شروع کرنے کے بعد، اسٹیٹس آؤٹ پٹ سب سے تیز تصدیق ہے کہ jail موجود ہے اور گن رہا ہے:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

پھر تصدیق کریں کہ بلاک اس فائر وال تک پہنچتا ہے جو آپ واقعی چلاتے ہیں، کیونکہ ایسے backend کے لیے ترتیب دیا گیا jail جسے کوئی نافذ نہیں کرتا کچھ بھی محفوظ نہیں کرتا۔ iptables عمل کے ساتھ پتے jail کے نام والی زنجیر میں ظاہر ہوتے ہیں (f2b-openvpnas-tunnel)؛ nftables عمل کے ساتھ وہ fail2ban کی اپنی جدول میں ایک سیٹ میں آتے ہیں۔ اندازہ لگانے کے بجائے وہی جانچیں جو آپ کا ہوسٹ استعمال کرتا ہے۔

دو ضمنی جانچیں خود بلاک سے زیادہ اہم ہیں۔ پہلی، تصدیق کریں کہ real_ip کلائنٹ کا پتہ ہے اور لوڈ بیلنسر یا ریورس پراکسی نہیں؛ پراکسی کے پیچھے ہر بلاک پراکسی پر پڑتا ہے اور پوری سروس کو ساتھ لے ڈوبتا ہے۔ دوسری، ان بلاک کا طریقہ کار لکھ کر رکھیں، کیونکہ 02:00 بجے حد سے گزرنے والا پتہ عام طور پر ڈیوٹی پر موجود انجینئر کا ہوتا ہے: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24۔

ٹیوننگ کرتے وقت حد کو ذہن میں رکھیں۔ Fail2ban ایک تصدیقی سطح پر رفتار محدود کرنے والا ہے، رسائی کنٹرول کی تہہ نہیں۔ یہ MFA، فی اکاؤنٹ پابندیوں یا ایڈمن انٹرفیس کو عوامی انٹرنیٹ سے باہر رکھنے کا متبادل نہیں ہے، اور Access Server کی اپنی autoban ترتیبات ہیں جنہیں ایک ہی پورٹ پر دو رفتار محدود کرنے والے رکھنے سے پہلے جانچنا مناسب ہے۔