حملات DDoS و محافظت از سرور مجازی و اختصاصی: راهنمای تشخیص، مقابله و انتخاب پلن مناسب

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

این راهنما سه بخش دارد: حمله DDoS چیست و چه شکل‌هایی دارد، چطور در لینوکس تشخیص و تا حدی مقابله کنیم، و هنگام خرید یا ارتقای سرور چه معیارهایی برای محافظت DDoS را بررسی کنیم.

حمله DDoS چیست و چرا سرور مجازی و اختصاصی هدف می‌شوند؟

DDoS (Distributed Denial of Service) یعنی ارسال حجم بالای ترافیک یا درخواست از چندین منبع هم‌زمان به یک هدف، با این نیت که منابع سرور (پهنای باند، CPU، حافظه یا تعداد اتصالات باز) تمام شود و سرویس برای کاربران واقعی از کار بیفتد.

سرورهای مجازی و اختصاصی هر دو هدف این حملات قرار می‌گیرند، اما دلیل متفاوت است:

• سرورهای مجازی معمولاً روی یک هاست فیزیکی مشترک با چند مشتری دیگر اجرا می‌شوند؛ حمله به یک IP می‌تواند پهنای باند یا منابع شبکه‌ای مشترک را هم تحت فشار بگذارد.
• سرورهای اختصاصی پهنای باند و سخت‌افزار جداگانه دارند، اما همین که uplink اختصاصی اشباع شود، کل سرور از دسترس خارج می‌شود، حتی اگر CPU بیکار باشد.

در هر دو حالت، نقطه شکست معمولاً پهنای باند ورودی به دیتاسنتر است، نه فقط منابع خود سرور. به همین دلیل مقابله واقعی با حملات حجیم باید در سطح شبکه دیتاسنتر و بالادست اتفاق بیفتد، و تنظیمات روی خود سرور بیشتر برای حملات کوچک‌تر و لایه اپلیکیشن مؤثر است.

انواع رایج حملات DDoS

برای انتخاب روش مقابله درست، باید دانست حمله در کدام لایه اتفاق می‌افتد.

حملات حجمی (Volumetric)

هدف این حملات اشباع پهنای باند است، نه خود سرور. نمونه‌ها: UDP flood، ICMP flood و حملات تقویت‌شده (amplification) مثل DNS یا NTP reflection. ترافیک می‌تواند به چند ده یا چند صد گیگابیت بر ثانیه برسد؛ در این مقیاس، هیچ تنظیم نرم‌افزاری روی خود سرور کافی نیست و باید در سطح شبکه بالادست فیلتر شود.

حملات پروتکلی (Protocol)

این دسته منابع شبکه مثل جدول اتصالات یا فایروال را هدف می‌گیرد. رایج‌ترین نمونه SYN flood است: مهاجم تعداد زیادی درخواست باز کردن اتصال TCP می‌فرستد بدون تکمیل handshake، تا صف نیمه‌باز سرور پر شود و اتصالات واقعی رد شوند.

حملات لایه اپلیکیشن (Layer 7)

این حملات شبیه ترافیک واقعی کاربر هستند؛ مثلاً درخواست‌های HTTP زیاد به یک صفحه سنگین (جستجو، لاگین، API). چون حجم هر درخواست کم است، از دید پهنای باند طبیعی به نظر می‌رسد، اما CPU و منابع برنامه یا پایگاه‌داده را می‌خورد. این نوع حمله معمولاً با فایروال شبکه معمولی قابل تشخیص نیست و نیاز به تحلیل در سطح وب‌سرور یا WAF دارد.

چطور بفهمیم سرور زیر حمله DDoS است؟

قبل از هر اقدام مقابله‌ای باید تشخیص درست داد؛ کندی سرور همیشه نتیجه حمله نیست و می‌تواند ناشی از بار واقعی، یک query سنگین یا نشتی حافظه باشد. چند دستور ساده در لینوکس تصویر اولیه خوبی می‌دهد:

ss -s                      # تعداد کل اتصالات و وضعیت‌ها
ss -ntp state syn-recv | wc -l   # تعداد اتصالات نیمه‌باز (نشانه SYN flood)
vnstat -l                  # ترافیک لحظه‌ای ورودی/خروجی
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

خط آخر تعداد اتصالات را بر اساس IP مبدا می‌شمارد. اگر چند IP (یا یک بازه IP) سهم نامتناسبی از اتصالات را دارند، این خودش یک نشانه قوی است. در لاگ کرنل (dmesg یا /var/log/kern.log) پیام‌هایی مثل TCP: request_sock_TCP: Possible SYN flooding هم مستقیماً به SYN flood اشاره می‌کند.

برای حمله لایه اپلیکیشن، لاگ وب‌سرور نقطه شروع بهتری است:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

اگر یک آدرس یا الگوی User-Agent با فاصله زمانی غیرطبیعی یکسان، حجم زیادی از درخواست‌ها را تولید کرده باشد، احتمال ترافیک خودکار بالاست.

اقدامات مقابله‌ای در سطح لینوکس

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

فعال کردن SYN cookies برای مقابله با SYN flood:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=2

این مقادیر برای ماندگاری باید در /etc/sysctl.conf هم ثبت شوند؛ برای سایر تنظیمات شبکه سطح کرنل در کنار همین پارامترها، بهینه‌سازی شبکه سرور لینوکس با TCP BBR و sysctl را هم ببینید.

محدود کردن نرخ اتصال جدید با nftables یا iptables:

iptables -A INPUT -p tcp --syn -m limit --limit 50/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

