فایروال WAF چیست و چگونه امنیت سایت را افزایش می‌دهد؟

فایروال WAF یا Web Application Firewall یک لایه امنیتی برای بررسی، فیلتر و کنترل ترافیک HTTP و HTTPS میان کاربران و برنامه وب است. WAF می‌تواند درخواست‌های مشکوک مانند برخی الگوهای SQL Injection، XSS، اسکن‌های خودکار، Bot Traffic و سوءاستفاده‌های رایج را قبل از رسیدن به سایت شناسایی یا مسدود کند و در کنار Secure Coding، به‌روزرسانی و تست امنیتی، سطح دفاع سایت را افزایش دهد.

وب‌سایت‌ها دیگر فقط مجموعه‌ای از صفحات HTML نیستند. فروشگاه اینترنتی، پنل مدیریت، API، سیستم ثبت‌نام، فرم ورود، آپلود فایل، پرداخت، جستجو، وب‌سرویس و ده‌ها قابلیت دیگر ممکن است دائماً Requestهای کاربران را دریافت و پردازش کنند. هر یک از این مسیرها می‌تواند بخشی از سطح حمله برنامه باشد.

از طرف دیگر، Firewall سنتی شبکه معمولاً اطلاعات کاملی درباره منطق درخواست HTTP ندارد. ممکن است اتصال به پورت 443 از نظر Network Firewall کاملاً مجاز باشد، اما همان اتصال حامل یک Request مخرب برای برنامه وب باشد. اینجاست که Web Application Firewall وارد معماری امنیتی می‌شود.

OWASP، WAF را یک Application Firewall برای برنامه‌های HTTP معرفی می‌کند که مجموعه‌ای از Ruleها را روی مکالمات HTTP اعمال می‌کند. OWASP همچنین توضیح می‌دهد که WAFها معمولاً برای مقابله با حملاتی مانند Cross-Site Scripting و SQL Injection به کار می‌روند و می‌توان آن‌ها را نوعی Reverse Proxy در نظر گرفت که از Web Application محافظت می‌کند.

اما یک نکته اساسی وجود دارد: WAF جای برنامه‌نویسی امن را نمی‌گیرد.

اگر سایت دارای Broken Access Control، ضعف Business Logic یا Permission اشتباه باشد، فایروال WAF الزاماً نمی‌تواند تشخیص دهد درخواست از نظر منطق کسب‌وکار غیرمجاز است. OWASP Web Security Testing Guide نیز اشاره می‌کند WAFها در برابر بعضی حملات مانند SQL Injection و XSS مؤثرند، اما در تشخیص مشکلاتی مانند کنترل دسترسی و Business Logic محدودیت دارند.

بنابراین WAF را باید بخشی از یک Defense in Depth دانست؛ یعنی معماری‌ای که در آن چندین لایه امنیتی به‌صورت هم‌زمان از سایت محافظت می‌کنند.

در این مقاله از رخنه کاو به‌طور کامل بررسی می‌کنیم فایروال WAF چیست، چگونه کار می‌کند، چه تفاوتی با Firewall شبکه دارد، انواع WAF کدام‌اند، چه حملاتی را شناسایی می‌کند، ModSecurity و OWASP Core Rule Set چه هستند، WAF ابری چه مزایایی دارد، چگونه باید Ruleها را تنظیم کرد و چگونه می‌توان از WAF برای افزایش امنیت سایت‌های وردپرسی، فروشگاه‌ها و APIها استفاده کرد.

WAF چیست؟

WAF مخفف Web Application Firewall است.

اگر بخواهیم مفهوم آن را بسیار ساده بیان کنیم، WAF لایه‌ای بین کاربر اینترنت و Web Application قرار می‌گیرد و Requestها را قبل از رسیدن به Backend بررسی می‌کند.

معماری ساده می‌تواند چنین باشد:

کاربر → WAF → وب‌سرور → برنامه → پایگاه‌داده

در حالت عادی، Request معتبر از WAF عبور کرده و به Application می‌رسد.

اما اگر Request با Ruleهای امنیتی یا سیاست‌های حفاظتی WAF ناسازگار باشد، بسته به تنظیمات ممکن است:

• ثبت شود؛
• امتیاز ریسک دریافت کند؛
• Challenge ایجاد شود؛
• Rate Limit شود؛
• یا کاملاً Block شود.

WAFها در سطح Application کار می‌کنند و می‌توانند بخش‌هایی از HTTP Request مانند Header، URL، Query String، Cookie و Request Body را بررسی کنند. NIST نیز توضیح می‌دهد WAF روی Requestهای Parse‌شده HTTP کار می‌کند و می‌تواند Policyهایی روی Headerها و Body درخواست اعمال کند.

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

برای درک نحوه کار Web Application Firewall باید ابتدا مسیر یک Request را تصور کنیم.

کاربر آدرس سایت را باز می‌کند.

مرورگر Request را ارسال می‌کند.

اگر WAF در جلوی سایت قرار گرفته باشد، Request ابتدا به WAF می‌رسد.

WAF سپس براساس Policy و Ruleهای تعریف‌شده Request را تحلیل می‌کند.

بررسی URL

مسیر مورد درخواست می‌تواند برای تشخیص رفتار غیرعادی بررسی شود.

برای مثال ممکن است یک Endpoint مدیریتی سیاست سخت‌گیرانه‌تری نسبت به صفحه عمومی سایت داشته باشد.

بررسی Query String

پارامترهای URL می‌توانند از نظر Patternهای غیرعادی، طول، Encoding و ساختار تحلیل شوند.

بررسی Headerها

WAF می‌تواند Headerهای HTTP را تحلیل کند.

برای مثال:

• Host
• Content-Type
• User-Agent
• Referer
• Authorization

ممکن است بخشی از Policy امنیتی باشند.

بررسی Cookie

Cookieها نیز جزئی از Request هستند و بسته به قابلیت WAF می‌توانند مورد تحلیل قرار گیرند.

بررسی Body درخواست

در Requestهایی مانند POST یا PUT، اطلاعات ممکن است در Body ارسال شوند.

WAFهای Application-Aware می‌توانند برخی Payloadها را Parse و بررسی کنند.

تصمیم‌گیری

پس از تحلیل Request، WAF باید تصمیم بگیرد:

Allow؟

Log؟

Challenge؟

Rate Limit؟

Block؟

این تصمیم ممکن است براساس یک Rule واحد یا مجموع چند نشانه گرفته شود.

چرا Firewall معمولی برای امنیت سایت کافی نیست؟

Network Firewall و Web Application Firewall هر دو Firewall هستند، اما در لایه‌های متفاوتی کار می‌کنند.

Firewall شبکه بیشتر روی مواردی مانند:

• IP
• Port
• Protocol
• Connection

تمرکز دارد.

فرض کنید یک وب‌سایت HTTPS روی پورت 443 فعال است.

Firewall شبکه باید اجازه اتصال کاربران به پورت 443 را بدهد؛ در غیر این صورت سایت قابل استفاده نخواهد بود.

حالا مهاجم نیز از همان پورت 443 یک Request HTTP ارسال می‌کند.

از نظر Network Firewall این Traffic ممکن است کاملاً عادی باشد:

IP → سرور TCP → 443 TLS → مجاز

