آموزش فایروال وردپرس و WAF؛ تنظیم Cloudflare، Rate Limit و محافظت از سرور

فایروال وردپرس باید پیش از رسیدن ترافیک مخرب به PHP، دیتابیس و افزونه‌های سایت، درخواست‌های پرخطر را شناسایی و متوقف کند. اگر دفاع فقط داخل یک افزونه وردپرسی انجام شود، بخش قابل‌توجهی از حمله تا مرحله اجرای WordPress پیش آمده و منابع CPU، RAM و PHP Worker را مصرف کرده است. به همین دلیل برای سایت‌های فروشگاهی، ترکیب WAF در لبه شبکه، کنترل‌های وب‌سرور و دفاع سطح برنامه معمولاً نتیجه بهتری از اتکا به یک لایه دارد.

WAF یا Web Application Firewall درخواست‌های HTTP و HTTPS را براساس مسیر، روش درخواست، IP، کشور، User Agent، الگوی حمله، نرخ درخواست و قواعد مدیریت‌شده تحلیل می‌کند. این سیستم می‌تواند حملات شناخته‌شده، Brute Force، Credential Stuffing، اسکن فایل‌های حساس، Botهای مخرب و بخشی از سوءاستفاده‌های XSS، SQL Injection و File Inclusion را پیش از رسیدن به وردپرس متوقف کند.

در این آموزش، تفاوت فایروال شبکه، WAF و افزونه امنیتی، انتخاب محل دفاع، تنظیم Cloudflare، Managed Rules، Custom Rules، Rate Limit برای wp-login.php و xmlrpc.php، محافظت از Origin، استثناهای ووکامرس، Callback درگاه، REST API، LiteSpeed، Log و رفع False Positive را مرحله‌به‌مرحله بررسی می‌کنیم.

فایروال شبکه، WAF و افزونه امنیتی چه تفاوتی دارند؟

فایروال شبکه

فایروال شبکه روی IP، Port و Protocol کار می‌کند. برای مثال می‌تواند فقط پورت‌های ۸۰ و ۴۴۳ را باز نگه دارد، SSH را به IP مشخص محدود کند و دسترسی مستقیم به دیتابیس را مسدود نماید. این لایه معمولاً محتوای فرم Login یا Payload وردپرس را به‌طور کامل تحلیل نمی‌کند.

Web Application Firewall

WAF لایه کاربرد را می‌بیند و می‌تواند مسیر، Header، Cookie، Query String، روش POST و الگوهای حمله را بررسی کند. Cloudflare WAF، ModSecurity و WAF شرکت میزبان نمونه‌هایی از این لایه‌اند.

فایروال افزونه وردپرس

افزونه امنیتی داخل محیط وردپرس اجرا می‌شود و اطلاعاتی مانند User، Role، Login Failure و تغییر فایل را بهتر می‌شناسد. ضعف آن این است که درخواست معمولاً به سرور و PHP رسیده است. این لایه برای Log، 2FA و کنترل Context مفید است، اما بهتر است تنها خط دفاع نباشد.

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

1. CDN یا Reverse Proxy برای DDoS، Bot و Rate Limit
2. فایروال شبکه و وب‌سرور برای Port، Origin و ModSecurity
3. وردپرس برای 2FA، نقش‌ها، Session و Audit Log
4. کد امن در افزونه و قالب
5. بکاپ و واکنش به حادثه

هیچ لایه‌ای جایگزین به‌روزرسانی نیست. WAF ممکن است بعضی Exploitها را متوقف کند، اما افزونه آسیب‌پذیر باید به‌روزرسانی یا حذف شود.

WAF لبه شبکه چه مزیتی دارد؟

در مدل Reverse Proxy، DNS دامنه به شبکه سرویس WAF اشاره می‌کند. درخواست ابتدا وارد شبکه محافظ می‌شود و فقط ترافیک مجاز به Origin ارسال خواهد شد.

