امنیت زیردامنه (Subdomain) هتل: تهدیدات پنهان و استراتژی‌های حفاظتی

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

پاسخ ساده بود: زیردامنه "mail.hotelname.com" مستقیماً به سرور ایمیل قدیمی که با Cloudflare پیکربندی نشده بود، اشاره می‌کرد. و آن آدرس IP عمومی بود.

زیردامنه پیشوندی است که به یک دامنه اصلی اضافه می‌شود. "www.hotelname.com" یک زیردامنه است؛ "reservation.hotelname.com" هم همینطور. هتل‌ها معمولاً در طول سال‌ها ده‌ها زیردامنه ایجاد می‌کنند: سایتی برای کمپین یک فصل، موتور رزرواسیون قدیمی، محیط تست، زیرساخت ایمیل سازمانی و موارد دیگر.

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

سرویس‌های Cloudflare و مشابه آن (CDN - شبکه تحویل محتوا) یک لایه حفاظتی در مقابل وب‌سایت‌ها اضافه می‌کنند. این کار IP واقعی سرور را پنهان می‌کند. با این حال، این محافظت فقط برای رکوردهایی اعمال می‌شود که از طریق Cloudflare پیکربندی شده‌اند.

زیردامنه ای مانند "mail.hotelname.com" برای ترافیک SMTP (ایمیل) باید مستقیماً به IP سرور اشاره کند. پروتکل ایمیل نمی‌تواند از طریق Cloudflare هدایت شود. این بدان معناست که اگر کسی با یک کوئری ساده DNS زیردامنه "mail" را جستجو کند، به راحتی می‌تواند IP واقعی را پیدا کند.

در تحقیقات خود، در بیش از هفتاد و پنج درصد هتل‌های ترکیه‌ای که بررسی کردیم، با چنین رکوردهای زیردامنه بازی برخورد کردیم. برخی از این‌ها آدرس‌های زیرساختی قدیمی بودند که سال‌ها استفاده نشده بودند، اما همچنان در دسترس بودند. برای اطلاعات بیشتر در مورد رابطه بین گواهینامه‌های SSL و زیردامنه‌ها، مقاله sahte-ssl-sertifika-tespiti-rehberi ما را بخوانید.

اصطلاح "Dangling DNS" به وضعیتی اشاره دارد که در آن یک رکورد DNS هنوز وجود دارد، اما سرور یا سرویسی که به آن اشاره می‌کند دیگر فعال نیست. این یک تهدید رایج اما اغلب نادیده گرفته شده در صنعت هتلداری است.

هتلی سال‌ها پیش با یک موتور رزرواسیون شخص ثالث قرارداد بست. یک زیردامنه "reservation.hotelname.com" ایجاد شد و به سرور آن شرکت اشاره کرد. در سال‌های بعد، موتور رزرواسیون تغییر کرد و زیردامنه جدیدی برای ارائه دهنده جدید باز شد؛ با این حال، رکورد قدیمی DNS در جای خود باقی ماند و توسط همه فراموش شد.

در این مرحله، سه سناریو می‌تواند ظاهر شود. در سناریوی اول، شرکت شخص ثالث بسته شده و آن آدرس IP به مشتری دیگری اختصاص یافته است. مالک IP جدید می‌تواند ترافیک ورودی به "reservation.hotelname.com" را به سرور خود هدایت کند. در سناریوی دوم، ارائه دهنده خدمات را قطع کرده اما ثبت دامنه همچنان به آن‌ها اشاره می‌کند. در سناریوی سوم، یک مهاجم می‌تواند آن آدرس IP را بخرد و یک سایت فیشینگ با استفاده از اعتبار هتل از طریق آن زیردامنه راه اندازی کند.

برخی هتل‌ها مطالب تبلیغاتی یا محتوای وبلاگ قدیمی خود را در سرویس‌های ذخیره‌سازی ابری مانند AWS S3، Azure Blob یا Google Cloud Storage میزبانی کرده‌اند. زیردامنه‌هایی مانند "cdn.hotelname.com" یا "media.hotelname.com" برای این سرویس‌ها پیکربندی شده بودند، اما وقتی قرارداد تمام شد، فضای ذخیره‌سازی (bucket) حذف شد.

اگر در زمان حذف فضا، رکورد DNS حذف نشده باشد، هر کسی که بتواند فضایی با همان نام فضای حذف شده ایجاد کند، می‌تواند آن زیردامنه را در اختیار بگیرد. این کار "subdomain takeover" نامیده می‌شود و وضعیتی است که گاه به گاه در سایت‌های هتل‌های ترکیه‌ای که در تحقیقات خود بررسی کردیم با آن مواجه می‌شویم.

زیردامنه‌های ایجاد شده در طول ادغام با خدمات SaaS مانند نرم‌افزار مدیریت رزرواسیون، مدیریت کانال (channel managers) یا برنامه‌های وفاداری مشتری، می‌توانند با پایان قرارداد خدمات، یتیم شوند. آدرس‌هایی مانند "loyalty.hotelname.com" یا "crm.hotelname.com" می‌توانند برای ماه‌ها یا حتی سال‌ها در رکوردهای DNS باقی بمانند.

زیردامنه‌هایی مانند "mail."، "smtp."، "imap." و "webmail." به زیرساخت ایمیل اشاره می‌کنند. این‌ها همیشه IP واقعی را در معرض دید قرار می‌دهند. کارشناسان صنعت به ویژه تأکید می‌کنند که رکوردهای DNS برای این زیردامنه‌ها باید با دقت مدیریت شوند.