اما محتوای Application Request می‌تواند غیرعادی باشد.

WAF دقیقاً برای دیدن همین لایه طراحی شده است.

OWASP توضیح می‌دهد در حالی که Proxyها معمولاً برای محافظت از Clientها استفاده می‌شوند، WAF از Server و Web Application محافظت می‌کند و Ruleهایی را بر ارتباط HTTP اعمال می‌کند.

تفاوت WAF و Firewall شبکه چیست؟

این دو جای یکدیگر را نمی‌گیرند.

در معماری حرفه‌ای ممکن است هر دو وجود داشته باشند.

تفاوت WAF و Reverse Proxy چیست؟

Reverse Proxy واسطه‌ای بین Client و Backend است.

Client به Reverse Proxy وصل می‌شود و Reverse Proxy Request را به Server مناسب انتقال می‌دهد.

WAF نیز در بسیاری از Deploymentها به شکل Reverse Proxy عمل می‌کند، اما هدف اصلی آن بررسی امنیتی Traffic است.

یک Reverse Proxy ممکن است قابلیت‌هایی مانند:

• TLS Termination
• Load Balancing
• Cache
• Routing

ارائه دهد.

WAF قابلیت‌های امنیت Application را به این جریان اضافه می‌کند.

امروزه بسیاری از سرویس‌های Cloud یک Edge Platform ایجاد کرده‌اند که CDN، Reverse Proxy، WAF، Bot Management و DDoS Protection را در یک لایه ترکیب می‌کند.

WAF چه تفاوتی با IDS و IPS دارد؟

IDS یا Intrusion Detection System معمولاً برای تشخیص رفتار مشکوک استفاده می‌شود.

IPS یا Intrusion Prevention System علاوه بر تشخیص می‌تواند برای جلوگیری از Traffic مخرب اقدام کند.

اما WAF به‌طور تخصصی روی Application Traffic وب متمرکز است.

ممکن است یک IPS Pattern شبکه را بررسی کند، در حالی که WAF ساختار HTTP Request را تحلیل می‌کند.

OWASP WSTG نیز WAF را سیستمی معرفی می‌کند که محتوای HTTP Request را بررسی کرده و Requestهای مشکوک یا مخرب را Block می‌کند.

WAF در کجای معماری سایت قرار می‌گیرد؟

Web Application Firewall را می‌توان در نقاط مختلفی مستقر کرد.

روی همان Web Server

در بعضی معماری‌ها WAF به‌صورت Module یا Software روی Server نصب می‌شود.

مزیت:

کنترل زیاد.

محدودیت:

Traffic مخرب قبل از رسیدن به Server حذف نشده و همچنان منابع شبکه و سیستم را مصرف می‌کند.

روی Server یا Appliance جداگانه

WAF می‌تواند به شکل Gateway در جلوی Web Server قرار گیرد.

Traffic ابتدا از این سیستم عبور می‌کند.

در Cloud یا Edge

در این مدل DNS یا Routing سایت به Provider امنیتی هدایت می‌شود.

Traffic قبل از رسیدن به Origin Server در شبکه Provider بررسی می‌شود.

OWASP نیز این سه مدل کلی را برای Deployment WAF مطرح می‌کند: روی Web Server، روی ماشین یا Appliance مجزا، یا در Cloud جلوی Backend.

انواع WAF چیست؟

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

WAF مبتنی بر شبکه

Network-Based WAF معمولاً به‌صورت Appliance فیزیکی یا مجازی در زیرساخت قرار می‌گیرد.

مزایا:

• Latency قابل کنترل
• کنترل زیاد روی زیرساخت
• امکان استفاده در Data Center خصوصی

معایب:

• هزینه بالا
• نیاز به نگهداری
• نیاز به تیم متخصص
• Scaling پیچیده‌تر

این مدل بیشتر برای سازمان‌های بزرگ یا محیط‌هایی که کنترل Infrastructure اهمیت زیادی دارد استفاده می‌شود.

WAF مبتنی بر Host

Host-Based WAF در نزدیکی یا روی Web Server اجرا می‌شود.

ModSecurity نمونه معروفی از WAF Engineهای Open Source است که می‌تواند با Web Serverهای مختلف استفاده شود.

OWASP Developer Guide، ModSecurity را یک Web Application Firewall متن‌باز معرفی می‌کند که سابقه آن به سال 2002 می‌رسد و از سال 2024 به پروژه Production در OWASP منتقل شده است.

مزایای Host-Based WAF:

• انعطاف بالا
• کنترل Ruleها
• مناسب برای زیرساخت شخصی
• هزینه License پایین‌تر در گزینه‌های Open Source

معایب:

• مصرف منابع Server
• نیاز به تنظیم Rule
• احتمال False Positive
• نیاز به Update و Maintenance

WAF ابری

Cloud WAF در شبکه Provider قرار می‌گیرد.

در این معماری Traffic معمولاً قبل از رسیدن به Origin بررسی می‌شود.

مزایا:

• راه‌اندازی نسبتاً سریع
• Scaling آسان‌تر
• ظرفیت بالا
• قابلیت ترکیب با CDN
• محافظت بهتر Origin در معماری صحیح
• Ruleهای Managed

برای بسیاری از سایت‌های عمومی، WAF ابری یکی از ساده‌ترین روش‌ها برای اضافه کردن لایه امنیتی در Edge است.

اما فقط فعال کردن Cloud WAF کافی نیست.

اگر IP واقعی Origin Server مستقیماً از اینترنت قابل دسترسی باشد و Firewall سرور اجازه اتصال عمومی بدهد، ممکن است Traffic از مسیر مستقیم به Backend برسد و Edge WAF عملاً دور زده شود.

بنابراین Origin باید به‌درستی Restrict شود.

WAF چه حملاتی را شناسایی می‌کند؟

توانایی واقعی WAF به Engine، Rule Set، Configuration و معماری بستگی دارد.

بااین‌حال چند دسته حمله معمولاً هدف WAF هستند.

SQL Injection

SQL Injection زمانی رخ می‌دهد که ورودی کنترل‌نشده بتواند روی Query پایگاه‌داده تأثیر ناخواسته بگذارد.

WAF ممکن است Patternهای مشکوک مرتبط با SQL Injection را در Parameterها تشخیص دهد.

OWASP CRS نیز Ruleهایی برای محافظت در برابر دسته‌هایی مانند SQL Injection ارائه می‌دهد.

اما نکته مهم:

WAF جای Prepared Statement و Parameterized Query را نمی‌گیرد.

رفع واقعی SQL Injection باید در Application Code انجام شود.

Cross-Site Scripting یا XSS

WAF می‌تواند بعضی Payloadهای رایج XSS را شناسایی کند.

برای مثال Patternهای مشکوکی که تلاش دارند محتوای Scriptمانند وارد برنامه کنند.

OWASP WAF و Core Rule Set صراحتاً XSS را از حملاتی معرفی می‌کنند که Ruleهای WAF برای آن‌ها استفاده می‌شوند.

بااین‌حال دفاع اصلی XSS همچنان:

• Output Encoding
• Context-Aware Escaping
• Sanitization
• CSP

است.

Local File Inclusion

