وقتی صدها سایت جعلی هتل را تجزیه و تحلیل کردیم، تصویری که به دست آمد بسیار واضح بود: بیش از هشتاد درصد این سایتها پشت شبکه تحویل محتوا (Content Delivery Network - CDN) شرکت Cloudflare میزبانی میشدند. این انتخاب تصادفی نیست؛ Cloudflare آدرس IP واقعی سرور را پنهان میکند و فرآیندهای حذف (takedown) را به طور قابل توجهی پیچیده میکند.
برای شروع اقدام علیه یک سایت جعلی، لازم است با شرکت میزبان (hosting) تماس بگیرید. برای دسترسی به شرکت میزبان، دانستن آدرس IP ضروری است. وقتی Cloudflare این IP را پنهان میکند، فرآیند متوقف به نظر میرسد. با این حال، آنچه دیده میشود و آنچه واقعیت دارد، همیشه یکی نیست.
در این مقاله، در مورد نحوه عملکرد Cloudflare، چرایی مطلق نبودن این حفاظت و روشهای فنی مورد استفاده برای دور زدن این محافظت و رسیدن به زیرساخت واقعی سایتهای جعلی بحث میکنیم.
چرا Cloudflare تا این حد مورد استفاده قرار میگیرد؟
سایتهای قانونی از Cloudflare برای محافظت در برابر حملات DDoS، بهینهسازی سرعت و امنیت استفاده میکنند. کلاهبرداران اما به دلیلی متفاوت آن را ترجیح میدهند: ناشناس ماندن.
وقتی سایتی پشت پروکسی Cloudflare قرار میگیرد، هر کوئری DNS خارجی فقط آدرسهای IP شرکت Cloudflare را نشان میدهد. IP واقعی سرور قابل مشاهده نیست. این امر هم درخواستهای حذف را پیچیده میکند و هم شناسایی شرکت میزبان را دشوارتر میسازد.
کارشناسان صنعت معتقدند کلاهبردارانی که به این صورت از Cloudflare استفاده میکنند، در واقع در حال سوءاستفاده از پلتفرم هستند. سیاستهای خود Cloudflare این نوع استفاده را ممنوع کرده است؛ با این حال، سیستم بدون شکایت به صورت خودکار مداخله نمیکند.
چرا "حریم خصوصی کامل" یک رویاست؟
محافظت Cloudflare در یک لایه خاص عمل میکند: ترافیک HTTP و HTTPS را ماسک (mask) میکند. با این حال، یک وبسرور فقط با ترافیک وب کار نمیکند. سرورهای ایمیل، رکوردهای قدیمی DNS، پیکربندیهای زیردامنه (subdomain) و رفتارهای سرور میتوانند خارج از این ماسک باقی بمانند.
در تحقیقات خود دیدهایم که در هفتاد و سه درصد سایتهای جعلی که از Cloudflare استفاده میکنند، رسیدن به آدرس IP واقعی با حداقل یک روش جایگزین امکانپذیر بوده است.
روش ۱: نشت زیردامنه (Subdomain Leakage)
این رایجترین و پربازدهترین آسیبپذیری است. حتی اگر دامنه اصلی پشت Cloudflare باشد، زیردامنهها میتوانند با پیکربندی متفاوت مستقیماً به IP سرور اشاره کنند.
دلیل فنی این امر چنین است: ترافیک SMTP (ایمیل) نمیتواند از طریق پروکسی Cloudflare هدایت شود. زیردامنههایی مانند "mail.fakehotel.com" یا "smtp.fakehotel.com" باید مستقیماً به سرور ایمیل متصل شوند. وقتی یک کوئری DNS برای این زیردامنه انجام میشود، آدرس IP واقعی مستقیماً قابل مشاهده است.
در موردی که در تحقیقات خود شناسایی کردیم، در حالی که دامنه اصلی کاملاً تحت حفاظت Cloudflare بود، زیردامنه ".info" مستقیماً به سروری در اروپای شرقی اشاره میکرد. هفده سایت مختلف رزرو جعلی روی همان سرور میزبانی میشدند.
ابزارهای مورد استفاده برای اسکن زیردامنه شامل Sublist3r، Amass و Subfinder هستند. این ابزارها نامهای زیردامنه رایج را برای یک دامنه امتحان میکنند و تعیین میکنند کدام یک به IP واقعی اشاره دارند.

