VPN سرور پر آنے والا انتباہ: مشاہدے کا نقطہ پڑھیں

VPN کے پیچھے موجود سرور اپنے عوامی سروس اندراجات رکھتا ہے، اور لوگ انہیں ڈھونڈتے رہتے ہیں۔ انتباہ کی قطار میں آنے والی چیز ایک دریافت نہیں بلکہ تین ممکنہ دریافتیں ہیں، اور ان کے معنی مختلف ہیں۔ پہلا کام یہ ہے کہ بے نقاب سروس کو بے نقاب لاگ اِن تفصیلات سے الگ کیا جائے۔

مشاہدے کے نکات کو ترتیب سے دیکھیں۔ جب ثبوت اپنی قسم بدل دے تو رک جائیں، کیونکہ اگلا مرحلہ کسی اور سوال کا جواب دیتا ہے۔

پہلا مرحلہ: گرفت نے واقعی کیا دیکھا

پیکٹ کی گرفت راستے پر اپنے ہی نقطے پر نظر آنے والی چیز درج کرتی ہے۔ وہ نقطہ بعد کے فلٹر فیصلے سے پہلے ہو سکتا ہے۔ پکڑا گیا پیکٹ ثابت کرتا ہے کہ ٹریفک وہاں پہنچی۔ یہ اس بارے میں کچھ ثابت نہیں کرتا کہ بعد میں کیا ہوا۔

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

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

دوسرا مرحلہ: رد کا ریکارڈ کیا ثابت کرتا ہے

رد کا ریکارڈ بتاتا ہے کہ پالیسی کی حد نے وہ پیکٹ مسترد کیا۔ یہ مضبوط ثبوت ہے۔ یہ محدود بھی ہے، کیونکہ یہ ایک حد پر ایک فیصلے کو محیط ہے۔ اسٹیک میں کوئی اور چیز اس سے بیان نہیں ہوتی۔

ٹوپل اور وقت کی مہر پر ملائیں۔ وہی ماخذ، وہی منزل، وہی پورٹ، اسی سیکنڈ کے اندر۔ ایسی مطابقت کے بغیر دوسرے لاگ میں ملتا جلتا واقعہ محض ایک اور واقعہ ہے، اور انہیں جوڑنا ایسی کہانی بناتا ہے جس کا کوئی دفاع نہیں کر سکتا۔

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

بند پورٹ اور مسترد شدہ پیکٹ باہر سے ایک جیسے نظر آتے ہیں اور ان دو نتائج میں بالکل مختلف ہوتے ہیں۔ یہی فرق مقامی ریکارڈ پڑھنے کی پوری وجہ ہے۔

تیسرا مرحلہ: تصدیق کا واقعہ کیا ثابت کرتا ہے

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

واقعے کا اصل سیاق پڑھیں۔ ایسے اکاؤنٹ کے لیے ناکام لاگ اِن جو موجود ہی نہیں، اسکیننگ کا شور ہے۔ معتبر ماخذ والے حقیقی اکاؤنٹ کے لیے ناکام لاگ اِن الگ ترجیح ہے۔ کامیاب سیشن بالکل الگ واقعہ قسم ہے۔

پروٹوکول کے نام بھی دیکھیں۔ RPC اور RDP الگ پورٹس والی الگ سروسز ہیں۔ ان میں سے صرف ایک پر نظر رکھنے والا ڈیٹیکٹر دوسرے کو محیط نہیں کرتا۔ نیٹ ورک سرگرمی کا خلاصہ دینے والے اوزار ہمیشہ نہیں بتاتے کہ واقعہ ان دونوں میں سے کس نے پیدا کیا۔

ایک ملایا گیا نمونہ ڈیش بورڈ سے بہتر ہے

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

پھر دو ذمہ داریاں الگ کریں۔ اگر انتظامیہ صرف VPN کے ذریعے ہونی چاہیے تو اسے عوامی راستے اور سرنگ کے راستے دونوں پر نافذ کریں اور منظور شدہ بحالی راستہ برقرار رکھیں۔ مسترد شدہ کوشش کی نگرانی کرنا سرور کو کیا قبول کرنا چاہیے، یہ طے کرنے کے کام کے برابر نہیں ہے۔

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