فایروال سایت چیست؟ انتخاب و تنظیم Network Firewall و WAF

فایروال خوب فهرستی از IPهای «بد» نیست؛ یک Policy مستند است که فقط جریان‌های لازم را اجازه می‌دهد، تغییراتش قابل بازگشت است و هنگام حمله هم کاربران واقعی را قطع نمی‌کند. اگر Origin از اینترنت مستقیم باز بماند، WAF ابری دور زده می‌شود؛ اگر Rule برای رفع False positive کاملاً خاموش شود، همان مسیر به Bypass تبدیل می‌شود.

این راهنما برای سایت ایرانی روی هاست، VPS یا معماری ابری نوشته شده و Network firewall، Host firewall و WAF را از انتخاب تا Rollout و مانیتورینگ پوشش می‌دهد.

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

Firewall جریان ترافیک میان Zoneها یا Hostها را بر اساس Policy کنترل می‌کند. تصمیم می‌تواند بر پایه Source/Destination، Port، Protocol، Connection state، Identity یا محتوای HTTP باشد. هدف، کاهش Attack surface و محدودکردن حرکت/خروج داده است.

راهنمای NIST SP ۸۰۰-۴۱ Rev.۱ نیز فایروال را کنترل جریان ترافیک میان شبکه‌ها یا میزبان‌های با وضعیت امنیتی متفاوت تعریف و بر انتخاب، پیکربندی، تست، استقرار و نگهداری Policy تأکید می‌کند.

WAF چیست؟

Web Application Firewall درخواست و پاسخ HTTP/HTTPS را در لایه برنامه بررسی می‌کند. WAF می‌تواند Patternهای حمله، Bot، Rate و Protocol anomaly را تشخیص دهد، اما منطق کسب‌وکار، Authorization و آسیب‌پذیری کد را کامل نمی‌شناسد.

WAF یک کنترل جبرانی و Detection layer است؛ Patch، Validation، Parameterized query و Output encoding را جایگزین نمی‌کند. مبانی کد امن در راهنمای جلوگیری از SQL Injection و XSS آمده است.

چهار لایه فایروال

این لایه‌ها مکمل‌اند. نصب دو مدیر متفاوت Host firewall روی یک Rule set می‌تواند تعارض بسازد؛ مالک و Source of truth را مشخص کنید.

Firewall چه چیزی را حل نمی‌کند؟

• Password سرقت‌شده و Login قانونی مهاجم؛
• Authorization اشتباه در Application؛
• Plugin/Dependency آسیب‌پذیر از مسیر مجاز HTTPS؛
• بدافزار از قبل نصب‌شده؛
• سرقت Session یا فیشینگ؛
• Insider با دسترسی مجاز؛
• Backup آلوده یا Secret لو‌رفته؛
• DDoS حجمی فراتر از ظرفیت لینک محلی.

برای Login از دفاع چندلایه Brute Force و Credential Stuffing استفاده کنید.

از Asset و Data flow شروع کنید

قبل از Rule، نقشه جریان لازم را بسازید:

جریان بدون Owner یا نیاز روشن، Candidate حذف است.

Zone و Trust boundary

• Public edge؛
• Web/Reverse proxy؛
• Application؛
• Database/Data؛
• Management؛
• Backup؛
• Monitoring/Logging؛
• Third-party integration.

ترافیک بین Zoneها هم باید Policy داشته باشد. «شبکه داخلی = قابل‌اعتماد» فرض خطرناکی است.

اصل Default deny

Policy مطلوب فقط جریان لازم را Allow و باقی را Deny می‌کند. اجرای ناگهانی Default deny روی Production می‌تواند سایت را قطع کند؛ مسیر امن:

1. Flow inventory از Configuration و Log؛
2. Rule پیشنهادی با Owner و Expiry؛
3. Staging/Shadow observation؛
4. Canary روی بخش محدود؛
5. Alert و Rollback؛
6. Enforcement؛
7. Review پس از یک چرخه عملیاتی.

