🛡️ آموزش امنیت سایت

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

WAF یا Web Application Firewall یک لایه دفاعی در سطح HTTP/HTTPS است که بین کاربر و سایت قرار می‌گیرد و درخواست‌ها را قبل از رسیدن به برنامه بررسی می‌کند. این مقاله برای مدیران سایت، فروشگاه‌های اینترنتی، کاربران وردپرس، ادمین‌های سرور و تیم‌های فنی نوشته شده تا بدانند WAF دقیقاً چه کاری می‌کند، چه محدودیت‌هایی دارد و هنگام فعال‌سازی با چه چالش‌هایی روبه‌رو می‌شوند.

تعریف سریع WAF
مشکلات رایج WAF
چک‌لیست فعال‌سازی
سوالات متداول

WAF چیست؟ پاسخ کوتاه و کاربردی

WAF مخفف Web Application Firewall به معنی «فایروال برنامه وب» است. فایروال معمولی بیشتر روی IP، پورت و پروتکل تمرکز دارد؛ اما WAF محتوای درخواست‌های وب را می‌بیند: آدرس URL، کوئری‌استرینگ، کوکی، هدر، بدنه فرم، JSON، فایل آپلودی و گاهی پاسخ خروجی سایت.

به زبان ساده، اگر کاربر یا ربات بخواهد در فرم جستجو، فرم ورود، سبد خرید، API یا آدرس‌های مدیریتی سایت چیزی شبیه SQL Injection، XSS، Path Traversal یا درخواست مشکوک ارسال کند، WAF می‌تواند آن را لاگ کند، محدود کند، چالش امنیتی بدهد یا کامل بلاک کند.

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

WAF چگونه کار می‌کند؟

WAF معمولاً در مسیر درخواست‌های HTTP/HTTPS قرار می‌گیرد. کاربر درخواست را به دامنه سایت می‌فرستد، WAF درخواست را بررسی می‌کند، سپس اگر درخواست سالم بود آن را به سرور اصلی یا اپلیکیشن ارسال می‌کند. اگر درخواست مشکوک باشد، بسته به تنظیمات ممکن است فقط لاگ شود، با کد 403 بسته شود، CAPTCHA/Challenge بگیرد یا وارد Rate Limit شود.

دریافت درخواستWAF هدر، IP، مسیر URL، کوکی، پارامترها، User-Agent، کشور، ASN و گاهی بدنه درخواست را بررسی می‌کند.
مقایسه با قوانین امنیتیدرخواست با قوانین آماده، قوانین OWASP، امتیاز ریسک، لیست‌های IP، Ruleهای اختصاصی و الگوهای حمله مقایسه می‌شود.
تصمیم امنیتیدرخواست می‌تواند Allow، Block، Count/Log، Challenge، CAPTCHA یا Rate Limit شود.
تحلیل لاگ و تنظیمادمین باید گزارش‌های WAF را ببیند تا خطاهای مثبت کاذب و مسیرهای حساس را تنظیم کند.

WAF جلوی چه حملاتی را می‌گیرد؟

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

  • SQL Injection: تلاش برای تزریق دستور SQL از طریق فرم، URL، API یا پارامترها.
  • XSS: ارسال اسکریپت مخرب در فرم‌ها، کامنت‌ها، جستجو یا پنل کاربری.
  • LFI/RFI و Path Traversal: تلاش برای خواندن فایل‌های حساس یا فراخوانی فایل از مسیرهای غیرمجاز.
  • Command Injection و RCE: تلاش برای اجرای دستور روی سرور از طریق ورودی‌های ناامن.
  • Brute Force و Credential Stuffing: تلاش زیاد برای ورود به پنل مدیریت یا حساب کاربران.
  • حملات رباتی و Scraping: درخواست‌های زیاد از ربات‌های ناشناس، اسکنرها یا ابزارهای مخرب.
  • آپلود فایل مخرب: تلاش برای آپلود فایل PHP، WebShell یا فایل با MIME مشکوک.
  • سوءاستفاده از API: درخواست‌های غیرعادی به endpointهای JSON، REST API یا GraphQL.

