جلوگیری از حملات DDoS با فایروال میکروتیک

جلوگیری از حملات DDoS با فایروال میکروتیک یعنی شما باید هم‌زمان سه لایه دفاع داشته باشید: سخت‌افزار مناسب (مثل سری CCR)، تنظیم درست Connection Tracking و پیاده‌سازی رول‌های هوشمند (limit، dst-limit، address-list) روی RouterOS تا ترافیک مخرب قبل از خفه کردن CPU یا لینک، قطع شود. اگر این سه لایه یکی‌شان ضعیف باشد، حتی گران‌ترین روتر میکروتیک هم زیر یک UDP flood ساده یا SYN flood متوسط کم می‌آورد و عملاً شبکه سازمان‌تان از دسترس خارج می‌شود.

چرا میکروتیک برای دفاع در برابر DDoS جواب می‌دهد؟

خرید روتر Mikrotik  وقتی برای DDoS درست عمل می‌کند که شما آن را مثل یک فایروال لبه با رول‌های دقیق و پایش مداوم ببینید، نه صرفاً یک روتر ارزان برای عبور ترافیک. RouterOS ابزارهایی مثل connection tracking، tcp-syncookies، address-list و dst-limit را در اختیار شما می‌گذارد که اگر طبق یک طرح معماری شده استفاده شوند، می‌توانند اغلب حملات volumetric و application-level ساده را در همان لبه متوقف کنند.

تنظیمات پایه RouterOS برای کاهش ریسک DDoS

اولین قدم در جلوگیری از DDoS روی میکروتیک این است که خود روتر را از دید اینترنت مخفی و محافظت کنید، سپس به سراغ سرویس‌های پشت آن بروید. روی RouterOS همیشه ورودی‌های غیرضروری را در chain=input می‌بندیم، فقط پورت‌های مدیریتی از شبکه‌های مدیریت محدود اجازه می‌گیرند و برای TCP، گزینه tcp-syncookies را فعال می‌کنیم تا فشار SYN flood روی Connection Tracking کنترل شود.

در عمل، روی روترهایی که در پروژه‌های دولتی استفاده کردیم، ترکیب زیر همیشه ثابت بود: محدود کردن تعداد connection جدید از هر IP، محدود کردن نرخ ICMP (برای جلوگیری از ping flood)، بستن همه سرویس‌های ناامن روی خود روتر (مثل Winbox از اینترنت یا API باز) و جدا کردن دقیق chain=input (حفاظت از خود روتر) از chain=forward (حفاظت از سرورها). این تفکیک باعث می‌شود حتی اگر سرور وب سازمان هدف حمله حجیم قرار گرفت، CPU روتر درگیر پردازش غیرضروری روی ترافیک به خودش نشود و حداقل دسترسی مدیریت و مانیتورینگ شما پایدار بماند.

تکنیک‌های پیشرفته فایروال میکروتیک برای مهار DDoS

برای حملات جدی‌تر، رول‌های ساده drop کافی نیستند و باید از chainهای اختصاصی و address-list‌های داینامیک برای شناسایی و قرنطینه IPهای مشکوک استفاده کرد. در این مدل، هر اتصال جدید ابتدا به یک chain مثل «detect-ddos» پرش می‌کند، در آنجا با پارامترهایی مثل dst-limit، limit و connection-rate رفتار آن سنجیده می‌شود و اگر از آستانه‌ها تجاوز کرد، IP منبع برای مدت مشخصی در لیست «attacker» قرار گرفته و کل ترافیکش drop می‌شود.

این ساختار را در چند پروژه واقعی روی سرویس‌های وب دولتی اجرا کردیم؛ ترافیک HTTP/HTTPS عادی (کاربران مردمی) بدون مشکل عبور می‌کرد، اما ربات‌ها و اسکریپت‌هایی که در چند ثانیه ده‌ها connection جدید می‌زدند، به‌سرعت در لیست حمله‌کنندگان قرار می‌گرفتند و برای ۳۰ دقیقه یا بیشتر مسدود می‌شدند. نکته کلیدی این است که این رول‌ها باید بعد از رول‌های دقیق اجازه‌دهنده (whitelist برای IPهای سازمانی، دیتاسنترها یا همکاران) و قبل از dropهای کلی قرار بگیرند تا هم false positive کم شود و هم از لحاظ مصرف CPU بهینه بمانند.