• کاهش مصرف منابع هاست در حمله
• محافظت DDoS و Bot در لبه
• قابلیت Managed Challenge
• Rate Limit بدون اجرای PHP
• ثبت Security Event
• مخفی‌شدن نسبی IP سرور مبدأ

اگر مهاجم IP واقعی Origin را پیدا کند و سرور دسترسی مستقیم را بپذیرد، ممکن است WAF را دور بزند. محافظت از Origin بخش مهم راه‌اندازی است.

پیش‌نیازهای نصب یا فعال‌سازی WAF

1. از فایل و دیتابیس بکاپ کامل بگیرید.
2. یک Staging مشابه سایت اصلی آماده کنید.
3. فهرست مسیرهای حساس را بنویسید.
4. درگاه پرداخت، API، Webhook و اتصال‌های خارجی را مستند کنید.
5. IPهای ثابت مدیریتی و سرویس‌های ضروری را ثبت نمایید.
6. راه Rollback DNS و Ruleها را مشخص کنید.
7. Log وب‌سرور و WAF را قابل دسترسی نگه دارید.

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

مسیرهای حساس وردپرس

• /wp-login.php
• /wp-admin/
• /xmlrpc.php
• /wp-json/
• /wp-admin/admin-ajax.php
• /wp-cron.php
• فرم ثبت‌نام و Lost Password
• Endpointهای افزونه‌های سفارشی

حساس‌بودن یک مسیر به معنی مسدودکردن کامل آن نیست. برای مثال admin-ajax.php ممکن است از Frontend، Cart و افزونه‌های قالب استفاده شود.

مسیرهای حساس WooCommerce

• Cart و Checkout
• My Account و Lost Password
• wc-ajax
• Store API زیر /wp-json/wc/store/
• REST API ووکامرس
• order-pay و order-received
• Callback و Webhook درگاه
• مجوز و لینک دانلود

Challenge یا Cache روی این مسیرها می‌تواند سفارش، پرداخت یا ورود مشتری را خراب کند. استثنا باید محدود، مستند و فقط برای Rule مشکل‌دار باشد.

فعال‌سازی Cloudflare به‌عنوان Reverse Proxy

روند عمومی:

1. دامنه را به حساب Cloudflare اضافه کنید.
2. رکوردهای DNS را بررسی نمایید.
3. رکورد وب‌سایت را در حالت Proxied قرار دهید.
4. Nameserverهای اعلام‌شده را در Registrar ثبت کنید.
5. پس از فعال‌شدن، HTTPS و Origin را تست نمایید.
6. Security Events و Analytics را بررسی کنید.

قبل از تغییر Nameserver، رکوردهای ایمیل، DKIM، SPF و سرویس‌های جانبی را دقیق منتقل کنید. اشتباه DNS می‌تواند ایمیل یا سرویس‌های دیگر را قطع کند.

SSL در WAF و Origin

ارتباط باید هم میان کاربر و WAF و هم میان WAF و سرور Origin رمزگذاری شود. حالت‌هایی که اتصال WAF به Origin را بدون اعتبارسنجی کافی انجام می‌دهند، امنیت End-to-End را کاهش می‌دهند.

گواهی Origin، Hostname و Redirectهای HTTPS را آزمایش کنید. خطاهای 525 و 526 معمولاً به Handshake یا اعتبار گواهی میان Proxy و Origin مرتبط‌اند.

Managed Rules چیست؟

Managed Rules مجموعه قواعدی هستند که ارائه‌دهنده WAF برای الگوهای شناخته‌شده حمله نگهداری می‌کند. مزیت آن‌ها به‌روزرسانی مستمر در برابر تکنیک‌های رایج است.

در Cloudflare، Ruleهای مدیریت‌شده دارای Tagهایی مانند WordPress هستند و بسته به Plan می‌توان Rule، Tag یا Ruleset را تنظیم کرد.

روش استقرار امن

