📄 تنظیمات دیواره آتش (Firewall)

دیواره آتش وب (WAF) شبکه توزیع محتوای ستون، یک فایروال لایه ۷ است که به شما امکان کنترل دقیق ترافیک ورودی و خروجی را می‌دهد. با تعریف قوانین فایروال، می‌توانید تصمیم بگیرید که چه نوع ترافیکی به سرورهای اصلی (Origin) شما فرستاده شود، کدام درخواست‌ها مسدود شوند و برای کدام کاربران چالش امنیتی طرح شود.

هر قانون فایروال از دو بخش اصلی تشکیل شده است:

1. شرط‌ها (Constraints): معیارهایی برای شناسایی درخواست‌ها (مانند IP، کشور، هدرهای خاص یا مسیر درخواست).
2. عملیات (Actions): کاری که در صورت برقرار بودن شرط‌ها روی درخواست انجام می‌شود.

در این مستند، انواع عملیات (Action) قابل پیکربندی در دیواره آتش CDN ستون به همراه جزئیات پیاده‌سازی هرکدام بررسی می‌شود.

---

اولویت قوانین فایروال

ترتیب و نحوه اجرای قوانین فایروال به صورت زیر است:

• بررسی ترتیبی: قوانین فایروال دقیقاً به ترتیب قرارگیری در جدول قوانین (از بالا به پایین) ارزیابی می‌شوند.
• قوانین خاتمه‌دهنده (Terminating): در صورتی که شرط یک قانون برقرار شود و اقدام آن منجر به بلاک شدن (Block) یا ریدایرکت (Redirect) شود، پردازش در همان‌جا متوقف شده و قوانین بعدی بررسی نخواهند شد.
• قوانین غیرخاتمه‌دهنده (Non-terminating): در نسخه فعلی، در صورتی که درخواست با قانونی منطبق شود (مانند Allow یا ریت لیمیت در حالتی که منجر به بلاک نشود)، سایر قوانین بعدی نیز ممکن است برای بررسی‌های بیشتر روی درخواست اعمال شوند.

---

انواع عملیات (Actions) در فایروال

دیواره آتش ستون از عملیات‌های زیر پشتیبانی می‌کند:

۱. عملیات Allow (مجاز کردن)

با انتخاب این عملیات، در صورت برقرار بودن شرط‌های قانون، به درخواست اجازه عبور داده شده و بدون مسدودسازی به سمت سرور اصلی هدایت می‌شود.

---

۲. عملیات Block (مسدودسازی)

این عملیات درخواست‌های منطبق با شرط قانون را به طور کامل مسدود می‌کند.