Inbound و Outbound هر دو مهم‌اند

Inbound

دسترسی از Internet به Serviceها را محدود می‌کند. Database، Redis، Admin panel و Metrics نباید بی‌دلیل Public باشند.

Outbound/Egress

اگر Web shell نصب شود، Egress آزاد به Exfiltration و دانلود Payload کمک می‌کند. مقصدهای لازم مانند Update repository، Email relay، Payment API و Object storage را مستند کنید. Egress deny کامل بدون Dependency map باعث قطعی پنهان می‌شود.

پورت و Protocol

• فقط Serviceهای فعال؛
• Bind روی Interface مناسب؛
• Admin از VPN/Bastion یا شبکه مدیریت؛
• FTP/Telnet و Protocol ناامن حذف؛
• Database روی Private network؛
• IPv4 و IPv6 Rule parity؛
• UDP لازم جدا ارزیابی؛
• Service discovery و Container portها در Scope؛
• Rule برای Health/Monitoring حداقلی.

تغییر پورت SSH Noise اسکن را کم می‌کند، اما Authentication یا Firewall control نیست. کلید/Passkey، MFA، VPN، Rate limit و Least privilege مهم‌ترند.

IPv6 را فراموش نکنید

اگر Server IPv6 دارد ولی فقط IPv4 Policy شده، مسیر موازی باز می‌ماند. انتخاب روشن:

• IPv6 لازم است: Addressing، Route، DNS AAAA و Rule معادل تست شود؛
• لازم نیست: در لایه درست و مستند غیرفعال/مسدود شود؛
• Link-local و Container networking جدا بررسی شود؛
• Log و Monitoring هر دو خانواده IP را Parse کنند.

Admin access

IP ثابت تنها Identity نیست و ممکن است تغییر/اشتراک/تصاحب شود. برای Management plane:

• VPN یا Zero-trust access proxy؛
• حساب شخصی، نه Shared root؛
• MFA/SSH key و حذف Password login در صورت امکان؛
• Sudo/Role حداقلی؛
• Session logging و Alert؛
• Break-glass جدا و تست‌شده؛
• IP allowlist به‌عنوان لایه اضافه، نه عامل اصلی؛
• Console اضطراری Provider پیش از تغییر Firewall.

Origin را پشت Edge پنهان کنید

صرف تغییر DNS، IP Origin را امن نمی‌کند. برای جلوگیری از Bypass:

• Inbound وب فقط از Range رسمی Edge یا Tunnel خصوصی؛
• Authenticated Origin Pull/mTLS در صورت پشتیبانی؛
• Host header و SNI معتبر؛
• Origin IP در DNS/Email/Certificate history تا حد عملی مدیریت؛
• Admin/Monitoring مسیر جدا؛
• تست مستقیم IP از بیرون؛
• فرایند خودکار به‌روزرسانی Range Provider؛
• Failover بدون بازکردن Origin به همه.

معماری Edge و Cache در راهنمای CDN برای سایت ایرانی توضیح داده شده است.

WAF را کجا قرار دهیم؟

انتخاب بر اساس Threat model، ظرفیت، دسترسی از ایران، حریم خصوصی، Log، SLA و مهارت تیم باشد.

Rule set و Anomaly scoring

WAFهای مبتنی بر Signature ممکن است چند Match را به Score تبدیل کنند. Threshold خیلی بالا Bypass می‌سازد و خیلی پایین کاربر واقعی را Block می‌کند.

مستند Anomaly Scoring در OWASP CRS هشدار می‌دهد افزایش Threshold فقط راه‌حل موقت Tuning است؛ راه پایدار، شناخت False positive و Exclusion دقیق است.

Detection mode تا Blocking

1. Rule set و Paranoia/Protection level مستند؛
2. Detection/Log روی Traffic نماینده؛
3. طبقه‌بندی Match واقعی و False positive؛
4. Exclusion محدود به Rule + Route/Parameter لازم؛
5. Test suite از Requestهای قانونی و Attack sample امن؛
6. Blocking با Canary؛
7. Monitor نرخ Block و Business KPI؛
8. کاهش/افزایش تدریجی با Change record.

