راهنمای جامع راه‌اندازی فایروال سرور: محافظت از سرور در برابر حملات DDoS و ترافیک ربات‌ها

راه‌اندازی فایروال سرور به معنای باز گذاشتن فقط پورت‌های ضروری و مسدود کردن تمامی دسترسی‌های غیرضروری است؛ این لایه نخست دفاعی در برابر حملات DDoS، حملات حدس رمز (brute force) و ترافیک مخرب ربات‌ها محسوب می‌شود. هدف عملیاتی این است که دسترسی SSH محدود شود، سرویس‌های وب به صورت کنترل شده باز بمانند، درخواست‌های مشکوک محدودیت نرخ دریافت کنند، لاگ‌ها به دقت بررسی شوند و در صورت امکان با استفاده از ابزارهای لایه بالا مانند CDN یا WAF، ترافیک پیش از رسیدن به سرور فیلتر شود.

وقتی سرور وب خود را به اینترنت متصل می‌کنید، در عرض چند دقیقه با اسکن پورت‌ها، تلاش برای ورود SSH، ربات‌های جستجوگر ضعف امنیتی و شبیه‌سازهای مرورگرهای جعلی روبرو خواهید شد. به‌ویژه در سایت‌های وردپرسی، فروشگاه‌های اینترنتی، پنل‌های مدیریتی، APIها یا سرورهای بازی، فایروال سرور صرفاً یک گزینه فنی نیست بلکه برای پایداری سرویس ضروری است. در این راهنما، معماری مرحله به مرحله فایروال روی سرورهای لینوکسی را بررسی می‌کنیم؛ ابزارهایی همچون UFW، firewalld، nftables، Fail2ban، فایروال برنامه وب و روش‌های کاهش حملات DDoS را با هم مرور خواهیم کرد.

یک واقعیت مهم را ابتدا بگوییم: فایروال محلی سرور به تنهایی نمی‌تواند حملات حجیم DDoS را متوقف کند. وقتی حمله‌ای با حجم ۲۰، ۸۰ گیگابیت بر ثانیه یا بیشتر به دیتاسنتر یا هسته شبکه برسد، بسته‌ها پیش از رسیدن به قوانین روی سیستم‌عامل شما پهنای باند را اشغال می‌کنند. بنابراین رویکرد درست استفاده از امنیت چندلایه است: محافظت DDoS روی سطح ارائه‌دهنده سرویس، CDN/WAF، فایروال سیستم‌عامل، محدودیت نرخ برنامه و تحلیل مرتب لاگ‌ها باید هم‌زمان اجرا شوند. برای انتخاب زیرساخت مناسب، می‌توانید به صفحه راهکارهای سرور VPS و VDS Hostragons و برای گزینه‌های میزبانی امن وب به صفحه بسته های هاستینگ وب Hostragons مراجعه کنید.

فایروال سرور چه کاری انجام می‌دهد؟

فایروال سرور یک لایه امنیتی است که ترافیک شبکه را بر اساس آی‌پی مبدا، آی‌پی مقصد، پورت، پروتکل، وضعیت اتصال و گاهی ویژگی‌های بسته‌ها فیلتر می‌کند. به عنوان مثال ساده؛ برای سایت شما باید پورت‌های ۸۰ و ۴۴۳ باز باشد، اما پورت پایگاه داده مثل ۳۳۰۶ نباید روی اینترنت باز باشد. به جای اجازه دادن به همه برای اتصال به پورت ۲۲ SSH، بهتر است فقط آی‌پی دفتر یا شبکه VPN خود را مجاز کنید.

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

درک حملات DDoS و ترافیک ربات‌ها

چرا حملات DDoS متفاوت‌اند؟

حملات DDoS یا انکار سرویس توزیع‌شده، با ارسال حجم زیادی ترافیک از منابع مختلف، هدف را از دسترس خارج می‌کنند. این حملات گاهی پهنای باند را پر می‌کنند، گاهی منابع CPU و RAM سرور را مصرف می‌کنند و گاهی عملیات‌های سنگین در لایه برنامه را تحریک می‌کنند. برای مثال، سرور نرم‌افزاری کوچک که ۵۰ هزار درخواست HTTP در ثانیه دریافت می‌کند، حتی اگر شبکه اشباع نشود، ممکن است به‌خاطر محدودیت‌های PHP-FPM، Node.js یا اتصال پایگاه داده، پاسخگو نباشد.

آیا همه ربات‌ها مخرب هستند؟

