چگونه IP اصلی سرور پشت Cloudflare را مخفی کنیم؟ بررسی امنیت Origin Server

پاسخ کوتاه: برای مخفی کردن IP اصلی سرور پشت Cloudflare، صرفاً فعال‌کردن Proxy روی DNS کافی نیست. باید تمام رکوردهای افشاکننده IP بررسی شوند، دسترسی مستقیم به پورت‌های وب در فایروال Origin محدود شود، ارتباط Cloudflare با سرور با TLS امن شود و در معماری‌های حساس از Authenticated Origin Pulls یا Cloudflare Tunnel استفاده شود.

فرض کنید Cloudflare را فعال کرده‌اید، آیکون ابر نارنجی کنار رکورد دامنه دیده می‌شود و هنگام بررسی DNS نیز به‌جای IP واقعی سرور، آدرس‌های Cloudflare نمایش داده می‌شوند. در نگاه اول همه‌چیز امن به نظر می‌رسد. اما آیا این یعنی Origin Server دیگر مستقیماً از اینترنت قابل دسترسی نیست؟

پاسخ الزاماً مثبت نیست.

یکی از اشتباهات رایج در معماری سایت‌های پشت Cloudflare این است که «مخفی بودن IP در DNS» با «غیرقابل دسترس بودن مستقیم سرور» یکسان در نظر گرفته می‌شود. Cloudflare به‌عنوان Reverse Proxy می‌تواند IP اصلی را از پاسخ DNS عمومی پنهان کند، اما اگر Origin IP از مسیر دیگری افشا شده باشد یا فایروال سرور همچنان درخواست مستقیم از کل اینترنت را بپذیرد، مهاجم می‌تواند Cloudflare را دور بزند و مستقیماً Origin را هدف قرار دهد.

در چنین شرایطی بسیاری از قابلیت‌هایی که مدیر سایت به آن‌ها تکیه کرده است، مانند Web Application Firewall یا WAF، Rate Limiting، Bot Management، Cache و بخشی از لایه‌های مقابله با DDoS، دیگر در مسیر درخواست قرار ندارند.

بنابراین امنیت Origin Server فقط یک مسئله DNS نیست. باید آن را به‌صورت یک معماری چندلایه بررسی کرد:

Visitor → Cloudflare → Origin Server

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

Visitor → Origin Server

در ادامه دقیقاً بررسی می‌کنیم IP اصلی سرور چگونه ممکن است افشا شود، Cloudflare چه چیزی را مخفی می‌کند و چه چیزی را مخفی نمی‌کند، فایروال Origin چگونه باید طراحی شود، Authenticated Origin Pulls چه کاربردی دارد، Cloudflare Tunnel چه تفاوتی با معماری معمولی دارد و چگونه می‌توان امنیت سرور اصلی را بدون ایجاد اختلال در سایت افزایش داد.

Origin Server چیست و چرا امنیت آن اهمیت دارد؟

Origin Server یا سرور مبدأ همان سیستمی است که محتوای واقعی وب‌سایت، برنامه وب، API یا فایل‌های سایت روی آن قرار گرفته‌اند.

این Origin ممکن است یکی از موارد زیر باشد:

• یک VPS لینوکسی
• Dedicated Server
• سرور Nginx یا Apache
• هاست دارای کنترل‌پنل مانند cPanel یا DirectAdmin
• سرور WordPress
• یک Load Balancer
• یک Application Server
• زیرساخت ابری
• یک Kubernetes Ingress
• یا مجموعه‌ای از چند سرور Backend

وقتی Cloudflare در مقابل این زیرساخت قرار می‌گیرد، بازدیدکننده مستقیماً به Origin متصل نمی‌شود. ابتدا DNS دامنه او را به شبکه Cloudflare هدایت می‌کند و Cloudflare درخواست را دریافت، بررسی و در صورت نیاز به سرور اصلی ارسال می‌کند.

در معماری عادی پشت Cloudflare مسیر تقریباً چنین است:

کاربر ↓ Cloudflare Edge ↓ Origin Server ↓ Application / WordPress / API / Database

این جداسازی مزایای امنیتی مهمی دارد. برای مثال Cloudflare می‌تواند برخی ترافیک‌های مخرب را قبل از رسیدن به زیرساخت واقعی متوقف کند.

اما اگر IP واقعی Origin مشخص باشد و سرور درخواست مستقیم اینترنت را قبول کند، مسیر دیگری نیز ایجاد می‌شود:

کاربر یا مهاجم ↓ IP مستقیم Origin ↓ Web Server

در این مسیر Cloudflare اصلاً حضور ندارد.

به همین دلیل «پنهان بودن IP» باید در کنار «محدود کردن دسترسی مستقیم» پیاده‌سازی شود.

Cloudflare چگونه IP اصلی سرور را مخفی می‌کند؟

هنگامی که یک رکورد DNS از نوع A، AAAA یا CNAME در Cloudflare در وضعیت Proxied قرار داشته باشد، درخواست DNS عمومی معمولاً به جای مقصد واقعی، IPهای شبکه Cloudflare را بازمی‌گرداند.

در نتیجه کاربر به Cloudflare متصل می‌شود و Cloudflare در پشت صحنه درخواست را به Origin می‌رساند.

Cloudflare در این معماری Reverse Proxy است.

به زبان ساده:

بدون Cloudflare:

Browser → Origin IP

با Cloudflare Proxy:

Browser → Cloudflare IP → Origin IP

بنابراین IP واقعی پشت لایه Proxy قرار می‌گیرد و مستقیماً در پاسخ عادی DNS نمایش داده نمی‌شود. Cloudflare نیز تصریح می‌کند که رکوردهای Proxied آدرس‌های Anycast شبکه Cloudflare را به کاربران برمی‌گردانند، نه IP سرور مبدأ.

اما نکته مهم اینجاست:

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

اگر همان Origin IP در یک رکورد DNS دیگر، سرویس ایمیل، سابقه قدیمی DNS یا سرویس عمومی دیگری قابل مشاهده باشد، ابر نارنجی دامنه اصلی مشکل را برطرف نخواهد کرد.

تفاوت مخفی بودن Origin IP با امن بودن Origin

این دو مفهوم باید کاملاً از یکدیگر جدا شوند.

مخفی بودن Origin IP

یعنی کاربری که رکورد دامنه را بررسی می‌کند، به‌جای IP واقعی Backend، IP Cloudflare را مشاهده کند.

امن بودن Origin

یعنی حتی اگر IP واقعی سرور somehow مشخص شد، دسترسی غیرمجاز مستقیم به سرویس وب امکان‌پذیر نباشد یا بسیار محدود شده باشد.

یک پیکربندی قوی باید هر دو ویژگی را داشته باشد.

اگر فقط IP را مخفی کنیم ولی Origin روی پورت 443 از کل اینترنت درخواست قبول کند، امنیت همچنان به ناشناس ماندن یک مقدار عددی وابسته است.

این رویکرد نوعی Security by Obscurity محسوب می‌شود و نباید تنها لایه دفاعی باشد.

هدف صحیح این است:

حتی در صورت افشای Origin IP، درخواست مستقیم نباید بتواند به‌سادگی مسیر Cloudflare را دور بزند.

چرا دور زدن Cloudflare می‌تواند خطرناک باشد؟

Cloudflare زمانی می‌تواند درخواست را بررسی یا مسدود کند که درخواست واقعاً از شبکه آن عبور کند.

فرض کنید برای سایت موارد زیر فعال هستند:

• WAF
• Rate Limiting
• Bot Protection
• DDoS Protection
• Firewall Rules
• Managed Rules
• Geo Restrictions
• Access Policies