Detection mode طولانی بدون Owner فقط Log تولید می‌کند؛ Deadline برای Enforcement تعیین کنید.

False positive را چگونه Tune کنیم؟

• Rule ID، Phase، URI، Parameter و Payload را بدون Secret بررسی کنید؛
• اول Bug/فرمت عجیب Application را اصلاح کنید؛
• Exclusion را به کوچک‌ترین Scope محدود کنید؛
• Rule فایل Vendor را مستقیم ویرایش نکنید؛
• Bypass کل SQLi/XSS برای یک سایت ندهید؛
• Regression test بسازید؛
• Expiry و Owner برای Exception؛
• پس از Upgrade Rule set دوباره تست کنید.

راهنمای Tuning خود CRS نیز تغییر مستقیم Ruleهای اصلی را رد و Rule exclusion جدا را توصیه می‌کند.

WAF و داده حساس

Audit log WAF ممکن است Password، Cookie، Authorization header، آدرس، Search query یا Payload پرداخت را ذخیره کند.

• Redaction قبل از Storage؛
• عدم Log کردن Body مسیرهای حساس مگر ضرورت و کنترل؛
• Token/Cookie کامل ممنوع؛
• دسترسی Role-based؛
• Encryption و Retention؛
• Data residency/Vendor review؛
• Sample امن برای Debug؛
• Deletion و Incident process.

Rate limiting در Edge و Application

Edge IP/ASN/Path را خوب می‌بیند؛ Application Account/Tenant/Business action را. برای Login، Search، API، Cart، Coupon و Callback Policy جدا لازم است.

• Token bucket/Sliding window متناسب؛
• Burst قانونی؛
• Retry-After و Response روشن برای API؛
• عدم Lock کاربران پشت NAT صرفاً با IP؛
• Webhook/Payment با Signature و Idempotency، نه Allow همه؛
• Monitoring False positive؛
• Global safeguard برای Origin capacity.

Callback پرداخت را طبق راهنمای اتصال امن درگاه تنظیم کنید.

Geo blocking؛ با احتیاط

کشور IP دقیق و پایدار نیست؛ VPN، اپراتور، Bot proxy و کاربر مسافر خطا می‌سازند. به‌جای Block گسترده:

• نیاز بازار و داده Traffic را بررسی کنید؛
• Challenge/Rate limit برای Risk بالاتر؛
• API/Admin و Public content را جدا کنید؛
• Search crawler و سرویس‌های ثالث را Verify کنید؛
• False positive و Conversion را بسنجید؛
• Bypass پشتیبانی و Expiry داشته باشد.

Googlebot و Crawler

User-Agent قابل جعل است. برای Allowlist crawler از Reverse/Forward DNS یا Range رسمی و Verification خود Provider استفاده کنید. همه درخواست‌های دارای «Googlebot» را Allow نکنید و Bot ناشناس را فقط بر اساس نام Block نکنید.

• Robots.txt امنیت نیست؛
• WAF Challenge نباید Crawler معتبر را حلقه کند؛
• Statusهای ۴۰۳/۴۲۹ و Crawl pattern مانیتور شوند؛
• URLهای Admin/Private با Auth محافظت شوند، نه robots.

DDoS و مرز توان فایروال

Host firewall بعد از پرشدن لینک اینترنت کمکی نمی‌کند. برای حمله حجمی به Upstream/Anycast/Provider ظرفیت‌دار نیاز است. در لایه Application:

• Cache و Queue؛
• Rate limit و Request cost؛
• Connection/Timeout tuning؛
• Bot challenge؛
• Origin protection؛
• Degraded mode برای قابلیت پرهزینه؛
• Runbook ارتباط Provider؛
• Capacity test کنترل‌شده.

Container و Kubernetes

Host firewall تنها کافی نیست؛ Overlay network، Ingress، Service و Pod communication را ببینید.

