Rate Limiting در وردپرس چطور از حملات جلوگیری می‌کند؟

Rate Limiting (محدودسازی نرخ) در وردپرس یک تکنیک دفاعی است که تعداد درخواست‌های ارسالی از یک IP، یک کاربر، یا یک Endpoint را در بازه زمانی مشخص محدود می‌کند و از حملات Brute Force (نیروی خام)، Credential Stuffing (پرکردن اعتبارنامه)، DDoS (Distributed Denial of Service)، و Scraping (خزش محتوا) جلوگیری می‌نماید. برخلاف Firewall که بر پایه محتوای درخواست تصمیم می‌گیرد، Rate Limiting بر پایه فرکانس و نرخ تصمیم می‌گیرد و به همین دلیل، لایه‌ای مستقل از محتوا فراهم می‌کند که برای دفاع در برابر حملات حجمی حیاتی است. پیاده‌سازی Rate Limiting در وردپرس سه سطح دارد: سطح سرور با Nginx یا Apache، سطح لبه با CDN، و سطح Application با کد PHP. بدون Rate Limiting، یک ربات ساده می‌تواند در چند دقیقه هزاران تلاش ورود انجام دهد و منابع سرور را مصرف کند. این مقاله چارچوب کامل پیاده‌سازی Rate Limiting در وردپرس را از سطح سرور تا Application ارائه می‌دهد.

در یک پروژه، سرور یک سایت وردپرسی بعد از یک هفته از راه‌اندازی، با Load Average بالای ۲۰ مواجه شد. تحلیل لاگ‌ها نشان داد یک IP واحد، روزانه ۸۰۰,۰۰۰ درخواست به /wp-login.php ارسال می‌کند. بعد از پیاده‌سازی Rate Limiting در Nginx با محدودیت ۵ درخواست در دقیقه، همان IP در کمتر از یک ساعت مسدود شد و Load Average به زیر ۱ بازگشت. این تجربه، تفاوت بین یک سایت در معرض حمله و یک سایت مقاوم را نشان داد.

Rate Limiting چیست و چرا ضروری است؟

Rate Limiting (محدودسازی نرخ) یک تکنیک کنترلی است که تعداد درخواست‌های مجاز از یک منبع مشخص را در بازه زمانی معین محدود می‌کند. منبع می‌تواند یک IP، یک کاربر احراز هویت‌شده، یک API Key، یا یک Endpoint مشخص باشد. بازه زمانی می‌تواند ثانیه، دقیقه، ساعت، یا روز باشد.

ضرورت Rate Limiting برای سایت‌های وردپرسی از چند جهت قابل تحلیل است. اول، حفاظت از منابع: هر درخواست، یک چرخه PHP و MySQL را اجرا می‌کند. اگر نرخ درخواست از ظرفیت سرور بیشتر شود، سایت کند می‌شود یا از کار می‌افتد. دوم، دفاع در برابر Brute Force: حملات Brute Force با ارسال هزاران تلاش ورود در دقیقه، رمز عبور را حدس می‌زنند. اگر با دفع حملات Brute Force در وردپرس آشنا شده باشید، می‌دانید که Rate Limiting مؤثرترین دفاع است. سوم، کاهش بار CDN: اگر سایت روی CDN باشد، ترافیک اضافی هزینه مستقیم دارد. چهارم، حفاظت از API: اگر سایت REST API یا GraphQL دارد، Rate Limiting از سوءاستفاده جلوگیری می‌کند.

«Rate Limiting یک محدودیت نیست، یک محافظ است: به کاربران واقعی اجازه می‌دهد از سایت استفاده کنند، در حالی که ربات‌های مخرب را در بیرون نگه می‌دارد.»

اگر با Bot Management در وردپرس و ضرورت آن آشنا شده باشید، می‌دانید که Rate Limiting یکی از لایه‌های کلیدی Bot Management است. اگر با حمله DDoS و روش‌های دفع آن آشنا شده باشید، می‌دانید که Rate Limiting برای حملات لایه ۷ حیاتی است.

نوع حمله	بدون Rate Limiting	با Rate Limiting
Brute Force	هزاران تلاش در دقیقه	۵ تلاش در دقیقه
Credential Stuffing	میلیون‌ها ترکیب	محدود به نرخ
DDoS لایه ۷	سرور از کار می‌افتد	ترافیک فیلتر می‌شود
Scraping	کل محتوا کپی می‌شود	نرخ خزش محدود
API Abuse	مصرف بی‌رویه منابع	سهمیه هر API Key