خیر. ربات‌هایی مانند Googlebot و Bingbot و برخی ربات‌های مانیتورینگ مفیدند. اما ربات‌های مخرب به دنبال جستجو در پنل مدیریت، بررسی دایرکتوری‌های باز، ارسال هرزنامه، کپی محتوا، سوءاستفاده از XML-RPC، ایجاد حساب‌های جعلی و تلاش برای ورود غیرمجاز هستند. بنابراین هدف مدیریت ربات‌ها، مسدود کردن همه آنها نیست بلکه تشخیص رفتارهای مشکوک است. نرخ بالای خطا، تعداد زیاد درخواست در زمان کوتاه، هدرهای غیرمرورگر واقعی و الگوهای URL مشکوک، نشانه‌های مهم هستند.

پیش از شروع راه‌اندازی، چک‌لیست ایمنی

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

• جلسه SSH فعال را نبندید؛ با یک ترمینال دیگر تغییرات را تست کنید.
• مطمئن شوید ارائه‌دهنده سرور دسترسی کنسول، VNC یا حالت ریکاوری دارد.
• پورت‌های باز فعلی را با دستور ss -tulpn یا netstat -tulpn بررسی کنید.
• پورت‌هایی که وب، ایمیل، DNS، پایگاه داده، پنل و سرویس‌های مانیتورینگ استفاده می‌کنند را یادداشت کنید.
• اگر از IPv6 استفاده می‌کنید، قوانین فایروال آن را هم برنامه‌ریزی کنید.
• ابتدا قوانین اجازه (allow)، سپس قوانین مسدودسازی (deny) را اعمال کنید.
• مطمئن شوید قوانین پس از راه‌اندازی مجدد سرور حفظ می‌شوند.

مثلاً در یک سرور معمولی که فقط سایت میزبانی می‌کند، پورت‌های باز معمولاً ۸۰، ۴۴۳ و یک پورت محدود SSH هستند. اگر سرور ایمیل نیست، پورت‌های ۲۵، ۴۶۵، ۵۸۷ و ۹۹۳ نباید باز باشند. اگر پایگاه داده فقط از داخل سرور استفاده می‌شود، پورت ۳۳۰۶ یا ۵۴۳۲ باید بسته باشد.

کدام ابزار فایروال را انتخاب کنیم؟

در دنیای لینوکس ابزارهای مختلفی وجود دارد که بیشترشان از هسته فیلترینگ مشابهی استفاده می‌کنند اما با رابط و امکانات متفاوت. برای مبتدیان UFW ساده و سریع است. در سیستم‌های سازمانی یا مبتنی بر Red Hat، firewalld رایج است. برای سناریوهای پیشرفته‌تر nftables ساختاری مدرن و انعطاف‌پذیر ارائه می‌دهد. جدول زیر انتخاب را ساده‌تر می‌کند.

گام به گام راه‌اندازی فایروال سرور

۱. پورت‌ها و سرویس‌های باز را شناسایی کنید

اولین گام دیدن سرویس‌های فعال است. دستور ss -tulpn در لینوکس نشان می‌دهد کدام سرویس روی کدام پورت‌ها گوش می‌دهد. مثلاً اگر nginx روی 0.0.0.0:80 و 0.0.0.0:443 فعال باشد، ترافیک وب از همه اینترفیس‌ها پذیرفته می‌شود. اگر MariaDB روی 0.0.0.0:3306 فعال باشد، معمولاً ریسک بالایی است؛ معمولاً پایگاه داده باید فقط روی 127.0.0.1 گوش دهد.

قاعده عملی این است: هیچ سرویس غیرضروری نباید روی 0.0.0.0 گوش دهد. ابتدا پیکربندی سرویس را اصلاح کنید و سپس با فایروال فیلتر کنید، چون حتی اگر فایروال غیرفعال شود، سرویس نباید مستقیماً در دسترس باشد.

۲. سیاست پیش‌فرض را بسته تنظیم کنید

در سیاست‌های امن، ترافیک ورودی به طور پیش‌فرض مسدود و ترافیک خروجی بر اساس نیاز مجاز می‌شود. این روش اجازه نمی‌دهد سرویس‌های جدید به اشتباه به اینترنت باز شوند. در UFW اوبونتو روند معمول این است که ابتدا اجازه SSH داده می‌شود، سپس پورت‌های ۸۰ و ۴۴۳ باز می‌شوند، بعد سیاست پیش‌فرض ورودی deny شده و فایروال فعال می‌گردد.

مثال: ابتدا به آی‌پی مدیریت SSH اجازه دهید، سپس HTTP و HTTPS را باز کنید، پورت‌های اضافی را ببندید و بعد فایروال را فعال کنید. فعال کردن فایروال بدون مجوز SSH یکی از رایج‌ترین اشتباهات در سرورهای راه دور است.