برخی WAF Rule Setها Patternهای مربوط به File Inclusion را بررسی می‌کنند.

OWASP CRS از Local File Inclusion نیز به‌عنوان یکی از Attack Categoryهای تحت پوشش خود نام می‌برد.

Protocol Violation

WAF می‌تواند Requestهایی را که از نظر HTTP Structure غیرعادی هستند شناسایی کند.

این مسئله در کاهش Attack Surface و حذف Requestهای Malformed مفید است.

Scanner و Bot Traffic

برخی WAFهای مدرن قابلیت Bot Detection یا Integration با Bot Management دارند.

Traffic ابزارهای خودکار می‌تواند براساس:

• Rate
• Fingerprint
• رفتار
• Reputation
• Challenge Result

تحلیل شود.

حملات Brute Force

WAF می‌تواند به کمک Rate Limiting یا Ruleهای Authentication Endpoint حجم Login Attemptها را محدود کند.

اما دفاع کامل Brute Force باید داخل Application نیز وجود داشته باشد.

MFA، Account-Level Throttling و Monitoring همچنان مهم هستند.

Application DDoS

برای DDoS لایه Application، WAF می‌تواند Requestهای پرتکرار یا Patternهای Bot را محدود کند.

اما WAF روی Server نمی‌تواند یک حمله Volumetric بزرگ را که پهنای باند را قبل از رسیدن به برنامه اشباع کرده است متوقف کند.

برای آن به DDoS Protection و Edge Capacity نیاز است.

WAF چه حملاتی را نمی‌تواند به‌خوبی متوقف کند؟

این بخش شاید مهم‌تر از فهرست قابلیت‌ها باشد.

WAF ابزار قدرتمندی است، اما جادو نمی‌کند.

Broken Access Control

فرض کنید API به User اجازه می‌دهد اطلاعات User دیگری را مشاهده کند.

Request از نظر Syntax کاملاً عادی است.

هیچ SQL Injection یا XSS وجود ندارد.

WAF از کجا باید بداند این User اجازه مشاهده آن Object را ندارد؟

این مشکل باید در Authorization Backend حل شود.

OWASP نیز WAF را در برابر ضعف‌های Access Control کم‌اثرتر از حملاتی مانند SQL Injection یا XSS می‌داند.

Business Logic Flaw

فرض کنید سایت Coupon را فقط یک بار باید قبول کند، اما Backend اجازه استفاده چندباره می‌دهد.

Requestها ممکن است کاملاً قانونی باشند.

WAF منطق تجاری فروشگاه را نمی‌داند.

این ضعف با Secure Design و Business Logic Testing برطرف می‌شود.

Credential Theft

اگر Password واقعی User از طریق Phishing سرقت شده باشد، Login Request ممکن است کاملاً معتبر به نظر برسد.

WAF به‌تنهایی نمی‌تواند مالک واقعی Credential را تشخیص دهد.

MFA و Risk-Based Authentication اهمیت دارند.

آسیب‌پذیری‌های داخل Server

WAF Requestهای Web را بررسی می‌کند.

اگر Server نرم‌افزار آسیب‌پذیر دیگری داشته باشد که از مسیر HTTP محافظت‌شده قابل دسترسی نیست، WAF الزاماً کمکی نمی‌کند.

Misconfiguration داخلی

WAF نمی‌تواند همه تنظیمات اشتباه برنامه را جبران کند.

برای مثال Secret ذخیره‌شده در Repository یا Permission اشتباه Cloud نیازمند کنترل‌های دیگری است.

مدل امنیتی Negative در WAF چیست؟

یکی از روش‌های رایج WAF، Negative Security Model است.

در این مدل WAF می‌گوید:

«هر Trafficی مجاز است مگر اینکه با الگوی مشکوک شناخته‌شده Match شود.»

Signatureها، Regexها و Ruleهای Generic معمولاً در این دسته هستند.

مزیت:

اجرای سریع‌تر روی Applicationهای عمومی.

معایب:

ممکن است حمله جدید یا Payload متفاوت از Rule عبور کند.

Positive Security Model چیست؟

در Positive Security Model رویکرد برعکس است:

«فقط چیزی مجاز است که از قبل به‌عنوان رفتار صحیح تعریف شده باشد.»

برای مثال Endpoint ممکن است فقط این ساختار را قبول کند:

• Method مشخص
• Content-Type مشخص
• Fieldهای مشخص
• طول مشخص
• Type مشخص

این مدل می‌تواند بسیار قوی باشد، اما نیازمند شناخت دقیق Application و Maintenance بیشتر است.

برای APIهایی که Schema مشخص دارند، Positive Validation می‌تواند بسیار ارزشمند باشد.

ترکیب Positive و Negative Security

در عمل معماری حرفه‌ای می‌تواند هر دو مدل را ترکیب کند.

Negative Rules:

برای Attack Patternهای عمومی.

Positive Rules:

برای Endpointهای حساس و Structureهای شناخته‌شده.

این ترکیب نسبت به تکیه کامل بر Signature می‌تواند پوشش بیشتری ایجاد کند.

OWASP Core Rule Set یا CRS چیست؟

یکی از مهم‌ترین مفاهیم هنگام صحبت درباره WAF متن‌باز، OWASP Core Rule Set است.

CRS مجموعه‌ای از Ruleهای عمومی تشخیص حمله برای ModSecurity و WAFهای سازگار است.

OWASP توضیح می‌دهد CRS برای محافظت از Web Applicationها در برابر طیف گسترده‌ای از حملات طراحی شده و تلاش می‌کند این کار را با حداقل Alert اشتباه انجام دهد. این Rule Set دسته‌هایی مانند SQL Injection، XSS و Local File Inclusion را پوشش می‌دهد.

WAF Engine و Rule Set یکی نیستند

این تفاوت بسیار مهم است.

ModSecurity:

Engine است.

OWASP CRS:

مجموعه Ruleهاست.

می‌توان گفت Engine توانایی خواندن و اجرای Policy را فراهم می‌کند و CRS بخشی از Policy امنیتی را ارائه می‌دهد.

ModSecurity چیست؟

ModSecurity یکی از شناخته‌شده‌ترین WAF Engineهای Open Source است.

طبق مستندات OWASP، این پروژه ابتدا برای Apache طراحی شد اما در طول زمان قابلیت استفاده در پلتفرم‌های مختلف مانند Apache، IIS و Nginx پیدا کرده است.

ModSecurity بدون Configuration مناسب راهکار کامل نیست.

در Deployment واقعی معمولاً باید Rule Set مانند OWASP CRS به آن اضافه و تنظیم شود. OWASP Developer Guide نیز تصریح می‌کند که ModSecurity برای استفاده عملی نیازمند Configuration است و CRS یکی از گزینه‌های اصلی برای این کار است.

Coraza WAF چیست؟

Coraza یک WAF Framework متن‌باز است که از Syntax سازگار با ModSecurity و OWASP CRS پشتیبانی می‌کند.

OWASP آن را در اکوسیستم WAFهای Open Source خود در کنار ModSecurity و CRS معرفی کرده است.

برای مدیر سایت معمولی مهم‌ترین نکته این نیست که کدام Engine محبوب‌تر است؛ بلکه باید بداند کیفیت واقعی دفاع به:

• Ruleها
• Configuration
• Tuning
• Update
• Monitoring

بستگی دارد.

Rule در WAF چیست؟

Rule مشخص می‌کند WAF چه چیزی را بررسی کند و در صورت مشاهده چه اقدامی انجام دهد.

یک Rule ممکن است روی:

• URL
• Header
• Cookie
• Query Parameter
• Request Body
• Response

عمل کند.

Rule می‌تواند بسیار عمومی یا کاملاً مخصوص Application باشد.

Managed Rule

Provider Rule را نگهداری و Update می‌کند.

مزیت:

مدیریت ساده‌تر.

Custom Rule

تیم سایت Rule اختصاصی ایجاد می‌کند.

برای مثال:

Endpoint /admin فقط از IPهای خاص در دسترس باشد.

یا:

Endpoint ارسال OTP محدودیت سخت‌گیرانه‌تری داشته باشد.

Custom Rule می‌تواند بسیار مؤثر باشد، اما Rule اشتباه ممکن است User واقعی را Block کند.

Anomaly Scoring چیست؟

بعضی WAFها به‌جای اینکه با مشاهده اولین Pattern مشکوک بلافاصله Request را Block کنند، برای نشانه‌های مختلف امتیاز Risk در نظر می‌گیرند.

برای مثال Request ممکن است چند Rule را Trigger کند.

مجموع امتیاز از Threshold عبور می‌کند.

سپس Request Block می‌شود.

این مدل باعث می‌شود Policy انعطاف بیشتری داشته باشد و امکان Tuning بهتر شود.

OWASP CRS نیز در Deploymentهای رایج از مدل Scoring برای جمع‌کردن شدت Ruleهای Triggerشده استفاده می‌کند.

False Positive در WAF چیست؟

False Positive یعنی WAF یک Request سالم را مخرب تشخیص دهد.

این یکی از مهم‌ترین مشکلات عملی WAFهاست.

فرض کنید یک سایت برنامه‌نویسی اجازه می‌دهد کاربران داخل مقاله نمونه Code ذخیره کنند.

یک متن آموزشی ممکن است شامل عبارت‌های SQL یا JavaScript باشد.

WAF Generic ممکن است این ورودی را به‌اشتباه Attack تشخیص دهد.

اگر بدون Tuning، Blocking بسیار سخت‌گیرانه فعال شود، کاربران واقعی دچار مشکل می‌شوند.

OWASP نیز اشاره می‌کند Customization و نگهداری WAF می‌تواند نیازمند تلاش قابل توجهی باشد و با تغییر Application باید Policy نیز Maintenance شود.

False Negative چیست؟

False Negative برعکس است.

Request واقعاً مخرب است اما WAF آن را تشخیص نمی‌دهد.

هیچ WAFی پوشش ۱۰۰ درصد ندارد.

Payload جدید، Encoding غیرمعمول یا Attack Logic متفاوت ممکن است از Ruleهای موجود عبور کند.

همین موضوع نشان می‌دهد WAF باید مکمل Secure Coding باشد.

WAF را ابتدا روی Block Mode قرار دهیم؟

در یک سیستم Production حساس، فعال کردن مجموعه بزرگی از Ruleهای جدید در Blocking Mode بدون بررسی می‌تواند خطرناک باشد.

رویکرد منطقی‌تر معمولاً:

مرحله اول: Detection

Traffic بررسی و Log شود.

مرحله دوم: تحلیل

False Positiveها شناسایی شوند.

مرحله سوم: Tuning

Exceptionهای دقیق ایجاد شوند.

مرحله چهارم: Blocking

Ruleهای مطمئن به حالت Block منتقل شوند.

البته روش دقیق به Provider و حساسیت سایت بستگی دارد.

WAF Tuning چیست؟

Tuning یعنی تنظیم Ruleها براساس رفتار واقعی Application.

هدف این نیست که تمام Ruleهای مزاحم Disable شوند.

هدف ایجاد تعادل میان:

امنیت

و

False Positive پایین

است.

Tuning صحیح

Exception فقط برای:

Endpoint مشخص

Parameter مشخص

Rule مشخص

تعریف می‌شود.

Tuning اشتباه

غیرفعال کردن کامل SQL Injection Detection برای کل سایت فقط چون یک Form مشکل ایجاد کرده است.

اصل مهم:

Exception باید تا حد ممکن کوچک و دقیق باشد.

WAF و SSL/TLS چگونه با هم کار می‌کنند؟

بخش عمده Traffic وب امروز HTTPS است.

اگر WAF قرار است محتوای HTTP را بررسی کند باید در نقطه‌ای قرار گیرد که Traffic پس از TLS Termination قابل تحلیل باشد.

در Cloud WAF معمولاً TLS در Edge Provider Terminate شده و سپس Traffic امن به Origin منتقل می‌شود.

این معماری باید با Certificate Management و Encryption مناسب بین Edge و Origin همراه باشد.

WAF و CDN چه تفاوتی دارند؟

CDN برای Delivery محتوا و کاهش Latency طراحی شده است.

WAF برای Security Filtering.

اما Providerهای مدرن اغلب این دو را ترکیب می‌کنند.

CDN می‌تواند:

• فایل Static را Cache کند.
• Traffic را از Edge پاسخ دهد.
• Load Origin را کاهش دهد.

WAF همان Edge می‌تواند:

• Request را بررسی کند.
• Attack Pattern را Block کند.
• Rate Limit اعمال کند.

این ترکیب علاوه بر امنیت، Availability را نیز افزایش می‌دهد.

WAF و DDoS Protection چه تفاوتی دارند؟

WAF عمدتاً روی Application Traffic تمرکز دارد.

DDoS Protection می‌تواند لایه‌های Network و Volumetric را نیز پوشش دهد.

برای مثال یک حمله حجیم ممکن است صدها گیگابیت Traffic ایجاد کند.

اگر WAF داخل Origin Server باشد، پهنای باند قبل از رسیدن Request به WAF اشباع می‌شود.

بنابراین DDoS Protection باید در Upstream یا Edge انجام شود.

برای Layer 7 DDoS، WAF و Rate Limiting نقش بیشتری دارند.

Rate Limiting در WAF چیست؟

Rate Limiting تعداد Request مجاز را در یک Window زمانی کنترل می‌کند.

برای مثال Policy می‌تواند برای Endpoint Login محدودیت متفاوتی نسبت به صفحه اصلی داشته باشد.

اما Rate Limit صحیح نباید فقط براساس یک IP ساده طراحی شود.

در معماری پیشرفته ممکن است سیگنال‌هایی مانند:

• IP
• Session
• User
• API Key
• Endpoint
• Reputation

در نظر گرفته شوند.

WAF و Bot Management

Botها فقط مهاجم نیستند.

Search Engine Crawler نیز Bot است.

Monitoring System نیز Bot است.

هدف Bot Management تفکیک Traffic خودکار مجاز از Automation مخرب است.

WAFهای پیشرفته می‌توانند با Bot Management ترکیب شوند و رفتارهایی مانند:

• Scraping
• Credential Stuffing
• Automated Signup
• Spam

را محدود کنند.

WAF و API Security

APIها نیز HTTP Traffic دریافت می‌کنند و WAF می‌تواند بخشی از دفاع آن‌ها باشد.

