DDoS Mitigation برای وردپرس چطور انجام می‌شود؟

DDoS Mitigation برای وردپرس مجموعه‌ای از سیاست‌ها، ابزارها و معماری‌هایی است که هدفشان حفظ در دسترس‌پذیری سایت در برابر حملات DDoS (Distributed Denial of Service) است. در این حملات، مهاجم با استفاده از هزاران دستگاه آلوده — که به آن‌ها بات‌نت گفته می‌شود — حجم عظیمی از درخواست‌ها را به سایت ارسال می‌کند تا منابع سرور اشباع شود و کاربران واقعی نتوانند به سایت دسترسی پیدا کنند. وردپرس به‌دلیل معماری مونولیتیک و پویا که برای هر درخواست به PHP و MySQL مراجعه می‌کند، به‌طور ساختاری در برابر حملات لایه ۷ آسیب‌پذیرتر از سایت‌های استاتیک است. آمار صنعتی نشان می‌دهد که یک حمله DDoS معمولی می‌تواند بین چند ساعت تا چند روز ادامه یابد و هزینه متوسط آن برای کسب‌وکارها در سال ۲۰۲۶ به چند صد هزار دلار برسد. این متن مسیر عملی دفاع در برابر DDoS را از لایه شبکه تا لایه برنامه، با تمرکز بر تصمیم‌های معماری و کد قابل اجرا بررسی می‌کند.

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

DDoS دقیقاً چیست و چه انواعی دارد؟

DDoS (Distributed Denial of Service) یک حمله است که در آن مهاجم با استفاده از منابع توزیع‌شده — دستگاه‌های آلوده، سرورهای اجاره‌ای یا حتی سرویس‌های قانونی — حجم عظیمی از ترافیک را به سمت هدف ارسال می‌کند تا سرویس از دسترس خارج شود. تفاوت آن با DoS (Denial of Service) در توزیع‌شدگی است: در DoS مهاجم از یک منبع حمله می‌کند، در حالی که در DDoS از هزاران منبع مستقل استفاده می‌شود که شناسایی و مسدودسازی آن‌ها را دشوار می‌کند.

انواع DDoS را می‌توان در سه دسته اصلی طبقه‌بندی کرد که هر یک لایه‌ای متفاوت از مدل OSI را هدف قرار می‌دهد. دسته اول، حملات لایه شبکه و انتقال (لایه ۳ و ۴) که حجم پهنای باند را اشباع می‌کنند. نمونه‌های آن شامل UDP Flood، SYN Flood و ICMP Flood است. دسته دوم، حملات لایه برنامه (لایه ۷) که منابع سرور را با درخواست‌های به‌ظاهر قانونی اشباع می‌کنند. نمونه‌های آن شامل HTTP Flood، Slowloris و حملات مبتنی بر REST API است. دسته سوم، حملات لایه DNS که رزولوشن دامنه را هدف می‌گیرند و به آن DNS Amplification می‌گویند.

حجم این حملات در سال‌های اخیر به‌طور چشمگیری افزایش یافته است. بر اساس گزارش‌های صنعتی منتشرشده در سال ۲۰۲۶، بزرگ‌ترین حمله ثبت‌شده در این دوره به بیش از ۴ ترابیت بر ثانیه رسیده است. اما نکته مهم این است که حجم بزرگ، تنها معیار خطر نیست. حملات لایه ۷ با حجم چند مگابیت بر ثانیه می‌توانند سایتی با معماری ضعیف را کاملاً از دسترس خارج کنند، در حالی که حمله ۴ ترابیتی ممکن است روی زیرساخت‌های مقاوم بی‌اثر باشد. برای درک مفاهیم پایه این دسته از حملات، مطلب حملات DDoS را بشناسید و خنثی کنید پیش‌نیاز مفیدی است.

DDoS مدرن یک مسئله پهنای باند نیست؛ یک مسئله معماری است که در آن هر درخواست به‌ظاهر قانونی می‌تواند یک ضربه باشد.

