sudo کے ساتھ چلانے پر پورٹ اسکین کیوں بدلتا ہے

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

دو پروب، ایک پورٹ، مختلف کوڈ راستے

SYN اسکین خود TCP ہیڈر بناتا ہے، اسے خام ساکٹ سے بھیجتا ہے اور کرنل کا TCP اسٹیک کوئی مکمل کنکشن ریکارڈ کرنے سے پہلے نیٹ ورک سے جواب پڑھتا ہے۔ connect اسکین آپریٹنگ سسٹم سے عام ساکٹ کھولنے کو کہتا ہے اور بتاتا ہے کہ connect() کیا واپس کرتا ہے۔ دونوں کسی پورٹ کو کھلا کہہ سکتے ہیں، لیکن نیم کھلی کوشش صرف ایک چھوڑتا ہے اور بھیجنے والے عمل سے جڑی ساکٹ سطح کی پالیسی کے تابع صرف ایک ہوتا ہے۔

خام راستے کو CAP_NET_RAW درکار ہے، اسی لیے وہ صلاحیت نہ ہونے پر طے شدہ اسکین خاموشی سے کمزور پڑ جاتا ہے۔ Nmap کا اپنا اسکین تکنیکوں کا حوالہ اس تبدیلی کو دستاویز کرتا ہے: connect اسکین متبادل ہے کیونکہ اسے کسی خاص اجازت کی ضرورت ہی نہیں۔ یہ تبدیلی زیادہ تر رنز میں بغیر انتباہ کے ہوتی ہے، اور یہی اسے غلط پڑھنا اتنا آسان بناتا ہے۔ ایک بار معلوم ہو جائے کہ متبادل موجود ہے تو ”root کے طور پر کھلا، صارف کے طور پر بند“ اجازت کی خرابی جیسا سننا بند کر دیتا ہے اور دو مختلف پیمائشوں جیسا سننے لگتا ہے۔

اسکین میں sudo دراصل کیا بدلتا ہے

اجازتیں بڑھانے سے خام ساکٹ کا راستہ واپس آتا ہے، اور یہ فیصلے سے زیادہ بدلتا ہے۔ ماخذ پورٹ کا انتخاب، پیکٹ کا وقت، دوبارہ بھیجنے کا رویہ اور فلٹر شدہ جواب کی درجہ بندی کا طریقہ سب مختلف کوڈ سے آتے ہیں۔ SYN کی رفتار محدود کرنے والا درمیانی آلہ منزل کے میزبان کے یکساں ہونے پر بھی دونوں رنز کے ساتھ غیر مساوی سلوک کرتا ہے۔

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

دونوں رنز میں طریقہ مستقل رکھیں

دونوں کالوں میں وہی تکنیک زبردستی استعمال کریں اور موازنہ کچھ معنی رکھنے لگے گا۔ -sT پرچم connect اسکین کی واضح طور پر درخواست کرتا ہے، -Pn میزبان کی دریافت ہٹاتا ہے، -n نام کا حل ہٹاتا ہے، اور ایک -p پورٹ فہرست کے فرق ہٹاتا ہے۔

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

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

اکاؤنٹ کا سیاق صرف اجازت کا پرچم نہیں

VPN تعیناتی پیکٹوں کو UID کے لحاظ سے، cgroup کے لحاظ سے، یا ساکٹ کھولنے والے عمل سے جڑے اصول کے لحاظ سے درجہ بند کر سکتی ہے۔ پھر root ٹریفک اور صارف ٹریفک مختلف روٹنگ جدولوں سے نکلتے ہیں یا مختلف اصولوں کے مجموعوں سے ٹکراتے ہیں، اور اسکین طریقے کا کوئی نظم انہیں نہیں ملا سکتا۔

اجازت نہیں، پالیسی دیکھیں۔ Linux میں nftables اسے meta skuid سے ظاہر کرتا ہے اور iptables مالک کی مطابقت سے، اور ان میں سے کوئی بھی ایک UID کو سرنگ میں بھیج سکتا ہے جبکہ دوسرا طبعی طے شدہ راستہ استعمال کرتا رہتا ہے۔

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

نتائج اخذ کرنے سے پہلے پروب کی تصدیق کریں

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

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

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