ACK پیکٹ پر conntrack NEW: یہ کیا ثابت نہیں کرتا

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

فیصلے سے نہیں، پیکٹ سے شروع کریں

تشریح سے پہلے مشاہدات کو الگ کریں۔ TCP پرچم اس پیکٹ کی وضاحت کرتے ہیں، ٹریکر کی حالت بتاتی ہے کہ اس hook پر اسے کیا معلوم تھا، اور آپ کی کیپچر صرف وہ ونڈو بیان کرتی ہے جو آپ نے ریکارڈ کی۔

ان تینوں کو ملانا ہی وہ طریقہ ہے جس سے ACK “پرووائیڈر نے کسی کو اندر آنے دیا” بن جاتا ہے۔

hook پر NEW کا اصل مطلب کیا ہے

iptables conntrack مماثلت NEW کو ایسے پیکٹ کے طور پر دستاویز کرتی ہے جو کنکشن شروع کرتا ہے، یا ایسے کنکشن سے منسلک پیکٹ جو ابھی دونوں سمتوں میں ٹریفک نہیں دیکھ سکا۔ ESTABLISHED کا مطلب ہے کہ ٹریکر نے دونوں سمتوں میں پیکٹ دیکھے ہیں۔ کوئی تعریف یہ نہیں کہتی کہ پیکٹ SYN تھا، اور نہ یہ کہ وہ تاریخ کے بغیر آیا۔

جو ٹریکر بہاؤ کو درمیان سے دیکھنا شروع کرتا ہے وہ اگلے پیکٹ کو اپنی معلوم کے مطابق درجہ بند کرتا ہے، اور وہ کچھ بھی نہ ہو۔ یہ ٹریکر کی یادداشت کے بارے میں بیان ہے، دور کے ہوسٹ کے ارادے کے بارے میں نہیں۔

ڈھیلا ٹریکنگ زیادہ تر ACK حیرتوں کی وضاحت کرتی ہے

کرنل دستاویز کرتا ہے nf_conntrack_tcp_loose، جو ٹریکر کو ایسے TCP کنکشن اٹھانے دیتا ہے جن کی شروعات اس نے نہیں دیکھی۔ ترتیب اپنی طے شدہ قدر پر ہو تو بہاؤ کے وسط سے آنے والا ACK قائم شدہ بہاؤ کے طور پر قبول کیا جا سکتا ہے۔ اسے بند کریں تو وہی پیکٹ NEW کے بجائے INVALID کے طور پر درجہ بند ہونے کا زیادہ امکان ہے۔ دونوں نتائج ٹریکر کے قواعد بیان کرتے ہیں، ایپلیکیشن کی تاریخ نہیں۔

اس لیے لیبل پر نظریہ بنانے سے پہلے وہ ترتیب جانچیں۔

بور کرنے والے اسباب کو اس ترتیب میں خارج کریں

میں نے جن NEW-on-ACK واقعات کا پیچھا کیا ان میں سے بیشتر انہی میں سے کسی ایک پر ختم ہوئے، اور سب کی جانچ سستی ہے:

• conntrack جدول فلش ہوا، یا ٹریکر دوبارہ شروع ہوا۔
• ہوسٹ ری بوٹ ہوا، یا بہاؤ کسی دوسرے namespace یا ڈیوائس پر منتقل ہو گیا۔
• غیر متوازی روٹنگ نے SYN کو ایسے راستے سے نکالا جو آپ کیپچر نہیں کر رہے۔
• NAT نے tuple دوبارہ لکھا، اس لیے اندراج اب آپ کے پڑھے ہوئے سے مطابقت نہیں رکھتا۔
• کیپچر دیر سے شروع ہوئی اور شروع کبھی نہ دیکھ سکی۔

ان میں سے ہر ایک پہلے کے پیکٹ ٹریکر کی نظر سے ہٹا دیتا ہے اور بعد والے محفوظ رہنے دیتا ہے۔ ری بوٹ یا جدول کا فلش uptime اور لاگز سے تصدیق کرنا سب سے آسان ہے۔ غیر متوازی روٹنگ یک طرفہ کیپچر کے طور پر ظاہر ہوتی ہے۔ NAT چالاک ہے، کیونکہ ٹریکر نے جو tuple محفوظ کیا وہ لاگ میں چھپا tuple نہیں ہے۔

آگے بڑھنے سے پہلے لکھیں کہ ان میں سے کون سے خارج کیے اور کیسے۔

tuple، انٹرفیس اور hook پڑھیں

conntrack اندراج پتوں، پورٹس اور پروٹوکول پر کلیدی ہوتا ہے، اس لیے کوئی بھی ترجمہ بدل دیتا ہے کہ کون سا اندراج مماثل ہے۔ انٹرفیس اور hook بھی درج کریں، کیونکہ غلط انٹرفیس پر یا کسی دوسری زنجیر کے بعد دیکھا گیا پیکٹ کہتا ہے کہ راستہ خاکے والا نہیں ہے۔ جب واقعہ VPN سے متعلق ہو، فیصلہ کریں کہ آپ اندرونی پیکٹ دیکھ رہے ہیں یا بیرونی حامل۔ پھر اسی پانچ حصوں والے tuple کے لیے گیٹ وے نے جو درج کیا اس سے موازنہ کریں۔

ایک ہی بہاؤ کے دو متضاد مناظر کسی ایک سے زیادہ معلومات دیتے ہیں۔

کب ایسکیلیٹ کرنا مناسب ہے

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

پھر وہ مرئیت کا خلا بند کریں جس نے ایک پیکٹ کو پورے سیشن جیسا دکھایا۔