چرا وردپرس هدف اصلی حملات DDoS است؟

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

ویژگی اول: معماری پویا و مونولیتیک

وردپرس برای هر درخواست، کد PHP را اجرا می‌کند، به دیتابیس متصل می‌شود و پاسخ را در قالب HTML رندر می‌کند. این معماری در شرایط عادی کارآمد است، اما در برابر حملات لایه ۷ به‌شدت آسیب‌پذیر است. سایت‌های استاتیک می‌توانند هزاران درخواست در ثانیه را از سرویس‌های کش ارائه دهند، در حالی که وردپرس برای هر درخواست حداقل چند میلی‌ثانیه از منابع CPU و دیتابیس را مصرف می‌کند.

ویژگی دوم: نقاط پایانی بدون احراز هویت

وردپرس چندین نقطه پایانی دارد که به‌طور پیش‌فرض بدون احراز هویت در دسترس هستند. فایل wp-login.php، مسیر xmlrpc.php، فایل wp-cron.php و API جست‌وجوی سایت، همگی می‌توانند به‌عنوان بردار حملات لایه ۷ مورد استفاده قرار گیرند. یک مهاجم می‌تواند با ارسال هزاران درخواست به این نقاط، سرور را بدون حتی یک تلاش برای ورود، از دسترس خارج کند.

ویژگی سوم: سهم بازار و اتوماسیون

وردپرس بیش از ۴۳ درصد از وب‌سایت‌های جهان را میزبانی می‌کند. این سهم بازار، آن را به هدفی طبیعی برای ابزارهای خودکار تبدیل کرده است. اکثر حملات DDoS علیه سایت‌های وردپرسی، به‌صورت خودکار و از پیش برنامه‌ریزی‌شده انجام می‌شوند و هدف آن‌ها از پیش انتخاب نشده است. اگر سایت شما یک نقطه پایانی آسیب‌پذیر داشته باشد، احتمالاً در فهرست اهداف قرار می‌گیرد.

در بافت وردپرس، نقطه پایانی xmlrpc.php یکی از پرتکرارترین بردارهای حمله است. این فایل که برای اتصال اپلیکیشن‌های موبایل به سایت استفاده می‌شود، به‌طور پیش‌فرض روش‌های متعددی مانند system.multicall را ارائه می‌دهد که می‌تواند هزاران درخواست را در یک درخواست HTTP ترکیب کند. اگر این فایل غیرفعال نشده باشد، به یک تشدیدکننده حمله (Attack Amplifier) تبدیل می‌شود. برای آشنایی با حملات مشابه در بافت وردپرس، مطلب حملات سایبری رایج علیه وردپرس کدامند؟ را مطالعه کنید.

لایه حمله	هدف	نمونه	روش دفاع اصلی
لایه ۳ و ۴	پهنای باند و پشته شبکه	UDP Flood، SYN Flood	Anycast، Rate Limiting
لایه ۷	CPU، دیتابیس و برنامه	HTTP Flood، Slowloris	WAF، CDN، کش
لایه DNS	رزولوشن دامنه	DNS Amplification	DNSSEC، Anycast DNS

معماری دفاع چندلایه در برابر DDoS

در پروژه‌های واقعی، دفاع موفق در برابر DDoS همیشه چندلایه است. یک لایه واحد، حتی اگر قوی باشد، نمی‌تواند همه انواع حملات را دفع کند. مدل توصیه‌شده، چهار لایه دفاعی دارد که از لبه شبکه تا لایه برنامه کشیده می‌شود.

لایه اول: لبه شبکه و Anycast

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

لایه دوم: CDN و WAF

لایه دوم، ترکیب CDN (Content Delivery Network) و WAF (Web Application Firewall) است. CDN ترافیک را در سرورهای لبه کش می‌کند و بخش زیادی از درخواست‌های تکراری را پیش از رسیدن به سرور اصلی پاسخ می‌دهد. WAF درخواست‌های مشکوک را بر پایه الگوهای رفتاری و امضای حملات شناخته‌شده فیلتر می‌کند.