حملات رایج که Rate Limiting دفع می‌کند

Rate Limiting پنج دسته اصلی از حملات را دفع می‌کند که هرکدام الگوی متفاوتی دارند:

دسته اول: Brute Force. در این حمله، مهاجم با ارسال هزاران ترکیب نام کاربری و رمز عبور، سعی می‌کند وارد پنل مدیریت شود. ربات‌های Brute Force معمولاً نرخ بالایی دارند (صدها درخواست در دقیقه) و از IPهای مختلف استفاده می‌کنند. اگر با امن‌سازی ورود ادمین وردپرس آشنا شده باشید، می‌دانید که Rate Limiting اولین لایه دفاع است.

دسته دوم: Credential Stuffing. در این حمله، مهاجم از لیست‌های لو رفته (مثل لیست‌های RockYou) استفاده می‌کند و ترکیب‌های ایمیل/رمز را روی سایت‌های مختلف امتحان می‌کند. این حمله از Brute Force خطرناک‌تر است چون از رمزهای واقعی استفاده می‌کند و ممکن است موفق شود.

دسته سوم: DDoS لایه ۷. در این حمله، هزاران ربات (Botnet) به‌طور همزمان درخواست ارسال می‌کنند تا سرور را از کار بیندازند. Rate Limiting در سطح IP به‌تنهایی کافی نیست چون هر ربات نرخ پایینی دارد. راه‌حل، Rate Limiting در سطح Endpoint و استفاده از CDN است.

دسته چهارم: Scraping. در این حمله، یک ربات تمام محتوای سایت را کپی می‌کند. اگر نرخ خزش بالا باشد، منابع سرور مصرف می‌شوند و محتوا در سایت‌های دیگر بازنشر می‌گردد. Rate Limiting نرخ خزش را محدود می‌کند.

دسته پنجم: API Abuse. اگر سایت REST API یا GraphQL دارد، مهاجم می‌تواند از API برای استخراج داده یا مصرف منابع استفاده کند. Rate Limiting بر پایه API Key یا IP، این سوءاستفاده را محدود می‌کند. اگر با امنیت API در وب آشنا شده باشید، می‌دانید که Rate Limiting بخشی از استراتژی امنیت API است.

الگوریتم‌های Rate Limiting

چهار الگوریتم اصلی برای Rate Limiting وجود دارد که هرکدام خواص متفاوتی دارند. انتخاب الگوریتم مناسب، تعادل بین دقت و کارایی را تعیین می‌کند.

الگوریتم اول: Fixed Window. در این الگوریتم، زمان به پنجره‌های ثابت تقسیم می‌شود (مثلاً هر دقیقه) و در هر پنجره، تعداد مشخصی درخواست مجاز است:

# Nginx Fixed Window
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m;

مزیت این الگوریتم، سادگی و کارایی بالا است. عیب آن، Burst Problem است: اگر محدودیت ۱۰۰ درخواست در دقیقه باشد، کاربر می‌تواند ۱۰۰ درخواست در ثانیه ۵۹ و ۱۰۰ درخواست در ثانیه ۶۱ ارسال کند که در عمل ۲۰۰ درخواست در ۲ ثانیه است.

الگوریتم دوم: Sliding Window. در این الگوریتم، پنجره به‌طور مستمر حرکت می‌کند و نرخ بر پایه بازه‌های لغزان محاسبه می‌شود. این الگوریتم، Burst Problem را حل می‌کند اما پیچیدگی محاسباتی بالاتری دارد.

الگوریتم سوم: Token Bucket. در این الگوریتم، هر کاربر یک سطل توکن دارد. هر درخواست، یک توکن مصرف می‌کند و توکن‌ها با نرخ مشخصی پر می‌شوند:

# Nginx Token Bucket (با burst)
limit_req zone=api burst=20 nodelay;

مزیت این الگوریتم، اجازه Burst کنترل‌شده است: اگر کاربر مدتی غیرفعال بوده، می‌تواند چند درخواست سریع ارسال کند.

