طراحی Security Zone و Policy در Juniper SRX؛ از trust و untrust تا Rule قابل دفاع

در Juniper SRX نقطه شروع طراحی فایروال، نوشتن چند policy نیست؛ اول باید Zoneها درست تعریف شوند. اگر trust، untrust، dmz، server-farm، management و vpn فقط از روی عجله ساخته شوند، بعد از چند ماه تشخیص اینکه هر Rule دقیقاً برای کدام جریان ترافیک است سخت می‌شود. نتیجه هم معمولاً Ruleهای باز، objectهای تکراری و تصمیم‌هایی است که هیچ‌کس با اطمینان حذفشان نمی‌کند.

این مطلب برای زمانی است که SRX در نقش فایروال سازمانی استفاده می‌شود و هدف فقط بالا آوردن ترافیک نیست. هدف این است که Zone و Policy طوری طراحی شوند که هم قابل عیب‌یابی باشند، هم در بازبینی امنیتی بتوان از آنها دفاع کرد. اگر هنوز تصویر کلی SRX و مسیرهای عملیاتی برایتان روشن نیست، صفحه آموزش و راهنمای Juniper نقطه شروع بهتری است.

Zone را بر اساس اعتماد واقعی طراحی کنید، نه صرفاً نام اینترفیس

در SRX هر اینترفیس لایه سه در یک Security Zone قرار می‌گیرد، اما Zone فقط یک برچسب فنی نیست. Zone باید مرز اعتماد را نشان بدهد. برای نمونه، شبکه کاربران داخلی و شبکه سرورها هر دو داخلی هستند، ولی سطح اعتماد و نوع دسترسی‌شان یکی نیست. اگر هر دو را داخل یک Zone بگذارید، خیلی از کنترل‌ها را از دست می‌دهید و بعداً مجبور می‌شوید با Ruleهای پیچیده جبران کنید.

• برای کاربران، سرورها، DMZ، اینترنت، مدیریت و VPN Site-to-Site مرز جدا در نظر بگیرید.
• Zone مدیریت را با شبکه کاربران یکی نکنید، حتی اگر فعلاً همه چیز از یک سوئیچ عبور می‌کند.
• برای DMZ فقط به نام Zone اکتفا نکنید؛ مسیر برگشت، NAT و لاگ را هم از ابتدا ببینید.
• اگر شعبه‌ها از طریق VPN وصل می‌شوند، دسترسی آنها را مثل شبکه داخلی کامل فرض نکنید.

Address Book را تمیز نگه دارید

یکی از علت‌های شلوغ شدن Policy در SRX، ساختن address objectهای فوری و بی‌نام است. نام‌هایی مثل host1، server-new یا test بعد از مدتی هیچ معنایی ندارند. بهتر است نام objectها نشان بدهد دارایی چیست، در کدام Zone قرار دارد و برای چه سرویس یا سامانه‌ای استفاده می‌شود.

set security zones security-zone server-farm address-book address srv-app01 10.10.20.11/32
set security zones security-zone server-farm address-book address srv-db01 10.10.30.21/32
set security zones security-zone users address-book address net-office-users 10.10.10.0/24

اگر objectها در سطح global address book تعریف می‌شوند، باید naming دقیق‌تر باشد تا معلوم شود هر object به کدام بخش تعلق دارد. در محیط‌های چندتیمی، global object بدون قاعده خیلی سریع به منبع خطا تبدیل می‌شود.

Policy را از نیاز واقعی ترافیک شروع کنید

در طراحی درست، Policy از این سؤال شروع می‌شود: کدام مبدأ، به کدام مقصد، با کدام سرویس، برای چه کاری باید دسترسی داشته باشد؟ اگر جواب این سؤال روشن نیست، ساخت Rule جدید فقط بدهی امنیتی ایجاد می‌کند.

set security policies from-zone users to-zone server-farm policy allow-users-to-app match source-address net-office-users
set security policies from-zone users to-zone server-farm policy allow-users-to-app match destination-address srv-app01
set security policies from-zone users to-zone server-farm policy allow-users-to-app match application junos-https
set security policies from-zone users to-zone server-farm policy allow-users-to-app then permit
set security policies from-zone users to-zone server-farm policy allow-users-to-app then log session-init
set security policies from-zone users to-zone server-farm policy allow-users-to-app then log session-close

برای ترافیک حساس، لاگ فقط هنگام بروز حادثه لازم نیست. اگر لاگ از ابتدا طراحی نشود، بعداً در زمان عیب‌یابی یا incident response چیزی برای تحلیل ندارید.

Ruleهای any any را موقت و قابل حذف نگه دارید

گاهی در زمان migration یا عیب‌یابی، یک Rule باز موقت ساخته می‌شود. مشکل وقتی شروع می‌شود که همان Rule موقت در production می‌ماند و تبدیل به مسیر دائمی ترافیک می‌شود. اگر واقعاً مجبور به ساخت Rule باز هستید، اسم، توضیح، زمان بازبینی و لاگ آن باید روشن باشد.

• در نام Rule کلمه temporary را بدون تاریخ و دلیل رها نکنید.
• برای Rule موقت حتماً لاگ session-close بگذارید تا بعداً مقصد و application واقعی را استخراج کنید.
• بعد از پایدار شدن سرویس، Rule باز را به چند Rule محدود و قابل دفاع تبدیل کنید.
• Ruleهای قدیمی را قبل از حذف با hit count، لاگ و owner سرویس بررسی کنید.

ترتیب Policyها را جدی بگیرید

SRX Policyها را از بالا به پایین بررسی می‌کند. یک Rule کلی در بالای لیست می‌تواند چند Rule دقیق‌تر را بی‌اثر کند. برای همین در بازبینی، فقط وجود داشتن Rule کافی نیست؛ جایگاه آن هم مهم است. Ruleهای خاص باید قبل از Ruleهای عمومی‌تر قرار بگیرند و Ruleهای موقت نباید وسط policy set گم شوند.

Policy خوب بدون لاگ قابل پشتیبانی نیست

در شبکه‌های سازمانی، لاگ بیش از حد هم مشکل است و لاگ ناکافی هم. برای Ruleهای پرحجم، باید مراقب فشار روی دستگاه و سامانه مانیتورینگ باشید. برای Ruleهای حساس مثل دسترسی مدیریت، VPN، ارتباط به سرورهای مالی یا مسیرهای DMZ، نبود لاگ ریسک عملیاتی ایجاد می‌کند.

اگر هدف شما طراحی و بازبینی کلی فایروال سازمانی است، صفحه پیاده‌سازی فایروال سازمانی مسیر کامل‌تری از Rule Review، سخت‌سازی و کنترل دسترسی را توضیح می‌دهد.

جمع‌بندی

طراحی Policy در Juniper SRX از Zone شروع می‌شود، نه از یک Rule فوری. هرچه مرزهای اعتماد، Address Book، Application و لاگ از ابتدا دقیق‌تر باشند، نگهداری فایروال در production ساده‌تر و کم‌ریسک‌تر می‌شود. یک SRX خوب فقط ترافیک را عبور نمی‌دهد؛ نشان می‌دهد چرا این ترافیک مجاز است و چطور می‌توان بعداً آن را بررسی کرد.