اگر شخصی بتواند مستقیماً با Origin ارتباط برقرار کند، بخشی از این کنترل‌ها دیگر در مسیر او نیستند.

برای مثال ممکن است روی Cloudflare یک Rule تنظیم کرده باشید که تعداد درخواست‌های Login را محدود کند، اما خود وب‌سرور همچنان از اینترنت قابل دسترسی باشد.

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

این موضوع به‌خصوص برای سایت‌هایی که دارای مسیرهای حساس هستند اهمیت بیشتری دارد:

/wp-login.php

/wp-admin/

API endpoints

صفحات احراز هویت

پنل‌های مدیریتی

سرویس‌های آپلود فایل

Webhook endpoints

صفحات پرداخت

Origin API

بنابراین جلوگیری از Direct Origin Access یکی از بخش‌های اساسی معماری دفاعی پشت CDN و Reverse Proxy است.

IP اصلی سرور پشت Cloudflare چگونه ممکن است افشا شود؟

پیش از سخت‌سازی Origin باید بدانیم چه چیزهایی باعث افشای IP می‌شوند.

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

رکوردهای DNS که Proxied نیستند

یکی از رایج‌ترین دلایل افشای Origin، وجود رکوردی با وضعیت DNS Only است.

برای مثال ممکن است دامنه اصلی Proxied باشد:

example.com

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

api.example.com

dev.example.com

staging.example.com

ftp.example.com

panel.example.com

direct.example.com

اگر این رکورد DNS Only باشد و به همان IP وب‌سرور اشاره کند، Origin IP عملاً قابل مشاهده خواهد بود.

Cloudflare نیز توصیه می‌کند رکوردهای DNS-only بررسی شوند، زیرا ممکن است اطلاعات Origin را آشکار کنند.

رکورد AAAA فراموش‌شده

گاهی مدیر سایت رکورد IPv4 از نوع A را پشت Cloudflare می‌برد اما رکورد IPv6 از نوع AAAA همچنان به Origin واقعی اشاره می‌کند.

نتیجه این است که IPv4 مخفی شده اما IPv6 واقعی سرور منتشر است.

بنابراین هنگام Audit نباید فقط A Record بررسی شود.

هر دو مسیر باید ارزیابی شوند:

IPv4 → A Record

IPv6 → AAAA Record

استفاده از یک IP مشترک برای وب و ایمیل

یکی از معماری‌های نامناسب این است که Web Server و Mail Server روی یک IP عمومی قرار داشته باشند.

برای سرویس ایمیل معمولاً رکوردهای MX و رکوردهای مرتبط باید مستقیماً به زیرساخت Mail اشاره کنند و Cloudflare Proxy استاندارد HTTP برای آن‌ها استفاده نمی‌شود.

اگر Mail Server همان IP Origin سایت را داشته باشد، جداکردن هویت شبکه وب‌سرور دشوارتر می‌شود.

Cloudflare نیز توصیه می‌کند در صورت امکان زیرساخت ایمیل روی همان Origin وب قرار نگیرد، زیرا سرویس ایمیل می‌تواند به افشای IP مرتبط منجر شود.

معماری بهتر:

Web Origin → IP A

Mail Server → IP B

به این ترتیب افشای Mail IP الزاماً Web Origin را افشا نمی‌کند.

رکوردهای قدیمی DNS

فرض کنید سایت چند سال روی IP زیر قرار داشته است:

Old Origin → IP A

سپس Cloudflare فعال شده ولی Origin همچنان همان IP را حفظ کرده است.

حتی اگر DNS فعلی IP را نمایش ندهد، اطلاعات DNS تاریخی ممکن است از گذشته باقی مانده باشند.

راهکار مؤثر در چنین شرایطی این است که پس از انتقال کامل و اطمینان از پیکربندی Cloudflare، Origin روی IP جدیدی قرار گیرد.

Cloudflare نیز در راهنمای محافظت از Origin، تغییر یا Rotate کردن IP سرور را در سناریوهایی که آدرس قبلی ممکن است شناخته شده باشد پیشنهاد می‌کند.

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

Origin قدیمی → Cloudflare فعال → بررسی DNS → IP جدید Origin → محدودسازی Firewall

اگر IP قدیمی سال‌ها عمومی بوده باشد، صرفاً فعال‌کردن ابر نارنجی نمی‌تواند سابقه آن را حذف کند.

زیردامنه‌های آزمایشی و فراموش‌شده

یک مشکل بسیار رایج در سازمان‌ها وجود محیط‌هایی مانند موارد زیر است:

Development

Staging

QA

Test

Old Panel

Legacy API

Backup Host

ممکن است دامنه اصلی کاملاً امن باشد اما staging همچنان DNS Only باقی مانده باشد و به همان ماشین Production اشاره کند.

به همین دلیل DNS Audit باید تمام Zone را پوشش دهد، نه فقط www و Root Domain را.

سرویس‌های مدیریتی روی همان IP

فرض کنید سایت پشت Cloudflare است اما سرویس‌های زیر نیز روی همان IP قرار دارند:

SSH

cPanel

WHM

DirectAdmin

Webmin

FTP

Database

Control Panel

Cloudflare Proxy عادی برای هر نوع پروتکل اینترنتی طراحی نشده است. بنابراین نباید تصور کرد فعال‌کردن Proxy روی دامنه، تمام پورت‌های سرور را پشت Cloudflare قرار می‌دهد.

دسترسی مدیریتی باید جداگانه محدود شود.

برای مثال:

SSH → فقط VPN یا IP مدیریت

Database → فقط Private Network

Control Panel → VPN / Zero Trust / Management IP

Web Traffic → Cloudflare

این جداسازی سطح حمله را به‌شدت کاهش می‌دهد.

اولین مرحله عملی: Audit کامل DNS

قبل از تغییر Firewall، ابتدا باید مطمئن شوید DNS به‌درستی طراحی شده است.

یک اشتباه در این مرحله ممکن است تمام تلاش‌های بعدی را بی‌اثر کند.

رکوردهای A و AAAA را بررسی کنید

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

برای هر رکورد بپرسید:

آیا این hostname باید عمومی باشد؟

آیا باید پشت Cloudflare قرار بگیرد؟

آیا واقعاً لازم است به همین Origin اشاره کند؟

اگر پاسخ مثبت است و سرویس با Proxy سازگار است، معمولاً رکورد وب باید Proxied باشد.

CNAMEها را فراموش نکنید

گاهی یک CNAME مستقیماً IP را نمایش نمی‌دهد اما مقصد آن به Host دیگری می‌رسد که اطلاعات Origin را آشکار می‌کند.

بنابراین فقط رکوردهای A کافی نیستند.

زنجیره Resolution نیز باید بررسی شود.

رکوردهای DNS Only را دسته‌بندی کنید

هر رکورد DNS Only باید دلیل مشخصی برای DNS Only بودن داشته باشد.

اگر دلیل آن مشخص نیست، احتمالاً باید دوباره ارزیابی شود.

نمونه سرویس‌هایی که ممکن است عمداً DNS Only باشند:

Mail

برخی سرویس‌های Verification

بعضی سرویس‌های غیر HTTP

برخی سرویس‌های داخلی خاص

اما DNS Only بودن نباید صرفاً به دلیل تنظیمات قدیمی باقی مانده باشد.

MX و زیرساخت ایمیل را بررسی کنید

اگر MX به ماشینی اشاره می‌کند که همان IP وب‌سرور را دارد، جداسازی Web و Mail را بررسی کنید.

این تفکیک علاوه بر مسئله IP، از نظر Operational Security نیز مفید است.

TXT و SPF را نیز نادیده نگیرید