۳. دسترسی SSH را محدود کنید

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

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

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

۴. پورت‌های وب را کنترل شده باز کنید

برای اکثر سرورها پورت‌های ۸۰ و ۴۴۳ ضروری‌اند. اما امروزه پورت ۴۴۳ (HTTPS) باید اصلی‌ترین مسیر باشد و ۸۰ فقط برای هدایت به HTTPS استفاده شود. سایت‌های بدون SSL هم اعتماد کاربران و هم رتبه SEO را به شدت آسیب می‌زنند. در اینجا لینک گواهی SSL Hostragons فرصتی طبیعی برای راهنمایی به نصب HTTPS امن است.

در باز کردن پورت‌های وب به رفتار IP واقعی دقت کنید. اگر از CDN یا پراکسی معکوس استفاده می‌کنید، بهتر است پورت‌های ۸۰ و ۴۴۳ سرور فقط به رنج IPهای CDN اجازه دسترسی داشته باشند. این کار باعث می‌شود حتی اگر مهاجم IP واقعی سرور را بداند، نتواند مستقیم به سرویس وب دسترسی پیدا کند.

۵. پایگاه داده و سرویس‌های داخلی را از اینترنت ببندید

باز بودن سرویس‌هایی مانند MySQL، MariaDB، PostgreSQL، Redis، Elasticsearch، MongoDB در اینترنت ریسک بالا دارد. نبود احراز هویت در Redis، دسترسی غیرمجاز به ایندکس‌های Elasticsearch یا باز بودن پورت مدیریت MongoDB باعث نشت داده‌های گسترده شده است. این سرویس‌ها باید فقط روی localhost یا شبکه خصوصی شنونده باشند.

مثلاً در سروری که وردپرس نصب است، کافی است پایگاه داده روی 127.0.0.1 باشد. اگر سرور برنامه و پایگاه داده جدا هستند، فقط آدرس IP خصوصی سرور برنامه باید مجاز باشد. باز گذاشتن ۳۳۰۶ یا ۵۴۳۲ روی اینترنت اشتباهی است که ربات‌ها دائماً دنبال آن می‌گردند.

۶. با Fail2ban تلاش‌های حدس رمز را مسدود کنید

Fail2ban لاگ‌ها را پایش می‌کند و تلاش‌های ناموفق ورود مکرر را شناسایی و به طور موقت IP را مسدود می‌کند. می‌توان jail برای SSH، nginx، Apache، Postfix، Dovecot، ورود وردپرس و برخی پنل‌ها تنظیم کرد. مثلاً مسدود کردن IPی که در ۱۰ دقیقه ۵ بار تلاش ناموفق SSH داشته باشد، به مدت یک ساعت یک شروع ساده و مؤثر است.

در تنظیم Fail2ban مراقب باشید قوانین بیش از حد حساس باعث مسدود شدن کاربران واقعی نشود. بهتر است ابتدا مدت مسدودسازی کوتاه باشد، لاگ‌ها بررسی شوند و سپس به تدریج سخت‌گیری افزایش یابد.

۷. محدودیت نرخ و تعداد اتصال اضافه کنید

محدودسازی نرخ در سطح سیستم‌عامل می‌تواند در برابر DDoS و ترافیک ربات‌ها کمک کند. مثلاً اگر یک IP در ثانیه تعداد زیادی اتصال جدید ایجاد کند، محدود شود. در سمت وب، nginx با ماژول‌های limit_req و limit_conn و Apache با mod_evasive یا معادل‌های آن قابل تنظیم است. در برنامه نیز باید محدودیت روی ورود، جستجو، سبد خرید، پرداخت و APIها اعمال شود.

مثال عملی: برای صفحه ورود، ۱۰ تلاش در دقیقه برای هر IP معقول است. برای endpoint جستجو، ۲ تا ۵ درخواست در ثانیه کفایت می‌کند. در APIها باید محدودیت بر اساس توکن کاربر، IP و تحلیل رفتار طراحی شود تا مهاجم با تغییر IP نتواند محدودیت‌ها را دور بزند.

نمونه راه‌اندازی امن با UFW

در سرورهای اوبونتو یا دبیان می‌توان سناریوی شروع ساده‌ای با این روش داشت: ابتدا سرویس‌های فعال را بررسی کنید، دسترسی SSH را فقط برای آی‌پی مدیریت باز کنید، پورت‌های ۸۰ و ۴۴۳ را فعال نمایید، سیاست پیش‌فرض ورودی را مسدود کنید و وضعیت UFW را بررسی کنید. اگر امکان محدود کردن SSH به آی‌پی ثابت نیست، می‌توانید موقتاً همه آی‌پی‌ها را مجاز کنید و بعد با VPN یا آی‌پی ثابت جایگزین کنید.