الگوریتم چهارم: Leaky Bucket. در این الگوریتم، درخواست‌ها در یک صف قرار می‌گیرند و با نرخ ثابت پردازش می‌شوند. اگر صف پر شود، درخواست‌های جدید رد می‌شوند. این الگوریتم، نرخ خروجی را کاملاً یکنواخت می‌کند.

الگوریتم	دقت	پیچیدگی	Burst
Fixed Window	پایین	پایین	مشکل‌ساز
Sliding Window	بالا	متوسط	حل شده
Token Bucket	بالا	متوسط	کنترل‌شده
Leaky Bucket	بالا	بالا	یکنواخت

Rate Limiting در سطح سرور

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

سه سطح Rate Limiting در سرور وجود دارد. سطح اول، Kernel Level با iptables یا nftables. این سطح، سریع‌ترین است اما انعطاف‌پذیری کمی دارد. سطح دوم، Web Server Level با Nginx یا Apache. این سطح، انعطاف‌پذیری بالایی دارد و می‌تواند بر پایه URL تصمیم بگیرد. سطح سوم، Application Level که در بخش بعدی بررسی می‌شود.

«Rate Limiting در سطح سرور، هزینه‌ای نزدیک به صفر دارد اما اثربخشی آن، بالاترین در بین سه سطح است.»

پیکربندی Nginx برای وردپرس

Nginx یکی از قدرتمندترین ابزارهای Rate Limiting است که با ماژول ngx_http_limit_req_module کار می‌کند. این ماژول، بر پایه الگوریتم Leaky Bucket کار می‌کند و سه پارامتر اصلی دارد: zone، rate، و burst.

پیکربندی پایه برای یک سایت وردپرسی:

http {
    # Zone برای ترافیک عمومی
    limit_req_zone $binary_remote_addr zone=general:10m rate=30r/s;
    
    # Zone برای صفحه ورود
    limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
    
    # Zone برای REST API
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    
    # Zone برای XML-RPC
    limit_req_zone $binary_remote_addr zone=xmlrpc:10m rate=1r/s;

    server {
        # ترافیک عمومی
        location / {
            limit_req zone=general burst=60 nodelay;
            limit_req_status 429;
            try_files $uri $uri/ /index.php?$args;
        }
        
        # صفحه ورود
        location = /wp-login.php {
            limit_req zone=login burst=3 nodelay;
            limit_req_status 429;
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        }
        
        # REST API
        location ~ ^/wp-json/ {
            limit_req zone=api burst=20 nodelay;
            limit_req_status 429;
            try_files $uri $uri/ /index.php?$args;
        }
        
        # XML-RPC
        location = /xmlrpc.php {
            limit_req zone=xmlrpc burst=2 nodelay;
            limit_req_status 429;
            deny all;
        }
    }
}

توضیح پارامترها:

Zone: نام و اندازه حافظه اشتراکی. 10m حدود ۱۶۰,۰۰۰ IP را نگه می‌دارد.
Rate: نرخ مجاز. 30r/s یعنی ۳۰ درخواست در ثانیه.
Burst: تعداد درخواست‌های اضافی که در صف قرار می‌گیرند. burst=60 یعنی ۶۰ درخواست اضافی مجاز است.
nodelay: درخواست‌های Burst فوراً پردازش می‌شوند، نه با تأخیر.
limit_req_status: کد وضعیت HTTP در صورت عبور از محدودیت. 429 استاندارد است.

برای لاگ کردن Rate Limitها، از Log Format سفارشی استفاده کنید:

log_format rate_limit '$remote_addr - $status - $request - $limit_req_status';
access_log /var/log/nginx/rate_limit.log rate_limit;

اگر با تقویت امنیت وردپرس گام‌به‌گام آشنا شده باشید، این پیکربندی بخشی از سخت‌سازی سرور است.

محدودسازی بر اساس Endpoint

هر Endpoint وردپرس نیاز به Rate Limiting متفاوتی دارد:

Endpoint	نرخ توصیه‌شده	Burst
صفحات عمومی	۳۰r/s	۶۰
/wp-login.php	۱r/s	۳
/wp-json/	۱۰r/s	۲۰
/xmlrpc.php	۱r/s	۲
/wp-admin/admin-ajax.php	۵r/s	۱۰
فایل‌های استاتیک	بدون محدودیت	—

پیکربندی Apache و ModSecurity

