قوانین فایروال که فقط NEW را می‌پذیرند همه مسیرهای WAN را نمی‌بندند

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

وضعیت یک شرط تطبیق است، نه حکم

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

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

قانون را در محیط اطرافش بخوانید

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

مجموعه قوانین مؤثر را بررسی کنید نه فایلی را که ویرایش کردید، از جمله پرش‌ها به زنجیره‌های دیگر و هر چیزی که پلتفرم تولید می‌کند. روی مسیریابی که با iptables مدیریت می‌شود، فهرست کردن زنجیره تعریف قوانین را نشان می‌دهد، و زنجیره‌هایی که به آن‌ها ارجاع می‌دهد هم باید دنبال شوند. یک سیستم بومی nftables نیاز به بررسی مجموعه قوانین و اولویت‌های قلاب خود دارد، چون فرم‌ور به‌ندرت زنجیره‌های یکسان تولید می‌کند.

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

ممنوعیت را مستقل از وضعیت بیان کنید

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

انتخاب reject به‌جای drop تغییر می‌دهد که ترافیک مطابق چگونه شکست بخورد، و مجموعه بسته‌هایی را که قانون انتخاب می‌کند بزرگ‌تر نمی‌کند. اتصالی که رد می‌شود و یک پایان مهلت خاموش نشانه‌های متفاوتی هستند که به یک انتخاب اشاره می‌کنند.

سیاستی که آگاهانه به پاسخ‌های دسترسی آغازشده از راه دور روی WAN اجازه می‌دهد قابل دفاع است. فقط باید همان‌طور توصیف شود نه اینکه به‌عنوان جداسازی کامل و تنها از طریق تونل ارائه شود.

بررسی کنید واقعاً چه کسی داخل گروه است

مثال ترافیک IPv4 ارسال‌شده از یک پیشوند از یک رابط را پوشش می‌دهد. درباره IPv6، یک پیوند بالادستی دوم، یا ترافیکی که خود مسیریاب تولید می‌کند چیزی نمی‌گوید. مسیریابی که به‌عنوان حل‌کننده DNS عمل می‌کند پرس‌وجوهای بالادستی خودش را می‌فرستد، و آن‌ها اصلاً از زنجیره forward عبور نمی‌کنند.

تأیید کنید که کلاینت‌های محافظت‌شده هنوز نشانی‌هایی درون پیشوند انتخاب‌شده دارند، چون دستگاهی که بیرونش رفته به‌طور تصادفی مستقیم است نه بر اساس سیاست. گستردن بلوک به کل LAN بدون بازبینی طرح استثناها هم معمولاً مسیر مدیریتی خودتان را از میان برمی‌دارد.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

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