مثال: آی‌پی مدیریت ۲۰۳.۰.۱۱۳.۱۰ باشد. SSH فقط از این آی‌پی اجازه داده شود. ترافیک وب ۸۰ و ۴۴۳ برای همه باز بماند. پایگاه داده، Redis، پنل و پورت‌های آزمایشی بسته باشند. این ساختار شروع خوبی برای بسیاری سایت‌های متوسط است. برای تنظیم درست دامنه و DNS می‌توانید به جستجوی دامنه و ثبت Hostragons مراجعه نمایید.

منطق Zone در firewalld

در سرورهای مبتنی بر AlmaLinux، Rocky Linux و RHEL، firewalld بسیار استفاده می‌شود. این ابزار از مفهوم zone بهره می‌برد. zone public برای اینترفیس‌های باز به اینترنت، zone trusted برای شبکه‌های خصوصی مطمئن و zone drop برای رها کردن بی‌صدا ترافیک ناخواسته است. نکته مهم تفاوت بین قوانین runtime و permanent است. قوانین runtime بلافاصله اعمال می‌شوند اما با راه‌اندازی مجدد پاک می‌شوند؛ قوانین permanent دائمی‌اند اما ممکن است reload لازم داشته باشند.

در محیط‌های سازمانی، تعریف سرویس‌ها امکان مدیریت آسان‌تر را فراهم می‌کند. مثلاً سرویس http و https را روی zone public باز کنید و سرویس ssh را فقط به آی‌پی‌های خاص محدود نمایید. اگر شبکه مدیریت، پشتیبان و کاربران جداست، استفاده از zoneها امنیت و خوانایی را افزایش می‌دهد.

CDN، WAF و محافظت DDoS در سطح ارائه‌دهنده

فایروال محلی فقط پس از رسیدن بسته‌ها به سرور تصمیم می‌گیرد. در حملات بزرگ DDoS هدف فیلتر کردن ترافیک پیش از رسیدن به سرور است. CDN محتواهای استاتیک را در لبه شبکه ارائه می‌دهد، WAF درخواست‌های مخرب لایه برنامه را مسدود می‌کند و محافظت ارائه‌دهنده حملات حجیم شبکه را دفع یا پاکسازی می‌کند.

مدل ایده‌آل این است که DNS شما از CDN عبور کند، IP واقعی سرور مخفی بماند و فایروال سرور فقط از رنج IPهای CDN اجازه دریافت ترافیک ۸۰ و ۴۴۳ را داشته باشد. پورت‌های مدیریت فقط از طریق VPN یا آی‌پی ثابت قابل دسترسی باشند. این مدل احتمال حمله مستقیم به IP را کاهش داده و ترافیک ربات‌ها را پیش از رسیدن به برنامه حذف می‌کند. برای مطالعه بیشتر در زمینه امنیت و بهینه‌سازی وب به راهنماهای تسریع و امنیت وب‌سایت مراجعه کنید.

اقدامات لایه برنامه برای مقابله با ربات‌ها

مسدودسازی ربات‌ها فقط به لیست سیاه IP محدود نمی‌شود. ربات‌های مدرن از پراکسی، شبکه‌های موبایل، IPهای دیتاسنتر و تغییر User-Agent استفاده می‌کنند. بنابراین باید رویکرد مبتنی بر رفتار داشت. تلاش‌های زیاد ورود از یک IP، اسکن صفحه‌های ۴۰۴، افزایش ناگهانی درخواست wp-login.php یا xmlrpc.php، الگوهای کلیک متفاوت با کاربران واقعی و هدرهای مشکوک باید تحلیل شوند.

• محدودیت نرخ برای فرم‌های ورود و ثبت‌نام اعمال کنید.
• دسترسی XML-RPC غیرضروری را ببندید یا محدود نمایید.
• پنل مدیریت را با URL متفاوت، محدودیت IP و احراز هویت چندمرحله‌ای محافظت کنید.
• الگوهای user-agent و referrer مشکوک را در سطح WAF فیلتر کنید.
• از CAPTCHA یا مکانیزم‌های نامرئی برای تشخیص ربات‌ها استفاده متعادل داشته باشید.
• برای APIها کنترل دسترسی با کلید، امضا، نرخ و زمان‌بندی اعمال نمایید.