کدام زیردامنهها باید بررسی شوند؟
- mail., smtp., imap., pop., mx., webmail. (زیرساخت ایمیل)
- ftp., sftp. (انتقال فایل)
- cpanel., whm., plesk., direct-admin. (پنلهای میزبانی)
- api., backend., admin., portal. (لایههای اپلیکیشن)
- dev., staging., test., beta. (محیطهای توسعه)
روش ۲: رکوردهای تاریخی DNS
اکثر سایتهای جعلی در ابتدا از Cloudflare استفاده نمیکنند. پس از راهاندازی سایت، برای مقابله با خطر شناسایی، به پشت CDN سوئیچ میکنند. رکوردهای DNS مربوط به دوره قبل از انتقال در سرویسهای مختلف آرشیو ذخیره میشوند.
پایگاههای داده غیرفعال DNS مانند SecurityTrails و ViewDNS.info آدرسهای IP و رکوردهای nameserver را که یک دامنه در گذشته استفاده کرده است، ذخیره میکنند. با نگاهی به این آرشیوها، IP واقعی سرور که قبل از سوئیچ به Cloudflare استفاده شده، قابل مشاهده است.
در تجربه یکی از مشتریان، تنها سه روز از اطلاعرسانی آنها به ما مبنی بر سوئیچ سایت جعلی به Cloudflare گذشته بود. کوئری که در SecurityTrails انجام دادیم، دو آدرس IP مختلف استفاده شده در دوره قبل از انتقال را نشان داد. یکی از این IPها هنوز فعالانه به چندین سایت جعلی خدمات میداد.
روش ۳: تحقیق در گزارشهای شفافیت گواهینامه (Certificate Transparency Log)
در گزارشهای CT، نه تنها نام دامنه، بلکه گهگاه جستجوهای مبتنی بر IP نیز قابل انجام است. برخی از سرورها برای آدرسهای IP مستقیم خود نیز گواهینامه SSL دریافت میکنند.
پس از شناسایی یک آدرس IP، میتوان رکوردهای گواهینامه آن IP را در crt.sh جستجو کرد. این جستجو میتواند سایر سایتهای جعلی موجود در همان زیرساخت را آشکار کند.
در یک مورد واقعی: پس از یافتن آدرس IP یک سایت جعلی هتل با استفاده از روش زیردامنه، ۲۷ دامنه جعلی دیگر را برای همان IP در جستجوی خود در گزارشهای CT شناسایی کردیم. همه آنها در محدوده یک عملیات بودند.
برای کسب اطلاعات جامعتر در مورد گزارشهای شفافیت گواهینامه، پیشنهاد میکنیم مقاله مانیتورینگ گزارشهای CT ما را بررسی کنید.
روش ۴: Shodan و کشف زیرساخت
Shodan یک موتور جستجو است که به طور مداوم دستگاهها و سرورهای متصل به اینترنت را اسکن میکند. وقتی یک آدرس IP در Shodan جستجو میشود، نسخههای نرمافزاری در حال اجرا روی آن سرور، پورتهای باز، هدرهای سرویس (HTTP response headers) و اطلاعات بنر قابل مشاهده است.
این اطلاعات میتواند برای چندین هدف مختلف استفاده شود:
- تعیین اینکه سرور متعلق به کدام شرکت میزبانی است (اطلاعات ASN).
- شناسایی سایر سایتهای میزبانی شده روی همان سرور.
- ثبت آسیبپذیریهای امنیتی شناخته شده در نرمافزار سرور (به عنوان مدرک پشتیبان در درخواستهای حذف).
در بخشی از سایتهای جعلی که ما تجزیه و تحلیل کردیم، اطلاعات به دست آمده از اسکنهای Shodan امکان شناسایی شرکت میزبانی ثبت شده سرور را فراهم کرد و فرصت شکایت مستقیم به آن شرکت را داد.
روش ۵: آسیبپذیریهای پیکربندی Apache و Nginx
برخی از وبسرورها به دلیل پیکربندی اشتباه، اطلاعات دقیق سرور را در نقاط پایانی (endpoints) مانند "/server-status" یا "/server-info" پخش میکنند. در سرورهایی که این بخش باز است، تمام نامهای میزبان مجازی (virtual host) که از آن سرور استفاده میکنند، قابل لیست شدن هستند.
وقتی این نوع آسیبپذیری شناسایی شود، محافظت Cloudflare غیرفعال میشود. زیرا با گزارش خود سرور، تمام روابط بین دامنهها و IPها آشکار میشود. ما دقیقاً با این آسیبپذیری در یکی از سایتهای جعلی که تحلیل کردیم برخورد کردیم؛ سرور میزبان ۳۱ دامنه جعلی مختلف بود و اطلاعات همه آنها را خودش ارائه میداد.
شناسایی این نوع آسیبپذیریها نیاز به بررسی دستی هر URL ندارد. ابزارهای خودکار میتوانند این نقاط پایانی را به سرعت اسکن کنند.
با IP شناسایی شده چه کاری انجام میشود؟
رسیدن به آدرس IP واقعی، فرآیند حذف (takedown) را ملموس میکند:
شکایت مستقیم به شرکت میزبانی: با یک کوئری ASN (با ابزارهایی مانند bgp.he.net یا ipinfo.io) میتوان تعیین کرد که IP متعلق به کدام شرکت میزبانی است. یک اخطاریه DMCA یا شکایت سوءاستفاده (abuse) میتواند به آدرس ایمیل سوءاستفاده شرکت میزبانی ارسال شود.
درخواست قوی به Cloudflare: ارائه اطلاعات واقعی سرور در شکایات ارسالی به Cloudflare، فرآیند ارزیابی درخواست را سرعت میبخشد. Cloudflare میتواند خدمات سایتهایی را که خطمشی سوءاستفاده آن را نقض میکنند، قطع کند.
مدرک فنی در درخواستهای قضایی: آدرس IP و اطلاعات میزبانی در روند رسیدگیهای کیفری وضعیت مدرک فنی را دارند و به سرعت گرفتن تحقیقات کمک میکنند.
روش ۶: تجزیه و تحلیل هدر پاسخ HTTP (HTTP Response Header Analysis)
هر وبسرور اطلاعات هدر مختلفی را در پاسخهای HTTP ارسال میکند. این هدرها ممکن است حاوی سرنخهایی در مورد نرمافزار سرور، محیط اجرا یا زیرساخت میزبانی باشند.
هدرهایی که باید به آنها توجه ویژه داشت:
- Server: میتواند نرمافزار سرور مانند Apache، Nginx، LiteSpeed را توضیح دهد؛ گاهی اوقات حاوی اطلاعات نسخه نیز هست.
- X-Powered-By: اطلاعات زمان اجرا مانند نسخه PHP، نسخه ASP.NET.
- CF-Cache-Status: وضعیت کش Cloudflare - تایید میکند که آیا سایت واقعاً پشت Cloudflare است یا خیر.
- Set-Cookie: برخی از پلتفرمهای میزبانی ردپای خود را در هدر کوکی باقی میگذارند (cPanel، Plesk و غیره).
برای بررسی این هدرها، میتوان از ابزارهای توسعهدهنده مرورگر (F12 ← تب Network) استفاده کرد. در عین حال، امکان مشاهده هدرها در فرمت خام با استفاده از دستور curl وجود دارد.
در تجربه یکی از مشتریان، هدر "X-Powered-By: PHP/7.4" و یک فرمت خاص کوکی نشست (session cookie)، شناسایی ارائه دهنده میزبانی را ممکن ساخت. این ترکیب اثر انگشت یک شرکت میزبانی خاص را داشت و گزارش سوءاستفاده مستقیماً به آن شرکت ارسال شد.
روش ۷: تجزیه و تحلیل رکورد MX ایمیل
سایتهای جعلی هتل گهگاه از آدرسهای ایمیل فعال برای ایجاد تصور واقعیت استفاده میکنند. صفحات تماس حاوی آدرسهای ایمیل مانند "[email protected]" ظاهری قانونی به سایت جعلی میدهند.
کوئری رکورد MX (مخفف Mail Exchange) برای این آدرس ایمیل میتواند آدرس IP سرور ایمیل را آشکار کند. کوئری MX که با MXToolbox یا دستور dig انجام میشود، نشان میدهد ترافیک ایمیل به کجا هدایت میشود. سرور ایمیل اغلب پشت پروکسی Cloudflare نیست و IP واقعی را فاش میکند.
در موردی که در تحقیقات خود شناسایی کردیم، رکورد MX به آدرس IP کاملاً متفاوتی از ترافیک وب اشاره داشت. این آدرس با زیرساخت میزبانی جعلی که قبلاً شناسایی کرده بودیم همپوشانی داشت؛ این امر به ما اجازه داد مستند کنیم که دو سایت جعلی مختلف هتل متعلق به یک اپراتور هستند.
جریان تحقیقاتی ترکیبی از تمام روشها
در عمل، به کار بردن این روشها در یک جریان به جای استفاده مستقل، کارآمدترین نتیجه را میدهد. ترتیب تحقیقات پیشنهادی:
۱. کوئری تاریخی DNS (SecurityTrails): آیا IP قبل از Cloudflare وجود دارد؟ ۲. اسکن زیردامنه: آیا زیردامنههایی مانند mail.، smtp.، ftp.، admin. مستقیماً به یک IP اشاره میکنند؟ ۳. کوئری رکورد MX: سرور ایمیل به کجا متصل است؟ ۴. تحقیق گزارش CT: آیا رکوردهای گواهینامه دیگری برای IP پیدا شده وجود دارد؟ آیا سایتهای دیگر همان اپراتور قابل شناسایی هستند؟ ۵. اسکن Shodan: اطلاعات نرمافزاری و زیرساختی در حال اجرا روی IP. ۶. تجزیه و تحلیل هدر HTTP: سرنخهای پلتفرم میزبانی.
وقتی این جریان را برای یک سایت جعلی واحد اعمال میکنیم، به طور متوسط ۴۵ تا ۹۰ دقیقه زمان صرف میکنیم؛ با این حال، نتایج عمدتاً اطلاعات جامعی در مورد کل عملیات جعلی میدهد، نه فقط آن سایت.