رکورد TXT لزوماً فقط متن بی‌اهمیت نیست.

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

Cloudflare صراحتاً توصیه می‌کند رکوردهای DNS-only، از جمله رکوردهای مرتبط مانند SPF و TXT، برای اطلاعات احتمالی Origin بررسی شوند.

مهم‌ترین لایه دفاعی: Firewall روی Origin Server

یکی از مهم‌ترین اصول امنیت Origin این است که Web Server برای تمام اینترنت باز نباشد.

در معماری کلاسیک Cloudflare:

Internet → Cloudflare → Origin

بنابراین اگر هیچ کاربری نباید مستقیماً به Origin متصل شود، فایروال می‌تواند ورودی HTTP/HTTPS را فقط از شبکه Cloudflare قبول کند.

این تغییر بسیار مهم است، زیرا حتی اگر IP Origin بعداً شناخته شود، درخواست مستقیم از IPهای معمول اینترنت به Web Server نمی‌رسد.

مدل Allowlist

به‌جای این مدل:

Internet → TCP 80/443 → Allow

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

Cloudflare Networks → TCP 80/443 → Allow

Internet → TCP 80/443 → Deny

این همان Positive Security Model است؛ یعنی به‌جای تلاش برای مسدودکردن میلیون‌ها منبع نامعتبر، فقط منابع مورد اعتماد اجازه دارند.

Cloudflare نیز توصیه می‌کند در Origin، IPهای شبکه Cloudflare Allow شوند تا ترافیک Proxied معتبر به سرور برسد.

Cloudflare IP ranges را دستی و دائمی Hardcode نکنید

Cloudflare مجموعه‌ای از Prefixهای IPv4 و IPv6 را برای ارتباط با Origin منتشر می‌کند.

اما معماری عملیاتی بهتر این است که این Prefixها از منبع رسمی مدیریت شوند و فرآیند به‌روزرسانی وجود داشته باشد.

اگر یک لیست قدیمی برای سال‌ها داخل Firewall باقی بماند، تغییرات شبکه می‌توانند باعث اختلال شوند.

بنابراین سیاست خوب شامل این موارد است:

• دریافت Prefixها از منبع رسمی
• نگهداری نسخه فعلی
• مدیریت IPv4 و IPv6
• تست قبل از اعمال Rule جدید
• داشتن Recovery Access
• ثبت تغییرات Firewall

قبل از بستن پورت‌ها Recovery Path داشته باشید

هر تغییری در Firewall ممکن است در صورت خطا دسترسی مدیر را نیز قطع کند.

بنابراین قبل از اعمال محدودیت:

• Console دسترسی ارائه‌دهنده سرور را بررسی کنید.
• SSH Session دوم باز داشته باشید.
• Ruleهای جدید را قبل از حذف Rule قبلی تست کنید.
• Configuration Backup بگیرید.
• از صحت IPv4 و IPv6 مطمئن شوید.

امنیت خوب نباید باعث Lockout مدیر سیستم شود.

آیا باید Port 80 و 443 Origin را کاملاً ببندیم؟

پاسخ به معماری بستگی دارد.

در مدل کلاسیک Cloudflare، این پورت‌ها باید برای Cloudflare قابل دسترس باشند ولی لازم نیست برای تمام اینترنت باز باشند.

یعنی:

Cloudflare → 80/443 → Allow

Other Sources → 80/443 → Deny

در مدل Cloudflare Tunnel حتی می‌توان معماری‌ای داشت که برای Application هیچ Inbound Port عمومی باز نباشد؛ زیرا cloudflared از داخل سرور ارتباط Outbound با Cloudflare ایجاد می‌کند.

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

Cloudflare Tunnel؛ راهکار قوی برای مخفی کردن Origin

اگر هدف این باشد که Origin اساساً برای سرویس وب نیازمند Listener عمومی اینترنت نباشد، Cloudflare Tunnel یکی از معماری‌های مهم است.

در روش سنتی:

Cloudflare → Public Origin IP → Nginx

اما در Tunnel:

Origin / cloudflared → Outbound Tunnel → Cloudflare

کاربر درخواست خود را به Cloudflare ارسال می‌کند و Cloudflare آن را از طریق Tunnel موجود به سرویس داخلی منتقل می‌کند.

تفاوت معماری Tunnel

مدل سنتی:

Internet ↓ Cloudflare ↓ Public IP ↓ Firewall ↓ Origin

مدل Tunnel:

Internet ↓ Cloudflare ⇅ Encrypted Outbound Tunnel ⇅ cloudflared ↓ Local Application

در این مدل می‌توان Application را مثلاً فقط روی Interface داخلی یا localhost نگه داشت.

Cloudflare Tunnel به‌صورت Outbound-only ارتباط را از داخل زیرساخت آغاز می‌کند و برای سرویس‌های منتشرشده از طریق Tunnel نیازی به IP عمومی قابل‌دسترسی مستقیم وجود ندارد. مستندات فعلی Cloudflare این قابلیت را برای همه پلن‌ها ارائه می‌کنند.

مزیت امنیتی Tunnel

مهم‌ترین مزیت این است که مهاجم دیگر صرفاً با دانستن IP ماشین نمی‌تواند به پورت عمومی Application متصل شود، به شرط آنکه Firewall نیز مطابق معماری Tunnel بسته شده باشد.

Cloudflare در راهنمای Firewall مربوط به Tunnel توضیح می‌دهد که می‌توان Ingress را مسدود کرد و فقط ارتباط Outbound مورد نیاز cloudflared را مجاز دانست.

این مدل سطح حمله شبکه‌ای را کاهش می‌دهد.

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

خیر.

یک معماری سنتی با Cloudflare Proxy، Firewall Allowlist و TLS صحیح نیز می‌تواند بسیار امن باشد.

Tunnel زمانی جذاب‌تر است که:

• می‌خواهید Origin بدون پورت ورودی عمومی باشد.
• زیرساخت Private دارید.
• سرویس داخلی را می‌خواهید Publish کنید.
• مدیریت Firewall سنتی پیچیده است.
• می‌خواهید مسیر Origin → Cloudflare از داخل آغاز شود.
• معماری Zero Trust دارید.

انتخاب بین این مدل‌ها باید بر اساس Availability، Operational Complexity، معماری شبکه و نیاز سازمان انجام شود.

Authenticated Origin Pulls چیست؟

Authenticated Origin Pulls یا AOP یک لایه امنیتی دیگر برای ارتباط Cloudflare و Origin است.

در حالت عادی، سرور HTTPS یک Certificate به Client ارائه می‌کند تا هویت Server بررسی شود.

در AOP از Client Certificate Authentication در ارتباط Cloudflare با Origin استفاده می‌شود.

در نتیجه Origin می‌تواند درخواست را فقط زمانی قبول کند که طرف مقابل گواهی Client معتبر مورد انتظار را ارائه دهد.

این مفهوم به Mutual TLS یا mTLS نزدیک است.

مدل بدون AOP:

Cloudflare → HTTPS → Origin

External Client → HTTPS → Origin

اگر Firewall محدود نشده باشد، هر دو مسیر ممکن است به سرور برسند.

با AOP:

Cloudflare + Client Certificate → Origin → Accepted

Client بدون Certificate معتبر → Origin → Rejected

Cloudflare توضیح می‌دهد که Authenticated Origin Pulls روی Full یا Full (strict) قابل استفاده است و هدف آن اطمینان بیشتر از این است که درخواست Origin Pull از شبکه Cloudflare آمده باشد.

آیا AOP جای Firewall را می‌گیرد؟

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

مدل دفاع در عمق می‌تواند شامل موارد زیر باشد:

DNS Proxy

*

Firewall Allowlist

*

Full (strict)

*

Authenticated Origin Pulls

هر لایه یک مسئله متفاوت را پوشش می‌دهد.

تفاوت Global AOP و Certificate اختصاصی

در مدل Global AOP، Certificate ارائه‌شده توسط Cloudflare تضمین می‌کند درخواست از شبکه Cloudflare آمده است، اما این Certificate اختصاصی یک حساب خاص نیست.

Cloudflare برای نیازهای سخت‌گیرانه‌تر، استفاده از Certificate اختصاصی در سطح Zone یا Hostname را مطرح می‌کند.

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

AOP و Cloudflare Tunnel

این دو را نباید بی‌دلیل هم‌زمان روی یک Hostname طراحی کرد.

Cloudflare تصریح می‌کند که Authenticated Origin Pulls برای Hostnameهایی که از Cloudflare Tunnel استفاده می‌کنند کاربرد ندارد؛ زیرا Tunnel Listener ورودی عمومی Origin را به همان شکل استفاده نمی‌کند و احراز مسیر توسط Credentials خود Tunnel انجام می‌شود.

TLS بین Cloudflare و Origin را جدی بگیرید

یکی دیگر از اشتباهات رایج این است که مدیر سایت فقط به HTTPS بین Browser و Cloudflare توجه کند.

اما در معماری Cloudflare دو ارتباط جدا وجود دارد:

Browser ↔ Cloudflare

Cloudflare ↔ Origin

امنیت واقعی End-to-End زمانی شکل می‌گیرد که ارتباط دوم نیز به‌درستی رمزنگاری و احراز شود.

حالت Full (strict)

برای اکثر زیرساخت‌هایی که امکان Certificate معتبر دارند، Full (strict) انتخاب مناسب‌تری است.

در این حالت Cloudflare هنگام ارتباط HTTPS با Origin، Certificate سرور را نیز اعتبارسنجی می‌کند.

Certificate باید:

• منقضی نشده باشد.
• برای Hostname مناسب صادر شده باشد.
• از CA قابل اعتماد یا Cloudflare Origin CA باشد.

Cloudflare نیز Full (strict) را در صورت امکان به‌عنوان حالت امن‌تر توصیه می‌کند.

تفاوت Full و Full (strict)

در Full ارتباط TLS وجود دارد اما اعتبار Certificate Origin به سخت‌گیری Full (strict) بررسی نمی‌شود.

به بیان ساده:

Full → Encryption

Full (strict) → Encryption + Origin Certificate Validation

بنابراین وجود قفل HTTPS در Browser به‌تنهایی اثبات نمی‌کند ارتباط Cloudflare تا Origin نیز در امن‌ترین وضعیت ممکن قرار دارد.

Cloudflare Origin CA

Cloudflare Origin CA برای ارتباط Cloudflare با Origin طراحی شده است.

اگر Origin فقط از طریق Cloudflare در دسترس باشد، این Certificate می‌تواند گزینه مناسبی باشد.

پس از نصب Origin CA، Full (strict) قابل استفاده است.

یک نکته عملی مهم این است که Origin CA برای Browserهایی که مستقیماً به سرور وصل می‌شوند مانند Certificate عمومی عادی طراحی نشده است.

این موضوع در معماری بسته Origin معمولاً مشکل محسوب نمی‌شود، زیرا قرار نیست کاربران مستقیماً Origin را باز کنند.

HTTP نباید مسیر فراموش‌شده باشد

گاهی مدیر سیستم HTTPS را به Cloudflare محدود می‌کند اما پورت HTTP همچنان برای تمام اینترنت باز است.

در نتیجه مسیر جانبی ایجاد می‌شود.

اگر Origin برای Cloudflare به هر دو پورت نیاز دارد، هر دو باید تحت سیاست Firewall مناسب قرار بگیرند.

اگر فقط HTTPS لازم است، معماری را بر همان اساس محدود کنید.

هدف این است که Ruleهای Firewall با رفتار واقعی Cloudflare و Web Server هماهنگ باشند.

Host Header و Virtual Host را نیز محدود کنید

حتی اگر یک IP میزبان چند سایت باشد، Web Server باید به Hostnameهای مورد انتظار پاسخ دهد.

در Nginx یا Apache بهتر است Default Virtual Host به‌گونه‌ای تنظیم شود که درخواست‌های ناشناس یا Hostnameهای غیرمجاز را به Application اصلی تحویل ندهد.

برای مثال معماری مطلوب این نیست:

هر Hostname → Application Production

بلکه:

Expected Host → Application

Unknown Host → Reject / Minimal Response

این کار جای Firewall را نمی‌گیرد اما سطح دفاع Application Layer را افزایش می‌دهد.

IP واقعی بازدیدکننده را چگونه حفظ کنیم؟

وقتی Cloudflare Reverse Proxy است، اتصال TCP مستقیم به Origin از IPهای Cloudflare می‌آید.

بنابراین اگر Web Server بدون تنظیم اضافی Log بگیرد، ممکن است به‌جای IP واقعی Visitor، IP Cloudflare را مشاهده کند.

برای کاربردهایی مانند:

Security Logging

Rate Limiting داخلی

Fraud Detection

Audit Trail

Login Monitoring

Fail2ban Integration

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

Cloudflare برای HTTP هدر CF-Connecting-IP را در اختیار Origin قرار می‌دهد.

خطر اعتماد کورکورانه به Header

نباید صرفاً هر مقدار CF-Connecting-IP یا X-Forwarded-For را از هر Client اینترنتی معتبر فرض کرد.

یک Header HTTP می‌تواند توسط Client ارسال شود.

مدل امن زمانی است که ابتدا مطمئن باشید درخواست واقعاً از Proxy مورد اعتماد آمده است و سپس Header آن Proxy را Trust کنید.

بنابراین:

Cloudflare IP → Header Trusted

Unknown Internet IP → Header Untrusted

Cloudflare نیز توصیه می‌کند Origin فقط ترافیک شبکه Cloudflare را بپذیرد؛ در غیر این صورت هدرهای مرتبط با IP می‌توانند در سناریوی دسترسی مستقیم قابل جعل باشند.

Nginx

در Nginx معمولاً ngx_http_realip_module برای این هدف استفاده می‌شود.

منطق پیکربندی چنین است:

Trusted Proxy Networks = Cloudflare

Real IP Header = CF-Connecting-IP

در این حالت Nginx فقط هنگامی هدر را معتبر در نظر می‌گیرد که Connection از Proxy مورد اعتماد رسیده باشد.

Apache

برای Apache معمولاً mod_remoteip گزینه رایج است.

Cloudflare نیز به‌جای mod_cloudflare قدیمی، استفاده از mod_remoteip را برای Apache توصیه می‌کند.

چرا WAF روی Cloudflare جای امنیت Origin را نمی‌گیرد؟

WAF ابزار مهمی است اما WAF فقط ترافیکی را بررسی می‌کند که از مسیر آن عبور کند.

به همین دلیل معماری صحیح باید دو سؤال را جداگانه پاسخ دهد:

1. اگر درخواست از Cloudflare عبور کرد، چگونه بررسی شود؟
2. چگونه مطمئن شویم درخواست عمومی بدون عبور از Cloudflare به Origin نمی‌رسد؟

سؤال اول مربوط به Edge Security است.

سؤال دوم مربوط به Origin Security است.

این دو مکمل یکدیگر هستند.

یک معماری نمونه:

Internet ↓ Cloudflare DDoS Protection ↓ Cloudflare WAF ↓ Firewall / Tunnel ↓ TLS Validation ↓ Web Server ↓ Application Security ↓ Database

