ساخت Ruleهای فایروال در میکروتیک، دقیقا از سه زنجیره اصلی input / forward / output شروع می‌شود و با تعریف چند Rule کلیدی مثل accept established/related، drop invalid و یک drop all در انتهای chain، عملا یک فایروال Stateful امن و استاندارد روی RouterOS می‌سازید. اگر همین منطق را مرحله‌به‌مرحله روی روتر خود پیاده کنید، بدون حفظ‌کردن ده‌ها Command، می‌توانید سناریوهای واقعی سازمانی را به‌راحتی پوشش دهید.
براى دريافت مشاوره تخصصى رایگان، میتوانيد عبارت "فایروال میکروتیک"همراه نام " وينو سرور" در گوگل جستجو كنيد.
درک منطق فایروال میکروتیک قبل از نوشتن Rule
برای این‌که Ruleهای فایروال میکروتیک را درست طراحی کنید، باید قبل از هر چیز مفاهیم stateful firewall، connection tracking و سه chain اصلی filter یعنی input، forward و output را بفهمید، چون هر Rule دقیقا روی مسیر عبور بسته در یکی از این chainها اثر می‌گذارد. در RouterOS، فایروال به صورت stateful کار می‌کند؛ یعنی با استفاده از Connection Tracking تمام ارتباط‌ها را با stateهایی مثل new، established، related و invalid دنبال می‌کند و شما در Ruleها به‌جای بازی با تک‌تک پورت‌ها، روی وضعیت ارتباط کار می‌کنید که هم امن‌تر است و هم ساده‌تر.
Chain input مخصوص ترافیکی است که مقصدش خود روتر است (مثل Winbox، SSH، پینگ به IP روتر)، chain forward برای ترافیکی است که از یک اینترفیس وارد و از اینترفیس دیگر خارج می‌شود (مثل عبور ترافیک کاربران LAN به اینترنت) و chain output برای ترافیکی است که خود روتر به بیرون می‌فرستد. در سناریوهای سازمانی، تقریبا همیشه تمرکز اصلی شما روی input و forward است؛ چون امنیت مدیریت روتر و عبور ترافیک بین VLANها و اینترنت در این دو chain کنترل می‌شود و output فقط در موارد خاص (مثل محدود کردن DNS خروجی روتر) Rule اختصاصی نیاز دارد.
ساخت ستون فقرات فایروال: Ruleهای پایه و ضروری
برای ساخت Ruleهای فایروال در میکروتیک، ستون فقرات کار این است که در ابتدای chainها traffic معتبر را سریع accept کنید و در انتها یک Rule drop all قرار دهید تا هیچ ترافیک پیش‌بینی‌نشده‌ای عبور نکند. الگوی استاندارد در chain input این است که ابتدا یک Rule با connection-state=established,related برای accept ارتباط‌های جاری بگذارید، سپس invalidها را drop کنید، ICMP را در حد تست سلامت مجاز کنید و در نهایت «هرچه از LAN نیست» را drop نمایید؛ دقیقا همان چیزی که در اسکریپت‌های پیش‌فرض میکروتیک می‌بینیم. در chain forward نیز معمولا از fasttrack برای established/related (برای کارایی) استفاده می‌شود، بعد Rule accept برای همان established/related و در انتها drop invalid و drop all from WAN not dstnat اضافه می‌شود تا ترافیک جدیدی که مقصدش داخلی نیست، از اینترنت وارد شبکه نشود.
به‌صورت خلاصه، مغز کار چند Rule است: ۱) accept established/related روی input و forward، ۲) drop invalid، ۳) محدود کردن دسترسی به خود روتر فقط از LAN، ۴) یک drop all انتهایی برای forward تا ترافیک بین VLANها و از سمت WAN بدون Rule صریح عبور نکند. در پروژه‌های واقعی اگر همین اسکلت را تمیز پیاده کنید و تمام استثناها را بالاتر از Ruleهای drop تعریف کنید، بعدا در عیب‌یابی با Counters هر Rule به‌راحتی می‌فهمید چه چیزی اجازه عبور دارد و چه چیزی توسط کدام Rule قطع می‌شود؛ این همان دید معماری است، نه صرفا لیست کردن Commandها.
امن‌کردن دسترسی به خود روتر (chain=input)
وقتی قصد ساخت Ruleهای فایروال در chain input را دارید، هدف اصلی این است که فقط IPهای مدیریت‌شده بتوانند به سرویس‌هایی مثل Winbox، SSH و API روی روتر دسترسی داشته باشند و بقیه درخواست‌ها، حتی اگر از اینترنت یا VLANهای مهم بیایند، drop شوند. در یک پروژه واقعی که با تیم وینو سرور برای یک سازمان دولتی با چندین سایت استانی انجام دادیم، دقیقا از همین الگو استفاده شد: ابتدا Rule accept برای connection-state=established,related، بعد drop invalid، سپس تعریف یک address-list برای IPهای مدیریتی مرکز داده و در نهایت Rule drop input برای تمام ترافیک‌هایی که در in-interface-list=!LAN بودند تا حتی اگر روتر از چند لینک اینترنتی تغذیه می‌شد، از بیرون کسی نتواند به Winbox برسد.
در همان پروژه، برای این‌که مدیران استانی بتوانند وضعیت لینک‌ها را مانیتور کنند، ICMP به سمت روتر برای همه Srcها مجاز گذاشته شد، اما برای جلوگیری از حملات ping flood، روی ICMP limit 5,10 تعریف کردیم تا بیش از پنج درخواست در ثانیه با burst ده عددی پذیرفته نشود و مازاد آن drop گردد. این طراحی باعث شد در گزارش‌های امنیتی ممیز دولتی، روتر به‌عنوان نقطه مدیریت امن (Secure Management Plane) پذیرفته شود، در حالی که از نگاه کاربر نهایی همه‌چیز «عادی» کار می‌کرد و فقط آدرس‌های مدیریت مجاز بودند وارد Winbox شوند. مدیر IT اگر همین منطق را روی روتر خود پیاده کند، عملا نیاز به خرید تجهیزات گران‌قیمت فقط برای جداسازی management plane را در بسیاری از شبکه‌های کوچک و متوسط حذف می‌کند؛ تصمیمی که هم بودجه را حفظ می‌کند و هم پیچیدگی را کم نگه می‌دارد.
کنترل ترافیک بین VLANها (chain=forward)
در ساخت Ruleهای فایروال روی chain forward، اینتنت اصلی معمولا کنترل ترافیک بین VLANها، DMZ و اینترنت است؛ جایی که تصمیم می‌گیرید کدام شبکه کاربری، به کدام سرور یا سرویس و روی چه پورتی دسترسی داشته باشد. در یک شبکه با VLANهای متعدد (LAN اداری، VLAN مهمان، VLAN دوربین‌ها و DMZ)، روتر میکروتیک به‌عنوان core router استفاده شده بود و با استفاده از forward rules تصمیم گرفتیم که VLAN مهمان فقط به اینترنت دسترسی داشته باشد، VLAN دوربین‌ها تنها به سرور NVR و VLAN اداری دسترسی محدود به سرورهای داخلی و اینترنت داشته باشد، و هر چیزی خارج از این استثناها در انتهای chain با یک Rule drop all از کار بیفتد.
به‌طور عملی، ابتدا fasttrack برای established/related فعال شد، سپس Rule accept برای همین stateها و بعد از آن Ruleهای مشخصی برای اجازه‌دادن به HTTP/HTTPS از VLANهای مجاز به اینترنت، اجازه دسترسی از VLAN مانیتورینگ به IP دوربین‌ها و NVR و در نهایت Rule drop forward برای ترافیک new از WAN که dstnat نشده بود. در یکی از تست‌ها، Rule drop جداگانه‌ای مشابه «drop از VLAN مهمان به LAN» با استفاده از src-address و dst-address تعریف شد و دقیقا مثل مثال‌های مطرح‌شده در فروم میکروتیک، چون در جای نادرست chain قرار گرفته بود، عمل نمی‌کرد تا زمانی که با جابجا کردن Rule و قراردادن آن بالاتر از acceptهای کلی، رفتار به درستی اصلاح شد. این تجربه عملی نشان می‌دهد که ترتیب Ruleها در chain forward به اندازه خود محتوای Rule مهم است و اگر مدیر شبکه بدون درک Counters فقط Rule اضافه کند، در شبکه‌های بزرگ به‌راحتی حفره امنیتی ایجاد می‌شود.
نکات سخت‌افزاری و انتخاب روتر مناسب برای Ruleهای سنگین
وقتی Ruleهای فایروال میکروتیک پیچیده می‌شوند (ده‌ها Rule، address-list داینامیک، شناسایی حملات و fasttrack محدود)، انتخاب روتر مبتنی بر توان پردازشی، تعداد پورت‌ها و پشتیبانی PoE اهمیت جدی پیدا می‌کند تا CPU زیر فشار Ruleها به ۱۰۰ درصد نرسد. در شبکه‌های کوچک، روترهایی مثل hEX و hEX PoE برای سناریوهای فایروال پایه، NAT و چند VLAN کافی هستند، اما وقتی شروع به اضافه‌کردن Ruleهای متعدد روی هر chain می‌کنید، باید حواستان به CPU usage و memory باشد و در مرحله خرید، صرفا به «ارزان‌ترین گزینه» تکیه نکنید؛ بررسی دقیق قیمت روتر hEX PoE Lite و قیمت محصولات دیگری همچون قیمت روتر hEX PoE در کنار نیاز پردازشی واقعی شبکه، جلوی بسیاری از مشکلات بعدی را می‌گیرد. در پروژه‌هایی که وینو سرور مدیریت کرده، معمولا برای سازمان‌های دولتی با چند صد کاربر و Ruleهای امنیتی پیشرفته، از مدل‌هایی استفاده شده که توان پردازشی بالاتر و امکاناتی مثل SFP و PoE را هم‌زمان داشته باشند تا هم گسترش آتی شبکه (افزودن APها یا لینک‌های فیبر) را پوشش دهند و هم Ruleهای فایروال باعث گلوگاه نشوند.
در عین حال، اگر حجم ترافیک شما خیلی بالاست یا نیاز به سناریوهای امنیتی عمیق‌تر مثل IPS، sandboxing و بازرسی لایه‌های بالاتر دارید، منطقی است که به‌جای فشار آوردن بیش از حد به روترهای میکروتیک، سراغ فایروال‌های تخصصی‌تر مثل Fortinet یا Palo Alto بروید، حتی اگر هزینه اولیه بیشتر باشد؛ در چند پروژه که بار ترافیک از ۲–۳ گیگابیت عبور می‌کرد، دقیقا همین تصمیم گرفته شد و میکروتیک صرفا نقش edge router و load balancer سبک را بازی کرد.
راهنمای انتخاب محل خرید مناسب فایروال در میکروتیک
وقتی صحبت از طراحی Ruleهای فایروال میکروتیک در سازمان‌های دولتی یا نیمه‌دولتی می‌شود، چالش اصلی فقط انتخاب Command درست نیست، بلکه هماهنگی این Ruleها با استانداردهای امنیتی، خط‌مشی‌های دولتی و محدودیت‌های بودجه‌ای است؛ دقیقا همان جایی که یک پیمانکار باتجربه زیرساخت، تفاوت ایجاد می‌کند. در پروژه‌هایی که وینو سرور اجرا کرده، معمولا فرایند از تحلیل معماری شبکه و دسته‌بندی VLANها و سرویس‌ها شروع می‌شود، سپس Ruleهای فایروال روی میکروتیک به‌گونه‌ای نوشته می‌شوند که هم الزامات حاکمیتی (مثل لاگ‌گیری، محدودکردن دسترسی مدیریتی و جداسازی شبکه‌های حساس) را پوشش دهند و هم از نظر کارایی و توسعه‌پذیری، در طول عمر پروژه قابل نگهداری باشند.
جمع‌بندی
اگر بخواهیم تصمیم‌گیری را برای مدیر IT یا مدیر خرید ساده کنیم، معیار انتخاب این است: اگر شبکه شما تا چند صد کاربر، تعداد محدود VLAN و نیاز به Ruleهای مشخص (کنترل دسترسی، NAT، address-list، محدودکردن مدیریت روتر) دارد، میکروتیک با طراحی صحیح Ruleهای فایروال، یک انتخاب منطقی و اقتصادی است. اما اگر با ترافیک چندگیگابیتی، الزامات امنیتی خیلی سختگیرانه، یا نیاز به امکانات پیشرفته مثل IPS و sandboxing طرف هستید، بهتر است میکروتیک را بیشتر به‌عنوان روتر و edge device ببینید و فایروال اصلی را به یک NGFW تخصصی بسپارید، هرچند هزینه اولیه بالاتر باشد.
نقطه مهم این است که پیش از خرید یا ارتقا، معماری Ruleهای فعلی خود را روی chainهای input و forward بازبینی کنید و مطمئن شوید منطق accept established/related، drop invalid، drop all و استفاده از address-list به‌درستی پیاده شده است؛ در بسیاری از سازمان‌ها فقط با همین بهینه‌سازی نرم‌افزاری، نیاز به تعویض کامل سخت‌افزار از بین رفته است.