NIST SP 800-228-upd1 توضیح می‌دهد WAF می‌تواند Metadata و Payload Request را بدون دخالت مستقیم Application بررسی کند و به‌عنوان Policy متمرکز مفید باشد، اما WAF معمولاً درک کامل API Schema و منطق API را ندارد؛ بنابراین یک مرحله خوب در دفاع است ولی راهکار کامل API Security نیست.

مثال

WAF می‌تواند Pattern شبیه SQL Injection را تشخیص دهد.

اما الزاماً نمی‌تواند بداند:

Field name باید String با طول کمتر از مقدار مشخص باشد.

یا:

User شماره ۱ اجازه مشاهده Order شماره ۲ را ندارد.

این کنترل‌ها باید در API Gateway، Schema Validation و Application انجام شوند.

WAAP چیست؟

در معماری‌های جدید اصطلاح WAAP یا Web Application and API Protection بیشتر دیده می‌شود.

WAAP معمولاً مجموعه‌ای از قابلیت‌ها مانند:

• WAF
• API Protection
• Bot Management
• DDoS Protection

را در یک Platform ترکیب می‌کند.

این مفهوم نشان می‌دهد امنیت Web دیگر فقط Signature-Based Filtering نیست و سرویس‌های مدرن باید طیف گسترده‌تری از Threatها را پوشش دهند.

NIST نیز در راهنمای امنیت APIهای Cloud-Native به Web Application and API Protection اشاره می‌کند.

WAF در سایت وردپرسی

وردپرس نیز مانند هر Web Application دیگری می‌تواند پشت WAF قرار گیرد.

WAF برای WordPress می‌تواند به‌خصوص در کاهش Trafficهای:

• Scanner
• Bot
• Login Abuse
• Payloadهای شناخته‌شده
• درخواست‌های غیرعادی

مفید باشد.

اما نباید تصور کرد نصب WAF یعنی دیگر نیازی به Update وردپرس نیست.

WAF جای آپدیت وردپرس را نمی‌گیرد

هسته WordPress، قالب و افزونه‌ها باید به‌روز نگه داشته شوند.

اگر Plugin دارای Vulnerability باشد، WAF ممکن است در بعضی موارد Virtual Patch ایجاد کند، اما Patch واقعی همچنان ضروری است.

Virtual Patching چیست؟

Virtual Patching یعنی ایجاد Rule در WAF برای مسدود کردن مسیر Exploit یک Vulnerability بدون تغییر فوری Application Code.

این قابلیت زمانی بسیار ارزشمند است که:

Patch رسمی هنوز آماده نیست.

یا:

Deploy Patch نیازمند زمان است.

در این شرایط WAF می‌تواند Window خطر را کاهش دهد.

اما Virtual Patch باید موقت تلقی شود.

راهکار اصلی اصلاح Vulnerability است.

محافظت از wp-login.php با WAF

یکی از کاربردهای رایج WAF در WordPress محافظت از Login Endpoint است.

می‌توان:

• Rate Limit
• Bot Challenge
• Geo Policy
• IP Restriction برای Adminهای ثابت

تعریف کرد.

بااین‌حال MFA و Password Policy همچنان لازم هستند.

محافظت از wp-admin

اگر سایت فقط چند مدیر ثابت دارد، می‌توان Policy سخت‌گیرانه‌تری برای مسیرهای مدیریتی تعریف کرد.

مثلاً:

• IP Allowlist در محیط سازمانی
• MFA
• Challenge
• Session Policy

اما هر Rule باید متناسب با شرایط واقعی سایت باشد.

WAF و XML-RPC وردپرس

برخی سایت‌ها به XML-RPC نیاز ندارند.

در چنین شرایطی می‌توان دسترسی را محدود کرد.

اما اگر Jetpack یا Integration دیگری به آن نیاز داشته باشد، Block کامل می‌تواند عملکرد سایت را مختل کند.

Policy باید براساس نیاز واقعی تنظیم شود.

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

بعضی افزونه‌ها قابلیت Firewall دارند، اما Architecture آن‌ها یکسان نیست.

Firewall داخل WordPress

Request ممکن است ابتدا به Server و PHP برسد و سپس Plugin آن را بررسی کند.

Cloud WAF

Request قبل از رسیدن به Origin تحلیل می‌شود.

برای حملات پرحجم، Edge WAF مزیت معماری مهمی دارد چون Traffic مخرب زودتر حذف می‌شود.

WAF برای فروشگاه اینترنتی

فروشگاه دارای Endpointهای حساس متعددی است:

• Login
• Cart
• Checkout
• Coupon
• Search
• Account
• API
• Payment Callback

استفاده از Rule عمومی برای تمام این مسیرها همیشه مناسب نیست.

برای مثال Checkout باید False Positive بسیار کمی داشته باشد.

Search ممکن است Input آزاد بیشتری بپذیرد.

Login نیازمند Rate Limit است.

در نتیجه WAF فروشگاه باید Endpoint-Aware تنظیم شود.

آیا WAF روی سئو اثر دارد؟

WAF مستقیماً ابزار SEO نیست.

اما Configuration اشتباه می‌تواند روی Crawl اثر منفی بگذارد.

اگر Googlebot یا Search Engineهای معتبر به‌اشتباه Block شوند، Crawl سایت مختل می‌شود.

همچنین Challenge بیش از حد می‌تواند دسترسی کاربران را دشوار کند.

بنابراین Bot Management و Firewall Ruleها باید با Log و Monitoring بررسی شوند.

از سوی دیگر، کاهش Downtime و جلوگیری از Defacement یا Infection به سلامت کلی سایت کمک می‌کند.

WAF و Performance سایت

WAF یک مرحله اضافه در Request Path است.

اما یک Cloud WAF مناسب معمولاً همراه CDN و Edge Network ارائه می‌شود و در عمل ممکن است Performance کلی نیز بهتر شود.

بااین‌حال Ruleهای بسیار سنگین یا Inspection بیش از حد می‌توانند Latency ایجاد کنند.

بنابراین Performance Monitoring ضروری است.

چگونه یک WAF مناسب انتخاب کنیم؟

انتخاب WAF نباید فقط براساس نام برند انجام شود.

چند سؤال مهم باید پاسخ داده شوند.

سایت چه نوعی است؟

وردپرس؟

API؟

SaaS؟

فروشگاه؟

Traffic چقدر است؟

ظرفیت Provider باید متناسب باشد.

آیا DDoS Protection لازم است؟

برای سایت مهم، بهتر است WAF با Edge DDoS Protection ترکیب شود.

آیا Managed Rule ارائه می‌شود؟

برای تیم کوچک، Managed Rule می‌تواند Maintenance را آسان‌تر کند.

Custom Rule چقدر انعطاف دارد؟

آیا می‌توانید Policy مخصوص Endpoint ایجاد کنید؟

Logging چقدر کامل است؟

بدون Log مناسب Tuning دشوار خواهد بود.

SIEM Integration وجود دارد؟

سازمان‌های بزرگ ممکن است Eventها را به SIEM ارسال کنند.

API Security ارائه می‌شود؟

اگر معماری API-محور است، WAF سنتی شاید کافی نباشد.