• به‌طور پیش‌فرض، کلاینت مسدود شده با کد خطای 403 (Forbidden) مواجه می‌شود.
• شما می‌توانید کد وضعیت پاسخ (بین ۲۰۰ تا ۴۹۹) و همچنین قالب صفحه‌ی خطای نمایش داده شده به کاربر (کد HTML سفارشی) را شخصی‌سازی کنید. برای جزئیات بیشتر به [تنظیمات Status Code در دیواره آتش](file:///Users/sotoon/Downloads/docs-alternative/content/01. products/02. cdn/6. firewall/4. status-code-firewall.md) مراجعه کنید.

---

۳. چالش کپچا (Captcha Challenge)

این عملیات برای تشخیص کاربران واقعی از ربات‌ها کاربرد دارد. کاربر برای دسترسی به سایت با چالش کپچای گوگل مواجه می‌شود. در حال حاضر فقط سرویس Google reCAPTCHA v2 پشتیبانی می‌شود.

مرحله اول: ساخت کلید reCAPTCHA

1. وارد حساب کاربری گوگل خود شوید.
2. به صفحه Google reCAPTCHA بروید.
3. در فیلد Label یک نام دلخواه وارد کنید.
4. در بخش reCAPTCHA type گزینه Challenge (v2) و سپس “I’m not a robot” Checkbox را انتخاب کنید.
5. در فیلد Domains آدرس دامنه وب‌سایت خود را وارد کنید.
6. قوانین را پذیرفته و روی Submit کلیک کنید.
7. مقادیر Site Key و Secret Key ارائه شده را کپی کنید.

مرحله دوم: اعمال تنظیمات در پنل ستون

1. وارد پنل CDN خود در ستون شده و به بخش فایروال بروید.
2. یک قانون جدید بسازید و شرط‌های مد نظر خود را تعریف کنید.
3. در بخش عملیات، گزینه Captcha را انتخاب کنید.
4. مقادیر Site Key و Secret Key که از گوگل دریافت کرده‌اید را در فیلدهای مربوطه وارد کنید.
5. فیلد TTL را تنظیم کنید (این مقدار نشان‌دهنده زمان معتبر بودن حل چالش به ثانیه است. پس از انقضای این زمان، کاربر در صورت ارسال درخواست مجدد باید دوباره چالش را حل کند).
6. روی دکمه تأیید کلیک کنید.

---

۴. چالش جاوااسکریپت (JS Challenge)

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

---

۵. چالش کوکی (Cookie Challenge)

ساده‌ترین روش برای تشخیص مرورگرهای واقعی از کلاینت‌های متفرقه (مانند اسکریپت‌ها یا ابزارهای تست نفوذ). در این عملیات، یک کوکی موقت در پاسخ اول به کلاینت فرستاده می‌شود و از او خواسته می‌شود صفحه را دوباره بارگذاری کند. در صورتی که کلاینت کوکی را در درخواست بعدی ارسال کند، اجازه دسترسی صادر می‌شود.

---

۶. محدود کردن نرخ دسترسی (Ratelimit)

این عملیات تعداد درخواست‌های مجاز یک شناسه کاربر را در یک دوره زمانی مشخص محدود می‌کند. درخواست‌های بیش از حد مجاز با خطای 429 (Too Many Requests) مسدود خواهند شد.

نحوه شناسایی کاربر (Identifier)

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

• شناسه IP: کاربران بر اساس آدرس IP عمومی شناسایی می‌شوند. در صورتی که چند کاربر پشت یک IP (مثلاً در یک شبکه سازمانی) باشند، محدودیت به صورت اشتراکی اعمال می‌شود.
• شناسه JWT: کاربران بر اساس توکن امضا شده JWT شناسایی می‌شوند. با انتخاب این حالت، باید فیلدهای زیر را پر کنید:
  • Header name: نام هدری که توکن در آن ارسال می‌شود (مثلاً Authorization).
  • Payload key: نام فیلدی در بخش ادعاهای توکن (Payload) که نماینده هویت کاربر است (مثلاً user_id یا sub).
  • Secret: کلید امنیتی مورد استفاده برای امضا و تایید توکن. در صورت نامعتبر بودن یا عدم تطابق امضای توکن، کلاینت با خطای 412 (Precondition Failed) مواجه می‌شود.

حالت‌های اعمال محدودیت

• حالت ساده: تعداد مجاز درخواست‌ها در بازه زمانی تعیین‌شده اعمال می‌شود.

  • نرخ (Rate): تعداد درخواست مجاز.
  • دوره (Period): بازه زمانی (به ثانیه). (مثال: نرخ ۱۰ و دوره ۶۰، یعنی حداکثر ۱۰ درخواست در هر دقیقه مجاز است).

• حالت پیشرفته: در این حالت از مفهوم صف و تاخیر برای هموارسازی ترافیک استفاده می‌شود:

  • درخواست‌های کمتر از نرخ مجاز بدون مشکل عبور می‌کنند.
  • درخواست‌های اضافه بر نرخ اصلی تا سقف معین (Burst)، با تاخیر عمدی پاسخ داده می‌شوند تا نرخ مجاز حفظ شود.
  • درخواست‌های بیش از سقف تاخیر، بلاک شده و با پاسخ خطای ۴۲۹ مواجه می‌شوند. (مثال: اگر نرخ روی ۱۰ و نرخ اضافه با تاخیر روی ۵ باشد، ۱۰ درخواست اول ثانیه بدون تاخیر پاسخ داده می‌شوند، ۵ درخواست بعدی با تاخیر مواجه شده و درخواست‌های ۱۶ام به بعد در همان ثانیه مسدود می‌شوند).

• جریمه زمانی (Penalty): مدت زمانی (به ثانیه) که کاربر متخلف پس از بلاک شدن، حق ارسال درخواست جدید نخواهد داشت. مقدار پیش‌فرض آن صفر است.

---

۷. عملیات ریدایرکت (Redirect)

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

• target: آدرس مقصدی که کلاینت باید به آن ریدایرکت شود (می‌تواند شامل پروتکل و دامنه جدید باشد).
• preservePath: در صورت فعال بودن (true)، بخش مسیر URL اولیه در مقصد حفظ و به انتهای آدرس هدف چسبانده می‌شود.
• preserveQueryString: با فعال‌سازی این فیلد، پارامترهای درخواست اولیه (Query Strings) به مقصد منتقل می‌شوند.
• referrer: آدرس صفحه ارجاع‌دهنده درخواست اصلی را به صورت پارامتر به آدرس ریدایرکت‌شده اضافه می‌کند.
• extraQueryString: امکان اضافه کردن پارامترهای دلخواه به آدرس مقصد (حداکثر ۱۰ پارامتر).

عیب‌یابی ریدایرکت‌های حلقوی (ERR_TOO_MANY_REDIRECTS)

یکی از مشکلات رایج در زمان فعال‌سازی ریدایرکت (به‌ویژه ریدایرکت www به non-www یا برعکس) در فایروال CDN، مواجه شدن با خطای ERR_TOO_MANY_REDIRECTS در مرورگر است. این خطا زمانی رخ می‌دهد که درخواست‌های کلاینت بین CDN و سرور اصلی (Origin) یا درون خود CDN در یک چرخه بی‌انتها (Loop) قرار بگیرند.

دلایل اصلی و روش‌های حل این مشکل:

۱. اعمال شدن ناخواسته قانون روی زیردامنه‌ها (Subdomains): اگر دامنه‌ی اصلی و زیردامنه‌های شما (مثال: vmusic.ir و زیردامنه‌ی مربوط به فایل‌ها/رسانه‌ها مانند dc.music.ir) بر روی یک سرویس CDN مشترک (توزیع مشترک با Wildcard یا ثبت چند دامنه در یک سرویس) تعریف شده باشند، یک قانون ریدایرکت کلی (مانند ریدایرکت تمام مسیرها به دامنه با www) روی تمام زیردامنه‌ها نیز اعمال خواهد شد. در این حالت، درخواست به زیردامنه (مثلاً dc.vmusic.ir/file.jpg) توسط فایروال به دامنه اصلی ریدایرکت می‌شود، اما سرور اصلی (مثلاً تنظیمات وردپرس یا وب‌سرور شما) مجدداً درخواست‌های رسانه را به زیردامنه‌ی مخصوص خود هدایت می‌کند. این رفتار باعث ایجاد لوپ بین CDN و سرور اصلی می‌شود.

• راه‌حل: برای دامنه‌ی اصلی و زیردامنه‌های حساس خود (مانند زیردامنه‌های دانلود یا API)، سرویس‌های (توزیع‌های) CDN مجزا در پنل ستون بسازید تا قوانین فایروال دامنه اصلی بر روی ترافیک زیردامنه‌ها اعمال نشود. همچنین در صورت نیاز به ریدایرکت دامنه‌ها، این کار را در سمت وب‌سرور اصلی (Nginx/Apache) انجام دهید تا کنترل دقیق‌تری داشته باشید.

۲. عدم هماهنگی پروتکل SSL/TLS بین CDN و سرور اصلی (SSL Mismatch): اگر سرور اصلی شما درخواست‌های HTTP را به HTTPS ریدایرکت می‌کند، اما در پنل ستون پروتکل ارتباط با آپ‌استریم (Origin Protocol) روی HTTP تنظیم شده باشد، ریدایرکت حلقوی اتفاق می‌افتد. (CDN درخواست کاربر را به صورت HTTPS دریافت می‌کند، اما درخواست را به صورت HTTP به وب‌سرور شما می‌فرستد؛ وب‌سرور مجدداً پاسخ ریدایرکت به HTTPS می‌دهد و این چرخه تکرار می‌شود).

• راه‌حل: در تنظیمات CDN بخش آپ‌استریم، مطمئن شوید پروتکل ارتباط روی HTTPS یا Match Client تنظیم شده باشد و سرور اصلی شما گواهی SSL معتبر داشته باشد.

۳. عدم استثنا کردن دامنه هدف در شرط‌های قانون: اگر قانونی برای ریدایرکت درخواست‌ها به www.example.com ایجاد کرده‌اید، اما شرط قانون به گونه‌ای است که شامل خود دامنه هدف نیز می‌شود (مثلاً شرط Host matches *example.com یا شرط‌های بسیار کلی بدون استثنا کردن دامنه اصلی)، درخواست‌هایی که پیش‌فرض به www آمده‌اند مجدداً به همان آدرس ریدایرکت شده و وارد حلقه می‌شوند.

• راه‌حل: شرط‌های قانون فایروال را به گونه‌ای بنویسید که فقط دامنه‌ی فاقد www را هدف قرار دهد، یا ریدایرکت‌ها را از بخش تنظیمات اختصاصی دامنه یا وب‌سرور مبدا مدیریت کنید.