Apache نیز از Rate Limiting پشتیبانی می‌کند اما با ابزارهای متفاوت. سه رویکرد اصلی:

رویکرد اول: mod_ratelimit. این ماژول، پهنای باند را محدود می‌کند، نه تعداد درخواست:

<Location /wp-content/uploads/>
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
</Location>

رویکرد دوم: mod_evasive. این ماژول، نرخ درخواست را محدود می‌کند و IPهای مشکوک را مسدود می‌نماید:

<IfModule mod_evasive20.c>
    DOSHashTableSize 3097
    DOSPageCount 5
    DOSSiteCount 50
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 600
</IfModule>

این تنظیم، اگر یک IP بیش از ۵ درخواست به یک صفحه در ثانیه ارسال کند، آن را به‌مدت ۱۰ دقیقه مسدود می‌کند.

رویکرد سوم: ModSecurity. ModSecurity یک WAF کامل است که قوانین Rate Limiting پیشرفته دارد:

SecRule IP:bf_counter "@gt 5" 
    "id:1001,phase:2,deny,status:429,msg:'Brute Force Detected'"

SecAction "id:1002,phase:2,pass,nolog,setvar:IP.bf_counter=+1,expirevar:IP.bf_counter=60"

اگر با استانداردهای امنیت وب آشنا شده باشید، می‌دانید که ModSecurity استاندارد صنعتی WAF است.

Rate Limiting در CDN

Rate Limiting در CDN، لایه‌ای قبل از رسیدن درخواست به سرور مبدأ است که بار سرور را به‌شدت کاهش می‌دهد. اکثر CDNهای مدرن از Rate Limiting پشتیبانی می‌کنند.

Cloudflare Rate Limiting. Cloudflare از Rate Limiting در پلن‌های مختلف پشتیبانی می‌کند:

Rule Name: Login Protection
When incoming requests match:
  - URI Path equals /wp-login.php
  - OR URI Path equals /wp-json/wp/v2/users
Then:
  - Rate Limit: 5 requests per minute
  - Action: Block for 1 hour
  - Response: 429 Too Many Requests

در پلن رایگان، Cloudflare یک قانون Rate Limiting دارد. در پلن Pro، ۱۰ قانون، و در Business، ۱۰۰ قانون.

BunnyCDN Rate Limiting. BunnyCDN از Rate Limiting از طریق Edge Rules پشتیبانی می‌کند:

Rule: Block Rapid Login Attempts
Condition: Request URL equals /wp-login.php
Action: Rate limit to 3 requests per minute per IP

اگر با BunnyCDN برای وردپرس آشنا شده باشید، می‌دانید که Edge Rules یکی از قابلیت‌های کلیدی این CDN است.

KeyCDN Rate Limiting. KeyCDN از Rate Limiting بومی پشتیبانی نمی‌کند اما از طریق قوانین سفارشی می‌توان محدودسازی را اعمال کرد. اگر با KeyCDN برای وردپرس آشنا شده باشید، می‌دانید که این CDN روی سادگی متمرکز است.

Rate Limiting در سطح Application

Rate Limiting در سطح Application، انعطاف‌پذیرترین لایه است که می‌تواند بر پایه منطق کسب‌وکار تصمیم بگیرد. این لایه کندتر از لایه‌های قبلی است اما امکاناتی فراهم می‌کند که در لایه‌های دیگر ممکن نیست.

پیاده‌سازی با Transient API. ساده‌ترین روش، استفاده از Transient API وردپرس است:

function my_plugin_rate_limit( $action, $limit = 10, $window = 60 ) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $key = 'rate_' . $action . '_' . md5( $ip );
    $count = (int) get_transient( $key );
    
    if ( $count >= $limit ) {
        wp_die( 
            'Rate limit exceeded. Try again later.', 
            'Too Many Requests', 
            array( 'response' => 429 ) 
        );
    }
    
    set_transient( $key, $count + 1, $window );
}
add_action( 'init', function() {
    my_plugin_rate_limit( 'login', 5, 60 );
} );

این کد، نرخ را به ۵ درخواست در دقیقه برای هر IP محدود می‌کند. اگر با کش هوشمند با Transient API آشنا شده باشید، این الگو برای شما آشناست.