False Positive چگونه مدیریت می‌شود؟

Exception باید Granular باشد.

چک‌لیست نصب و راه‌اندازی WAF

پیش از فعال‌سازی Blocking جدی بهتر است این مراحل طی شوند:

• Inventory دامنه‌ها مشخص شود.
• Origin Server شناسایی شود.
• Traffic معمول Baseline شود.
• HTTPS Configuration بررسی شود.
• Managed Rules فعال شوند.
• Detection Mode بررسی شود.
• False Positiveها ثبت شوند.
• Ruleهای پرخطا Tune شوند.
• Endpointهای حساس مشخص شوند.
• Rate Limit اختصاصی تعریف شود.
• Login و Admin Policy ایجاد شود.
• API Ruleهای جداگانه داشته باشد.
• Origin فقط از Proxyهای مجاز Traffic بپذیرد.
• Log و Alert فعال شود.
• Rollback Plan وجود داشته باشد.
• Ruleها به‌صورت دوره‌ای Review شوند.

چگونه Origin را پشت WAF محافظت کنیم؟

این یکی از مهم‌ترین بخش‌هایی است که گاهی فراموش می‌شود.

فرض کنید Domain به Cloud WAF اشاره می‌کند.

اما IP واقعی Origin Server هنوز عمومی است.

اگر مهاجم IP را پیدا کند، ممکن است مستقیماً به Server Request بفرستد.

برای جلوگیری از این وضعیت:

Firewall سرور باید فقط Networkهای Provider یا Load Balancer مورد اعتماد را بپذیرد.

همچنین بهتر است سرویس‌های غیرضروری Public نباشند.

اما این محدودسازی باید با دقت انجام شود تا Maintenance و Monitoring دچار اختلال نشوند.

Logging در WAF

WAF بدون Logging فقط یک Black Box است.

Log باید کمک کند بفهمیم:

• چه Requestی Block شده؟
• چه Ruleی Trigger شده؟
• Source چه بوده؟
• Endpoint چه بوده؟
• Action چه بوده؟
• آیا Pattern تکراری است؟

این اطلاعات برای Incident Response و Tuning بسیار ارزشمند هستند.

چه چیزی را در WAF Log نکنیم؟

Request ممکن است شامل داده حساس باشد.

برای مثال:

• Authorization Header
• Session Cookie
• Password
• API Key
• اطلاعات شخصی

Logging بدون Masking می‌تواند Risk جدید ایجاد کند.

Provider و Configuration باید طوری تنظیم شوند که Secretها بی‌دلیل در Log ذخیره نشوند.

Alerting در WAF

تمام Blockها نیازمند Alert فوری نیستند.

سایت عمومی ممکن است روزانه هزاران Bot یا Scanner ببیند.

اگر برای هر Event Alert ایجاد شود، Alert Fatigue رخ می‌دهد.

Alert بهتر است برای Patternهایی مانند:

• افزایش ناگهانی Attack Rate
• حمله روی Admin
• Trigger شدن Rule بسیار حساس
• حملات موفق احتمالی
• Traffic غیرعادی روی API
• افزایش Block از یک User معتبر

تنظیم شود.

WAF و SIEM

در سازمان‌های بزرگ Logهای WAF می‌توانند وارد SIEM شوند.

سپس Eventهای WAF با اطلاعات:

• Authentication
• Server
• Endpoint
• EDR
• Cloud

Correlation می‌شوند.

برای مثال:

WAF Attack Alert

*

Login Success غیرعادی

می‌تواند اهمیت بیشتری از هر Event به‌تنهایی داشته باشد.

اشتباهات رایج هنگام استفاده از WAF

تصور اینکه WAF سایت را ضد هک می‌کند

هیچ WAFی تضمین امنیت کامل نمی‌دهد.

WAF فقط یک لایه است.

استفاده از Ruleهای پیش‌فرض بدون Tuning

هر Application رفتار متفاوتی دارد.

Rule پیش‌فرض باید با Traffic واقعی بررسی شود.

Disable کردن Ruleهای زیاد

هر False Positive نباید با خاموش کردن کامل Rule حل شود.

Exception باید دقیق باشد.

محافظت نکردن Origin

Cloud WAF زمانی مفیدتر است که مسیر مستقیم Origin بسته باشد.

نداشتن Monitoring

ممکن است Attack در Log ثبت شود اما هیچ‌کس آن را بررسی نکند.

فراموش کردن API

گاهی سایت اصلی پشت WAF است ولی api.example.com مستقیماً به Server اشاره می‌کند.

Attack Surface باید کامل Inventory شود.

استفاده از IP Blocking دستی برای همه‌چیز

IP فقط یکی از Signalهاست.

Botnet و Proxy می‌توانند IP را تغییر دهند.

Rule بسیار سخت‌گیرانه

Block کردن Userهای واقعی می‌تواند خسارت عملیاتی بزرگی ایجاد کند.

عدم تست بعد از تغییر سایت

هر Feature جدید می‌تواند با Ruleهای موجود Interaction متفاوتی داشته باشد.

آیا WAF می‌تواند Zero-Day را متوقف کند؟

پاسخ قطعی خیر است.

WAF ممکن است رفتار یا Pattern عمومی Exploit را تشخیص دهد، حتی اگر Vulnerability جدید باشد.

برای مثال اگر Zero-Day در نهایت نیازمند Pattern خاصی از Injection باشد، Rule عمومی ممکن است بخشی از حملات را Block کند.

اما تضمینی وجود ندارد.

به همین دلیل Patch Management، Threat Intelligence و Incident Response همچنان ضروری هستند.

WAF و Patch Management

WAF می‌تواند فاصله زمانی میان کشف Vulnerability و نصب Patch را کاهش خطر دهد.

اما نباید باعث شود Update به تعویق بیفتد.

یک Rule WAF ممکن است:

• ناقص باشد.
• Bypass شود.
• فقط یک Vector را پوشش دهد.

Patch واقعی Root Cause را حل می‌کند.

تست WAF چگونه انجام می‌شود؟

تست فقط باید روی سیستم خودتان یا سیستمی که مجوز صریح دارید انجام شود.

هدف تست دفاعی این است که مشخص شود:

• WAF واقعاً در Request Path قرار دارد؟
• Ruleهای Managed فعال هستند؟
• Detection درست است؟
• False Positive وجود دارد؟
• Logging درست است؟
• Origin قابل دور زدن نیست؟
• Rate Limit عمل می‌کند؟
• Failover چگونه است؟

برای تست Production باید از Requestهای کنترل‌شده و غیرمخرب استفاده شود.

WAF در تست نفوذ سایت

وجود WAF به معنی عدم نیاز به Pentest نیست.

تست نفوذ می‌تواند مشخص کند:

• چه Vulnerabilityهایی پشت WAF وجود دارند؟
• آیا WAF فقط Attack Pattern را مخفی کرده؟
• Authorization مشکل دارد؟
• Business Logic آسیب‌پذیر است؟
• API Endpoint خارج از WAF وجود دارد؟

هدف نهایی این است که Application حتی در صورت عدم وجود WAF نیز تا حد ممکن Secure باشد.

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

ممکن است بعضی Scanner Requestها Block شوند.

در تست مجاز، تیم امنیت معمولاً باید با تیم WAF هماهنگ باشد.

