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-এর পেছনের প্রতিটি ব্যবহারকারীকে শাস্তি দেয়, আর টানেল পৃষ্ঠে আক্রমণাত্মক ব্যান সেই বৈধ ক্লায়েন্টদের বিচ্ছিন্ন করে যাদের সংরক্ষিত শংসাপত্র রাতারাতি মেয়াদোত্তীর্ণ হয়েছে।

ব্যান, ব্যাকএন্ড ও পার্শ্বপ্রতিক্রিয়া যাচাই করুন

পুনরায় চালুর পরে স্ট্যাটাস আউটপুটই দ্রুততম নিশ্চিতকরণ যে jail-টি আছে এবং গণনা করছে:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

তারপর নিশ্চিত করুন যে ব্যানটি আপনার আসলে চালানো ফায়ারওয়াল পর্যন্ত পৌঁছায়, কারণ যে ব্যাকএন্ড কেউ প্রয়োগ করে না তার জন্য সাজানো 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 সেটিংস আছে যা একই পোর্টে দুটি রেট লিমিটার স্তূপ করার আগে পরীক্ষা করা উচিত।