پیاده‌سازی با Object Cache. برای سایت‌های پرترافیک، Transient API که بر پایه دیتابیس کار می‌کند می‌تواند گلوگاه شود. راه‌حل، استفاده از Object Cache (Redis یا Memcached) است:

function my_plugin_redis_rate_limit( $key, $limit, $window ) {
    $redis = wp_cache_get( $key, 'rate_limit' );
    $count = $redis ? $redis : 0;
    
    if ( $count >= $limit ) {
        return false;
    }
    
    wp_cache_set( $key, $count + 1, 'rate_limit', $window );
    return true;
}

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

صفحه ورود (/wp-login.php) یکی از هدف‌های اصلی حملات است. Rate Limiting این صفحه باید سخت‌گیرانه باشد چون کاربران واقعی معمولاً بیش از ۳ تا ۵ بار در دقیقه تلاش ورود نمی‌کنند.

استراتژی اول: محدودسازی بر پایه IP. استانداردترین رویکرد:

location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
}

استراتژی دوم: مسدودسازی IP بعد از چند تلاش ناموفق. این رویکرد با Fail2Ban پیاده‌سازی می‌شود:

# /etc/fail2ban/filter.d/wordpress-login.conf
[Definition]
failregex = ^<HOST> .* "POST /wp-login.php
ignoreregex =

# /etc/fail2ban/jail.local
[wordpress-login]
enabled = true
filter = wordpress-login
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime = 3600

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

add_action( 'login_form', function() {
    $ip = $_SERVER['REMOTE_ADDR'];
    $key = 'failed_login_' . md5( $ip );
    $count = (int) get_transient( $key );
    
    if ( $count >= 3 ) {
        // نمایش CAPTCHA
        echo '<div class="g-recaptcha" data-sitekey="YOUR_KEY"></div>';
    }
} );

اگر با فعال‌سازی احراز هویت دو مرحله‌ای در وردپرس آشنا شده باشید، می‌دانید که 2FA لایه دوم دفاعی است که Rate Limiting را تکمیل می‌کند.

حفاظت از REST API و GraphQL

REST API و GraphQL نقاط پایانی هستند که برای اپلیکیشن‌ها و سرویس‌های خارجی طراحی شده‌اند و نیازمند Rate Limiting دقیق‌تری هستند. سه سطح حفاظت:

سطح اول: Rate Limiting بر پایه IP. این سطح پایه است و برای همه درخواست‌های ناشناس اعمال می‌شود:

location ~ ^/wp-json/ {
    limit_req zone=api burst=20 nodelay;
}

سطح دوم: Rate Limiting بر پایه API Key. اگر API از Application Password یا JWT استفاده می‌کند، Rate Limiting بر پایه توکن اعمال می‌شود. این سطح، دقیق‌تر است چون هر اپلیکیشن سهمیه خود را دارد.

function my_plugin_api_rate_limit( $token, $limit = 1000, $window = 3600 ) {
    $key = 'api_rate_' . md5( $token );
    $count = (int) get_transient( $key );
    
    if ( $count >= $limit ) {
        return new WP_Error( 
            'rate_limit_exceeded', 
            'API rate limit exceeded', 
            array( 'status' => 429 ) 
        );
    }
    
    set_transient( $key, $count + 1, $window );
    return true;
}

سطح سوم: Rate Limiting بر پایه Endpoint. Endpointهای حساس مثل ورود، ثبت‌نام، و بازیابی رمز عبور نیازمند محدودیت سخت‌گیرانه‌تری هستند:

Endpoint	نرخ	پنجره
/wp-json/wp/v2/posts	۱۰۰	دقیقه
/wp-json/wp/v2/users	۱۰	دقیقه
/wp-json/wp/v2/comments	۵	دقیقه
/wp-json/wp/v2/media	۲۰	دقیقه
/graphql	۵۰	دقیقه

اگر با راهنمای کامل WPGraphQL آشنا شده باشید، می‌دانید که GraphQL نیازمند Query Depth Limiting و Query Complexity Analysis نیز است که مکمل Rate Limiting هستند.

افزونه‌های Rate Limiting برای وردپرس

چند افزونه وردپرس وجود دارند که Rate Limiting را در سطح Application پیاده‌سازی می‌کنند:

افزونه اول: Wordfence. این افزونه، Rate Limiting پیشرفته برای صفحه ورود و REST API فراهم می‌کند. Wordfence از یک لیست سیاه مشترک از IPهای مخرب استفاده می‌کند که به‌طور مداوم به‌روزرسانی می‌شود. اگر با بهترین افزونه‌های امنیتی وردپرس آشنا شده باشید، می‌دانید که Wordfence یکی از جامع‌ترین گزینه‌ها است.

افزونه دوم: Limit Login Attempts Reloaded. این افزونه، به‌طور تخصصی روی صفحه ورود متمرکز است و Rate Limiting، IP Blocking، و CAPTCHA را فراهم می‌کند. این افزونه، سبک و ساده است.

افزونه سوم: WP Cerber Security. این افزونه، Rate Limiting برای صفحه ورود، REST API و XML-RPC فراهم می‌کند و یک Dashboard جامع برای پایش دارد.

افزونه چهارم: Shield Security. این افزونه، Rate Limiting بر پایه IP و User Agent فراهم می‌کند و از Machine Learning برای تشخیص الگوهای مشکوک استفاده می‌نماید.

افزونه	پوشش	ویژگی کلیدی
Wordfence	Login + REST API	IP Reputation مشترک
Limit Login Attempts	Login	تمرکز تخصصی
WP Cerber	Login + REST + XML-RPC	Dashboard جامع
Shield Security	Login + REST	Machine Learning

پایش و تحلیل

Rate Limiting بدون پایش، فقط یک حدس است. برای اطمینان از اثربخشی، باید داده‌های زیر پایش شوند:

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

متریک دوم: False Positive Rate. چه تعداد کاربر واقعی به‌اشتباه مسدود شده‌اند؟ اگر این نرخ بالا باشد، تجربه کاربری مختل می‌شود و باید آستانه‌ها بازبینی شوند.

متریک سوم: توزیع IPها. چه IPهایی بیشترین درخواست را ارسال می‌کنند؟ اگر یک IP خاص بار غیرعادی داشته باشد، احتمال حمله بالاست.

# تحلیل ۱۰ IP پرترافیک
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

اگر با بررسی لاگ حملات سایت آشنا شده باشید، می‌دانید که این تحلیل بخشی از استراتژی تشخیص است.

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

اشتباهات رایج در Rate Limiting

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

اشتباه دوم: آستانه‌های بیش از حد آزاد. اگر آستانه بالاتر از نرخ حمله باشد، Rate Limiting بی‌اثر است. راه‌حل: تنظیم آستانه بر پایه الگوهای حمله مشاهده‌شده.

اشتباه سوم: یکسان‌سازی برای همه Endpointها. صفحه ورود و صفحه عمومی نیازهای متفاوتی دارند. راه‌حل: قوانین مجزا برای هر Endpoint.

اشتباه چهارم: نادیده گرفتن CDN و پروکسی. اگر سایت پشت CDN یا پروکسی باشد، $remote_addr آدرس CDN است، نه کاربر واقعی. راه‌حل: استفاده از $http_x_forwarded_for یا real_ip_header:

set_real_ip_from 103.21.244.0/22;  # Cloudflare IP Range
real_ip_header CF-Connecting-IP;

اشتباه پنجم: مسدود کردن IPهای Googlebot. اگر Rate Limiting برای Googlebot اعمال شود، رتبه سایت به‌شدت افت می‌کند. راه‌حل: Whitelist کردن IPهای Googlebot.

اشتباه ششم: نبود راه‌حل برای کاربران مشترک. اگر چند کاربر از یک IP (مثل کافی‌نت یا شرکت) استفاده کنند، Rate Limiting می‌تواند همه را مسدود کند. راه‌حل: استفاده از Rate Limiting بر پایه Session یا User ID.

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

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

اگر با اشتباهات امنیتی رایج در وب آشنا شده باشید، این اشتباهات برای شما آشناست.

پرسش‌های پرتکرار درباره Rate Limiting

Rate Limiting چیست و چرا ضروری است؟

Rate Limiting یک تکنیک کنترلی است که تعداد درخواست‌های مجاز از یک منبع مشخص را در بازه زمانی معین محدود می‌کند. ضروری است چون از Brute Force، DDoS لایه ۷، Scraping و API Abuse جلوگیری می‌کند و بار سرور را کاهش می‌دهد.

چگونه Rate Limiting را در وردپرس پیاده‌سازی کنم؟