در بعضی پروژه‌ها IP تستر Allowlist می‌شود تا Application واقعی بدون تأثیر WAF ارزیابی شود.

سپس خود WAF نیز به‌صورت مستقل بررسی می‌شود.

این موضوع باعث می‌شود تفاوت «امنیت Application» و «امنیت Edge» مشخص شود.

معماری امنیتی مناسب با WAF چگونه است؟

یک معماری چندلایه می‌تواند چنین باشد:

Internet ↓ CDN / DDoS Protection ↓ WAF ↓ Load Balancer ↓ Web / API Gateway ↓ Authentication و Authorization ↓ Application ↓ Database

در کنار این مسیر:

• Monitoring
• SIEM
• Secret Management
• Backup
• Patch Management
• Vulnerability Management

فعال هستند.

WAF تنها یکی از این اجزاست.

Defense in Depth و WAF

اگر WAF Request را از دست بدهد، Application Validation باید وجود داشته باشد.

اگر Application Bug داشته باشد، WAF ممکن است بخشی از Exploitها را Block کند.

اگر Credential لو برود، MFA مانع ورود شود.

اگر Server دچار مشکل شود، Network Segmentation دامنه Incident را محدود کند.

اگر Incident رخ داد، Logging امکان بررسی را بدهد.

این همان دفاع چندلایه است.

WAF برای چه سایت‌هایی ضروری‌تر است؟

هر سایت عمومی می‌تواند از WAF سود ببرد، اما اهمیت آن برای برخی سیستم‌ها بیشتر است.

فروشگاه اینترنتی

به دلیل Login، Checkout، User Data و API.

سایت‌های سازمانی

به دلیل اطلاعات حساس و پنل‌های داخلی.

سرویس SaaS

به دلیل API و Accountهای متعدد.

سایت وردپرسی پرترافیک

به دلیل حجم Bot و Scanner بالا.

سامانه مالی

به دلیل حساسیت Availability و Data.

API عمومی

به دلیل Automation بالا.

آیا سایت کوچک به WAF نیاز دارد؟

بودجه و Risk مهم هستند.

یک وبلاگ کوچک ممکن است زیرساخت امنیتی سازمانی نیاز نداشته باشد.

اما WAF Cloud ساده می‌تواند Traffic Bot و Attackهای عمومی را کاهش دهد.

برای سایت کوچک مهم‌تر از هر چیز:

• Update
• Backup
• Password قوی
• MFA
• Hosting امن
• Least Privilege

است.

WAF لایه مکمل است.

فایروال WAF رایگان بهتر است یا پولی؟

پاسخ به نیاز سایت بستگی دارد.

WAF رایگان یا Open Source می‌تواند بسیار قدرتمند باشد، اما معمولاً نیازمند:

• Server
• Configuration
• Tuning
• Monitoring
• تخصص

است.

سرویس Managed هزینه مالی دارد ولی بخش زیادی از Maintenance را Provider انجام می‌دهد.

برای تیم کوچک، هزینه نیروی متخصص ممکن است از Subscription بیشتر شود.

برای سازمان بزرگ، Self-Hosted ممکن است کنترل بیشتری ایجاد کند.

معیار ارزیابی عملکرد WAF

نباید فقط تعداد Blockها را معیار موفقیت دانست.

Metrics مفیدتر عبارت‌اند از:

False Positive Rate

چند User واقعی Block شده‌اند؟

Detection Coverage

چه Attack Categoryهایی پوشش داده می‌شوند؟

Latency

WAF چقدر زمان پاسخ را افزایش داده است؟

Availability

در صورت Failure WAF چه اتفاقی می‌افتد؟

Mean Time to Tune

رفع False Positive چقدر طول می‌کشد؟

Rule Update

Threat Ruleها چقدر سریع Update می‌شوند؟

Visibility

آیا Log کافی برای Investigation وجود دارد؟

بهترین تنظیمات WAF چیست؟

یک Configuration واحد برای تمام سایت‌ها وجود ندارد.

بهترین Policy همان Policy است که براساس:

• Application
• Traffic
• Risk
• Endpoint
• User Behavior

تنظیم شده باشد.

اما اصول عمومی عبارت‌اند از:

• Managed Ruleهای معتبر
• Detection و Tuning قبل از Blocking گسترده
• Rule اختصاصی برای Endpointهای حساس
• Rate Limiting
• Origin Protection
• Logging
• Alerting
• Update مداوم

چک‌لیست افزایش امنیت سایت با WAF

برای پیاده‌سازی اصولی Web Application Firewall این چک‌لیست مفید است:

• تمام Domainها و Subdomainها Inventory شوند.
• Web و API هر دو پشت WAF قرار گیرند.
• Origin مستقیم Public نباشد یا محدود شود.
• HTTPS بین User و Edge اجباری باشد.
• ارتباط Edge و Origin نیز امن باشد.
• Managed Rule Set فعال شود.
• Ruleها ابتدا Monitor شوند.
• False Positiveها Tune شوند.
• Exceptionها حداقلی باشند.
• SQLi Protection فعال باشد.
• XSS Protection فعال باشد.
• Protocol Validation فعال باشد.
• Rate Limit برای Login تنظیم شود.
• Rate Limit برای OTP تنظیم شود.
• Admin Policy مجزا داشته باشد.
• API Ruleها براساس Endpoint تنظیم شوند.
• Bot Management در صورت نیاز فعال شود.
• DDoS Protection جداگانه بررسی شود.
• Log Security فعال باشد.
• Secretها در Log Mask شوند.
• Alertهای مهم تعریف شوند.
• Ruleها مرتب Update شوند.
• پس از Deploy Feature جدید Regression Test انجام شود.
• Backup و Incident Response Plan وجود داشته باشد.
• Vulnerability اصلی در Code نیز اصلاح شود.

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

فایروال WAF چیست؟

WAF یا Web Application Firewall لایه‌ای امنیتی است که ترافیک HTTP و HTTPS میان کاربران و Web Application را بررسی می‌کند و می‌تواند Requestهای مشکوک را براساس Rule و Policy شناسایی، ثبت، محدود یا مسدود کند.

WAF مخفف چیست؟

WAF مخفف Web Application Firewall است.

تفاوت WAF و Firewall چیست؟

Firewall شبکه بیشتر روی IP، Port و Connection تمرکز دارد، در حالی که WAF محتوای Application Requestهای HTTP را تحلیل می‌کند.

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

WAF می‌تواند بسیاری از Patternهای SQL Injection را شناسایی کند و OWASP CRS نیز Ruleهایی برای این دسته حملات دارد، اما راهکار اصلی جلوگیری از SQL Injection استفاده از Queryهای امن و Parameterized در Application است.

آیا WAF از XSS جلوگیری می‌کند؟

WAF می‌تواند بعضی Payloadهای XSS را Block کند، اما دفاع اصلی XSS باید در Code با Output Encoding، Sanitization و سایر کنترل‌های مناسب انجام شود.

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

WAF می‌تواند در Layer 7 و همراه Rate Limiting مفید باشد، اما حملات حجیم Network نیازمند DDoS Protection با ظرفیت Upstream هستند.

آیا WAF برای وردپرس مفید است؟