حمله UDP flood روی سامانه دولتی

در یکی از پروژه‌های واقعی که به‌عنوان معمار زیرساخت مدیریت می‌کردیم، یک سازمان دولتی دارای پرتال خدمات مردمی بود که روی چند سرور مجازی پشت یک CCR1036 منتشر شده بود و به‌صورت ناگهانی با حملات UDP flood به سمت پورت‌های تصادفی سرور مواجه شد؛ نتیجه اولیه، بالا رفتن CPU روتر تا ۹۵ درصد و قطع و وصل متناوب سرویس بود. در این وضعیت، تنها افزودن چند رول ساده drop روی پروتکل UDP مشکل را حل نکرد، چون connection tracking هنوز زیر بار شدید بود و روتر مجبور بود هر بسته را پردازش کند.

در بازطراحی فایروال، ابتدا ترافیک UDP ورودی به‌جز چند پورت مشخص (DNS داخلی و سرویس‌های لازم) به‌طور کامل drop شد، سپس روی همان پورت‌های مجاز، limit نرخ برای هر IP در chain=forward تنظیم شد و یک chain تشخیص DDoS خاص UDP اضافه شد که IPهایی با تعداد غیرعادی بسته در ثانیه را در address-list مهاجم قرار می‌داد. بعد از اعمال این معماری، CPU روتر به زیر ۴۰ درصد برگشت و حتی در اوج حملات، تأخیر کاربران واقعی در استفاده از سامانه کمتر از ۲۰ درصد افزایش پیدا کرد؛ مهم‌تر از آن، تیم IT سازمان در داشبورد مانیتورینگ به‌وضوح می‌دید که کدام IPها در حال حمله هستند و بر اساس آن، در لایه‌های بالاتر (ISP یا CDN) هم می‌توانستند اقدام کنند. در این پروژه، بخش طراحی و پیاده‌سازی رول‌ها و مانیتورینگ روی دوش تیم فنی وینو سرور بود و سازمان صرفاً نتیجه نهایی یعنی پایداری سامانه را لمس می‌کرد.

فشار SYN flood روی لینک ۱۰ گیگابیتی

در سناریوی دیگری، یک دیتاسنتر کوچک با دو لینک ۱۰G که هر دو روی یک CCR2004-1G-12S+2XS terminate شده بودند، با حملات ترکیبی SYN flood و HTTP flood روبه‌رو شد که هدف آن، از کار انداختن gateway اصلی بود؛ در اولین حمله، چون فایروال بهینه نشده بود، با حدود ۸–۹ گیگابیت ترافیک، CPU روتر به سقف مصرف رسید و latency شبکه به چند ثانیه افزایش یافت. تحلیل NetFlow و لاگ‌ها نشان داد که بخش زیادی از فشار روی Connection Tracking است و رول‌های فایروال ترتیب درستی ندارند و ابتدا ترافیک مخرب را accept می‌کنند و بعد در chainهای بعدی تلاش برای drop کردن آن انجام می‌شود.

در بازطراحی، chainی اختصاصی برای محافظت از سرویس‌های وب تعریف شد که همه connectionهای جدید به پورت‌های ۸۰ و ۴۴۳ را با limit و dst-limit کنترل می‌کرد و بالاتر از آن، tcp-syncookies برای کاهش اثر SYN flood فعال شد، همچنین رول‌های whitelist برای IPهای مطمئن (دفاتر و سامانه‌های همکار) در ابتدای فایروال قرار گرفتند تا بدون عبور از این فیلترها سرویس بگیرند. نتیجه این بود که در حملات بعدی با ترافیک مشابه، CPU روتر از ۶۰–۷۰ درصد فراتر نرفت و سرویس‌های حیاتی بدون downtime باقی ماندند، در حالی که حملات حجیم‌تر هم فقط باعث کاهش جزئی کیفیت سرویس می‌شد، نه قطع کامل آن. در این پروژه، مدیر خرید سازمان ابتدا قصد تعویض روتر را داشت، اما بعد از طراحی مجدد فایروال، همان سخت‌افزار موجود با تنظیمات بهینه، پاسخ‌گوی نیاز شد و هزینه سرمایه‌ای جدید حذف شد.