• Network policy بر Namespace/Workload؛
• Default deny ingress/egress تدریجی؛
• Ingress controller/WAF؛
• Control plane غیرعمومی یا محدود؛
• Node port و Load balancer audit؛
• Service account/Identity به‌جای IP تنها؛
• DNS egress و Dependency map؛
• Policy test در CI.

WordPress و هاست اشتراکی

روی Shared hosting ممکن است Network firewall دست شما نباشد. مسئولیت را روشن کنید:

• Provider: شبکه، Host isolation، Patch و DDoS طبق قرارداد؛
• شما: WordPress/Plugin/Theme، حساب، WAF/Edge، Backup و Monitoring؛
• Plugin firewall: Context بیشتر ولی پس از رسیدن Request به PHP؛
• Cloud WAF: قبل از Origin اما نیازمند DNS/Origin control؛
• File permission و Upload policy؛
• تست Compatibility با wp-admin، REST، Cron و WooCommerce.

Logging و Correlation

Request/correlation ID را از Edge تا App نگه دارید. حجم Dropهای تکراری را Sample/Aggregate کنید تا Storage و Alert اشباع نشود.

Dashboard و Alert

• Allowed/blocked/challenged به تفکیک Rule/Route؛
• False positive و Support ticket؛
• Origin direct traffic؛
• Top attack class بدون افشای Payload؛
• WAF latency و error؛
• ۴۲۹/۴۰۳ و Conversion/Checkout؛
• Firewall config change؛
• Rule disabled/exception expired؛
• Port exposure drift؛
• Egress anomaly.

Signal و Runbook را با راهنمای Observability سایت هماهنگ کنید.

Change management

Rule فایروال کد Production است:

• Version control و Review؛
• Ticket با دلیل، Owner و Expiry؛
• Policy-as-code در صورت امکان؛
• Lint/validation؛
• Test قانونی و منفی؛
• Staging/Canary؛
• Backup config؛
• Out-of-band console؛
• Rollback تمرین‌شده؛
• Audit پس از تغییر.

جلوگیری از Lockout

1. Console Provider/دیتاسنتر را قبل از تغییر تست کنید.
2. Session مدیریت موجود را باز نگه دارید.
3. Rule Allow لازم را قبل از Default deny اعمال کنید.
4. Syntax و dry-run را اجرا کنید.
5. تغییر را با Auto-rollback زمان‌دار انجام دهید.
6. از شبکه دوم اتصال را تست کنید.
7. پس از تأیید، Rollback timer را لغو کنید.
8. نتیجه و Config hash را ثبت کنید.

غیرفعال‌کردن کامل فایروال برای رفع مشکل آخرین راه و باید زمان‌دار/مانیتورشده باشد.

Test plan فایروال

Network

• Portهای لازم از Source درست باز؛
• Portهای غیرلازم از Internet بسته؛
• IPv4/IPv6 parity؛
• Origin direct بسته؛
• Egress لازم و غیرلازم؛
• Failover و Health check.

WAF

• مسیرهای Public، Admin، API، Upload و Checkout؛
• Requestهای قانونی فارسی/Unicode/JSON/File؛
• Rule matchهای کنترل‌شده بدون آسیب؛
• False positive exclusions؛
• Rate limit و Retry؛
• Log redaction؛
• Rule update regression.

Operations

• Config deployment و rollback؛
• Alert و On-call؛
• Provider outage؛
• Emergency bypass با Approval/Expiry؛
• Incident drill.

Runbook هنگام حمله

1. اثر، Route، Source و ظرفیت را مشخص کنید.
2. Rule تغییر اخیر و False positive را تفکیک کنید.
3. Challenge/Rate limit محدود و قابل‌برگشت اعمال کنید.
4. قابلیت پرهزینه را Degrade یا Cache کنید.
5. Origin و Backend saturation را رصد کنید.
6. با Provider Upstream هماهنگ شوید.
7. کاربر/تیم را درباره اختلال لازم مطلع کنید.
8. Rule اضطراری Expiry و Owner داشته باشد.
9. پس از حادثه Rule، Capacity و Detection را بازبینی کنید.

