اکاؤنٹ لاک بمقابلہ پتہ پابندی: OpenVPN واقعی کہاں گنتا ہے

پتہ بلاک کرنا اور اکاؤنٹ لاک کرنا دو مختلف طریقے ہیں اور یہ مخالف سمتوں میں ناکام ہوتے ہیں۔ پتہ پابندی ایک ماخذ کو روکتی ہے اور ہدف اکاؤنٹ کسی اور جگہ سے قابل رسائی رہتا ہے؛ اکاؤنٹ لاک اس شناخت کو ہر جگہ روکتا ہے، خود صارف کے لیپ ٹاپ پر بھی۔

ایسے VPN کے لیے جو تصدیق PAM کو سونپتا ہے، گنتی وہ ہے جہاں PAM اسٹیک پہنچتا ہے، نہ کہ وہ جو سننے والے نے درج کیا۔

دو گنتیاں، دو مختلف متاثرین

رفتار محدود کرنے والا ماخذ کو دیکھتا ہے اور پوچھتا ہے کہ حال ہی میں وہاں سے کتنی کوششیں آئیں۔ لاک شناخت کو دیکھتا ہے اور پوچھتا ہے کہ اس اکاؤنٹ نے کتنی ناکامیاں جمع کیں۔ پہلا دستیابی بچاتا ہے، دوسرا اسناد؛ کوئی ایک دوسرے کی جگہ نہیں لیتا۔

اسی لیے یہ جملہ کہ پانچ ناکامیوں کے بعد ہم IP بلاک کرتے ہیں، اسناد بھرنے کی رپورٹ کا جواب نہیں ہے۔ حملہ آور ماخذ بدلتا ہے، ہر ایک کو کم کوششیں ملتی ہیں اور اکاؤنٹ کبھی شمار نہیں ہوتا۔ اس کے برعکس، ماخذ کے کنٹرول کے بغیر لاک حملہ آور کو جان بوجھ کر ناکام ہو کر اکاؤنٹ غیر معینہ مدت تک بند رکھنے دیتا ہے۔

دونوں کنٹرول کی بحالی کی کہانیاں بھی مختلف ہیں۔ پتہ پابندی ایسے ٹائمر پر ختم ہوتی ہے جس کے بارے میں کسی کو سوچنا نہیں؛ اکاؤنٹ لاک کے لیے منتظم، تحریری انتظار کی مدت یا خود سروس ری سیٹ درکار ہو سکتا ہے۔

وہ ذخیرہ تلاش کریں جس کے پاس پہلے سے گنتی ہے

کچھ بھی شامل کرنے سے پہلے معلوم کریں کہ ناکامیوں کا ذخیرہ پہلے سے موجود ہے یا نہیں۔ مقامی Linux اکاؤنٹ، ڈائریکٹری سروس اور بیرونی شناخت فراہم کنندہ ہر ایک اپنی گنتی رکھتا ہے، اور ان کے آگے رکھا PAM ماڈیول پہلے کو بڑھانے کے بجائے دوسرا بناتا ہے۔

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

وہ سروس فائل پڑھیں جس کا VPN واقعی نام لیتا ہے اور اس کی شمولیت کی سطریں follow کریں۔ بہت سی تقسیموں میں 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'

کامیابی کے رویے کو ناکامی جیسی توجہ سے دیکھیں۔ اگر کامیاب لاگ ان تاریخ صاف نہ کرے تو عام غلطیوں کے آہستہ جمع ہونے کے بعد اکاؤنٹ بند ہو جائے گا۔ اگر ہر سروس سے سب کچھ صاف کرے تو گنتی پالیسی کے دعوے سے کمزور ہے۔

آخر میں، فتح کا اعلان کرنے سے پہلے بغیر نگرانی والے کلائنٹ روکیں۔ محفوظ اسناد پس منظر میں دوبارہ کوشش کر کے بحالی کے چند منٹ بعد ناکامیاں دوبارہ پیدا کریں گی اور اکاؤنٹ پھر بند کر دیں گی۔ ماخذ کی بنیاد پر رفتار کی حد اضافی کنٹرول کے طور پر رہ سکتی ہے، مگر یہ اکاؤنٹ پالیسی نہیں ہے۔