هیچ لایه‌ای به‌تنهایی کافی نیست.

Cloudflare جلوی تمام حملات DDoS به Origin را می‌گیرد؟

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

اما اگر IP Origin افشا شده و مستقیماً قابل دسترسی باشد، مهاجم ممکن است به‌جای دامنه Cloudflare، IP Backend را هدف قرار دهد.

در آن حالت بسته‌ها پیش از رسیدن به Cloudflare وارد شبکه Hosting Provider یا سرور شما می‌شوند.

پس Origin Protection یکی از اجزای مهم استراتژی DDoS است.

همچنین باید توجه داشت که ظرفیت لینک شبکه Provider نیز اهمیت دارد.

Firewall نرم‌افزاری داخل سیستم‌عامل همیشه قادر نیست یک حمله حجمی بزرگ را حل کند، زیرا ممکن است پهنای باند قبل از رسیدن Packet به Firewall اشباع شده باشد.

برای زیرساخت‌های حساس، محافظت Upstream در سطح Provider و طراحی مناسب شبکه نیز اهمیت دارد.

سرویس SSH را چگونه مدیریت کنیم؟

SSH نباید صرفاً به این دلیل که وب‌سایت Cloudflare دارد، امن فرض شود.

Cloudflare Proxy وب با SSH عمومی یک مسئله متفاوت است.

برای SSH بهتر است یکی از مدل‌های زیر استفاده شود:

• VPN
• Private Network
• Zero Trust Access
• Management IP Allowlist
• Bastion Host
• Cloudflare Tunnel در معماری مناسب
• کلید SSH به‌جای Password
• محدودیت Login
• غیرفعال‌سازی Root Login مستقیم در صورت امکان

اگر Port 22 روی همان Origin برای کل اینترنت باز باشد، مخفی کردن IP وب‌سایت به‌تنهایی این سرویس را محافظت نمی‌کند.

Database نباید مستقیماً عمومی باشد

یکی از بدترین خطاهای معماری این است که سرویس‌هایی مانند MySQL، PostgreSQL یا Redis بدون نیاز واقعی روی Public Interface قرار گرفته باشند.

در اکثر معماری‌های وب:

Internet نباید مستقیماً Database را ببیند.

مدل مناسب:

Web Application → Private Database

نه:

Internet → Database

اگر Database و Web Server روی یک ماشین هستند، Bind Address و Firewall باید متناسب با نیاز واقعی تنظیم شوند.

اگر روی ماشین‌های متفاوت هستند، Private Network یا Segment داخلی گزینه بهتری است.

WordPress پشت Cloudflare؛ چه چیزهایی باید بررسی شود؟

برای WordPress، امنیت Origin اهمیت ویژه‌ای دارد زیرا مسیرهای شناخته‌شده‌ای مانند Login و XML-RPC ممکن است هدف درخواست‌های خودکار زیادی قرار گیرند.

اما راهکار اصلی مخفی‌کردن URLها نیست.

معماری باید شامل چند لایه باشد:

Cloudflare

↓

Origin Firewall

↓

Web Server

↓

WordPress

↓

Authentication Controls

در WordPress بهتر است علاوه بر امنیت Origin موارد زیر نیز بررسی شوند:

• به‌روزرسانی Core
• به‌روزرسانی Plugin و Theme
• حذف افزونه‌های بلااستفاده
• استفاده از 2FA برای مدیران
• محدودیت حساب‌های Administrator
• Backup مستقل
• Logging
• کنترل Brute Force
• مدیریت صحیح REST API
• File Permission مناسب
• غیرفعال‌سازی قابلیت‌های غیرضروری
• محافظت از پنل Hosting

Cloudflare نباید جای Hardening خود WordPress را بگیرد.

آیا مخفی کردن صفحه wp-admin باعث مخفی شدن Origin می‌شود؟

خیر.

تغییر URL ورود یا محدودکردن صفحه مدیریت یک کنترل Application Layer است.

Origin IP یک مسئله Network Layer و DNS/Infrastructure است.

این دو نباید با یکدیگر اشتباه گرفته شوند.

ممکن است /wp-admin/ کاملاً محدود شده باشد ولی IP Origin همچنان عمومی باشد.

یا بالعکس، Origin به‌خوبی پشت Firewall باشد اما WordPress رمز عبور ضعیف داشته باشد.

امنیت واقعی نتیجه مجموع این لایه‌هاست.

پنل‌های cPanel و DirectAdmin چه وضعیتی دارند؟

اگر Web Hosting Control Panel روی همان IP Origin قرار دارد، باید مشخص شود چه کسانی واقعاً نیاز دارند به آن دسترسی داشته باشند.

پنل مدیریتی یک سرویس عمومی عادی نیست.

بهتر است دسترسی آن محدود شود، مثلاً:

Administrator Network → Control Panel

General Internet → Denied

اگر IP مدیریت ثابت ندارید، VPN یا راهکار Zero Trust معمولاً انعطاف‌پذیرتر است.

همچنین حساب پنل باید:

• 2FA داشته باشد.
• Password یکتا و قوی داشته باشد.
• Login History بررسی شود.
• نسخه نرم‌افزار به‌روز باشد.
• سرویس‌های غیرضروری غیرفعال باشند.

معماری پیشنهادی سطح پایه

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

Visitor ↓ Cloudflare Proxy ↓ Origin Firewall ↓ Nginx / Apache ↓ Application

کنترل‌ها:

DNS → Proxied

TLS → Full (strict)

Firewall → فقط Cloudflare برای Web

SSH → فقط Management Access

Database → Private

Logging → Real Client IP

این معماری نسبتاً ساده و در عین حال مؤثر است.

معماری پیشنهادی سطح قوی‌تر

برای سایتی با حساسیت بیشتر:

Visitor ↓ Cloudflare ↓ WAF / Rate Limiting ↓ Restricted Origin Firewall ↓ Authenticated Origin Pulls ↓ Nginx ↓ Application

در این مدل درخواست علاوه بر Source Network، در لایه TLS نیز احراز می‌شود.

معماری Tunnel

برای زیرساخت‌هایی که می‌خواهند Public Inbound Web Port را حذف کنند:

Visitor ↓ Cloudflare ↓ Cloudflare Tunnel ↓ cloudflared ↓ Local Web Service

Firewall:

Inbound → Denied

Required Outbound Tunnel Traffic → Allowed

این مدل می‌تواند وابستگی امنیتی به مخفی ماندن Public Origin IP را تا حد زیادی کاهش دهد.

مقایسه روش‌های محافظت از Origin

<table> <thead> <tr> <th>روش</th> <th>هدف اصلی</th> <th>مزیت</th> <th>محدودیت</th> </tr> </thead> <tbody> <tr> <td>Cloudflare Proxy</td> <td>مخفی‌کردن Origin در DNS و عبور ترافیک وب از Edge</td> <td>ساده و مؤثر برای شروع</td> <td>به‌تنهایی Direct Origin Access را نمی‌بندد</td> </tr> <tr> <td>Firewall Allowlist</td> <td>قبول Web Traffic فقط از Cloudflare</td> <td>جلوگیری جدی از دور زدن Proxy</td> <td>نیازمند مدیریت صحیح Prefixها</td> </tr> <tr> <td>Full (strict)</td> <td>رمزنگاری و اعتبارسنجی ارتباط Origin</td> <td>امنیت بهتر TLS</td> <td>نیازمند Certificate صحیح</td> </tr> <tr> <td>Authenticated Origin Pulls</td> <td>احراز Cloudflare نزد Origin</td> <td>لایه اضافی mTLS</td> <td>پیکربندی پیچیده‌تر</td> </tr> <tr> <td>Cloudflare Tunnel</td> <td>حذف نیاز به Inbound Public Web Access</td> <td>کاهش سطح حمله Origin</td> <td>وابستگی به Connector و معماری Tunnel</td> </tr> <tr> <td>VPN / Zero Trust</td> <td>محافظت از سرویس مدیریتی</td> <td>مناسب SSH و Panel</td> <td>نیازمند مدیریت کاربران و Access Policy</td> </tr> </tbody> </table>