بله. WAF می‌تواند Bot Traffic، Scannerها و بخشی از Attack Patternها را قبل از رسیدن به WordPress محدود کند. بااین‌حال Update هسته، قالب و افزونه‌ها همچنان ضروری است.

ModSecurity چیست؟

ModSecurity یک WAF Engine متن‌باز است که در پلتفرم‌های مختلف Web Server قابل استفاده است و امروزه تحت پروژه OWASP توسعه داده می‌شود.

OWASP CRS چیست؟

OWASP Core Rule Set مجموعه‌ای از Ruleهای عمومی برای WAFهای سازگار مانند ModSecurity و Coraza است که برای شناسایی طیف گسترده‌ای از حملات وب طراحی شده است.

آیا فقط نصب ModSecurity کافی است؟

خیر. ModSecurity Engine است و برای استفاده عملی باید Configuration و Rule Set مناسب داشته باشد.

False Positive در WAF چیست؟

False Positive زمانی رخ می‌دهد که WAF یک Request سالم را مخرب تشخیص دهد و آن را Alert یا Block کند.

WAF Tuning چیست؟

Tuning فرایند تنظیم Ruleها و Exceptionها براساس Traffic واقعی Application است تا امنیت حفظ شود و False Positive کاهش یابد.

آیا WAF جای تست نفوذ را می‌گیرد؟

خیر. WAF ممکن است بعضی Exploitها را Block کند، اما ضعف‌های Authorization، Business Logic و مشکلات دیگر همچنان باید با تست امنیتی و Code Review بررسی شوند.

آیا WAF جای Secure Coding را می‌گیرد؟

خیر. NIST نیز WAF را یک گام دفاعی مفید می‌داند، اما تأکید می‌کند WAF راهکار کامل امنیت Application یا API نیست.

آیا WAF ابری بهتر است؟

WAF ابری برای بسیاری از سایت‌ها مزیت‌هایی مانند Scaling، Edge Filtering و مدیریت ساده‌تر دارد. اما انتخاب میان Cloud، Host-Based و Network WAF به معماری و نیاز سازمان بستگی دارد.

آیا Origin باید پشت WAF مخفی شود؟

در Cloud WAF بهتر است دسترسی مستقیم به Origin محدود شود تا Traffic نتواند مسیر حفاظتی Edge را دور بزند.

آیا WAF سرعت سایت را کم می‌کند؟

هر لایه پردازشی می‌تواند Latency اضافه کند، اما Cloud WAFهای ترکیب‌شده با CDN ممکن است در مجموع Performance سایت را بهبود دهند. اثر واقعی باید Monitoring شود.

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

WAF می‌تواند برای API بسیار مفید باشد، ولی Authorization، Schema Validation، Authentication و Rate Limiting اختصاصی API همچنان لازم هستند. NIST نیز WAF را برای API Protection یک شروع مناسب اما نه راهکار کامل معرفی می‌کند.

جمع‌بندی

فایروال WAF یا Web Application Firewall یکی از مهم‌ترین لایه‌های دفاعی برای محافظت از سایت‌ها و برنامه‌های تحت وب است. برخلاف Network Firewall که بیشتر روی اتصال، IP و Port تمرکز می‌کند، WAF می‌تواند Requestهای HTTP و HTTPS را در سطح Application بررسی کند و براساس مجموعه‌ای از Policyها درباره عبور، ثبت یا مسدود کردن Traffic تصمیم بگیرد.

OWASP نیز WAF را Application Firewall مخصوص HTTP معرفی می‌کند و تأکید دارد این ابزارها برای مقابله با Attack Categoryهایی مانند SQL Injection و Cross-Site Scripting کاربرد دارند.

WAF ممکن است به شکل Host-Based، Network-Based یا Cloud-Based پیاده‌سازی شود. برای بسیاری از سایت‌های اینترنتی، استفاده از Cloud WAF در کنار CDN و DDoS Protection امکان حذف Traffic مخرب در Edge و قبل از رسیدن به Origin را فراهم می‌کند.

در زیرساخت‌های Self-Hosted نیز ابزارهایی مانند ModSecurity و OWASP Core Rule Set اهمیت زیادی دارند. ModSecurity Engine بررسی Traffic را فراهم می‌کند و CRS مجموعه‌ای از Ruleهای عمومی برای شناسایی بسیاری از Attack Patternهای رایج وب ارائه می‌دهد.

بااین‌حال WAF را نباید «سیستم ضد هک» یا جایگزین برنامه‌نویسی امن دانست.

مشکلاتی مانند Broken Access Control، BOLA، ضعف Business Logic، Permission اشتباه و Credential Compromise ممکن است Requestهایی کاملاً معتبر از نظر ساختار HTTP ایجاد کنند. WAF معمولاً Context کافی برای تشخیص این مشکلات ندارد. OWASP نیز بر همین محدودیت در مقابل ضعف‌های Access Control و Business Logic تأکید می‌کند.

بهترین راهکار استفاده از Defense in Depth است.

یعنی:

WAF در Edge Request را بررسی کند.

DDoS Protection حملات حجیم را جذب کند.

Rate Limiting سوءاستفاده را محدود کند.

Authentication هویت را بررسی کند.

Authorization Permission را کنترل کند.

Application ورودی‌ها را Validate کند.

Database فقط Queryهای امن دریافت کند.

Monitoring رفتار غیرعادی را تشخیص دهد.

و تیم توسعه Vulnerabilityهای واقعی را در کد اصلاح کند.

برای سایت‌های وردپرسی نیز WAF زمانی بیشترین ارزش را دارد که در کنار به‌روزرسانی مداوم WordPress، قالب و افزونه‌ها، MFA، Backup، Least Privilege و Monitoring استفاده شود.

فعال کردن Ruleهای بسیار سخت‌گیرانه بدون Tuning نیز توصیه نمی‌شود. False Positive می‌تواند User واقعی، Search Engine یا عملیات مهم سایت را Block کند. به همین دلیل بهتر است Ruleهای جدید ابتدا تحت Monitoring قرار گیرند، سپس براساس Traffic واقعی Tune و در نهایت وارد Blocking Mode شوند.

مسئله مهم دیگر محافظت از Origin Server است. اگر Cloud WAF روی Domain فعال باشد اما IP واقعی Origin همچنان مستقیماً از اینترنت قابل دسترسی باشد، معماری دفاعی ناقص خواهد بود. دسترسی Origin باید تا حد ممکن به Networkها و Proxyهای مورد اعتماد محدود شود.

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

این لایه می‌تواند درخواست‌های مخرب رایج را زودتر متوقف کند، Attack Surface را کاهش دهد، فرصت بیشتری برای Patch کردن Vulnerabilityها ایجاد کند، حجم Bot Traffic را کنترل کند و Visibility ارزشمندی درباره تهدیدهایی که سایت با آن‌ها روبه‌رو است در اختیار تیم امنیت قرار دهد.

سایت امن سایتی نیست که فقط یک Firewall داشته باشد؛ سایت امن سیستمی است که WAF، Secure Coding، Patch Management، Authentication، Authorization، Monitoring، Backup و تست امنیتی را به‌عنوان اجزای مکمل یک معماری دفاعی واحد در نظر بگیرد.