در مدیریت ربات‌ها حفظ تجربه کاربری اهمیت دارد. CAPTCHA بیش از حد، مسدودسازی‌های شدید یا بلاک اشتباه کشورها می‌تواند به مشتریان واقعی آسیب بزند. بنابراین اندازه‌گیری، تست و تشدید تدریجی بهترین راهکار است.

نظارت بر لاگ‌ها و قوانین هشدار

فکر کردن به پایان کار پس از راه‌اندازی فایروال یک اشتباه رایج است. فایروال یک سیستم زنده است که باید مرتب پایش شود. لاگ‌های auth.log یا secure برای تلاش‌های SSH، لاگ‌های دسترسی nginx برای حجم غیرمعمول درخواست‌ها، لاگ‌های خطا برای افزایش ۴۰۴ و ۵۰۰، و شاخص‌های سیستم مانند مصرف CPU و تعداد اتصالات باید بررسی شوند. حتی یک هشدار ساده می‌تواند در شروع حمله دقیقه‌ها زمان بخرد.

مثال آستانه‌ها برای شروع: بیش از ۱۰۰ درخواست ۴۰۴ از یک IP طی ۵ دقیقه، بیش از ۲۰ تلاش ورود در یک دقیقه، ماندن مصرف CPU بالای ۹۰٪ برای ۱۰ دقیقه، افزایش سه برابری اتصالات نسبت به حالت عادی. این مقادیر بسته به سایت متفاوت است؛ مهم شناخت پروفایل ترافیک معمولی است.

اشتباهات رایج و چگونه از آنها جلوگیری کنیم

• فعال کردن فایروال بدون اجازه SSH: ممکن است دسترسی به سرور را قطع کند. همیشه با جلسه دوم تست کنید.
• فراموش کردن IPv6: ممکن است IPv6 باز بماند در حالی که IPv4 بسته شده است.
• باز گذاشتن پایگاه داده روی اینترنت: پورت‌هایی مثل ۳۳۰۶، ۵۴۳۲، ۶۳۷۹ و ۹۲۰۰ دائماً توسط ربات‌ها اسکن می‌شوند.
• استفاده از CDN بدون مخفی کردن IP واقعی: مهاجم می‌تواند مستقیماً به سرور حمله کند.
• تغییر قوانین بدون مستندسازی: در مواقع اضطراری تشخیص کارکرد هر قانون سخت می‌شود.
• نداشتن برنامه دسترسی پشتیبان: اگر قانون اشتباهی اعمال شود و دسترسی کنسول نباشد، زمان قطعی طولانی می‌شود.

نمونه سیاست فایروال عملی و کاربردی

برای یک سایت شرکتی کوچک، سیاست خلاصه‌ای قابل اجرا به این شکل است: ترافیک ورودی به طور پیش‌فرض بسته است؛ پورت ۴۴۳ برای همه باز است؛ پورت ۸۰ فقط برای هدایت HTTPS باز است؛ SSH فقط از طریق VPN یا آی‌پی ثابت مدیر مجاز است؛ پایگاه داده روی localhost یا شبکه خصوصی است؛ اگر CDN دارید، پورت‌های ۸۰ و ۴۴۳ فقط از رنج IPهای CDN مجازند؛ Fail2ban تلاش‌های ناموفق SSH و ورود وب را پایش می‌کند؛ لاگ‌ها به سامانه مرکزی ارسال می‌شوند.

برای یک فروشگاه آنلاین متوسط، علاوه بر موارد فوق، آی‌پی‌های callback پرداخت مجاز می‌شوند، پنل مدیریت پشت VPN قرار می‌گیرد، محدودیت مصرف برای API کاربری اعمال می‌شود، قوانین WAF برای جلوگیری از SQL Injection و XSS فعال می‌شود و فیلترهای موقتی بر اساس کشور یا ASN برنامه‌ریزی می‌شود. داشتن مستندات این طرح بسیار مهم است؛ در حمله بهتر است طبق روند از پیش تعیین‌شده عمل کنید تا زمان قطعی کاهش یابد.

آزمایش: اطمینان از عملکرد واقعی قوانین

پس از راه‌اندازی فایروال حتماً باید آزمایش انجام دهید. از شبکه‌ای متفاوت اسکن پورت بگیرید، دسترسی SSH را فقط از آی‌پی مجاز تست کنید، سایت را از طریق HTTPS باز کنید، مطمئن شوید پورت پایگاه داده بسته است. اگر CDN دارید، از طریق آدرس IP واقعی سرور درخواست HTTP مستقیم ارسال کنید و مطمئن شوید مسدود شده است.

در فرآیند تست از اسکن‌های پرخطر روی سیستم‌های زنده خودداری کنید. هدف اعتبارسنجی ایمن است.