یک فرآیند استاندارد برای امن‌سازی Origin Server

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

مرحله اول: Inventory

تمام Hostnameهای دامنه را مشخص کنید.

برای هرکدام بدانید:

• به چه سرویسی متصل است؟
• IP مقصد چیست؟
• Proxied است یا DNS Only؟
• آیا عمومی بودن آن ضروری است؟
• آیا با Origin اصلی IP مشترک دارد؟

مرحله دوم: بررسی Origin فعلی

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

برای مثال:

80/TCP

443/TCP

22/TCP

Control Panel Ports

Database Ports

هر پورت باید Owner و دلیل مشخص داشته باشد.

قاعده مناسب:

اگر نمی‌دانید چرا یک سرویس عمومی است، نباید عمومی باقی بماند تا زمانی که نیاز آن بررسی شود.

مرحله سوم: اصلاح DNS

رکوردهای وبی که قابلیت Proxy دارند به‌درستی پشت Cloudflare قرار بگیرند.

رکوردهای قدیمی حذف شوند.

رکوردهای آزمایشی بررسی شوند.

IPv6 فراموش نشود.

مرحله چهارم: بررسی Mail Infrastructure

اگر Mail همان Origin IP را دارد، امکان جداسازی آن بررسی شود.

مرحله پنجم: تغییر Origin IP در صورت نیاز

اگر IP مدت زیادی عمومی بوده یا در معماری قبلی بدون Cloudflare استفاده شده است، IP جدید می‌تواند Exposure تاریخی را کاهش دهد.

اما تغییر IP بدون بستن Firewall کافی نیست.

مرحله ششم: تنظیم TLS

Certificate معتبر Origin نصب شود.

سپس Full (strict) فعال شود.

قبل از تغییر Production، صحت Hostname و Certificate بررسی شود.

مرحله هفتم: Firewall

Web Traffic فقط از مسیرهای مورد اعتماد اجازه داده شود.

IPv4 و IPv6 هر دو بررسی شوند.

دسترسی مدیریت جداگانه تعریف شود.

مرحله هشتم: Real Client IP

Web Server طوری تنظیم شود که IP واقعی Visitor را فقط از Trusted Proxy دریافت کند.

مرحله نهم: Application Test

موارد زیر بررسی شوند:

• Home Page
• Login
• API
• Upload
• Checkout
• Webhook
• Cron
• Admin Panel
• Static Assets
• WebSocket در صورت استفاده

مرحله دهم: Monitoring

پس از Hardening باید Logها بررسی شوند.

موارد غیرعادی:

Connection Attempts مستقیم

Repeated 403

Origin Errors

TLS Errors

502 / 521 / 522 / 525 / 526

Unexpected Host Headers

Unknown Management Login

Monitoring بخشی از کنترل امنیتی است، نه کاری که فقط پس از Incident انجام شود.

چگونه بفهمیم Origin دیگر مستقیماً قابل دسترسی نیست؟

آزمون باید از یک سیستم خارج از شبکه سرور انجام شود.

هدف آزمون این نیست که IP را روی اینترنت جستجو کنید، بلکه اگر IP Origin خودتان را می‌دانید بررسی کنید آیا Connection مستقیم از یک شبکه غیرمجاز پذیرفته می‌شود یا خیر.

نتیجه مورد انتظار در معماری Firewall Allowlist این است:

Domain through Cloudflare → Works

Direct Origin from normal Internet → Blocked

Management path → Works only from authorized source

اگر Direct Origin همچنان همان سایت Production را نمایش دهد، باید مشخص شود آیا این رفتار عمداً مورد نیاز است یا نتیجه تنظیم ناقص Firewall است.

Health Check و Monitoring را قبل از بستن Origin بررسی کنید

گاهی سرویس مانیتورینگ خارجی مستقیماً Origin IP را بررسی می‌کند.

اگر Firewall را فقط به Cloudflare محدود کنید، Monitoring ممکن است Fail شود.

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

• Monitor از طریق Domain و Cloudflare
• Allowlist کردن سرویس Monitoring در صورت ضرورت
• Health Check داخلی
• Private Monitoring
• Cloudflare Health Monitoring در معماری مناسب

نباید صرفاً به دلیل Monitoring کل Origin را برای اینترنت باز نگه داشت.

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

برخی مدیران تصور می‌کنند چون Stripe، GitHub، سیستم پیامک یا سرویس خارجی باید Webhook ارسال کند، Origin باید مستقیم باز باشد.

در بسیاری از موارد چنین نیست.

Webhook می‌تواند به Hostname Proxied ارسال شود:

Provider → Cloudflare → Origin

بنابراین سرویس External همچنان از Cloudflare عبور می‌کند.

البته Compatibility و نیاز هر Provider باید جداگانه بررسی شود.

APIها را نیز پشت Cloudflare نگه دارید

یکی از خطاهای رایج:

www.example.com → Proxied

api.example.com → DNS Only

اگر API روی همان Origin یا همان Backend قرار داشته باشد، این طراحی ممکن است IP را آشکار کند و Edge Security را دور بزند.

اگر دلیل فنی مشخصی برای DNS Only وجود ندارد، API نیز باید در طراحی Origin Security لحاظ شود.

Dev و Staging را از Production جدا کنید

محیط Staging نباید به نقطه ضعف Production تبدیل شود.

معماری بهتر:

Production → Protected Origin

Staging → Separate Private/Restricted Environment

Dev → Internal/VPN

اگر هر سه محیط روی یک Public IP باشند، نشت هرکدام می‌تواند ساختار Production را آشکار کند.

همچنین Staging معمولاً کنترل امنیتی ضعیف‌تری دارد:

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

Debug فعال

افزونه‌های آزمایشی

نسخه‌های قدیمی‌تر

صفحات تست

به همین دلیل جداسازی آن اهمیت زیادی دارد.

Debug Information می‌تواند معماری را افشا کند

در محیط Production نباید صفحات خطا اطلاعات غیرضروری زیر را نشان دهند:

Internal IP

Filesystem Path

Backend Hostname

Database Host

Reverse Proxy Structure

Software Debug Data

Stack Trace حساس

این اطلاعات لزوماً Origin IP عمومی را افشا نمی‌کنند، اما Reconnaissance را آسان‌تر می‌کنند.

اصل مناسب این است:

User-facing Error → Minimal

Server-side Log → Detailed

لاگ‌گیری برای تشخیص تلاش دور زدن Cloudflare

وقتی Firewall صحیح باشد، درخواست مستقیم معمولاً قبل از Application مسدود می‌شود.

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

موارد قابل بررسی:

• اتصال به پورت‌های غیرضروری
• Sourceهای تکرارشونده
• تلاش برای SSH
• درخواست با Hostname غیرمنتظره
• افزایش Connection روی Origin
• تغییر ناگهانی Traffic Pattern
• خطاهای TLS
• درخواست‌هایی که با معماری عادی سازگار نیستند

Security Monitoring باید الگوی عادی سیستم را بشناسد.

Fail2ban و ابزارهای مشابه پشت Cloudflare