سه سطح: اول، سطح سرور با Nginx (سریع‌ترین). دوم، سطح CDN با Cloudflare یا BunnyCDN (کاهش بار سرور). سوم، سطح Application با Transient API یا Object Cache (انعطاف‌پذیرترین). توصیه می‌شود از ترکیب هر سه سطح استفاده شود.

آستانه مناسب Rate Limiting چقدر است؟

بستگی به Endpoint دارد. برای صفحات عمومی ۳۰ درخواست در ثانیه، برای صفحه ورود ۱ درخواست در ثانیه، برای REST API ۱۰ درخواست در ثانیه. آستانه باید بر پایه تحلیل ترافیک واقعی تنظیم شود.

تفاوت Rate Limiting و Bot Management چیست؟

Rate Limiting بر پایه فرکانس تصمیم می‌گیرد، Bot Management بر پایه هویت. Rate Limiting یک لایه از Bot Management است اما Bot Management شامل روش‌های دیگر مثل IP Reputation، Fingerprinting و Behavioral Analysis نیز می‌شود.

آیا Rate Limiting بر کاربران واقعی اثر می‌گذارد؟

اگر آستانه به‌درستی تنظیم شود، کاربران واقعی تحت تأثیر قرار نمی‌گیرند. کاربران انسانی معمولاً زیر ۱۰ درخواست در دقیقه دارند، در حالی که ربات‌ها صدها یا هزاران درخواست ارسال می‌کنند.

چگونه Googlebot را از Rate Limiting مستثنا کنم؟

Googlebot از محدوده IP مشخصی استفاده می‌کند. باید این محدوده‌ها را Whitelist کنید. Google محدوده‌های خود را در مستندات رسمی منتشر می‌کند و از طریق https://developers.google.com/search/apis/ipranges/googlebot.json قابل دسترسی است.

آیا Rate Limiting با CDN سازگار است؟

بله، مکمل هستند. CDN Rate Limiting در لبه اجرا می‌شود و قبل از رسیدن درخواست به سرور مبدأ، آن را فیلتر می‌کند. Rate Limiting در سرور لایه دوم است که درخواست‌های عبورکرده از CDN را کنترل می‌کند.

چگونه Rate Limiting را پایش کنم؟

سه متریک: نرخ مسدودسازی، False Positive Rate، و توزیع IPها. ابزارهای مثل GoAccess و Cloudflare Analytics این داده‌ها را فراهم می‌کنند. اگر با Real User Monitoring و اهمیت آن آشنا شده باشید، می‌دانید که این پایش بخشی از Observability است.

آیا Rate Limiting با Fail2Ban یکسان است؟

خیر، مکمل هستند. Rate Limiting نرخ درخواست را در زمان واقعی محدود می‌کند. Fail2Ban لاگ‌ها را پایش می‌کند و بعد از تشخیص الگو، IP را مسدود می‌نماید. ترکیب این دو، دفاع قوی‌تری فراهم می‌کند.

آیا Rate Limiting برای سایت‌های کوچک ضروری است؟

بله، حتی برای سایت‌های کوچک. ربات‌های مخرب سایت‌های کوچک را نیز هدف می‌گیرند چون فرض می‌کنند امنیت کمتری دارند. برای سایت‌های کوچک، Rate Limiting در Nginx و افزونه Limit Login Attempts کافی است.

تحلیل معمارانه سطح ارشد

از منظر معماری نرم‌افزار، Rate Limiting یک مسئله Distributed State Management است: در یک سیستم توزیع‌شده با چند سرور و چند PoP، چگونه می‌توان وضعیت شمارنده‌ها را همگام نگه داشت؟ سه معماری استاندارد وجود دارد:

معماری اول: Centralized State. تمام شمارنده‌ها در یک دیتابیس مرکزی (مثل Redis) نگه داشته می‌شوند. این معماری، دقت بالایی دارد اما یک نقطه شکست (Single Point of Failure) ایجاد می‌کند و در سیستم‌های توزیع‌شده، تأخیر شبکه را افزایش می‌دهد.

معماری دوم: Distributed State با CRDT. در این معماری، هر PoP وضعیت خود را دارد و همگام‌سازی از طریق CRDT (Conflict-free Replicated Data Type) انجام می‌شود. این معماری، تحمل خطای بالایی دارد اما پیاده‌سازی پیچیده‌ای دارد.