اشتباه‌های پرتکرار

• WAF را جای Patch دانستن؛
• بازگذاشتن Origin؛
• Rule Allow from any برای رفع فوری؛
• IP allowlist دائمی بدون Identity؛
• Country block گسترده؛
• نادیده‌گرفتن IPv6/Egress؛
• ثبت Password/Cookie در WAF log؛
• ویرایش مستقیم Rule vendor؛
• Threshold خیلی بالا به‌جای Tuning؛
• تغییر بدون Console/Rollback؛
• نصب دو Host firewall ناسازگار؛
• عدم تست Checkout/API/Crawler.

نقشه اجرای ۳۰روزه

هفته اول: Inventory

Asset، Zone، Flow، Port، Edge، IPv6 و Owner را ثبت کنید.

هفته دوم: Network/Origin

Default deny تدریجی، Admin plane، Origin allow و Egressهای بحرانی را پیاده کنید.

هفته سوم: WAF

Rule set، Detection، False positive tuning، Rate limit و Log redaction.

هفته چهارم: Enforcement و Drill

Canary blocking، Dashboard، Lockout/attack drill و Review Exceptionها.

چک‌لیست فایروال سایت

• Asset، Zone و Data flow مستند است.
• Rule فقط جریان لازم و Owner/Expiry دارد.
• Inbound و Egress کنترل می‌شوند.
• IPv4 و IPv6 پوشش برابر دارند.
• Admin از مسیر امن و MFA استفاده می‌کند.
• Origin فقط Edge معتبر را می‌پذیرد.
• WAF جای Patch و Authorization نیست.
• Detection به Blocking با Tuning منتقل شده است.
• Exclusion کوچک و تست‌شده است.
• Log داده حساس را Redact می‌کند.
• Rate limit Business-aware و False positive‌سنج است.
• Googlebot با Verification، نه User-Agent، مدیریت می‌شود.
• Change versioned، reviewed و rollbackable است.
• Console اضطراری و Runbook تست شده‌اند.

سؤالات متداول فایروال و WAF

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

Firewall شبکه IP/Port/Protocol را کنترل می‌کند؛ WAF محتوای HTTP/HTTPS و الگوی درخواست وب را می‌بیند. برای سایت معمولاً هر دو لایه لازم‌اند.

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

خیر. WAF بخشی از حملات و Botها را کاهش می‌دهد، اما Business logic، Credential معتبر، Plugin آسیب‌پذیر و Authorization را کامل حل نمی‌کند.

آیا تغییر پورت SSH امنیت را زیاد می‌کند؟

Noise اسکن را کم می‌کند، اما دفاع اصلی نیست. مسیر مدیریت محدود، کلید/MFA، Least privilege، Rate limit و Patch لازم‌اند.

چطور False positive WAF را رفع کنیم؟

Rule ID و Parameter را پیدا، ابتدا رفتار Application را بررسی و سپس کوچک‌ترین Exclusion ممکن را خارج از فایل Rule اصلی بسازید؛ Regression test و Expiry فراموش نشود.

فایروال ابری کافی است؟

فقط اگر Origin قابل دورزدن نباشد و Host/Service داخلی هم Policy داشته باشند. Edge، Host firewall، Application security و Monitoring مکمل‌اند.

جمع‌بندی

فایروال مؤثر از خرید محصول شروع نمی‌شود؛ از Flow و Policy شروع می‌شود. Network/Host firewall سطح دسترسی را محدود، Edge ظرفیت و Bot را کنترل و WAF ترافیک وب را بررسی می‌کند. همه Ruleها باید تست، مانیتور، Version و قابل Rollback باشند.

برای Audit Port، طراحی Origin protection یا Tuning WAF، از فرم مشاوره امنیت مایندیو استفاده کنید و معماری، Provider و نمونه Rule/خطای Redact‌شده را بنویسید.