اگر Fail2ban بر اساس IP موجود در Connection TCP تصمیم بگیرد، ممکن است IP Cloudflare را ببیند، نه Visitor واقعی.

اگر بدون تنظیم درست اقدام به Ban کند، خطر مسدودکردن Proxyهای Cloudflare وجود دارد.

بنابراین قبل از استفاده از ابزارهای IP-based باید Real Client IP به‌درستی Restore شود و Trust Boundary روشن باشد.

این موضوع برای موارد زیر نیز صدق می‌کند:

Application Rate Limiting

Nginx Limit Rules

Apache Security Rules

IDS/IPS

Custom Anti-Brute-Force Scripts

Security Plugins

آیا باید Cloudflare IPها را در WordPress Allowlist کنیم؟

در حالت ایده‌آل کنترل اصلی شبکه باید در لایه Firewall یا Reverse Proxy انجام شود، نه صرفاً داخل WordPress.

WordPress آخرین لایه Application است.

اگر Packet از ابتدا نباید وارد Origin شود، بهتر است در Firewall متوقف شود تا منابع PHP، Web Server و WordPress مصرف نشوند.

Application-level Allowlist می‌تواند لایه مکمل باشد، اما جای Network-level Rule را نمی‌گیرد.

نقش Rate Limiting روی Origin چیست؟

حتی در صورت استفاده از Cloudflare، Rate Limiting داخلی می‌تواند به‌عنوان Defense in Depth مفید باشد.

اما باید با معماری Proxy هماهنگ شود.

اگر همه درخواست‌ها از دید Origin یک IP Cloudflare باشند و Real IP درست بازیابی نشده باشد، Rate Limiting ممکن است اشتباه عمل کند.

بنابراین ترتیب منطقی:

Trusted Proxy Configuration

↓

Restore Real Client IP

↓

Application / Server Rate Limiting

Origin Server نباید به Hostname اشتباه پاسخ کامل بدهد

یکی از تست‌های دفاعی مفید این است که بررسی شود Web Server در برابر Host Header غیرمنتظره چه رفتاری دارد.

بهتر است Default Server محتوای Production را برای هر Host دلخواه سرو نکند.

این اصل در موارد زیر اهمیت بیشتری دارد:

Shared Hosting

Multiple Virtual Hosts

Reverse Proxy

Load Balancer

Multi-Tenant Infrastructure

هدف کاهش رفتارهای ناخواسته و جلوگیری از Routing اشتباه است.

اگر IP Origin قبلاً لو رفته باشد چه کنیم؟

این سناریو بسیار رایج است و به معنی شکست کامل پروژه نیست.

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

1. تمام DNS Exposureها را اصلاح کنید.
2. سرویس Mail را در صورت امکان جدا کنید.
3. Firewall Ruleها را آماده کنید.
4. Certificate و Cloudflare را بررسی کنید.
5. Origin IP را تغییر دهید.
6. DNS Cloudflare را به IP جدید متصل کنید.
7. دسترسی Web را فقط به منابع مورد اعتماد محدود کنید.
8. IP قبلی را از سرویس Production خارج کنید.
9. Logها را مانیتور کنید.

مهم این است که IP جدید نیز دوباره از همان مسیر قبلی افشا نشود.

آیا تغییر IP بدون Firewall فایده دارد؟

فایده دارد، اما کافی نیست.

اگر IP جدید دوباره برای تمام اینترنت روی 80 و 443 باز باشد، امنیت هنوز به مخفی‌ماندن IP وابسته است.

طراحی بهتر این است:

Rotate IP

*

Remove DNS Leaks

*

Restrict Firewall

*

Secure TLS

در این حالت تغییر IP بخشی از Remediation است، نه کل راهکار.

اشتباهات رایج هنگام مخفی کردن IP اصلی سرور پشت Cloudflare

فقط فعال‌کردن ابر نارنجی

این رایج‌ترین اشتباه است.

Proxy DNS قدم اول است، نه آخر.

باز گذاشتن Origin برای تمام اینترنت

اگر 80 و 443 از هر IP قابل دسترسی باشند، Direct Access همچنان ممکن است.

فراموش کردن IPv6

A Record امن شده ولی AAAA همچنان Origin را نمایش می‌دهد.

استفاده از IP مشترک Mail و Web

سرویس ایمیل ممکن است طراحی پنهان‌سازی Web Origin را تضعیف کند.

فراموش کردن Staging

دامنه اصلی Proxied است اما زیردامنه آزمایشی همان IP را آشکار می‌کند.

استفاده از Full به جای Full (strict) بدون دلیل

TLS وجود دارد، اما Validation قوی‌تر Certificate انجام نمی‌شود.

در صورت پشتیبانی Origin، Full (strict) معماری مناسب‌تری است.

Trust کردن X-Forwarded-For از همه

Header نباید بدون Trusted Proxy Boundary مبنای تصمیم امنیتی قرار گیرد.

بستن Firewall بدون Recovery

یک Rule اشتباه می‌تواند مدیر را نیز از Server خارج کند.

باز گذاشتن SSH

پنهان‌سازی وب به معنی محافظت خودکار از SSH نیست.

عمومی کردن Database

Database معمولاً نباید Public Internet Facing باشد.

تصور اینکه WAF همه‌چیز را حل می‌کند

WAF ترافیکی را می‌بیند که از WAF عبور کند.

Origin Security باید از Bypass جلوگیری کند.

عدم مانیتورینگ پس از تغییر

ممکن است سایت ظاهراً سالم باشد اما Webhook، API یا Cron دچار مشکل شده باشد.

پس از Hardening باید Behaviour سیستم بررسی شود.

چک‌لیست امنیت Origin Server پشت Cloudflare

DNS

• رکوردهای وب Proxied هستند.
• تمام A Recordها بررسی شده‌اند.
• تمام AAAA Recordها بررسی شده‌اند.
• CNAMEها بررسی شده‌اند.
• DNS-only Recordها دلیل مشخص دارند.
• Staging و Dev بررسی شده‌اند.
• Mail Infrastructure ارزیابی شده است.
• رکوردهای قدیمی حذف شده‌اند.

Network

• پورت‌های عمومی Inventory شده‌اند.
• 80 و 443 فقط طبق معماری مورد نیاز باز هستند.
• Cloudflare Prefixها در Firewall لحاظ شده‌اند.
• IPv6 Firewall فعال است.
• Database عمومی نیست.
• SSH محدود شده است.
• Control Panel محدود شده است.
• سرویس‌های بدون استفاده بسته‌اند.

TLS

• Certificate Origin معتبر است.
• Full (strict) در صورت امکان فعال است.
• Certificate Expiry مانیتور می‌شود.
• Hostname Certificate صحیح است.
• AOP در صورت نیاز بررسی شده است.

Application

• WordPress یا CMS به‌روز است.
• 2FA برای مدیران فعال است.
• Debug غیرفعال است.
• خطاها اطلاعات حساس نمایش نمی‌دهند.
• Rate Limiting درست کار می‌کند.
• Real Visitor IP به‌درستی تشخیص داده می‌شود.

Monitoring

• Origin Logs بررسی می‌شوند.
• Firewall Logs وجود دارند.
• Alert برای خطاهای مهم تنظیم شده است.
• Backup تست شده است.
• Recovery Access وجود دارد.
• تغییرات Configuration مستند هستند.

مدل Zero Trust برای Origin چه معنایی دارد؟

Zero Trust به زبان ساده می‌گوید صرف حضور یک Connection در شبکه نباید باعث اعتماد خودکار شود.

در مورد Origin Server این مفهوم می‌تواند به شکل زیر اجرا شود:

«هر درخواست مستقیم اینترنتی معتبر نیست؛ تنها مسیرها و Identityهای مشخص مجاز هستند.»

