طراحی فایروال عملی: از تئوری تا اجرا

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

با مناطق شروع کنید، نه قوانین

پیش از نوشتن یک ACL، مناطق اعتماد خود را تعریف کنید. یک طرح‌بندی سازمانی معمولی میزبان‌های رویی DMZ، شبکه‌های کاربری داخلی، سطح‌های سرور/داده، و شبکه‌های مدیریت/OOB را جدا می‌کند. هر منطقه باید یک سطح اعتماد متمایز را نشان دهد، و ترافیک بین مناطق باید استثنایی باشد که توجیه می‌طلبد، نه پیشفرض.

نقشه‌برداری کنید که چه چیزی به طور قانونی باید با چه چیزی صحبت کند. این فهرست جریان ترافیک خسته‌کننده است اما بنیادی است که همه چیز دیگر بر آن استوار است. رد کردن آن منجر به قوانین بیش‌ازحد مجاز "allow any-any between subnets" می‌شود که کل منظور تقسیم‌بندی را شکست می‌دهد.

Default-Deny غیرقابل‌مذاکره است

هر رابط، هر جفت منطقه، باید به یک deny ضمنی یا صریح ختم شود. قوانین باید استثناهای افزودنی برای یک حالت بسته باشند، نه استثناهای تفریقی برای یک حالت باز. این واضح به نظر می‌رسد، اما ممیزی‌ها به طور منظم فایروال‌هایی با قوانین catch-all مجاز پیدا می‌کنند که از استقرار عجولانه یا تغییر "موقتی" troubleshooting باقی‌ماند که هرگز حذف نشد.

وقتی default-deny چیزی را می‌شکند، این در واقع سیگنال ارزشمندی است—این بدان معناست که شما یک وابستگی مستند‌نشده پیدا کرده‌اید که باید به‌صورت صریح مدل‌شود، نه خاموشانه اجازه‌داده‌شود.

ترتیب و تخصص قوانین

اکثر موتورهای فایروال قوانین را از بالا به پایین ارزیابی می‌کنند و در اولین تطابق متوقف می‌شوند. این ترتیب‌بندی را یک تصمیم طراحی نه یک فکر ثانوی می‌کند. قوانین خاص (میزبان واحد، پورت واحد) عموماً باید قوانین گسترده (دامنه‌های زیرشبکه، دامنه‌های پورت) را پیش‌بینی کنند. یک حالت شکست معمول، قرار دادن یک قانون allow گسترده در ابتدای لیست است، که به‌خاموشی قوانین محدودتر زیرش را سایه می‌کند—آن قوانین روی کاغذ وجود دارند اما هرگز واقعاً فعال نمی‌شوند.

به‌طور دوره‌ای برای قوانین سایه‌شده و اضافی ممیزی کنید. ابزارهایی که تعداد hit قوانین را تصور می‌کنند در اینجا بی‌ارزش هستند: یک قانون با صفر hit در یک پنجره معنی‌دار یا وزن مردار است یا بدتر، شواهدی که ترافیک از طریق مسیری جریان می‌یابد که شما انتظار آن را نداشتید.

بررسی وضعیت و محدودیت‌های آن

فایروال‌های مدرن وضعیت اتصال را دنبال می‌کنند، که به شما اجازه می‌دهد تنها برای جهت آغازکننده قوانین بنویسید و موتور را برای اجازه ترافیک بازگشتی قابل‌اعتماد کنید. این یک ساده‌سازی عمده نسبت به فیلتر کردن بسته بندی stateless است، اما جایگزین برای آگاهی لایه کاربردی نیست. یک فایروال stateful که TCP/443 outbound اجازه می‌دهد نمی‌داند یا برای آن اهمیت ندارد که آیا آن ترافیک HTTPS قانونی است یا یک کانال C2 که روی همان پورت تونل شده است. در جایی که ممکن است، اجرای فایروال را با دیدرسی لایه کاربردی جفت کنید—پروکسی‌ها، بررسی TLS جایی که سیاست اجازه می‌دهد، یا شناسایی کاربردی NGFW—تا اینکه بر شماره‌های پورت به عنوان پروکسی برای نیت متکی باشید.

فیلتر Egress توجه برابری را مستحق است

سازمان‌ها بر روی قوانین inbound وسوسه می‌شوند و outbound را غافل می‌گذارند. این از دیدگاه پاسخ به حادثه معکوس است: پس از اینکه مهاجم پای‌رزی پیدا کرد، کنترل‌های egress تعیین می‌کنند که آیا آنها می‌توانند داده را تخلیه کنند یا به زیرساخت خود تماس بگیرند. سیاست‌های egress صریح برای هر منطقه تعریف کنید—سرورها به ندرت نیاز به دسترسی outbound internet غیرمحدود دارند، و ایستگاه‌های کاری به ندرت نیاز به شروع اتصالات به IP‌های خارجی دلخواه در پورت‌های دلخواه دارند. فیلتر کردن restrictive egress همه چیز را متوقف نخواهد کرد، اما بهای فعالیت post-exploitation را افزایش می‌دهد و احتمال پرچم‌شدن ترافیک ناهنجار را افزایش می‌دهد.

مدیریت تغییر و drift

مجموعه‌های قانون فایروال در طول زمان cruft تجمع می‌کنند: قوانینی که برای پروژه‌ای اضافه شد که سال‌ها پیش تمام شد، استثناهایی موقتی که دائمی شدند، و قوانینی که کسی منظور آن را یاد نمی‌آورد. پیکربندی فایروال را مانند کد رفتار کنید—نسخه‌کنترل‌شده، بررسی‌شده‌ای توسط همتا، و مرتبط با توجیه تجاری مستند‌شده برای هر قانون. بررسی‌های دوره‌ای برنامه‌ریزی کنید تا ورودی‌های کهنه را هرس کنید. یک فایروال با هزار قانون مستند‌نشده امنیت واقعی کمتری فراهم می‌کند نسبت به مجموعه قوانین کوچکتر و خوب‌فهم‌شده، زیرا کسی نمی‌تواند درباره آن چه اجازه می‌دهد استدلال کند.

ثبت و همبستگی

فایروالی که ترافیک را به‌خاموشی مسدود کند تنها نیمی مفید است. اطمینان حاصل کنید که ترافیک مسدود و مجاز‌شده مورد علاقه ثبت‌شود و به SIEM یا خط لوله log شما ارسال شود، با زمینه کافی (منطقه، شناسه قانون، منبع/مقصد، پروتکل) برای پشتیبانی تحقیق بعداً. در طول حادثه، log‌های فایروال اغلب سریع‌ترین راه برای ایجاد timeline از حرکت جانبی یا تلاش‌های تخلیه هستند—اما تنها در صورتی که نگهداری و دقت در پیش‌زمینه پیکربندی‌شده باشند.

افکار پایانی

طراحی فایروال عملی درباره انتخاب فروشنده مناسب یا مجموعه ویژگی NGFW جدید نیست—درباره مدل‌سازی منطقه منضبط، اجرای default-deny، بهداشت قانون دقیق، و رفتار‌کردن با egress با سنجیدگی یکسان inbound است. اگر بنیادی‌ها درست انجام دهید، ویژگی‌های پیشرفته به جای جایگزین برای معماری، تقویت‌کننده نیروی می‌شوند.

برای اطلاعات بیشتر درباره تقسیم‌بندی شبکه، همبستگی log، و بنیادی‌های تیم آبی، بخش‌های مرتبط در کتابخانه DEFENSE_GRID کتابخانه Korra Studio را کاوش کنید.