زیردامنه‌هایی مانند "summer2022."، "campaign."، "rez." و "booking." ممکن است برای پروژه‌های قدیمی باز شده و فراموش شده باشند. این آدرس‌ها ممکن است در موتورهای جستجو ایندکس شده باشند و مستقیماً به سرور متصل بمانند.

زیردامنه‌هایی مانند "dev."، "test."، "staging." و "beta." از نظر امنیتی خطرناک‌ترین هستند. دلیل آن این است که این محیط‌ها معمولاً با پیکربندی‌های امنیتی ناقص کار می‌کنند و ممکن است به پایگاه‌های داده اصلی دسترسی داشته باشند.

زیردامنه‌هایی مانند "admin."، "panel."، "cpanel." و "wp-admin." می‌توانند مستقیماً به پنل‌های دسترسی اشاره کنند. در صورت پیکربندی اشتباه، این‌ها هم IP را فاش می‌کنند و هم به اهدافی برای حملات Brute Force تبدیل می‌شوند.

وقتی یک کلاهبردار یا مهاجم می‌خواهد آدرس IP واقعی یک هتل را بداند، این مراحل را دنبال می‌کند:

۱. DNS Enumeration: زیردامنه‌های رایج مانند "www"، "mail"، "ftp" و "admin" را با ابزارهای Brute-force DNS امتحان می‌کند. ۲. گزارش‌های شفافیت گواهینامه: با نگاه کردن به تمام گواهینامه‌های صادر شده برای آن دامنه از طریق crt.sh، زیردامنه‌های مورد استفاده را لیست می‌کند. ۳. آرشیو وب: رکوردهای قدیمی DNS را در Wayback Machine و آرشیوهای مشابه جستجو می‌کند. ۴. Reverse IP Query: تمام سایت‌های میزبانی شده روی آن IP قبل از Cloudflare را لیست می‌کند.

این چهار مرحله در عرض چند دقیقه انجام می‌شود و در بیشتر موارد، به IP واقعی می‌رسند. می‌توانید جزئیات بیشتری در مورد روش‌های مورد استفاده کلاهبرداران برای دور زدن لایه حفاظتی Cloudflare در مقاله otel-domain-guvenligi-typosquatting ما بیابید.

اولین و مهم‌ترین قدم این است که تمام رکوردهای DNS خود را جمع‌آوری کنید. می‌بینیم که بسیاری از هتل‌ها لیست زیردامنه‌های خود را نمی‌دانند. تمام رکوردهای A، CNAME و MX را از پنل مدیریت DNS خود خروجی بگیرید.

رکوردهای DNS زیردامنه‌هایی را که دیگر استفاده نمی‌شوند، مانند سایت‌های کمپین قدیمی، زیرساخت‌های قدیمی CRM یا ادغام‌های تجارت الکترونیک قدیمی، حذف کنید. این کار هم شکاف امنیتی را می‌بندد و هم مدیریت دامنه را ساده می‌کند.

زیردامنه‌هایی را که همچنان استفاده می‌کنید (به جز پنل مدیریت) تا حد امکان از طریق پروکسی Cloudflare هدایت کنید. این کار آدرس IP واقعی را پنهان نگه می‌دارد.

اجازه دسترسی به زیردامنه‌های مدیریتی مانند "admin." یا "cpanel." را فقط از آدرس‌های IP خاص بدهید. این کار از حملات Brute Force و تلاش‌های دسترسی غیرمجاز جلوگیری می‌کند.

حداقل ماهی یک بار، تمام زیردامنه‌های خود را با ابزارهای اسکن بررسی کنید. با این کار شانس شناسایی زودهنگام در هنگام ظهور یک آسیب‌پذیری جدید را خواهید داشت.

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

subdomain takeover چیست و چرا برای هتل من خطر ایجاد می‌کند؟ این زمانی است که یک مهاجم زیردامنه‌ای را که رکورد DNS برای آن وجود دارد اما دیگر فعال نیست، در اختیار می‌گیرد. مهاجم می‌تواند یک حساب پلتفرم برای سرویس حذف شده باز کند و رکورد DNS را به سرور خود هدایت کند. در این صورت، زیردامنه‌ای که اعتبار هتل را یدک می‌کشد می‌تواند به عنوان سایت فیشینگ استفاده شود.

چگونه بفهمم چند زیردامنه دارم؟ می‌توانید تمام رکوردها را از پنل مدیریت DNS خود (cPanel، Cloudflare، Route53) خروجی بگیرید. همچنین می‌توانید با جستجوی نام دامنه خود از طریق crt.sh، گواهینامه‌های متعلق به تمام زیردامنه‌های ثبت شده در گزارش‌های CT را ببینید. ترکیب این دو روش جامع‌ترین موجودی را ارائه می‌دهد.

آیا نمی‌توانم زیردامنه‌های ایمیل را پشت پروکسی Cloudflare قرار دهم؟ خیر، ترافیک ایمیل SMTP نمی‌تواند از طریق پروکسی Cloudflare هدایت شود. بنابراین، زیردامنه‌هایی مانند "mail." و "smtp." همیشه IP واقعی را فاش می‌کنند. به عنوان راه حل، توصیه می‌شود زیرساخت ایمیل را به یک IP جداگانه یا یک سرویس ایمیل مبتنی بر ابر منتقل کنید.

آیا حذف رکوردهای DNS برای زیردامنه‌های قدیمی مضر نیست؟ خیر، برعکس، مفید است. حذف رکوردهای DNS برای زیردامنه‌های بلااستفاده ریسک امنیتی را از بین می‌برد. اگر مطمئن نیستید که هنوز ترافیکی به آن آدرس می‌آید یا خیر، قبل از حذف رکورد DNS، نوع رکورد را تحلیل کنید؛ سپس می‌توانید آن را با خیال راحت حذف کنید.

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