انواع WAF و روش‌های استقرار

نوع WAF نمونه مزیت چالش
Cloud/CDN WAF Cloudflare WAF، AWS WAF فعال‌سازی سریع، مناسب DDoS و مدیریت Ruleها از پنل اگر Origin مستقیم باز باشد، بخشی از حملات می‌تواند WAF را دور بزند.
Server-side WAF ModSecurity + OWASP CRS روی خود وب‌سرور اجرا می‌شود و حتی بدون CDN هم قابل استفاده است. نیاز به تیونینگ دارد و ممکن است روی فرم‌ها یا API خطای کاذب بدهد.
Managed Hosting WAF WAF داخل کنترل‌پنل یا سرویس میزبانی برای کاربر ساده‌تر است و معمولاً توسط میزبان تنظیم می‌شود. گاهی دسترسی کامل به Ruleها و لاگ‌ها وجود ندارد.
Custom/Hybrid WAF ترکیب Cloudflare + ModSecurity + قوانین اختصاصی برای سایت‌های حساس و فروشگاهی قوی‌تر است. اگر بدون برنامه فعال شود، ممکن است پرداخت، API یا پنل مدیریت را مختل کند.

تفاوت WAF با فایروال معمولی، آنتی‌ویروس و DDoS Protection

فایروال معمولی معمولاً تصمیم می‌گیرد کدام IP یا پورت مجاز است؛ مثلاً پورت 22، 80، 443 یا 3306. اما WAF می‌فهمد داخل درخواست وب چه چیزی ارسال شده است. برای مثال فایروال معمولی فقط می‌بیند درخواست روی پورت 443 آمده، اما WAF می‌تواند تشخیص دهد که داخل URL یا فرم، الگوی مشکوک SQL Injection وجود دارد.

DDoS Protection بیشتر برای حجم بالای ترافیک و حملات حجمی است. WAF بیشتر برای منطق و محتوای درخواست‌های وب استفاده می‌شود. بهترین حالت، ترکیب چند لایه است: فایروال شبکه، WAF، Rate Limit، آپدیت برنامه، بکاپ و مانیتورینگ.

چالش‌ها و مشکلات رایج هنگام فعال‌سازی WAF

بخش مهم مقاله همین‌جاست؛ چون بیشتر کاربران وقتی WAF را روشن می‌کنند، با چند مشکل تکراری روبه‌رو می‌شوند. اگر این موارد را از قبل بدانید، هم سایت امن‌تر می‌شود، هم فروش و فرم‌های سایت خراب نمی‌شود.

۱. خطای 403 برای کاربر واقعی

رایج‌ترین مشکل WAF این است که یک درخواست سالم را مخرب تشخیص دهد. مثلاً کاربر در فرم پشتیبانی کد HTML، دستور SQL، لینک، کاراکتر فارسی/عربی، JSON یا متن طولانی وارد می‌کند و WAF آن را حمله می‌بیند. به این حالت False Positive می‌گویند.

راه‌حل: کل WAF را خاموش نکنید. لاگ امنیتی را ببینید، Rule ID را پیدا کنید و فقط برای همان مسیر، همان Rule یا همان پارامتر Exception بسازید. برای مثال مسیرهای پنل مدیریت، callback پرداخت، API یا فرم خاص را جداگانه تنظیم کنید.

۲. فعال بودن WAF اما عبور حمله

اگر DNS دامنه از CDN عبور نکند، اگر IP اصلی سرور لو رفته باشد، اگر Origin مستقیماً از اینترنت قابل دسترسی باشد، یا اگر Ruleهای اصلی نصب/فعال نشده باشند، WAF ممکن است عملاً جلوی حمله را نگیرد.

  • رکورد DNS باید در حالت Proxy/Protected باشد، نه فقط DNS-only.
  • روی سرور اصلی فقط IPهای سرویس WAF/CDN اجازه اتصال به 80/443 داشته باشند.
  • قوانین Managed WAF و OWASP Core Ruleset باید واقعاً Deploy شده باشند.
  • Exceptionها نباید خیلی گسترده باشند؛ مثلاً کل دامنه را Skip نکنید.