لایه سوم: کش سرور و Reverse Proxy

لایه سوم، کش سرور است. ابزارهایی مانند Varnish یا Nginx FastCGI Cache می‌توانند کل صفحه را در حافظه سرور کش کنند و درخواست‌های تکراری را بدون مراجعه به PHP و دیتابیس پاسخ دهند. این لایه، ظرفیت سرور را چند برابر می‌کند و در برابر حملات لایه ۷ بسیار مؤثر است.

لایه چهارم: لایه برنامه وردپرس

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

دفاع در لایه شبکه و انتقال

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

مکانیزم Anycast

Anycast یک تکنیک مسیریابی است که در آن یک آدرس IP از چندین نقطه جغرافیایی به‌طور هم‌زمان اعلام می‌شود. بسته‌های مهاجم به نزدیک‌ترین نقطه ارسال می‌شوند و بار حمله بین سرورها توزیع می‌شود. این تکنیک پایه اکثر سرویس‌های Mitigation مدرن است.

Rate Limiting در سطح لبه

در لبه شبکه، ابزارهایی مانند iptables، nftables و XDP (eXpress Data Path) می‌توانند نرخ بسته‌ها را در سطح کرنل لینوکس محدود کنند. این محدودسازی پیش از رسیدن بسته به فضای کاربر انجام می‌شود و بار پردازشی بسیار کمتری دارد.

# محدودسازی نرخ اتصال‌های جدید در iptables
iptables -A INPUT -p tcp --syn -m limit --limit 100/second \
         --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# محدودسازی نرخ درخواست به پورت 443 در سطح IP
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW \
         -m hashlimit --hashlimit-above 50/sec --hashlimit-burst 100 \
         --hashlimit-mode srcip --hashlimit-name https-limit -j DROP

SYN Cookies

در برابر حملات SYN Flood، فعال‌سازی SYN Cookies در کرنل لینوکس یک دفاع مؤثر است. این مکانیزم اجازه می‌دهد سرور در شرایط اشباع جدول SYN، اتصال‌های جدید را بدون نگه‌داشتن وضعیت نیمه‌کامل بپذیرد.

# فعال‌سازی SYN Cookies در لینوکس
sysctl -w net.ipv4.tcp_syncookies=1

# تنظیم صف SYN
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096

# کاهش زمان انتظار برای اتصال‌های نیمه‌کامل
sysctl -w net.ipv4.tcp_synack_retries=2

نقش CDN و WAF در Mitigation

ترکیب CDN و WAF ستون فقرات دفاع لایه ۷ در پروژه‌های وردپرسی است. بدون این لایه، دفاع در برابر حملات HTTP Flood تقریباً غیرممکن است.

CDN: جذب بار و پخش جغرافیایی

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

انتخاب CDN مناسب، یک تصمیم معماری است. سه معیار کلیدی وجود دارد: پوشش جغرافیایی سرورهای لبه، توانایی Mitigation در زمان حمله و پشتیبانی از پروتکل‌های مدرن مانند HTTP/3. در پروژه‌های واقعی، Cloudflare و Fastly از رایج‌ترین گزینه‌ها هستند. برای بررسی عمیق‌تر یک گزینه محبوب، مطلب نقد Cloudflare: آیا لایه امنیتی اول برای هر سایت است؟ را پیشنهاد می‌کنم.

WAF: فیلترینگ هوشمند درخواست‌ها

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

; نمونه قواعد WAF در Cloudflare (ModSecurity syntax)
SecRule REQUEST_URI "@streq /wp-login.php" \
    "id:1001,phase:1,deny,status:403,\
    msg:'Direct access to wp-login blocked'"

SecRule REQUEST_HEADERS:User-Agent "@pm python-requests curl wget" \
    "id:1002,phase:1,pass,setvar:'tx.suspicious_ua=1'"

