اندرونی ALB، عوامی DNS نام: کیا یہ واقعی بے پردہ ہے؟

کسی اندرونی لوڈ بیلنسر کے خلاف عوامی DNS تلاش چلائیں اور آپ کو نجی پتہ واپس مل سکتا ہے، جو ریکارڈ کس لیے ہے یہ جانچنے تک غلط ترتیب جیسا لگتا ہے۔ AWS درج کرتا ہے کہ اندرونی لوڈ بیلنسروں کے نام عوامی طور پر حل ہو سکتے ہیں جبکہ ان کے نوڈ صرف نجی پتے رکھتے ہیں۔ resolver نے جواب دیا کہ سروس کہاں ہے؛ اس نے کوئی راستہ نہیں بنایا، سیکیورٹی گروپ نہیں کھولا اور کسی کی تصدیق نہیں کی۔ وہ جواب مسئلہ ہے یا نہیں، اس کا ان حقائق پر دارومدار ہے جنہیں آپ ترتیب سے جانچ سکتے ہیں۔

پہلا قدم: اسکیم پڑھیں، IP نہیں

اسکیم فیلڈ لوڈ بیلنسر کا اپنی حد کے بارے میں اپنا بیان ہے۔ aws elbv2 describe-load-balancers --names app-internal internal یا internet-facing قدر والا Scheme واپس کرتا ہے، ساتھ ہی IPv4 یا دوہرے اسٹیک کے لیے پتے کی قسم۔ انٹرنیٹ کی طرف رخ کرنے والا لوڈ بیلنسر پھر بھی نجی اہداف کی طرف بھیج سکتا ہے، اس لیے نجی back-end پتے دیکھنا سامنے کے حصے کے بارے میں کچھ ثابت نہیں کرتا۔

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

دوسرا قدم: دیکھیں نام کس میں حل ہوتا ہے

VPC سے باہر dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com سے پوچھیں اور نوٹ کریں کہ جوابات 10.0.0.0/8، 172.16.0.0/12 یا 192.168.0.0/16 میں ہیں۔ عوامی resolver سے نجی جواب اندرونی لوڈ بیلنسر نام کے لیے متوقع رویہ ہے؛ یہ ثبوت نہیں کہ پتہ انٹرنیٹ سے روٹ ہو سکتا ہے۔

وہی نام VPC کے اندر سے حل کریں اور موازنہ کریں۔ اگر دونوں جواب مختلف ہوں تو آپ split-horizon نام رکھنا دیکھ رہے ہیں، اور وہ فرق ڈیزائن کی تفصیل ہے، رساؤ نہیں۔

تیسرا قدم: وہ راستے فہرست کریں جو وہاں پہنچ سکتے ہیں

نجی پتہ ہر اس جگہ سے پہنچ سکتا ہے جہاں راستہ اور سیکیورٹی قاعدہ ہو۔ انہیں جان بوجھ کر فہرست کریں: سائٹ سے سائٹ VPN، کلائنٹ VPN، VPC peering، transit gateway کنکشنز، Direct Connect اور VPC کے اندر کوئی بھی proxy یا bastion۔ ان میں سے ایک مطلوبہ راستہ ہے، اور باقی وہ ہیں جنہیں حملہ آور ڈھونڈے گا۔

پھر ہر راستے کے کنٹرول چیک کریں: لوڈ بیلنسر پر سیکیورٹی گروپس، سب نیٹ پر نیٹ ورک ACL اور وہ روٹنگ جو راستہ بناتی ہے۔ بے پردہ اندرونی سروس کے زیادہ تر رپورٹ شدہ واقعات یہیں حل ہوتے ہیں، یا غیر ارادی peering تھا یا راستہ ارادی تھا اور ایپلیکیشن میں تصدیق نہیں تھی۔

چوتھا قدم: listener اور ایپلیکیشن الگ الگ جانچیں

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

قابل رسائی listener قابل رسائی ایپلیکیشن کے برابر نہیں۔ TLS سرٹیفکیٹ اور پروٹوکول پالیسی، پھر ایپلیکیشن کی اپنی تصدیق اور اجازت چیک کریں۔ کارپوریٹ VPN پر کسی بھی کالر کو قبول کرنے والا اندرونی ٹول اس VPN کے ہر متاثرہ لیپ ٹاپ کے سامنے بے پردہ ہے، جو انٹرنیٹ کی طرف والے خطرے سے مختلف ہے، مگر پھر بھی خطرہ ہے۔

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

پانچواں قدم: فیصلہ کریں کہ کیا نام کا اپنا کوئی وزن ہے

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

اگر تنظیم نجی نام رکھنے کا تجربہ چاہے، نجی hosted zone ایک alias دے سکتا ہے جو صرف منسلک VPC کے اندر حل ہوتا ہے۔ یہ وہ نام بدلتا ہے جو صارف دیکھتے ہیں؛ یہ فراہم کنندہ کے بنائے نام کو خفیہ نہیں کرتا اور کوئی نیٹ ورک راستہ نہیں ہٹاتا۔

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