۳. مشکل در ورود ادمین، wp-admin، admin-ajax و REST API

در وردپرس و ووکامرس، درخواست‌های `wp-admin`، `admin-ajax.php`، `wp-json`، checkout، پرداخت، آپلود تصویر و ذخیره تنظیمات افزونه‌ها ممکن است با WAF درگیر شوند. مخصوصاً وقتی فرم‌ها متن طولانی، کد، iframe، لینک یا JSON ارسال می‌کنند.

# نمونه بررسی سریع با SSH روی سرور
# در مسیرهای لاگ دنبال 403، ModSecurity، rule id یا denied بگردید
grep -RniE “modsecurity|denied|403|waf|rule id|949110” /usr/local/lsws/logs /var/log 2>/dev/null | tail -n 80

۴. کند شدن سایت بعد از WAF

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

راه‌حل: قوانین غیرضروری را فعال نکنید، Rate Limit را منطقی تنظیم کنید، فایل‌های استاتیک را از Ruleهای سنگین مستثنی کنید و برای مسیرهای API حساس، اول حالت Count/Log را تست کنید.

۵. اختلال در پرداخت آنلاین و وبهوک‌ها

درگاه پرداخت، سیستم پیامک، سرویس ارسال ایمیل، CRM، API صرافی، callback ووکامرس یا WHMCS ممکن است از IPها و User-Agentهای خاص درخواست بفرستند. اگر WAF همه درخواست‌های غیرمرورگری را Challenge کند، callback موفق نمی‌شود.

  • مسیرهای webhook و callback را بشناسید.
  • به‌جای خاموش کردن WAF، فقط همان مسیرها را با شرط دقیق Skip/Allow کنید.
  • اگر سرویس خارجی IP ثابت دارد، allowlist محدود بسازید.
  • بعد از هر تغییر، پرداخت تستی انجام دهید.

۶. بلاک شدن Googlebot، ابزارهای سئو یا اشتراک‌گذاری شبکه‌های اجتماعی

گاهی WAF یا Bot Protection اشتباهاً خزنده‌های معتبر را محدود می‌کند و در نتیجه Google Search Console، Facebook/Telegram preview یا ابزارهای مانیتورینگ سایت خطا می‌گیرند.

راه‌حل: برای ربات‌های معتبر از روش‌های رسمی تشخیص استفاده کنید. فقط بر اساس User-Agent اعتماد نکنید؛ چون قابل جعل است. لاگ Security Events و Access Log را با زمان دقیق خطا بررسی کنید.

WAF برای وردپرس، ووکامرس و سایت‌های ایرانی

وردپرس به دلیل محبوبیت بالا، هدف دائمی ربات‌ها و اسکنرهاست. WAF می‌تواند جلوی درخواست‌های مشکوک به `wp-login.php`، `xmlrpc.php`، `wp-admin`، افزونه‌های آسیب‌پذیر، اسکن مسیرهای قدیمی و تلاش‌های تزریق را کاهش دهد.

بخش سایت ریسک رایج پیشنهاد تنظیم WAF
wp-login.php Brute Force، Credential Stuffing Rate Limit، Challenge، محدودسازی کشور/IP در صورت نیاز
xmlrpc.php حملات brute force و سوءاستفاده از pingback اگر لازم ندارید، بلاک یا محدود کنید.
wp-admin حساس‌ترین بخش مدیریت Challenge، محدودیت IP، 2FA و استثنای دقیق برای admin-ajax
WooCommerce checkout اختلال پرداخت یا callback اول Count/Log، سپس Exception محدود برای callbackهای ضروری
فرم تماس و تیکت Spam، XSS، متن طولانی ترکیب WAF، CAPTCHA، Rate Limit و ضداسپم
آپلود فایل WebShell، MIME مخرب بررسی پسوند، MIME، حجم و مسیر ذخیره‌سازی خارج از اجرای PHP

چک‌لیست فعال‌سازی حرفه‌ای WAF