این قانون تعداد اتصالات TCP جدید در ثانیه را سقف می‌زند و ترافیک اضافه را drop می‌کند، بدون این‌که اتصالات موجود و معتبر قطع شوند. برای مهاجرت کامل‌تر از iptables و تنظیم قوانین پیشرفته‌تر، راه‌اندازی فایروال nftables روی سرور لینوکس را ببینید.

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

محدود کردن نرخ درخواست در nginx برای لایه اپلیکیشن:

limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
limit_req zone=req_limit burst=20 nodelay;

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

تفاوت محافظت DDoS در سرور مجازی و سرور اختصاصی

انتخاب بین سرور مجازی و اختصاصی روی نوع محافظتی که عملاً دریافت می‌کنید اثر می‌گذارد:

• در سرور مجازی، معمولاً فیلترینگ ترافیک حجیم در سطح شبکه ارائه‌دهنده (قبل از رسیدن به هایپروایزر) انجام می‌شود، چون چند مشتری روی یک زیرساخت مشترک هستند و یک حمله به یکی می‌تواند بقیه را هم تحت تأثیر بگذارد. این یعنی ارائه‌دهنده انگیزه مستقیم دارد که ترافیک مخرب را زودتر فیلتر کند.
• در سرور اختصاصی، پهنای باند و سخت‌افزار مجزاست؛ محافظت در برابر حملات حجیم باید به‌صورت صریح بخشی از پلن یا یک سرویس اضافه (مثل اسکرابینگ ترافیک یا قرار گرفتن پشت CDN/Load Balancer) باشد، چون جداسازی فیزیکی خودبه‌خود فیلترینگ شبکه ایجاد نمی‌کند.

جدول مقایسه سطح محافظت DDoS در پلن‌های مختلف

ویژگی	VPS بدون محافظت اضافه	VPS با محافظت DDoS	سرور اختصاصی + CDN/Load Balancer
فیلترینگ ترافیک حجمی	معمولاً فقط در حد پایه شبکه	در سطح upstream، پیش از رسیدن به سرور	در سطح لایه CDN/WAF، پیش از رسیدن به سرور
محافظت لایه اپلیکیشن (L7)	نیاز به تنظیم دستی (nginx، fail2ban)	بخشی پایه + همچنان نیاز به تنظیم اپلیکیشن	توسط WAF/CDN انجام می‌شود
اثر روی سرعت ترافیک عادی	بدون تأخیر اضافه	تأخیر کم، قابل چشم‌پوشی	وابسته به مسیر CDN، معمولاً قابل قبول
مناسب برای	پروژه‌های آزمایشی، ترافیک کم‌ریسک	سایت و سرویس‌های عمومی با ریسک حمله متوسط	سرویس‌های پرترافیک، API عمومی، زیرساخت حساس

این جدول نقطه شروع است، نه قانون قطعی؛ جزئیات دقیق هر پلن را باید از صفحه محصول یا پشتیبانی ارائه‌دهنده گرفت، چون نحوه پیاده‌سازی بین ارائه‌دهنده‌ها فرق دارد.

نکات انتخاب پلن سرور با محافظت DDoS مناسب

هنگام خرید یا ارتقای سرور، این موارد را از ارائه‌دهنده بپرسید:

• ظرفیت فیلترینگ در سطح شبکه: آیا ترافیک حجیم پیش از رسیدن به سرور فیلتر می‌شود یا فقط در خود سرور باید مدیریت شود؟
• سیاست null-routing: در حملات بسیار بزرگ، برخی ارائه‌دهندگان به‌صورت موقت IP را null-route می‌کنند تا شبکه‌شان پایدار بماند؛ بدانید این سیاست چه زمانی فعال می‌شود و چقدر طول می‌کشد.
• پوشش لایه اپلیکیشن: محافظت شبکه‌ای صرفاً حملات حجمی و پروتکلی را پوشش می‌دهد؛ برای لایه ۷ به WAF یا rate limiting در سطح اپلیکیشن نیاز دارید.
• زمان پاسخ پشتیبانی: در لحظه حمله، سرعت پاسخ تیم پشتیبانی برای شناسایی و فیلتر ترافیک اهمیت زیادی دارد.
• هزینه و محدودیت ترافیک: برخی پلن‌ها محافظت DDoS را به‌صورت رایگان تا یک سقف مشخص ارائه می‌دهند و فراتر از آن هزینه جداگانه دارد؛ این سقف را پیش از خرید بررسی کنید.

جمع‌بندی

محافظت DDoS سرور مجازی یا اختصاصی یک اقدام تک‌مرحله‌ای نیست؛ ترکیبی از تشخیص درست در سطح سرور، تنظیمات لینوکس برای حملات کوچک، و پلن سروری است که در سطح شبکه از ترافیک حجیم محافظت می‌کند. تنظیمات محلی مثل SYN cookies، محدودسازی نرخ اتصال و fail2ban برای حملات کوچک تا متوسط مؤثرند، اما در برابر حملات حجیم، نوع پلن و زیرساخت شبکه ارائه‌دهنده نقش تعیین‌کننده‌تری دارد. محافظت DDoS یک بخش از امنیت سرور است؛ برای تصویر کامل‌تر افزایش امنیت سرور لینوکس را هم مطالعه کنید.

اگر در حال انتخاب یا ارتقای سرور برای سرویسی هستید که باید در برابر این نوع حملات پایدار بماند، پلن‌های سرور مجازی آریانت را بررسی کنید؛ برای پروژه‌هایی که به منابع اختصاصی و پهنای باند جداگانه نیاز دارند، سرور اختصاصی آریانت گزینه مناسب‌تری است.