1. ابتدا حالت Log یا کم‌خطر را انتخاب کنید.
2. ترافیک واقعی و False Positiveها را مشاهده نمایید.
3. Rule ID و مسیر مشکل‌دار را ثبت کنید.
4. فقط Rule مشخص را برای مسیر دقیق Exclude کنید.
5. از Skip کامل WAF برای کل سایت خودداری نمایید.
6. بعد از تأیید، Action را به Block یا Managed Challenge ارتقا دهید.

Custom Rule چیست؟

Custom Rule براساس شرایط اختصاصی سایت ساخته می‌شود. مثال‌ها:

• Challenge برای POSTهای صفحه ورود
• Block فایل‌های پشتیبان عمومی
• محدودکردن دسترسی wp-admin به IP مشخص
• مسدودکردن User Agent مخرب
• اجازه عبور مسیر Callback مشخص

Ruleها به‌ترتیب اجرا می‌شوند و Actionهایی مانند Block ممکن است بررسی Ruleهای بعدی را متوقف کنند. ترتیب باید مستند باشد.

نمونه Rule برای صفحه ورود

یک Expression محافظه‌کارانه برای بررسی POST روی صفحه Login:

(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")

Action اولیه می‌تواند Managed Challenge باشد. برای کاربران دارای IP ثابت می‌توانید Rule جدا و دقیق‌تری بسازید، اما Allowlist عمومی و دائمی IP متغیر مناسب نیست.

Rate Limit برای wp-login.php

Rate Limiting تعداد درخواست‌های منطبق را در یک بازه زمانی می‌شمارد و پس از عبور از Threshold، Challenge یا Block اعمال می‌کند.

نمونه آموزشی

• مسیر: /wp-login.php
• روش: POST
• ویژگی شمارش: IP
• Threshold شروع: حدود ۱۰ درخواست در یک دقیقه
• Action: Managed Challenge یا Block کوتاه
• Mitigation Timeout: چند دقیقه

این عدد نسخه نهایی برای همه سایت‌ها نیست. اگر شرکت یا ISP کاربران IP مشترک دارد، Threshold پایین می‌تواند کاربر قانونی را مسدود کند. ابتدا Log را بررسی کنید.

چرا Lockout دائمی مناسب نیست؟

مهاجم می‌تواند با تلاش عمدی، حساب مدیر یا IP شرکت را قفل کند. Rate Limit موقت و افزایش تدریجی تأخیر معمولاً از Block دائمی بهتر است.

برای Login، Rate Limit باید همراه با 2FA اجرا شود. مقاله آموزش امنیت ورود وردپرس جزئیات 2FA و Passkey را توضیح می‌دهد.

محافظت از XML-RPC

اگر Jetpack، اپلیکیشن WordPress یا ابزار انتشار از XML-RPC استفاده نمی‌کند، می‌توان مسیر را مسدود کرد:

(http.request.uri.path eq "/xmlrpc.php")

Action می‌تواند Block باشد. اگر سرویس وابسته دارید، به‌جای Block کامل:

• Rate Limit شدیدتر اعمال کنید.
• Methodهای غیرضروری را محدود نمایید.
• IP یا سرویس مورد اعتماد را با Rule دقیق مدیریت کنید.
• Log درخواست‌های XML-RPC را مانیتور کنید.

محافظت از wp-admin

در سایت با تیم کوچک و IP ثابت می‌توان برای /wp-admin/ Rule مبتنی بر IP ساخت، اما این روش برای مدیر متحرک، اینترنت موبایل و IP پویا دردسر ایجاد می‌کند.

هیچ‌گاه کل /wp-admin/ را بدون بررسی مسدود نکنید؛ /wp-admin/admin-ajax.php ممکن است برای Frontend لازم باشد. گزینه‌های امن‌تر:

• Managed Challenge برای بخش مدیریت
• 2FA برای Administrator
• Rate Limit صفحه Login
• Access Policy سازمانی
• Allowlist فقط برای تیم دارای IP ثابت

Block فایل‌های حساس و بکاپ عمومی

اسکنرها به‌دنبال فایل‌های قابل حدس هستند:

• .env
• wp-config.php.bak
• backup.zip
• database.sql
• Logها و فایل‌های موقت

این فایل‌ها باید از Web Root حذف شوند. WAF فقط لایه دوم است؛ فایل حساس را در مسیر عمومی نگه ندارید.

Challenge بهتر است یا Block؟

Managed Challenge

برای ترافیکی که ممکن است بخشی از آن قانونی باشد مناسب‌تر است. سیستم براساس سیگنال‌های Bot و مرورگر تصمیم می‌گیرد.

Block

برای مسیر غیرضروری، Payload قطعی مخرب یا IP تأییدشده مناسب است.

Log

برای شروع استقرار و شناخت False Positiveها ضروری است.

از Challenge روی Callback درگاه و Webhook ماشینی استفاده نکنید؛ سرویس‌های Server-to-Server نمی‌توانند صفحه Challenge مرورگر را حل کنند.

استثناهای ووکامرس را چگونه بسازیم؟

استثنا باید دقیق باشد. به‌جای غیرفعال‌کردن کل WAF روی Checkout:

1. Security Event را پیدا کنید.
2. Rule ID ایجادکننده خطا را ثبت نمایید.
3. مسیر، روش و منبع درخواست را مشخص کنید.
4. فقط همان Rule را برای همان Endpoint Skip کنید.
5. مدت و دلیل استثنا را مستند نمایید.
6. پس از آپدیت افزونه یا WAF دوباره آزمایش کنید.

Skip کلی Managed Rules برای /checkout/ سطح دفاع را بیش‌ازحد پایین می‌آورد.

Callback درگاه پرداخت

مسیر Callback به افزونه درگاه بستگی دارد. WAF ممکن است Payload، Query String یا تکرار درخواست را مشکوک تشخیص دهد.

قواعد ایمن

• مسیر واقعی Callback را از مستندات افزونه استخراج کنید.
• IPهای ارائه‌دهنده را فقط اگر رسمی و پایدارند استفاده نمایید.
• Challenge را برای Callback غیرفعال کنید.
• فقط Rule مشکل‌دار را Skip کنید.
• تأیید تراکنش سمت سرور در افزونه باید باقی بماند.
• Log درگاه و WAF را تطبیق دهید.

Allowlist گسترده IP ممکن است تمام لایه‌های WAF را دور بزند. بعضی ابزارهای IP Access در صورت Allowکردن، Custom Rules و Managed Rules را نیز کنار می‌گذارند؛ بنابراین Scope را دقیق بخوانید.

REST API و Store API

REST API برای WordPress، WooCommerce، ویرایشگر، اپلیکیشن‌ها و اتصال‌های خارجی ضروری است. Block کامل /wp-json/ معمولاً تصمیم درستی نیست.

روش بهتر:

• Rate Limit Endpointهای پرمصرف
• احراز هویت صحیح Application Password
• محدودکردن Methodهای تغییر داده
• کنترل Capability داخل افزونه
• Log خطاهای 401، 403 و 429
• استثنای محدود برای Integration شناخته‌شده

WooCommerce و wc-ajax

WoodMart و WooCommerce برای افزودن به سبد، Mini Cart و Checkout از AJAX استفاده می‌کنند. WAF نباید درخواست‌های معتبر wc-ajax را به‌صورت عمومی Challenge کند.

در عین حال Endpointهای AJAX نباید کاملاً بدون کنترل باشند. Rate Limit منطقی، بررسی Bot و محدودیت عملیات سنگین لازم است.

محافظت از سرور Origin

وقتی Cloudflare یا Reverse Proxy استفاده می‌شود، باید تا حد امکان ترافیک مستقیم به Origin محدود شود.

روش‌های رایج

• Allowکردن Rangeهای رسمی Proxy در فایروال سرور
• Block سایر اتصال‌های مستقیم روی ۸۰ و ۴۴۳
• Cloudflare Tunnel در زیرساخت سازگار
• Origin Certificate
• حذف رکوردهای DNS افشاکننده IP

Rangeهای IP سرویس ممکن است تغییر کنند؛ از فهرست رسمی استفاده و فرایند Update داشته باشید. محدودسازی اشتباه می‌تواند کل سایت را قطع کند.

بازیابی IP واقعی بازدیدکننده

پس از Reverse Proxy، وب‌سرور ممکن است همه درخواست‌ها را با IP Cloudflare ثبت کند. باید ماژول یا تنظیم معتبر برای خواندن Header رسمی Proxy فعال شود.

این موضوع برای موارد زیر حیاتی است:

• Rate Limit
• Fail2ban
• Log و Forensics
• محدودیت ورود
• گزارش جغرافیایی

هرگز Header اعلام‌شده کاربر را بدون اعتماد به Proxy معتبر به‌عنوان IP واقعی قبول نکنید؛ مهاجم می‌تواند آن را جعل کند.

ModSecurity روی هاست

ModSecurity یک WAF سطح وب‌سرور است و اغلب با OWASP Core Rule Set استفاده می‌شود. مزایا:

• دفاع نزدیک Origin
• محافظت حتی اگر CDN دور زده شود
• قابلیت Rule سفارشی
• Log دقیق وب‌سرور

در هاست اشتراکی ممکن است دسترسی تنظیم محدود باشد. هنگام False Positive، Rule ID را از شرکت میزبان بخواهید و Exclude کلی دامنه درخواست نکنید.

استفاده هم‌زمان از چند WAF

Cloudflare، ModSecurity و افزونه امنیتی می‌توانند هم‌زمان فعال باشند، اما احتمال پیچیدگی و False Positive بالا می‌رود.

برای هر لایه نقش مشخص تعیین کنید:

• Cloudflare: DDoS، Bot، Rate Limit و Managed Challenge
• ModSecurity: محافظت Origin و OWASP Rules
• WordPress Plugin: 2FA، Login Log و File Integrity

سه لایه با Ruleهای تکراری و بدون مستندات، عیب‌یابی را دشوار می‌کنند.

LiteSpeed Cache و WAF

LiteSpeed Cache فایروال نیست، اما با CDN و صفحات پویا تعامل دارد.

• Cart، Checkout و My Account کش عمومی نشوند.
• Challenge Page کش نشود.
• Cookieهای WooCommerce در Cache Vary درست باشند.
• ESI و AJAX بعد از Rule جدید تست شوند.
• Purge گسترده در زمان حمله کنترل شود.

مستندات WooCommerce نیز تأکید می‌کنند Cart، Checkout و My Account نباید مانند صفحات عمومی کش شوند.

Country Block مناسب است؟

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

گزینه بهتر:

• Challenge برای کشور پرریسک روی Login
• Rate Limit
• 2FA
• Bot Score یا رفتار درخواست
• Block فقط در صورت نبود مشتری و سرویس قانونی

Bot Management و Scraping

Botها می‌توانند محصول، قیمت، فایل و Endpointها را Scrape کنند. همه Botها مخرب نیستند؛ موتور جست‌وجو و سرویس‌های مانیتورینگ نیز Bot هستند.

قبل از Block:

• User Agent به‌تنهایی ملاک نباشد.
• Verified Botها بررسی شوند.
• نرخ درخواست و مسیر تحلیل گردد.
• SEO و Torob یا سرویس‌های فروش تست شوند.
• Rate Limit به‌جای Block دائمی بررسی شود.

امنیت Upload

WAF می‌تواند بعضی Payloadها را تشخیص دهد، اما امنیت Upload باید داخل برنامه نیز اجرا شود:

• محدودیت MIME و Extension
• Sanitize نام فایل
• جلوگیری از اجرای PHP در Uploads
• اسکن فایل
• محدودیت Size
• Capability و Nonce

سایت Safe SVG دارد؛ Upload SVG باید فقط برای نقش‌های لازم مجاز باشد.

Security Event را چگونه تحلیل کنیم؟

برای هر Event این داده‌ها را ثبت کنید:

• زمان و منطقه زمانی
• Action و Rule ID
• Path و Method
• IP، ASN و کشور
• User Agent
• Request ID یا Ray ID
• Response Code
• ارتباط با سفارش یا Login واقعی

بر اساس یک Event استثنا نسازید. الگوی تکرار و درخواست واقعی کاربر را بررسی کنید.

False Positive چیست؟

درخواست قانونی که اشتباهاً مخرب تشخیص داده می‌شود. نمونه‌ها:

• ویرایش محتوای حاوی کد
• Upload فایل خاص
• Callback درگاه
• REST API افزونه
• Checkout با فیلد سفارشی
• Import انبوه محصول

روش رفع صحیح

1. Event دقیق را پیدا کنید.
2. Rule ID را ثبت نمایید.
3. Request را روی Staging بازتولید کنید.
4. تنها Rule مرتبط را برای Scope محدود Exclude کنید.
5. بعد از تغییر دوباره تست امنیتی انجام دهید.

خطاهای رایج WAF

خطای 403

Block توسط WAF، ModSecurity یا Permission محتمل است. Ray ID یا Log سرور را بررسی کنید.

خطای 429

Rate Limit فعال شده است. Threshold، IP مشترک و Request Burst را بررسی نمایید.

خطای 1015 Cloudflare

بازدیدکننده به Rate Limit Cloudflare رسیده است. Rule و ویژگی شمارش را بازبینی کنید.

Loop در Challenge

Cookie، JavaScript، Browser Privacy، Cache یا Rule تکراری می‌تواند علت باشد.

Checkout بدون واکنش

در Console مرورگر و Security Events، Block شدن wc-ajax، Store API یا admin-ajax.php را بررسی کنید.

درگاه پرداخت برنمی‌گردد

Callback یا Webhook ممکن است Challenge یا Block شده باشد. Log درگاه و WAF را با زمان تراکنش تطبیق دهید.

آزمایش قبل از انتشار Rule

1. Rule را در Log یا Challenge کم‌خطر شروع کنید.
2. ورود مدیر موفق و ناموفق را تست نمایید.
3. Lost Password را آزمایش کنید.
4. یک خرید مهمان و یک خرید حساب‌دار ثبت نمایید.
5. Cart، Checkout و My Account را روی موبایل بررسی کنید.
6. درگاه را در Sandbox و تراکنش کم‌مبلغ تست کنید.
7. REST API و اتصال AI را کنترل نمایید.
8. Import محصول و Upload را آزمایش کنید.
9. XML-RPC یا سرویس وابسته را بررسی نمایید.
10. Log WAF، وب‌سرور و وردپرس را تطبیق دهید.

برنامه پیشنهادی برای dev-source.ir

1. ابتدا مشخص شود آیا Cloudflare یا WAF میزبان فعال است.
2. از DNS، فایل و دیتابیس بکاپ گرفته شود.
3. Staging با WoodMart، LiteSpeed و افزونه‌های سفارشی آماده گردد.
4. Managed Rules در حالت مشاهده یا محافظه‌کارانه فعال شوند.
5. Rate Limit برای POSTهای wp-login.php آزمایش شود.
6. وضعیت استفاده از XML-RPC مشخص گردد.
7. Callback درگاه آینده و اتصال Royal MCP مستند شوند.
8. Cart، Checkout، Store API و دانلود فایل تست شوند.
9. Origin در صورت استفاده از Proxy محدود و IP واقعی بازدیدکننده بازیابی شود.
10. هشدار Security Event و فرایند رفع False Positive نوشته شود.

این برنامه مکمل مقاله چک‌لیست سخت‌سازی وردپرس است.

چک‌لیست نهایی فایروال وردپرس

• محل WAF مشخص و مستند است.
• Managed Rules فعال و بررسی شده‌اند.
• Rate Limit صفحه Login آزمایش شده است.
• XML-RPC براساس نیاز کنترل می‌شود.
• wp-admin بدون شکستن admin-ajax محافظت شده است.
• Origin در برابر دورزدن Proxy محافظت می‌شود.
• IP واقعی بازدیدکننده در Log ثبت می‌شود.
• Cart، Checkout و My Account Cache یا Challenge عمومی ندارند.
• Callback درگاه و Webhook تست شده‌اند.
• REST API و Application Password کار می‌کنند.
• استثناها محدود به Rule و Path مشخص‌اند.
• Skip کلی WAF وجود ندارد.
• Security Eventها مانیتور می‌شوند.
• False Positive فرایند مستند دارد.
• Rollback Rule و DNS آماده است.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

پرسش‌های متداول

آیا افزونه امنیتی همان WAF است؟

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

آیا Cloudflare برای وردپرس کافی است؟

خیر. Cloudflare لایه مهمی است، اما آپدیت، 2FA، کد امن، بکاپ و محافظت Origin همچنان ضروری‌اند.

چه عددی برای Rate Limit مناسب است؟

عدد ثابت برای همه سایت‌ها وجود ندارد. از Log ترافیک قانونی شروع کنید و Threshold را طوری تنظیم نمایید که Bot را محدود و کاربر واقعی را مسدود نکند.

آیا باید wp-admin را فقط به IP خودم محدود کنم؟

اگر IP ثابت و تیم محدود دارید مفید است. با IP پویا یا مدیر متحرک، 2FA و Managed Challenge معمولاً عملی‌ترند.

چرا Callback درگاه با WAF خراب می‌شود؟

درخواست Server-to-Server نمی‌تواند Challenge مرورگر را حل کند یا ممکن است یک Managed Rule آن را مسدود کند. Exclude محدود برای Rule و Endpoint واقعی لازم است.

آیا Block کشورها امنیت را بالا می‌برد؟

گاهی نویز را کم می‌کند، اما دفاع اصلی نیست و می‌تواند کاربران و سرویس‌های قانونی را قطع کند. رفتار، Rate Limit و 2FA دقیق‌ترند.

آیا WAF جلوی همه هک‌ها را می‌گیرد؟

خیر. WAF ریسک را کاهش می‌دهد، اما رمز سرقت‌شده، افزونه آسیب‌پذیر، دسترسی داخلی و کد سفارشی ناامن همچنان نیازمند کنترل مستقل‌اند.

جمع‌بندی

فایروال وردپرس و WAF باید ترافیک مخرب را در نزدیک‌ترین نقطه به اینترنت متوقف کند، بدون آنکه مسیرهای پویا و حیاتی فروشگاه را مختل نماید. Managed Rules، Custom Rules و Rate Limit زمانی مفیدند که با Log، Staging و Scope محدود اجرا شوند.

برای WordPress، تمرکز اولیه روی wp-login.php، XML-RPC، Origin و فایل‌های حساس است. برای WooCommerce، Cart، Checkout، My Account، AJAX، Store API، درگاه و دانلود باید به‌عنوان مسیرهای حیاتی در برنامه تست قرار گیرند.

Rule کلی و سریع معمولاً خطرناک‌تر از Rule محدود و مستند است. ابتدا مشاهده کنید، Event را تحلیل نمایید، Scope را محدود کنید و فقط پس از تست کامل Action را به Block ارتقا دهید.

منابع رسمی

• Brute Force Attacks – WordPress
• Hardening WordPress
• Cloudflare WAF Custom Rules
• Cloudflare Rate Limiting Rules
• Protect Your Origin Server
• WooCommerce Caching Guidance