مرحله ۱: نقشه سایت و مسیرهای حساسقبل از فعال‌سازی، مسیرهای ورود، پرداخت، API، پنل مدیریت، webhook، آپلود و فرم‌های مهم را لیست کنید.
مرحله ۲: شروع با حالت Log/Countبرای سایت‌های فعال و فروشگاهی، ابتدا قوانین جدید را در حالت لاگ/Count تست کنید تا رفتار واقعی کاربران را ببینید.
مرحله ۳: فعال‌سازی تدریجی Ruleهااول قوانین اصلی مثل SQLi، XSS، Bad Bots و Rate Limit را فعال کنید؛ سپس Ruleهای سخت‌گیرانه‌تر را مرحله‌ای اضافه کنید.
مرحله ۴: تحلیل False Positiveهر 403 مهم را با زمان، IP، مسیر، Rule ID، پارامتر و User-Agent بررسی کنید.
مرحله ۵: Exception دقیق، نه خاموشی کاملاگر مشکلی پیش آمد، فقط همان Rule یا همان مسیر را Skip کنید، نه کل WAF یا کل دامنه را.
مرحله ۶: بستن مسیر مستقیم Originاگر از WAF ابری استفاده می‌کنید، سرور اصلی نباید از همه IPها مستقیم روی 80/443 قابل دسترسی باشد.
مرحله ۷: مانیتورینگ بعد از فعال‌سازیتا چند روز لاگ WAF، لاگ وب‌سرور، نرخ خطای 403، فرم‌ها، پرداخت و سرچ کنسول را بررسی کنید.

نمونه تست کنترل‌شده WAF با SSH

این تست‌ها را فقط روی سایت خودتان یا محیط تست انجام دهید. هدف، بررسی این است که WAF لاگ تولید می‌کند یا نه؛ نه حمله به سایت دیگران.

# تست ساده درخواست معمولی
curl -I https://example.com/

# تست کنترل‌شده برای بررسی حساسیت WAF روی پارامتر URL
curl -I “https://example.com/?q=test”

# تست مسیرهای مهم بعد از فعال‌سازی WAF
curl -I https://example.com/wp-login.php
curl -I https://example.com/wp-json/
curl -I https://example.com/cart/
curl -I https://example.com/checkout/

چک لاگ با SSH

# بررسی خطاهای وب‌سرور و WAF در سرورهای رایج
sudo tail -n 100 /var/log/nginx/error.log 2>/dev/null
sudo tail -n 100 /var/log/apache2/error.log 2>/dev/null
sudo tail -n 100 /usr/local/lsws/logs/error.log 2>/dev/null

# جستجوی خطاهای رایج WAF/ModSecurity
grep -RniE “ModSecurity|Access denied|Inbound Anomaly|949110|403” /var/log /usr/local/lsws/logs 2>/dev/null | tail -n 100

تنظیم حرفه‌ای WAF: قانون طلایی

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

در OWASP CRS، مدل امتیازدهی یا Anomaly Scoring یعنی هر Rule به درخواست امتیاز مشکوک بودن می‌دهد و وقتی مجموع امتیاز از آستانه مشخص عبور کند، درخواست بلاک می‌شود. اگر آستانه را بی‌دلیل خیلی بالا ببرید، حملات واقعی ممکن است عبور کنند؛ اگر خیلی سخت‌گیرانه تنظیم کنید، کاربران واقعی ممکن است 403 بگیرند. بنابراین تیونینگ باید براساس لاگ واقعی انجام شود.

مشکل نشانه اقدام درست
False Positive کاربر واقعی 403 می‌گیرد Rule ID و مسیر را پیدا کنید، Exception محدود بسازید.
False Negative حمله به Origin می‌رسد DNS/Proxy، Ruleهای فعال، Skipها و دسترسی مستقیم Origin را بررسی کنید.
Rule سخت‌گیرانه فرم‌ها، API یا پرداخت خراب می‌شود اول Count/Log، بعد Block مرحله‌ای.
Exception گسترده مسیرهای زیاد بدون محافظ می‌مانند Exception را به Host، Path، Method، IP یا Header دقیق محدود کنید.
لاگ ناکافی نمی‌دانید چه چیزی بلاک شده Security Events، Access Log و Error Log را هم‌زمان بررسی کنید.