معماری سوم: Approximate State. در این معماری، از الگوریتم‌های تقریبی مثل Count-Min Sketch یا HyperLogLog استفاده می‌شود که دقت تقریبی با حافظه کم فراهم می‌کنند. این معماری، در سیستم‌های با ترافیک بسیار بالا استفاده می‌شود.

چالش دوم، Fairness است: در یک سیستم توزیع‌شده، اگر یک کاربر از چند IP استفاده کند (مثل موبایل با تغییر شبکه)، Rate Limiting بر پایه IP می‌تواند بی‌اثر باشد. راه‌حل، استفاده از Composite Keys است که IP را با Fingerprint، Session یا API Key ترکیب می‌کند.

چالش سوم، Burst Tolerance است: کاربران واقعی ممکن است به‌طور ناگهانی چند درخواست ارسال کنند (مثل بارگذاری یک صفحه با ۵۰ Asset). اگر Rate Limiting این Burst را مسدود کند، تجربه کاربری مختل می‌شود. راه‌حل، استفاده از الگوریتم Token Bucket با Burst Allowance است.

چالش چهارم، Observability در لبه است: وقتی Rate Limiting در چند لایه اجرا می‌شود، دیدن تصمیمات هر لایه نیازمند Log Aggregation است. راه‌حل، استفاده از استانداردهایی مثل OpenTelemetry برای جمع‌آوری و همبستگی داده‌ها. اگر با پروفایلینگ وردپرس با New Relic آشنا شده باشید، می‌دانید که این سطح از Observability در سیستم‌های حرفه‌ای ضروری است.

چالش پنجم، Adversarial Adaptation است: مهاجمان می‌توانند الگوی درخواست خود را طوری تنظیم کنند که زیر آستانه Rate Limiting باقی بمانند. راه‌حل، استفاده از Adaptive Thresholds است که بر پایه Baseline ترافیک، آستانه‌ها را به‌طور خودکار تنظیم می‌کنند. این رویکرد، در سیستم‌های Cloudflare Bot Management استفاده می‌شود.

در نهایت، Rate Limiting یک Defense Layer است، نه یک Silver Bullet. تیم‌هایی که آن را به‌عنوان بخشی از یک استراتژی دفاع لایه‌ای می‌بینند، سیستم‌هایی می‌سازند که در برابر طیف گسترده‌ای از حملات مقاوم هستند. تیم‌هایی که آن را تنها راه‌حل می‌بینند، با شکاف‌های امنیتی مواجه می‌شوند. اگر با طراحی معماری وب مقیاس‌پذیر آشنا شده باشید، این رویکرد را به‌عنوان یک اصل مهندسی می‌شناسید.

اگر این تجربه را در یک پروژه واقعی داشته‌اید، جالب است بدانید کدام سطح Rate Limiting بیشترین اثربخشی را برای سایت شما داشت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🛡️

Rate Limiting چیست و چرا ضروری است؟

حملات رایج که Rate Limiting دفع می‌کند

الگوریتم‌های Rate Limiting

Rate Limiting در سطح سرور

پیکربندی Nginx برای وردپرس

محدودسازی بر اساس Endpoint

پیکربندی Apache و ModSecurity

Rate Limiting در CDN

Rate Limiting در سطح Application

حفاظت از صفحه ورود

حفاظت از REST API و GraphQL

افزونه‌های Rate Limiting برای وردپرس

پایش و تحلیل

اشتباهات رایج در Rate Limiting

پرسش‌های پرتکرار درباره Rate Limiting

Rate Limiting چیست و چرا ضروری است؟

چگونه Rate Limiting را در وردپرس پیاده‌سازی کنم؟

آستانه مناسب Rate Limiting چقدر است؟

تفاوت Rate Limiting و Bot Management چیست؟

آیا Rate Limiting بر کاربران واقعی اثر می‌گذارد؟

چگونه Googlebot را از Rate Limiting مستثنا کنم؟

آیا Rate Limiting با CDN سازگار است؟

چگونه Rate Limiting را پایش کنم؟

آیا Rate Limiting با Fail2Ban یکسان است؟

آیا Rate Limiting برای سایت‌های کوچک ضروری است؟

تحلیل معمارانه سطح ارشد