وضعیت NEW در conntrack روی بسته ACK: چه چیزی را ثابت نمی‌کند

در گزارش فایروال یک خط هست که انتظارش را نداشتید: یک بسته ACK، وضعیت conntrack برابر NEW، نشانی مبدأ که مال شما نیست، درگاه مقصد باز. وسوسه این است که آن را اتصال ورودی تازه‌ای بخوانید که کسی مجوزش را نداده است. آنچه این خط واقعاً می‌گوید محدودتر است: وقتی آن بسته به این hook رسید، ردیاب هیچ وضعیت منطبقی نداشت، و بسته یک ACK حمل می‌کرد. این دو واقعیت درباره دو چیز متفاوت است و هیچ‌کدام صورت‌جلسه کامل یک دست‌دادن نیست. این ترتیبی است که پیش از رسیدن به نتیجه طی می‌کنم.

از بسته شروع کنید، نه از حکم

پیش از تفسیر، مشاهدات را از هم جدا کنید. پرچم‌های TCP این بسته را توصیف می‌کنند، وضعیت ردیاب توصیف می‌کند که در آن hook چه می‌دانست، و ضبط شما تنها پنجره‌ای را توصیف می‌کند که ثبت کرده‌اید.

قاطی کردن این سه، همان راهی است که یک ACK تبدیل به «ارائه‌دهنده کسی را داخل آورده» می‌شود.

NEW در hook واقعاً چه معنایی دارد

تطبیق conntrack در iptables NEW را بسته‌ای مستند می‌کند که اتصالی را آغاز می‌کند، یا بسته‌ای وابسته به اتصالی که هنوز ترافیک را در هر دو جهت ندیده است. ESTABLISHED یعنی ردیاب بسته‌ها را در هر دو جهت دیده است. هیچ‌یک از این دو تعریف نمی‌گوید بسته SYN بوده، و نمی‌گوید بدون پیشینه رسیده است.

ردیابی که جریانی را از میانه مشاهده می‌کند، بسته بعدی را بر پایه آنچه می‌داند دسته‌بندی می‌کند، و آن می‌تواند هیچ باشد. این سخنی درباره حافظه ردیاب است، نه درباره قصد میزبان دور.

ردیابی سهل‌گیرانه بیشتر غافلگیری‌های ACK را توضیح می‌دهد

هسته مستند می‌کند nf_conntrack_tcp_loose، که به ردیاب اجازه می‌دهد اتصال‌های TCP را که آغازشان را ندیده بردارد. با مقدار پیش‌فرض این تنظیم، یک ACK از میانه جریان می‌تواند به‌عنوان جریان برقرارشده پذیرفته شود. آن را خاموش کنید و همان بسته به‌احتمال بیشتر INVALID دسته‌بندی می‌شود نه NEW. هر دو نتیجه قواعد ردیاب را توصیف می‌کنند، نه تاریخچه برنامه را.

پس پیش از ساختن نظریه روی برچسب، آن تنظیم را بررسی کنید.

علت‌های کسل‌کننده را به این ترتیب کنار بگذارید

بیشتر رخدادهای NEW روی ACK که دنبال کرده‌ام به یکی از این‌ها رسیده‌اند و بررسی همه‌شان ارزان است:

• جدول conntrack پاک شده است، یا ردیاب دوباره راه‌اندازی شده است.
• میزبان دوباره راه‌اندازی شده، یا جریان به namespace یا دستگاه دیگری رفته است.
• مسیریابی نامتقارن SYN را از مسیری بیرون فرستاده که شما ضبط نمی‌کنید.
• NAT رشته tuple را بازنویسی کرده، بنابراین ورودی دیگر با آنچه خوانده‌اید نمی‌خواند.
• ضبط دیر شروع شده و آغاز را هرگز ندیده است.

هر یک از این‌ها بسته‌های پیشین را از دید ردیاب بیرون می‌برد و بسته‌های بعدی را دست‌نخورده می‌گذارد. راه‌اندازی دوباره یا پاک کردن جدول را از uptime و گزارش‌ها آسان‌تر می‌توان تأیید کرد. مسیریابی نامتقارن به شکل ضبط یک‌طرفه دیده می‌شود. NAT همان حیله‌گر است، چون tuple‌ای که ردیاب ذخیره کرده همان tuple چاپ‌شده در گزارش نیست.

پیش از ادامه بنویسید کدام‌یک را کنار گذاشته‌اید و چگونه.

tuple، رابط و hook را بخوانید

ورودی conntrack با نشانی‌ها، درگاه‌ها و پروتکل کلید می‌خورد، پس هر ترجمه‌ای تغییر می‌دهد که کدام ورودی منطبق شود. رابط و hook را هم ثبت کنید، چون بسته‌ای که روی رابط اشتباه یا پس از زنجیره‌ای دیگر دیده شود می‌گوید مسیر آن چیزی نیست که نمودار می‌گوید. وقتی رخداد به VPN مربوط است، تصمیم بگیرید به بسته درونی نگاه می‌کنید یا به حامل بیرونی. سپس با آنچه دروازه برای همان tuple پنج‌جزئی ثبت کرده مقایسه کنید.

دو دیدگاه از یک جریان که با هم نمی‌خوانند، از هر یک به‌تنهایی آموزنده‌ترند.

چه زمانی ارزش بالا بردن دارد

زمانی بالا ببرید که می‌توانید سرویسی را نشان دهید که در دسترس است و نباید باشد، همراه با جریان، سیاستی که آن را مجاز کرده و شواهدی از هر دو سر. نقص ارائه‌دهنده را بر پایه یک برچسب وضعیت یا یک ضبط ناقص گزارش نکنید، چون آن گزارش با همان توضیحی بسته می‌شود که همین حالا خواندید. اگر سرویس واقعاً در معرض است، صاحب آن مرز کسی است که باید درستش کند، و نگاشت درگاه واگذارشده یا شنونده ناخواسته علت محتمل‌تری از یک باگ است.

سپس شکاف دیدی را ببندید که گذاشت یک بسته مثل یک نشست کامل به نظر برسد.