سلام‌سرور چه کمکی می‌تواند بکند؟

برای بسیاری از کاربران، چالش اصلی خرید WAF نیست؛ چالش اصلی تنظیم درست آن است. اگر WAF اشتباه تنظیم شود، ممکن است پرداخت، فرم تماس، ورود کاربران، API یا حتی ایندکس شدن سایت دچار مشکل شود. در سلام‌سرور می‌توانیم هنگام راه‌اندازی سرور، وردپرس، هاست یا سرویس‌های مدیریتی، مسیر درست امنیت را پیشنهاد کنیم؛ از فعال‌سازی SSL و فایروال سرور تا تنظیم Cloudflare، ModSecurity، محدودسازی پورت‌ها، بررسی لاگ و ساخت Ruleهای دقیق.

پیشنهاد عملی: اگر سایت فروشگاهی یا شرکتی دارید، قبل از سخت‌گیر کردن WAF، یک لیست از مسیرهای پرداخت، callback، API، فرم‌های مهم و پنل مدیریت تهیه کنید. این لیست باعث می‌شود امنیت بالا برود بدون اینکه فروش یا تجربه کاربر خراب شود.

سوالات متداول درباره WAF

آیا WAF برای همه سایت‌ها لازم است؟

برای سایت‌های فروشگاهی، وردپرسی، سایت‌های دارای پنل کاربری، فرم تماس، API یا اطلاعات حساس بسیار توصیه می‌شود. سایت‌های ساده هم از WAF و Rate Limit سود می‌برند، اما باید متناسب با ریسک تنظیم شود.

آیا WAF جلوی هک شدن وردپرس را کامل می‌گیرد؟

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

Cloudflare WAF بهتر است یا ModSecurity؟

برای بسیاری از سایت‌ها ترکیب این دو بهتر است. Cloudflare در لبه شبکه و قبل از رسیدن درخواست به سرور کار می‌کند؛ ModSecurity روی خود سرور یا وب‌سرور فعال می‌شود. اگر Origin مستقیم بسته نشده باشد، WAF ابری قابل دور زدن است.

چرا بعد از فعال‌سازی WAF خطای 403 می‌گیرم؟

احتمالاً یک Rule درخواست سالم را مشکوک تشخیص داده است. باید لاگ WAF، Rule ID، مسیر درخواست، پارامتر و زمان خطا را بررسی کنید و Exception دقیق بسازید.

آیا باید کل Rule مشکل‌دار را خاموش کنم؟

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

آیا WAF باعث کندی سایت می‌شود؟

ممکن است کمی سربار ایجاد کند، اما در سرویس‌های CDN/WAF معمولاً کش و شبکه لبه باعث بهتر شدن سرعت کلی هم می‌شود. تنظیمات اشتباه، Ruleهای زیاد و بررسی بدنه‌های بزرگ می‌تواند کندی ایجاد کند.

برای درگاه پرداخت و وبهوک چه کار کنیم؟

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

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

WAF در برابر بخشی از حملات لایه ۷ کمک می‌کند، اما برای حملات حجمی بزرگ باید DDoS Protection، CDN، Rate Limit و فایروال شبکه هم داشته باشید.

بهترین روش شروع برای سایت زنده چیست؟

ابتدا WAF را در حالت Log/Count یا با حساسیت کم تست کنید، مسیرهای مهم را بررسی کنید، سپس مرحله‌ای قوانین را سخت‌تر کنید. برای سایت فروشگاهی، تست پرداخت و فرم‌ها ضروری است.

منابع و استانداردهای پیشنهادی برای مطالعه بیشتر

  • OWASP Web Application Firewall: تعریف WAF و کاربرد آن در محافظت از HTTP applicationها.
  • OWASP ModSecurity Core Rule Set: قوانین عمومی برای کاهش ریسک حملات رایج مثل SQL Injection و XSS.
  • Cloudflare WAF Documentation: مدیریت قوانین، Security Events، False Positive و False Negative.
  • AWS WAF Documentation: مفهوم Allow، Block، Count، CAPTCHA/Challenge و تست قوانین قبل از تولید.

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