برای Web:

Trusted Path → Cloudflare

برای Admin:

Trusted Identity → Zero Trust / VPN

برای Database:

Trusted Application Network

برای Monitoring:

Trusted Monitoring Service

این معماری بسیار قوی‌تر از این فرض است که «چون کسی IP سرور را نمی‌داند، پس سرور امن است.»

امنیت Origin فقط درباره Cloudflare نیست

گاهی تمرکز بیش از حد روی Cloudflare باعث می‌شود لایه‌های دیگر نادیده گرفته شوند.

فرض کنید Origin کاملاً پنهان است اما:

WordPress Plugin آسیب‌پذیر است.

SSH Password ضعیف است.

Server Patch نشده است.

Backup وجود ندارد.

Database Credential لو رفته است.

Admin فاقد 2FA است.

در این شرایط Origin Protection تنها یکی از کنترل‌های امنیتی است.

امنیت واقعی از Defense in Depth ساخته می‌شود.

یعنی:

Edge Security

*

Network Security

*

Transport Security

*

Server Hardening

*

Application Security

*

Identity Security

*

Monitoring

*

Backup & Recovery

سؤالات متداول

آیا Cloudflare واقعاً IP سرور را مخفی می‌کند؟

بله، زمانی که رکوردهای سازگار در وضعیت Proxied باشند، کاربران معمولاً IPهای Cloudflare را در پاسخ DNS مشاهده می‌کنند و نه Origin IP. اما این موضوع مانع افشای IP از رکوردهای DNS دیگر، سرویس Mail، سابقه DNS یا سرویس‌های عمومی دیگر نمی‌شود.

آیا فعال کردن ابر نارنجی برای امنیت Origin کافی است؟

خیر. بهتر است دسترسی مستقیم به Origin نیز با Firewall، AOP یا معماری Tunnel محدود شود.

اگر IP سرور لو برود، Cloudflare بی‌فایده می‌شود؟

خیر. Cloudflare همچنان برای ترافیکی که از آن عبور می‌کند محافظت‌های خود را ارائه می‌دهد. مشکل این است که اگر Origin مستقیماً قابل دسترسی باشد، یک مسیر موازی خارج از Cloudflare ایجاد می‌شود.

بهترین روش برای جلوگیری از Direct Origin Access چیست؟

در معماری کلاسیک، محدودکردن Web Traffic در Firewall به شبکه Cloudflare یکی از مهم‌ترین کنترل‌هاست. در معماری Tunnel می‌توان Inbound Public Access را حتی بیشتر محدود کرد.

Cloudflare Tunnel بهتر است یا Firewall Allowlist؟

هر دو معماری معتبرند.

Firewall Allowlist برای Origin سنتی ساده و مؤثر است.

Tunnel برای حالتی مناسب است که می‌خواهید Application بدون Public Inbound Port از طریق یک اتصال Outbound به Cloudflare منتشر شود.

آیا با Cloudflare Tunnel هنوز Public IP نیاز داریم؟

خود سرویس منتشرشده از طریق Tunnel برای دریافت درخواست کاربران نیازمند Public Inbound IP نیست؛ cloudflared اتصال را از داخل شبکه به Cloudflare ایجاد می‌کند.

Authenticated Origin Pulls چه مزیتی دارد؟

AOP با استفاده از Client Certificate Authentication کمک می‌کند Origin تشخیص دهد درخواست HTTPS معتبر از Cloudflare آمده است. این قابلیت یک لایه اضافی در کنار Firewall و TLS ایجاد می‌کند.

آیا AOP همراه Tunnel لازم است؟

برای Hostnameهایی که از Cloudflare Tunnel استفاده می‌کنند AOP اعمال نمی‌شود، زیرا Tunnel مدل ارتباط متفاوتی دارد و Connector با Credentials خودش احراز می‌شود.

Full بهتر است یا Full (strict)؟

اگر Origin Certificate معتبر و سازگار دارید، Full (strict) گزینه امن‌تری است زیرا علاوه بر Encryption، Certificate Origin را نیز اعتبارسنجی می‌کند.

چرا IP واقعی کاربران در Log سرور Cloudflare دیده نمی‌شود؟

چون TCP Connection به Origin از Cloudflare می‌آید. برای HTTP می‌توان از CF-Connecting-IP و تنظیم Trusted Proxy در Web Server استفاده کرد تا IP واقعی Visitor بازیابی شود.

آیا باید پورت SSH را پشت Cloudflare ببریم؟

SSH باید جدا از وب مدیریت شود. برای دسترسی مدیریتی معمولاً VPN، Zero Trust، Tunnel یا Allowlist شبکه مدیریت گزینه‌های مناسب‌تری هستند.

اگر سایت از cPanel استفاده کند چه کنیم؟

وب‌سایت می‌تواند پشت Cloudflare باشد، اما پنل مدیریتی باید جداگانه محدود و با 2FA، رمز قوی و Access Control محافظت شود.

آیا مخفی کردن Origin IP جلوی هک شدن سایت را می‌گیرد؟

خیر. این کار یک لایه مهم Network Security است اما آسیب‌پذیری‌هایی مانند XSS، SQL Injection، Broken Access Control، Plugin Vulnerability یا Credential Theft را برطرف نمی‌کند.

آیا Cloudflare جای Firewall سرور را می‌گیرد؟

خیر. Cloudflare Edge Security و Origin Firewall وظایف متفاوتی دارند و بهتر است مکمل یکدیگر باشند.

جمع‌بندی

مخفی کردن IP اصلی سرور پشت Cloudflare تنها زمانی ارزش امنیتی واقعی پیدا می‌کند که همراه با محافظت از خود Origin Server انجام شود.

فعال‌کردن Proxy یا همان ابر نارنجی باعث می‌شود DNS عمومی به‌جای IP مبدأ، آدرس‌های شبکه Cloudflare را نمایش دهد؛ اما این کار به‌تنهایی تضمین نمی‌کند که Origin از مسیر دیگری قابل کشف یا دسترسی نباشد.

رکوردهای DNS Only، IPv6، زیردامنه‌های قدیمی، Staging Server، زیرساخت Mail، سرویس‌های مدیریتی و اطلاعات DNS تاریخی می‌توانند طراحی را تضعیف کنند.

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

در معماری کلاسیک، Firewall Origin می‌تواند Web Traffic را تنها از شبکه Cloudflare قبول کند. Full (strict) ارتباط Cloudflare تا Origin را با TLS و اعتبارسنجی Certificate تقویت می‌کند و Authenticated Origin Pulls امکان احراز بیشتر درخواست Cloudflare نزد Origin را فراهم می‌کند.

در معماری‌هایی که به جداسازی قوی‌تر نیاز دارند، Cloudflare Tunnel می‌تواند مدل متفاوتی ایجاد کند: به‌جای آنکه Cloudflare به یک Web Port عمومی روی Origin متصل شود، cloudflared از داخل زیرساخت یک Tunnel خروجی ایجاد می‌کند. در این حالت می‌توان Inbound Access عمومی را به‌شدت محدود کرد.

در نهایت هدف نباید فقط «پنهان کردن یک IP» باشد.

معماری درست باید طوری طراحی شود که حتی اگر فردی روزی IP سرور را متوجه شد، نتواند به‌سادگی با آن Cloudflare، WAF یا سایر کنترل‌های Edge را دور بزند.

امنیت Origin Server زمانی قابل اتکاست که DNS، Firewall، TLS، Authentication، Web Server، Application، Monitoring و مسیرهای مدیریتی همگی بخشی از یک مدل Defense in Depth باشند.