چک لیست راهنمای انتخاب مدل و بودجه برای CCR

برای یک مدیر IT یا مدیر خرید، سوال مهم این است که آیا اصلاً می‌ارزد برای جلوگیری از DDoS، روی میکروتیک سرمایه‌گذاری کند یا به‌جای آن سراغ سرویس‌های ابری و CDN برود. پاسخ این است که اگر ترافیک سازمان شما زیر چند صد مگابیت است و سرویس‌های شما عمومی جهانی نیست، یک طراحی درست روی روترهای رده میانی و استفاده از سرویس‌های ابری ارزان‌تر برای جذب ترافیک استاتیک، عقلانی‌تر است؛ اما وقتی وارد محدوده چند گیگابیت و ده‌ها هزار کاربر هم‌زمان می‌شوید، داشتن یک CCR قدرتمند در لبه می‌تواند هزینه سرویس‌های ابری را کاهش دهد و کنترل بیشتری در اختیار تیم فنی بگذارد.

در چنین سناریوهایی، بررسی دقیق نیازها و مقایسه مدل‌ها اهمیت دارد، چون صرفاً دانستن قیمت روتر CCR1036-12G-4S-EM یا رنج قیمتی محصولات دیگری همچون قیمت روتر CCR2004-1G-12S+2XS بدون تحلیل ترافیک، نوع سرویس‌ها، نیاز به IPsec و میزان رشد آینده، ممکن است منجر به خرید بیش از حد یا کمتر از نیاز شود. در پروژه‌های دولتی، معمولاً نگاه ما به‌عنوان معمار زیرساخت این بوده که قبل از خرید، یک سناریوی کامل شامل طراحی فایروال، سنجش بار، راهکار مانیتورینگ و حتی شبیه‌سازی حمله در محیط تست ارائه کنیم و بعد روی مدل روتر و ظرفیت نهایی تصمیم بگیریم. در این نقطه است که حضور یک شریک فنی مثل وینو سرور که هم تجربه بازرگانی و هم تجربه پیمانکاری زیرساختی دارد، می‌تواند معادله را به نفع سازمان حل کند، چون خرید، طراحی و اجرا را به صورت یکپارچه می‌بیند نه جداگانه.

جمعبندی

اگر مدیر IT یا مدیر خرید هستید، برای تصمیم‌گیری درباره استفاده از فایروال میکروتیک در جلوگیری از DDoS، ابتدا باید سه سوال را دقیق و صریح جواب دهید: حجم واقعی و پیک ترافیک شما چقدر است، مدل روتر فعلی شما تا کجا تحمل دارد، و آمادگی تیم فنی‌تان برای کار با RouterOS در سطح حرفه‌ای چقدر است. اگر ترافیک شما محدود و تیم‌تان آشنایی متوسطی با میکروتیک دارد، شروع با یک طراحی ساده و رول‌های پایه (محدودسازی connection، فعال‌سازی tcp-syncookies، بستن سرویس‌های غیرضروری) کاملاً منطقی است؛ اما در سناریوهای چند گیگابیتی و سرویس‌های حساس دولتی یا بانکی، بدون معماری حرفه‌ای و تست‌های واقعی، حتی بهترین روتر هم نمی‌تواند تضمین پایداری در حملات سنگین را بدهد.

در بسیاری از پروژه‌هایی که با سازمان‌های دولتی کار کرده‌ایم، انتخاب روتر میکروتیک، طراحی معماری فایروال و حتی سناریوی Incident Response در برابر DDoS در قالب یک بسته واحد دیده شده و مشتری صرفاً خروجی را به‌صورت «شبکه پایدار در زمان حمله» تحویل گرفته است. وینو سرور در این مدل نه صرفاً فروشنده روتر، بلکه به‌عنوان یک راه‌حل عمل می‌کند: از تحلیل اولیه ترافیک و ریسک، تا انتخاب مدل مناسب برای خرید روتر Mikrotik، طراحی رول‌های DDoS، پیاده‌سازی در محیط واقعی و تنظیم فرآیند مانیتورینگ و واکنش.