SecRule TX:suspicious_ua "@eq 1" \
    "id:1003,phase:2,deny,status:403,\
    msg:'Suspicious User-Agent detected'"

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

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

غیرفعال‌سازی نقاط پایانی غیرضروری

نخستین گام، غیرفعال‌سازی نقاط پایانی است که برای کارکرد سایت لازم نیستند. فایل xmlrpc.php در اکثر سایت‌ها غیرضروری است و می‌تواند به یک بردار حمله تشدیدکننده تبدیل شود. همچنین، مسیر wp-cron.php که برای زمان‌بندی وظایف استفاده می‌شود، در زمان حمله می‌تواند بار دیتابیس را چند برابر کند.

// غیرفعال‌سازی کامل xmlrpc.php
add_filter( 'xmlrpc_enabled', '__return_false' );

// حذف هدرهای xmlrpc از پاسخ
add_filter( 'wp_headers', function( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

// غیرفعال‌سازی pingback داخلی
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

// غیرفعال‌سازی wp-cron در درخواست‌های عمومی و جایگزینی با cron سرور
define( 'DISABLE_WP_CRON', true );

نکته مهم در غیرفعال‌سازی wp-cron.php این است که باید یک Cron واقعی در سرور برای اجرای wp-cron.php تعریف شود؛ در غیر این صورت، وظایف زمان‌بندی‌شده وردپرس هرگز اجرا نمی‌شوند.

محدودسازی نقاط پایانی حساس

مسیرهایی مانند wp-login.php و wp-admin/ باید محدود شوند. این محدودسازی می‌تواند از طریق تغییر مسیر، محدودسازی بر اساس IP یا احراز هویت اضافی باشد. روش‌های امنیتی این نقاط در مطلب چرا ورود ادمین وردپرس هدف اصلی هکرهاست و چگونه امنش کنیم؟ به‌طور کامل بررسی شده است.

// محدودسازی wp-login با محدودیت نرخ در سطح برنامه
add_action( 'login_init', function() {
    $ip = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';
    $key = 'wk_login_rate_' . md5( $ip );
    $count = (int) get_transient( $key );

    if ( $count >= 10 ) {
        wp_die( 'تعداد تلاش بیش از حد مجاز است', 'دسترسی مسدود', [ 'response' => 429 ] );
    }

    set_transient( $key, $count + 1, 5 * MINUTE_IN_SECONDS );
} );

محدودسازی نرخ درخواست

محدودسازی نرخ درخواست (Rate Limiting) یکی از مؤثرترین تکنیک‌های دفاع در برابر حملات لایه ۷ است. این تکنیک در سه سطح قابل پیاده‌سازی است: لبه شبکه، CDN و لایه برنامه وردپرس.

محدودسازی در سطح Nginx

در سرورهای Nginx، ماژول limit_req امکان محدودسازی نرخ را به‌صورت بسیار کارآمد فراهم می‌کند. این محدودسازی پیش از رسیدن درخواست به PHP اجرا می‌شود و بار پردازشی کمتری دارد.

# تعریف منطقه محدودسازی در http
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=3r/m;
limit_req_zone $binary_remote_addr zone=wp_api:10m rate=60r/m;

# اعمال روی wp-login.php
location = /wp-login.php {
    limit_req zone=wp_login burst=5 nodelay;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

# اعمال روی REST API
location ~ ^/wp-json/ {
    limit_req zone=wp_api burst=20 nodelay;
    try_files $uri $uri/ /index.php?$args;
}

محدودسازی در سطح برنامه وردپرس

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

add_action( 'init', function() {
    if ( is_admin() || wp_doing_ajax() || wp_doing_cron() ) {
        return;
    }

    $ip = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';
    $key = 'wk_global_rate_' . md5( $ip );
    $count = (int) get_transient( $key );

    if ( $count >= 120 ) {
        status_header( 429 );
        header( 'Retry-After: 60' );
        exit( 'Too Many Requests' );
    }

    set_transient( $key, $count + 1, MINUTE_IN_SECONDS );
}, 1 );

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

استراتژی کش برای جذب بار

کش کردن، مؤثرترین تکنیک برای کاهش بار سرور در زمان حمله است. اگر ۹۰ درصد درخواست‌ها از کش پاسخ داده شوند، حتی حمله‌ای با حجم ۱۰ برابر ظرفیت عادی، تنها ۱۰ درصد آن به دیتابیس و PHP می‌رسد.

ترکیب کش صفحه، شیء و پرس‌وجو

یک استراتژی کش کامل، سه لایه دارد. کش صفحه (Page Cache) که HTML کامل را ذخیره می‌کند و سریع‌ترین پاسخ را می‌دهد. کش شیء (Object Cache) که نتایج کوئری‌های دیتابیس را در Redis یا Memcached ذخیره می‌کند. کش پرس‌وجو (Query Cache) که در سطح دیتابیس عمل می‌کند و در MySQL 8 به بعد با تنظیمات خاص فعال می‌شود.

// فعال‌سازی Object Cache با Redis
// در wp-config.php
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_CACHE', true );

// نمونه کد استفاده از Object Cache در افزونه سفارشی
function wk_get_expensive_data( $id ) {
    $cache_key = 'wk_expensive_' . $id;
    $data      = wp_cache_get( $cache_key, 'wk_group' );

    if ( false === $data ) {
        $data = wk_perform_expensive_query( $id );
        wp_cache_set( $cache_key, $data, 'wk_group', HOUR_IN_SECONDS );
    }

    return $data;
}

کش در لبه CDN

کش در لبه CDN، مؤثرترین لایه کش در زمان حمله است چون درخواست‌ها حتی به سرور شما نمی‌رسند. تنظیم صحیح هدرهای Cache-Control و Vary برای صفحات عمومی، می‌تواند تا ۸۰ درصد ترافیک را از سرور شما دور کند. برای بررسی عمیق‌تر این لایه، مطلب آزمایش تأثیر CDN بر عملکرد سایت چگونه انجام می‌شود؟ داده‌های عملی مفیدی ارائه می‌دهد.

تنظیم سرور برای جذب بار حملات

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

تنظیم PHP-FPM

PHP-FPM مدیریت فرآیندهای PHP را بر عهده دارد. تنظیم نادرست آن می‌تواند در زمان حمله به یک گلوگاه تبدیل شود. سه پارامتر کلیدی عبارت‌اند از pm.max_children، pm.max_requests و request_terminate_timeout.

; تنظیم php-fpm برای جذب بار
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
request_terminate_timeout = 30s
; کاهش زمان اجرای هر درخواست، جذب بار را افزایش می‌دهد

تنظیم MySQL

دیتابیس معمولاً اولین گلوگاه در زمان حمله است. سه تنظیم کلیدی می‌تواند ظرفیت آن را چند برابر کند: افزایش اندازه innodb_buffer_pool_size، کاهش max_connections به میزان واقعی، و فعال‌سازی query_cache (در نسخه‌های قدیمی). همچنین wait_timeout باید کاهش یابد تا اتصال‌های بلااستفاده سریعاً آزاد شوند.

; تنظیم MySQL برای جذب بار
[mysqld]
innodb_buffer_pool_size = 2G
max_connections = 200
wait_timeout = 60
interactive_timeout = 60
max_allowed_packet = 64M
tmp_table_size = 64M
max_heap_table_size = 64M

تنظیم کرنل لینوکس

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

# افزایش ظرفیت صف اتصال‌ها
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

# کاهش زمان انتظار برای بستن اتصال‌های نیمه‌کامل
sysctl -w net.ipv4.tcp_fin_timeout=15
sysctl -w net.ipv4.tcp_tw_reuse=1

# افزایش محدوده پورت‌های محلی
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# محدودسازی نرخ بسته‌های ICMP
sysctl -w net.ipv4.icmp_ratelimit=100
sysctl -w net.ipv4.icmp_ratemask=88089

پاسخ به حادثه در زمان حمله فعال

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

گام اول: تشخیص حمله واقعی از مشکل سرور

نخستین گام، تشخیص این است که آیا مشکل از حمله DDoS است یا از یک خطای سرور. سه شاخص کلیدی وجود دارد: افزایش ناگهانی ترافیک ورودی بدون افزایش مشابه در تبدیل‌ها، افزایش نرخ خطای ۴xx و ۵xx در لاگ سرور، و افزایش غیرعادی بار CPU و اتصال‌های دیتابیس.

گام دوم: فعال‌سازی حالت Under Attack

اکثر CDNها و WAFهای مدرن، یک حالت ویژه به نام «Under Attack Mode» دارند که چالش JavaScript را برای همه بازدیدکنندگان فعال می‌کند. این حالت، ترافیک خودکار بات‌ها را مسدود می‌کند و تنها کاربران واقعی مرورگر می‌توانند عبور کنند.

گام سوم: تحلیل سریع الگوی حمله

در زمان حمله، تحلیل سریع الگوهای حمله حیاتی است. سه پرسش کلیدی باید پاسخ داده شوند: حمله از چه لایه‌ای انجام می‌شود (۳، ۴، ۷ یا DNS)؟ حمله از چه جغرافیایی می‌آید؟ و کدام نقاط پایانی سایت بیشترین فشار را دریافت می‌کنند؟ پاسخ این پرسش‌ها، مسیر پاسخ را مشخص می‌کند.

گام چهارم: اجرای پاسخ هدفمند

پس از تشخیص، پاسخ باید هدفمند باشد. اگر حمله از یک جغرافیای خاص می‌آید، محدودسازی جغرافیایی (Geo-blocking) مؤثر است. اگر حمله روی یک نقطه پایانی خاص متمرکز است، محدودسازی نرخ اختصاصی برای آن نقطه مفید است. اگر حمله ترکیبی است، فعال‌سازی حالت Under Attack و افزایش آستانه محدودسازی نرخ ضروری است.

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

اشتباهات رایج در Mitigation

در بررسی پروژه‌های متعدد، الگوهای تکرارشونده زیر پرتکرارترین خطاها در Mitigation حملات DDoS بوده‌اند.

اتکا به یک لایه دفاعی بدون پیاده‌سازی معماری چندلایه.
فعال‌سازی حالت Under Attack بدون پایش دقیق که منجر به مسدودسازی کاربران واقعی می‌شود.
نبود محدودسازی نرخ روی نقاط پایانی حساس مانند wp-login.php و xmlrpc.php.
فعال‌سازی کش در زمان حمله بدون تنظیم صحیح هدرها که منجر به نمایش محتوای اشتباه می‌شود.
نبود برنامه پاسخ به حادثه و واکنش شتاب‌زده در زمان حمله.
تغییرات ناگهانی در تنظیمات سرور در زمان حمله که خود می‌تواند مشکل جدید ایجاد کند.
نادیده گرفتن لاگ‌گیری و از دست دادن شواهد حمله.
محدودسازی نرخ بر پایه یک معیار واحد که در برابر حملات توزیع‌شده بی‌اثر است.
فعال‌سازی Geo-blocking بدون در نظر گرفتن کاربران واقعی منطقه.
نبود تست دوره‌ای مقاومت سایت با ابزارهای Load Testing.

هر یک از این خطاها به‌تنهایی می‌تواند در زمان حمله، اثر مخرب داشته باشد. اگر می‌خواهید سطح کلی امنیت سایت خود را ارزیابی کنید، مطلب تست امنیت وب‌سایت چگونه انجام می‌شود و از کجا باید شروع کرد؟ راهنمای مناسبی است.

پرسش‌های پرتکرار درباره DDoS Mitigation

در ادامه به پرسش‌هایی پاسخ می‌دهیم که بیشترین جستجو و بازخورد کاربران در ارتباط با DDoS Mitigation داشته‌اند.

آیا CDN به‌تنهایی برای دفاع در برابر DDoS کافی است؟

CDN بخش عمده‌ای از دفاع را فراهم می‌کند، اما به‌تنهایی کافی نیست. CDN در برابر حملات حجمی و حملات لایه ۷ نسبتاً مؤثر است، اما بدون لایه WAF و محدودسازی نرخ در سطح برنامه، حملات هوشمندانه‌تر می‌توانند از آن عبور کنند. معماری توصیه‌شده، ترکیب CDN و WAF و کش محلی و محدودسازی نرخ است.

آیا استفاده از Cloudflare رایگان برای دفاع کافی است؟

پلن رایگان Cloudflare برای سایت‌های کوچک و متوسط دفاع مناسبی فراهم می‌کند، اما در حملات حجمی بزرگ و پیچیده، محدودیت‌هایی دارد. برای سایت‌های تجاری با ترافیک بالا و نیاز به Mitigation پیشرفته، پلن‌های بالاتر با SLA تضمین‌شده و پشتیبانی ۲۴ ساعته توصیه می‌شود.

آیا محدودسازی نرخ در سطح وردپرس کافی است؟

محدودسازی نرخ در سطح وردپرس مفید است اما کافی نیست، چون در زمان حمله، درخواست‌ها به PHP می‌رسند و بار سرور را مصرف می‌کنند. محدودسازی نرخ باید در لایه‌های پایین‌تر (Nginx، CDN و WAF) نیز فعال باشد تا درخواست‌ها پیش از رسیدن به PHP مسدود شوند.

چرا حمله DDoS لایه ۷ خطرناک‌تر از حمله لایه ۴ است؟

حملات لایه ۴ حجم پهنای باند را اشباع می‌کنند و شناسایی آن‌ها ساده است. اما حملات لایه ۷ از درخواست‌های به‌ظاهر قانونی استفاده می‌کنند که از فیلترهای معمولی عبور می‌کنند و منابع سرور را مستقیماً هدف می‌گیرند. شناسایی این حملات نیازمند تحلیل رفتاری است و دفاع در برابر آن‌ها پیچیده‌تر است. برای آشنایی با تکنیک‌های دفاعی مرتبط، مطلب حمله DDoS چیست و چگونه دفع می‌شود؟ را مطالعه کنید.

آیا DDoS می‌تواند باعث از دست رفتن داده شود؟

DDoS به‌خودی‌خود باعث از دست رفتن داده نمی‌شود، چون هدف آن از دسترس خارج کردن سرویس است، نه دستکاری داده. اما در شرایطی که حمله با یک سوءاستفاده دیگر ترکیب شود، می‌تواند به از دست رفتن داده منجر شود. به‌عنوان مثال، اگر حمله DDoS به‌عنوان پوشش برای یک حمله نفوذ استفاده شود، ممکن است مهاجم در سایه آن به دیتابیس دسترسی پیدا کند. به همین دلیل، دفاع در برابر DDoS باید بخشی از یک استراتژی امنیتی کامل باشد.

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

چهار نشانه کلیدی وجود دارد: افت ناگهانی سرعت سایت بدون تغییر در محتوا، افزایش نرخ خطای ۵xx در لاگ سرور، افزایش غیرعادی مصرف CPU و پهنای باند، و افزایش اتصال‌های دیتابیس. اگر این نشانه‌ها هم‌زمان ظاهر شوند، احتمال حمله DDoS بالاست. ابزارهای مانیتورینگ مانند Uptime Robot و Pingdom می‌توانند در تشخیص سریع کمک کنند. برای آشنایی با تحلیل لاگ، مطلب چگونه خطاهای سرور را در لاگ‌ها بررسی کنیم؟ راهنمای خوبی است.

آیا DDoS تنها سایت‌های بزرگ را هدف می‌گیرد؟

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

آیا استفاده از HTTPS در برابر DDoS کمک می‌کند؟

HTTPS به‌طور مستقیم در برابر DDoS محافظت نمی‌کند، اما ترکیب آن با پروتکل‌های مدرن مانند HTTP/3 و QUIC می‌تواند تحمل سرور را در برابر برخی حملات افزایش دهد. همچنین HTTPS بخشی از زنجیره امنیت سایت است که در ترکیب با لایه‌های دیگر، مقاومت کلی را بالا می‌برد. اگر با اصول HTTPS آشنا نیستید، مطلب HTTPS چیست و چه تفاوتی با HTTP دارد؟ را پیشنهاد می‌کنم.

نگاهی در سطح معماری توزیع‌شده

در سطح مهندسی ارشد، Mitigation DDoS بخشی از یک معماری امنیتی توزیع‌شده است که در سازمان‌های بالغ با عنوان Resilient Architecture شناخته می‌شود. این معماری سه محدودیت ساختاری در بافت وردپرس دارد که باید صادقانه پذیرفته شوند.

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

محدودیت دوم، نبود قابلیت Autoscaling در معماری سنتی وردپرس است. سایت‌های وردپرسی معمولاً روی یک سرور واحد یا یک خوشه محدود اجرا می‌شوند که در زمان حمله نمی‌تواند به‌سرعت مقیاس‌پذیر شود. در معماری‌های مدرن، راه‌حل این محدودیت، ترکیب CDN با سرورهای لبه و اجرای وردپرس روی زیرساخت Kubernetes است که می‌تواند در زمان حمله به‌صورت خودکار Podهای جدید اضافه کند. این رویکرد نیازمند بازنویسی کامل استقرار وردپرس است، اما سطح مقاومت را چند برابر می‌کند. اگر با معماری Kubernetes آشنا نیستید، مطلب آموزش Kubernetes برای مبتدیان نقطه شروع خوبی است.

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

در سطح پیاده‌سازی پیشرفته، توصیه می‌شود Mitigation DDoS را به‌عنوان یک ماژول مستقل از معماری سایت طراحی کنید که سه جزء دارد: لایه تشخیص (مانیتورینگ و هشدار)، لایه جذب (CDN و کش توزیع‌شده) و لایه فیلترینگ (WAF و Rate Limiting). این تفکیک، آزمون‌پذیری را بالا می‌برد و امکان جایگزینی هر لایه را بدون بازنویسی کل سیستم فراهم می‌کند. اگر پروژه شما در سطح سازمانی است، ترکیب این لایه‌ها با اصول Zero Trust در لایه شبکه می‌تواند سطح مقاومت را به‌طور چشمگیری بالا ببرد. برای تکمیل این تصویر، مطلب چگونه امنیت سرور را افزایش دهیم؟ را مطالعه کنید.

DDoS یک نبرد تسلیحات است؛ هر لایه دفاعی که اضافه می‌کنید، مهاجم را مجبور می‌کند به منابع بیشتری برای شکستن آن متوسل شود.

بستن این مسیر

DDoS Mitigation برای وردپرس یک مسئله معماری است، نه یک افزونه یا یک تنظیم. برخلاف تصور رایج، دفاع موفق در برابر این حملات نیازمند ترکیب چندلایه است: لبه شبکه، CDN، WAF، کش محلی و محدودسازی نرخ در سطح برنامه. هر لایه به‌تنهایی ناقص است، اما در ترکیب با لایه‌های دیگر، یک ساختار دفاعی مقاوم می‌سازد که در برابر حملات پیچیده مقاومت می‌کند. اگر امروز تنها یک گام بردارید، بگذارید آن گام فعال‌سازی محدودسازی نرخ روی نقاط پایانی حساس مانند wp-login.php و xmlrpc.php باشد؛ چون این گام، ارزان‌ترین و مؤثرترین دفاع اولیه محسوب می‌شود. 🛡️

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