رویکرد Cloudflare نسبت به سوءاستفاده
یک سوال رایج: چرا Cloudflare به خدماترسانی به این سایتهای جعلی ادامه میدهد؟
Cloudflare شرکتی است که خدمات زیرساختی ارائه میدهد، نه محتوا، و طبق سیاستهای خود تصمیمگیری میکند. این شرکت خدمات سایتهایی را که ثابت شود حاوی فیشینگ، نقض برند و کلاهبرداری هستند، قطع میکند؛ با این حال، این تصمیم را طی فرآیندی مبتنی بر شکایت اتخاذ میکند.
در حین ارزیابی گزارشهای سوءاستفاده، Cloudflare به دنبال موارد زیر است:
- مدرک ملموس فیشینگ (فرم پرداخت، صفحه رزرو جعلی و غیره).
- سند نقض برند (ثبت علامت تجاری یا اثبات واضح مالکیت برند).
- اظهارات قربانیان (شکایات کاربران که قربانی شدن آنها را مستند میکند).
کارشناسان صنعت اظهار میدارند که در گزارشهایی با کیفیت مستندات بالا، تصمیم قطع خدمات Cloudflare ظرف ۳ تا ۷ روز صادر میشود. در گزارشهایی با مستندات ضعیف یا مبهم، فرآیند میتواند طولانیتر شود یا بدون نتیجه پایان یابد.
بنابراین، اضافه کردن شواهد فنی جمعآوری شده با روشهای تحقیق فوق به گزارش قبل از اطلاعرسانی به Cloudflare بسیار مهم است.
انتقال از فرآیند دستی به اتوماسیون
استفاده تک به تک از این روشها هم به دانش فنی نیاز دارد و هم زمانبر است. در برخی موارد در تحقیقات ما، ساعتها طول کشید تا به IP واقعی یک سایت جعلی برسیم.
با توجه به تعداد و پیچیدگی سایتهای جعلی هتل، تحقیق دستی در درازمدت پایدار نیست. کارشناسان صنعت معتقدند خودکارسازی چنین تحلیلهایی به یک ضرورت عملیاتی تبدیل شده است.
در تحقیقات ما مشاهده شد هتلهایی که به IP واقعی دسترسی پیدا کردند، سایتهای جعلی آنها به طور متوسط ظرف ۴ روز حذف شدند. در مواردی که IP واقعی شناسایی نشد، این دوره به ۳ تا ۶ هفته افزایش یافت؛ در این مدت، سایت جعلی به جمعآوری پول از مهمانان ادامه داد. شناسایی IP یک موضوع رفاهی نیست؛ بلکه تفاوتی در کارایی ایجاد میکند که مستقیماً با ضرر اقتصادی قابل اندازهگیری است.
علاوه بر تحقیق در تاریخچه DNS در مرحله شناسایی IP واقعی، مانیتورینگ گزارشهای CT نیز یک تکنیک مکمل قوی است. شما میتوانید در این راهنما بیاموزید چگونه تمام گواهینامههای SSL دریافت شده به نام هتل خود را از طریق گزارشهای شفافیت گواهینامه نظارت کنید. علاوه بر این، پلتفرمهای SecurityTrails و Shodan منابع رایگانی هستند که مکرراً در شناسایی IP مورد استفاده قرار میگیرند.
سوالات متداول
آیا شناسایی یک سایت پشت Cloudflare قانونی است؟ بله. کوئری غیرفعال DNS، تحقیق در گزارشهای CT و اسکن آرشیوها روشهای فنی کاملاً قانونی هستند. این روشها از دادههای در دسترس عموم بهره میبرند. اقداماتی با ماهیت دسترسی غیرمجاز یا حمله مستقیم به یک سیستم قانونی نیستند؛ با این حال، روشهای شرح داده شده در این راهنما در این دسته قرار نمیگیرند.
سریعترین روش برای دور زدن Cloudflare چیست؟ تحقیق تاریخچه DNS (مانند SecurityTrails) و کوئری گزارش CT (مانند crt.sh) در بیشتر موارد در عرض چند دقیقه نتیجه میدهند. زیردامنههای خاص سایت یا هدرهای ایمیل قدیمی نیز میتوانند شناسایی سریع IP را فراهم کنند. اگرچه رتبهبندی قطعی وجود ندارد، اما زمانی که این دو روش با هم استفاده شوند، نرخ موفقیت به طور قابل توجهی افزایش مییابد.
Shodan چه اطلاعاتی ارائه میدهد؟ Shodan با اسکن پورتهای باز، خدمات و اطلاعات بنر در حال اجرا روی یک آدرس IP خاص را لیست میکند. نشان میدهد که یک IP در چه کشوری است، از چه ارائه دهنده میزبانی استفاده میکند و چه سرویسهای وبی باز هستند. این اطلاعات به عنوان مدرک فنی ملموس در هنگام آمادهسازی گزارش سوءاستفاده (Abuse) برای ارائه دهنده میزبانی عمل میکند.
آیا میتوان فرآیند حذف را بدون IP واقعی شروع کرد؟ بله. حتی اگر IP واقعی مشخص نباشد، میتوان شکایت ICANN را به ثبتکننده دامنه و گزارش فیشینگ را به Cloudflare ارسال کرد. با این حال، دانستن IP واقعی مزیت قابل توجهی برای امکان درخواست مستقیم به ارائه دهنده میزبانی و گرفتن نتایج سریعتر فراهم میکند. حذف در سطح دامنه و خاموش کردن سرور پس از یافتن IP واقعی، دو استراتژی مکمل یکدیگر هستند.
از ابزار اسکن خودکار RuuSafe برای شناسایی زیرساخت واقعی پشت Cloudflare برای سایتهای جعلی متعلق به هتل خود استفاده کنید. اولین اسکن رایگان است و در عرض چند دقیقه نتیجه میدهد.


