Domain Hijacking چیست؟ چگونه از سرقت دامنه سایت جلوگیری کنیم؟

Domain Hijacking یا سرقت دامنه به وضعیتی گفته می‌شود که مهاجم بدون اجازه مالک واقعی، کنترل دامنه یک سایت را به دست می‌گیرد و می‌تواند تنظیمات DNS، اطلاعات مالکیت، Name Serverها یا حتی Registrar دامنه را تغییر دهد. در چنین شرایطی ممکن است وب‌سایت، ایمیل سازمانی و سرویس‌های متصل به دامنه همگی تحت کنترل مهاجم قرار بگیرند. مهم‌ترین راه‌های جلوگیری از Domain Hijacking شامل فعال‌سازی 2FA، استفاده از Registrar Lock یا Registry Lock، ایمن‌سازی ایمیل مالک دامنه، محافظت از EPP/Auth Code، محدودکردن دسترسی‌های مدیریتی و نظارت مداوم بر تغییرات DNS و اطلاعات دامنه است.

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

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

در این مقاله بررسی می‌کنیم Domain Hijacking چیست، سرقت دامنه چگونه اتفاق می‌افتد، چه تفاوتی با DNS Hijacking و سایر حملات مشابه دارد، چه نشانه‌هایی می‌تواند از تصاحب دامنه خبر دهد و مهم‌تر از همه چگونه می‌توان یک معماری دفاعی مناسب برای جلوگیری از سرقت دامنه ایجاد کرد.

Domain Hijacking چیست؟

Domain Hijacking به تصاحب غیرمجاز کنترل مدیریتی یک دامنه اینترنتی گفته می‌شود. در این حمله، شخصی غیر از مالک یا مدیر مجاز دامنه قادر می‌شود بخشی از تنظیمات حیاتی دامنه را تغییر دهد.

بسته به سطح دسترسی مهاجم، این تغییرات می‌تواند شامل موارد مختلفی باشد؛ برای مثال تغییر Name Server، تغییر اطلاعات حساب Registrar، دریافت Auth Code، انتقال دامنه به Registrar دیگر، تغییر DNS Recordها یا تغییر اطلاعات تماس و بازیابی حساب.

در بسیاری از حملات سایبری، مهاجم باید ابتدا وارد سرور شود یا یک آسیب‌پذیری نرم‌افزاری پیدا کند. اما در Domain Hijacking مسیر حمله متفاوت است. مهاجم ممکن است مستقیماً Registrar، حساب ایمیل مالک دامنه یا فرآیندهای پشتیبانی را هدف قرار دهد.

برای درک اهمیت موضوع، ساختار ساده یک دامنه را در نظر بگیرید.

وقتی کاربر آدرس سایتی مثل example.com را در مرورگر وارد می‌کند، مرورگر برای پیدا کردن سرور مقصد به DNS متکی است. اطلاعات DNS مشخص می‌کنند این دامنه باید به کدام IP، سرویس ایمیل یا سرویس‌های دیگر متصل شود.

اگر مهاجم بتواند تنظیمات دامنه را تغییر دهد، ممکن است رکوردهای DNS را به زیرساخت خودش هدایت کند. در نتیجه کاربر همچنان همان دامنه واقعی را در نوار مرورگر مشاهده می‌کند، اما محتوایی که دریافت می‌کند ممکن است از سرور مهاجم آمده باشد.

به همین دلیل Domain Hijacking صرفاً یک مشکل مربوط به «از دست دادن نام دامنه» نیست؛ بلکه می‌تواند به تهدیدی برای محرمانگی اطلاعات، اعتبار برند، ایمیل سازمانی، حساب‌های کاربران و حتی سایر سرویس‌های متصل به دامنه تبدیل شود.

چرا سرقت دامنه تا این اندازه خطرناک است؟

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

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

برای مثال فرض کنید یک فروشگاه اینترنتی دامنه‌ای شناخته‌شده دارد. اگر مهاجم Name Server دامنه را تغییر دهد، امکان دارد نسخه جعلی فروشگاه را روی سروری دیگر نمایش دهد. کاربران همچنان آدرس صحیح فروشگاه را وارد می‌کنند اما وارد زیرساختی می‌شوند که تحت کنترل مهاجم است.

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

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

• تغییر مسیر کاربران به سایت جعلی
• اختلال کامل در دسترسی به وب‌سایت
• تصاحب یا اختلال در سرویس ایمیل
• اجرای حملات Phishing با استفاده از دامنه معتبر
• آسیب به اعتبار برند و اعتماد کاربران
• ایجاد اختلال در APIها و سرویس‌های متصل
• تغییر DNS Recordهای سرویس‌های حساس
• دشوارشدن بازیابی سایر حساب‌های سازمانی
• ایجاد وقفه طولانی در فعالیت کسب‌وکار

در سازمان‌هایی که دامنه به ده‌ها سرویس داخلی و خارجی متصل است، اثر Domain Hijacking می‌تواند بسیار فراتر از یک وب‌سایت باشد.

Domain Hijacking چگونه اتفاق می‌افتد؟

یک تصور اشتباه این است که سرقت دامنه فقط زمانی اتفاق می‌افتد که Registrar هک شود. در عمل روش‌های مختلفی برای تصاحب دامنه وجود دارد و در بسیاری از موارد نقطه ضعف اصلی خود حساب مالک دامنه است.

سرقت رمز عبور حساب Registrar

ساده‌ترین سناریو، دسترسی مهاجم به نام کاربری و رمز عبور حساب مدیریت دامنه است.

این اطلاعات ممکن است از طریق Phishing، بدافزار، Credential Stuffing، نشت اطلاعات یا استفاده مجدد از رمز عبور به دست آمده باشند.

اگر مالک دامنه از همان رمز عبور در چند سرویس استفاده کند، افشای اطلاعات یک سرویس دیگر ممکن است زمینه ورود به Registrar را فراهم کند.

به همین دلیل رمز حساب Registrar باید منحصربه‌فرد باشد و نباید در سرویس دیگری استفاده شود.

حمله Phishing علیه مالک دامنه

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

مهاجم ممکن است ایمیلی شبیه پیام Registrar ارسال کند و ادعا کند دامنه در آستانه انقضا است، اطلاعات مالک باید تأیید شود یا حساب به دلیل فعالیت مشکوک محدود شده است.

لینک موجود در پیام کاربر را به صفحه‌ای جعلی هدایت می‌کند که ظاهری مشابه پنل واقعی Registrar دارد. اگر کاربر اطلاعات ورود خود را وارد کند، مهاجم می‌تواند آن‌ها را دریافت کند.

در حملات پیشرفته‌تر ممکن است مهاجم علاوه بر رمز عبور، تلاش کند Session یا کدهای تأیید را نیز تصاحب کند.

تصاحب ایمیل مالک دامنه

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

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

اگر مهاجم ابتدا ایمیل مدیر دامنه را تصاحب کند، احتمال دارد بتواند رمز Registrar را تغییر دهد یا درخواست‌های حساس را تأیید کند.

به همین دلیل امنیت دامنه بدون امنیت ایمیل مالک عملاً کامل نیست.

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

مهندسی اجتماعی علیه پشتیبانی Registrar

همه حملات فنی نیستند.

در Social Engineering یا مهندسی اجتماعی، مهاجم تلاش می‌کند کارکنان پشتیبانی را متقاعد کند که مالک واقعی دامنه است.

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

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

Registrarهایی که فرآیند تأیید هویت ضعیفی دارند در برابر این نوع حملات ریسک بیشتری ایجاد می‌کنند.

سرقت Session

حتی اگر رمز حساب Registrar قدرتمند باشد، سرقت Session می‌تواند خطرناک باشد.

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

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

کامپیوتری که برای مدیریت Registrar استفاده می‌شود نباید محیطی مملو از نرم‌افزارهای ناشناس، افزونه‌های غیرضروری یا ابزارهای کرک‌شده باشد.

سرقت یا افشای Auth Code

برای انتقال بسیاری از دامنه‌ها بین Registrarها از کدی که با نام‌هایی مثل Authorization Code، Auth Code یا EPP Code شناخته می‌شود استفاده می‌شود.

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

البته در بسیاری از انتقال‌ها فقط داشتن Auth Code کافی نیست و کنترل‌های دیگری نیز وجود دارد، اما افشای آن همچنان ریسک بزرگی محسوب می‌شود.

تغییر Name Server

در بسیاری از Domain Hijackingها مهاجم نیازی ندارد دامنه را فوراً به Registrar دیگری منتقل کند.

گاهی کافی است Name Serverهای دامنه تغییر کنند.

با تغییر Name Server، مهاجم ممکن است کنترل بخش بزرگی از DNS دامنه را در دست بگیرد و مسیر سرویس‌های مختلف را تغییر دهد.

این روش می‌تواند در مدت کوتاهی وب‌سایت، API، ایمیل یا Subdomainهای مختلف را تحت تأثیر قرار دهد.

سوءاستفاده از دسترسی کارکنان یا پیمانکاران

گاهی مشکل از هکر خارجی شروع نمی‌شود.

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

دامنه یک شرکت باید تحت کنترل حساب سازمانی و فرآیندهای مشخص مالکیت قرار داشته باشد.

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

اصل Least Privilege یا حداقل سطح دسترسی در اینجا نیز اهمیت دارد.

تفاوت Domain Hijacking و DNS Hijacking چیست؟

Domain Hijacking و DNS Hijacking گاهی به جای یکدیگر استفاده می‌شوند، اما دقیقاً یک مفهوم نیستند.

در Domain Hijacking مهاجم کنترل مدیریتی خود دامنه یا حساب مرتبط با آن را به دست می‌آورد.

در DNS Hijacking تمرکز اصلی روی دستکاری فرآیند Resolution یا تنظیمات DNS است.

برای مثال اگر مهاجم وارد پنل DNS شود و رکورد A سایت را تغییر دهد، با یک نوع DNS Hijacking مواجه هستیم. اما اگر ابتدا حساب Registrar را تصاحب کند، سپس Name Serverها را تغییر دهد و کنترل دامنه را در دست بگیرد، موضوع به Domain Hijacking نزدیک‌تر است.

ممکن است Domain Hijacking به DNS Hijacking منجر شود، اما هر حمله DNS لزوماً به معنی تصاحب مالکیت یا حساب دامنه نیست.

این تمایز در Incident Response اهمیت زیادی دارد؛ زیرا در هر سناریو نقطه بازیابی متفاوت است.

تفاوت Domain Hijacking با DNS Cache Poisoning

DNS Cache Poisoning حمله‌ای متفاوت است.

در Cache Poisoning هدف این است که اطلاعات نادرست وارد Cache یک DNS Resolver شود تا کاربران برای یک دامنه به IP اشتباه هدایت شوند.

در این سناریو ممکن است مالک دامنه همچنان کنترل کامل Registrar و DNS Zone خود را داشته باشد.

بنابراین اگر برخی کاربران به مقصد اشتباه هدایت می‌شوند ولی Name Server و رکوردهای اصلی تغییری نکرده‌اند، باید احتمال مشکلات مرتبط با Resolver یا Cache را نیز بررسی کرد.

در Domain Hijacking معمولاً تغییر در لایه مالکیت یا مدیریت دامنه اتفاق می‌افتد.

تفاوت Domain Hijacking و Subdomain Takeover

Subdomain Takeover نیز یکی دیگر از موضوعاتی است که گاهی با سرقت دامنه اشتباه گرفته می‌شود.

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

برای مثال ممکن است یک رکورد CNAME قدیمی همچنان به یک سرویس ابری حذف‌شده اشاره کند.

در این شرایط دامنه اصلی لزوماً تصاحب نشده است.

در مقابل Domain Hijacking می‌تواند کنترل سطح بالاتری از دامنه را در اختیار مهاجم قرار دهد.

آیا منقضی‌شدن دامنه Domain Hijacking محسوب می‌شود؟

منقضی‌شدن دامنه با Domain Hijacking یکسان نیست، اما نتیجه نهایی ممکن است برای مالک قبلی بسیار شبیه باشد.

اگر تمدید دامنه فراموش شود و پس از طی مراحل مربوط به Registrar و Registry دامنه دوباره برای ثبت آزاد شود، شخص دیگری ممکن است آن را ثبت کند.

در این حالت الزاماً هیچ حسابی هک نشده است.

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

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

چه بخش‌هایی از زیرساخت در Domain Hijacking اهمیت دارند؟

برای محافظت از دامنه باید بدانیم چه اجزایی در زنجیره مدیریت آن نقش دارند.

Registrar

Registrar شرکتی است که کاربر از طریق آن دامنه را ثبت و مدیریت می‌کند.

پنل Registrar معمولاً تنظیماتی مثل Name Server، قفل انتقال، اطلاعات تماس و برخی عملیات مربوط به انتقال دامنه را در اختیار مالک قرار می‌دهد.

حساب Registrar یکی از حساس‌ترین حساب‌های یک سازمان است.

Registry

Registry سازمانی است که پایگاه داده مربوط به یک TLD مشخص را مدیریت می‌کند.

برای مثال پسوندهای مختلف دامنه توسط Registryهای متفاوت مدیریت می‌شوند.

کاربر معمولاً مستقیماً با Registry تعامل روزمره ندارد و Registrar واسطه اصلی است.

DNS Provider

DNS Provider سامانه‌ای است که Zone و DNS Recordهای دامنه در آن مدیریت می‌شوند.

گاهی Registrar و DNS Provider یک شرکت هستند و گاهی دو سرویس مستقل‌اند.

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

حساب ایمیل مدیریتی

ایمیلی که برای Registrar، DNS Provider و سایر سرویس‌های زیرساختی استفاده می‌شود بخش مهمی از زنجیره امنیت است.

اگر این ایمیل تصاحب شود، مهاجم ممکن است بتواند فرآیند Password Reset را آغاز کند.

دستگاه مدیر

امنیت Endpoint نیز اهمیت دارد.

اگر سیستم مدیر به Infostealer، Remote Access Malware یا افزونه مخرب آلوده باشد، حتی فعال‌بودن بخشی از کنترل‌های امنیتی نیز ممکن است کافی نباشد.

Registrar Lock چیست؟

Registrar Lock قابلیتی است که برای جلوگیری از انتقال غیرمجاز دامنه استفاده می‌شود.

وقتی Domain Lock فعال است، انتقال دامنه به Registrar دیگر معمولاً تا زمانی که قفل برداشته نشود امکان‌پذیر نیست.

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

Registrar Lock یک لایه دفاعی مهم است اما نباید آن را تنها مکانیزم امنیت دامنه در نظر گرفت.

اگر مهاجم کنترل کامل حساب Registrar را به دست آورد، ممکن است در برخی سرویس‌ها بتواند ابتدا قفل را غیرفعال کند و سپس مراحل بعدی را انجام دهد.

بنابراین Lock باید همراه با 2FA، امنیت ایمیل، هشدار تغییرات و سایر کنترل‌ها استفاده شود.

Registry Lock چیست؟

Registry Lock معمولاً سطح قوی‌تری از حفاظت در برابر تغییرات حساس دامنه ارائه می‌دهد.

در این مدل، انجام تغییرات مشخص در سطح Registry نیازمند فرآیند تأیید اضافی است و صرفاً ورود به پنل Registrar برای انجام آن‌ها کافی نیست.

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

همه Registrarها یا همه پسوندها الزاماً چنین سرویسی را به شکل یکسان ارائه نمی‌کنند.

اگر دامنه بخش حیاتی کسب‌وکار است، هنگام انتخاب Registrar باید بررسی شود آیا Registry Lock یا مکانیزم امنیتی معادل آن ارائه می‌شود یا خیر.

نقش 2FA در جلوگیری از Domain Hijacking

فعال‌سازی Two-Factor Authentication یا 2FA یکی از مهم‌ترین اقدامات برای جلوگیری از تصاحب حساب Registrar است.

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

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

کد پیامکی نسبت به استفاده از Authentication App یا کلیدهای امنیتی سخت‌افزاری در برابر برخی حملات مقاومت کمتری دارد، زیرا حملاتی مانند SIM Swap می‌توانند شماره تلفن را هدف قرار دهند.

برای حساب‌های بسیار حساس، استفاده از روش‌های مقاوم‌تر در برابر Phishing اهمیت بیشتری دارد.

حساب Registrar یکی از بهترین مکان‌ها برای استفاده از Hardware Security Key یا روش‌های احراز هویت مبتنی بر استانداردهای مدرن و مقاوم در برابر Phishing است، مشروط بر اینکه سرویس مورد استفاده از آن پشتیبانی کند.

چرا SMS همیشه بهترین گزینه 2FA نیست؟

SMS بهتر از نداشتن احراز هویت دومرحله‌ای است، اما برای سرویس‌های بسیار حساس نباید همیشه اولین انتخاب باشد.

در SIM Swap مهاجم تلاش می‌کند شماره تلفن قربانی را به سیم‌کارتی تحت کنترل خودش منتقل کند.

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

همچنین برخی حملات Phishing می‌توانند کدهای یک‌بارمصرف را به صورت لحظه‌ای از قربانی دریافت و استفاده کنند.

در مقابل، کلیدهای امنیتی مبتنی بر استانداردهایی مانند FIDO2/WebAuthn می‌توانند مقاومت بیشتری در برابر سایت‌های جعلی ارائه دهند.

ایمیل مدیریت دامنه باید چگونه ایمن شود؟

ایمیل اصلی مدیریت دامنه باید مثل یک حساب عادی با آن برخورد نشود.

بهتر است این حساب برای ثبت‌نام در شبکه‌های اجتماعی، خبرنامه‌ها، سایت‌های متفرقه یا سرویس‌های غیرضروری استفاده نشود.

هرچه ایمیل مدیریتی در سرویس‌های بیشتری استفاده شود، سطح حمله افزایش پیدا می‌کند.

برای دامنه‌های مهم می‌توان یک حساب اختصاصی برای مدیریت Registrar ایجاد کرد که فقط افراد محدودی آن را بشناسند.

رمز این حساب باید منحصربه‌فرد، طولانی و ذخیره‌شده در Password Manager معتبر باشد.

2FA نیز باید برای آن فعال شود.

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

آیا استفاده از Password Manager برای دامنه مناسب است؟

بله. Password Manager یکی از بهترین ابزارها برای مدیریت رمزهای منحصربه‌فرد و طولانی است.

یکی از دلایل رایج تصاحب حساب‌ها Password Reuse یا استفاده مجدد از رمز عبور است.

فرض کنید مدیر سایت برای Registrar و یک فروشگاه اینترنتی ناشناس از یک رمز استفاده کرده باشد. اگر فروشگاه دچار Data Breach شود، مهاجم می‌تواند همان ترکیب ایمیل و رمز را روی Registrar امتحان کند.

این حمله Credential Stuffing نام دارد.

استفاده از Password Manager باعث می‌شود برای هر سرویس رمز کاملاً متفاوتی ایجاد شود.

در نتیجه افشای رمز یک سرویس تأثیر مستقیمی روی Registrar نخواهد داشت.

Auth Code را چگونه محافظت کنیم؟

Auth Code یا EPP Code باید اطلاعات محرمانه در نظر گرفته شود.

این کد نباید در سیستم‌های عمومی تیم، کانال‌های گروهی، پیام‌رسان‌های نامطمئن یا اسناد اشتراکی دائمی ذخیره شود.

اگر لازم است برای انتقال دامنه استفاده شود، فقط افراد مسئول باید به آن دسترسی داشته باشند.

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

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

اگر شخصی در پیام‌رسان درخواست EPP Code می‌کند، صرفاً شناختن نام او نباید برای تحویل کد کافی باشد.

امنیت DNS چه ارتباطی با سرقت دامنه دارد؟

حتی اگر Registrar ایمن باشد، تصاحب حساب DNS Provider می‌تواند پیامدی مشابه Domain Hijacking ایجاد کند.

مهاجم با تغییر رکوردهای DNS ممکن است وب‌سایت، ایمیل یا API را به مقصد دیگری هدایت کند.

بنابراین حساب DNS نیز باید مانند Registrar با بالاترین سطح حفاظت مدیریت شود.

موارد مهم شامل رمز منحصربه‌فرد، 2FA، مدیریت Roleها، محدودکردن API Tokenها، ثبت Audit Log و نظارت بر تغییر رکوردها است.

اگر ارائه‌دهنده DNS قابلیت Role-Based Access Control یا RBAC دارد، نیازی نیست تمام اعضای تیم دسترسی Administrator داشته باشند.

یک توسعه‌دهنده ممکن است فقط نیاز به تغییر چند رکورد مشخص داشته باشد و نباید لزوماً امکان حذف Zone یا تغییر تنظیمات امنیتی کل حساب را داشته باشد.

DNSSEC چگونه کمک می‌کند؟

DNSSEC یا Domain Name System Security Extensions برای افزایش اعتبارسنجی پاسخ‌های DNS طراحی شده است.

DNSSEC با امضای رمزنگاری‌شده داده‌های DNS به Resolverهای پشتیبان اجازه می‌دهد اعتبار پاسخ را بررسی کنند.

هدف اصلی آن مقابله با جعل برخی پاسخ‌های DNS است.

اما یک نکته بسیار مهم وجود دارد: DNSSEC جایگزین امنیت Registrar نیست.

اگر مهاجم کنترل کامل دامنه و تنظیمات Delegation را به دست آورد، مسئله فراتر از چیزی است که DNSSEC به تنهایی بتواند حل کند.

بنابراین DNSSEC باید یک لایه از معماری دفاعی باشد، نه راه‌حل کامل برای Domain Hijacking.

تفاوت TLS/HTTPS با امنیت دامنه

HTTPS نیز به تنهایی جلوی Domain Hijacking را نمی‌گیرد.

TLS ارتباط بین مرورگر و سرور را رمزنگاری و هویت دامنه را در چارچوب گواهی دیجیتال بررسی می‌کند.

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

بنابراین وجود علامت قفل در مرورگر به معنی ایمن‌بودن حساب Registrar نیست.

امنیت Domain، DNS، TLS، Server و Application پنج لایه مرتبط ولی متفاوت هستند.

حمله به حساب Registrar از طریق ایمیل بازیابی

یکی از اشتباهات رایج این است که مدیر یک رمز بسیار قدرتمند برای Registrar تنظیم می‌کند اما ایمیل Recovery او ضعیف است.

در این حالت مهاجم به جای شکستن رمز Registrar، ساده‌ترین مسیر را انتخاب می‌کند: حساب Recovery.

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

این اصل در امنیت با مفهوم Weakest Link یا ضعیف‌ترین حلقه شناخته می‌شود.

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

نقش شماره موبایل در امنیت دامنه

شماره تلفن نیز می‌تواند بخشی از فرآیند بازیابی حساب باشد.

اگر شماره موبایل یک مدیر به روش‌های مختلف قابل شناسایی باشد و Registrar از SMS برای بازیابی استفاده کند، مهاجم ممکن است مسیرهای حمله مبتنی بر Social Engineering یا SIM Swap را بررسی کند.

برای دارایی‌های حیاتی بهتر است فرآیند Recovery به شکلی طراحی شود که تنها یک شماره تلفن نقطه شکست کل سیستم نباشد.

چگونه یک Registrar امن انتخاب کنیم؟

قیمت دامنه نباید تنها معیار انتخاب Registrar باشد.

در دامنه‌های مهم، قابلیت‌های امنیتی ارائه‌دهنده اهمیت بیشتری از چند درصد تفاوت قیمت دارند.

Registrar مناسب باید امکاناتی برای حفاظت از حساب و تغییرات حساس ارائه دهد.

موارد مهمی که می‌توان بررسی کرد شامل پشتیبانی از 2FA قدرتمند، Security Key، قفل انتقال، هشدار تغییرات، Role Management، تاریخچه فعالیت، فرآیند بازیابی امن و در صورت نیاز Registry Lock است.

کیفیت تیم پشتیبانی نیز اهمیت زیادی دارد.

پشتیبانی نباید بتواند صرفاً با چند اطلاعات عمومی یک درخواست حساس را اجرا کند.

اصل Least Privilege برای مدیریت دامنه

Least Privilege به این معناست که هر کاربر فقط باید کمترین سطح دسترسی لازم برای انجام وظیفه خود را داشته باشد.

متأسفانه در بسیاری از شرکت‌ها اطلاعات ورود Registrar بین طراح سایت، برنامه‌نویس، مدیر مارکتینگ، مسئول هاست و مدیرعامل به اشتراک گذاشته می‌شود.

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

هرچه افراد بیشتری رمز اصلی را داشته باشند، احتمال نشت، Phishing، سوءاستفاده داخلی یا باقی‌ماندن دسترسی افراد سابق افزایش پیدا می‌کند.

اگر سرویس امکان ایجاد User یا Role مجزا دارد، باید از حساب‌های مستقل استفاده شود.

اشتراک یک Password بین چند نفر همچنین Audit کردن فعالیت‌ها را دشوار می‌کند؛ زیرا مشخص نیست چه کسی تغییر را انجام داده است.

چرا دامنه نباید در حساب شخصی کارمند ثبت شود؟

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

این کار ممکن است در ابتدای فعالیت سریع و ساده به نظر برسد اما در آینده ریسک حقوقی و امنیتی ایجاد می‌کند.

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

دامنه سازمانی باید در حسابی ثبت شود که مالکیت و کنترل آن متعلق به خود سازمان باشد.

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

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

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

اگر تغییر غیرمجاز به سرعت شناسایی شود، احتمال مهار حادثه بیشتر خواهد بود.

تیم فنی باید تغییرات مهمی مانند Name Server، DNS Recordهای حیاتی، وضعیت قفل دامنه، اطلاعات تماس و تاریخ انقضا را زیر نظر داشته باشد.

در صورت امکان باید برای تغییرات حساس Notification فعال شود.

برای دامنه‌های بسیار مهم حتی می‌توان وضعیت DNS و Resolution را از چند نقطه شبکه مانیتور کرد.

اگر IP سایت بدون Change Request مشخص تغییر کند، باید Alert ایجاد شود.

چه نشانه‌هایی می‌تواند از Domain Hijacking خبر دهد؟

یکی از مهم‌ترین مهارت‌ها تشخیص سریع نشانه‌های حادثه است.

علامت‌های احتمالی عبارت‌اند از:

• تغییر ناگهانی Name Server
• تغییر غیرمنتظره DNS Recordها
• عدم امکان ورود به Registrar
• دریافت ایمیل Password Reset بدون درخواست
• تغییر ایمیل یا شماره تلفن حساب
• غیرفعال‌شدن 2FA بدون اطلاع
• دریافت هشدار انتقال دامنه
• تغییر وضعیت Lock دامنه
• بازشدن سایتی متفاوت روی دامنه
• اختلال ناگهانی ایمیل سازمانی
• صدور گواهی غیرمنتظره برای دامنه
• مشاهده فعالیت ناشناس در Audit Log
• عدم دریافت ایمیل‌های مهم Registrar
• تغییر اطلاعات مالک یا Contact

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

اگر به Domain Hijacking مشکوک شدیم چه کنیم؟

در Incident Response سرعت و ترتیب اقدامات اهمیت زیادی دارد.

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

اگر هنوز به حساب Registrar دسترسی دارید، رمز را از یک دستگاه سالم تغییر دهید، Sessionهای فعال را ببندید و 2FA را بازبینی کنید.

سپس تنظیمات Name Server، DNS و Contact Information را بررسی کنید.

اگر دامنه به Registrar دیگری منتقل شده یا دسترسی کامل از بین رفته است، باید فوراً با تیم امنیت یا پشتیبانی Registrar تماس گرفته شود.

اطلاعاتی مثل سوابق پرداخت، ایمیل‌های ثبت دامنه، اطلاعات حساب، تاریخچه تغییرات و اسناد مرتبط با مالکیت می‌توانند در فرآیند بررسی مؤثر باشند.

در چنین شرایطی نباید فقط سایت بررسی شود.

ایمیل، DNS Provider، حساب‌های Cloud، Certificate Management و سرویس‌هایی که از دامنه برای Recovery استفاده می‌کنند نیز باید بررسی شوند.

چرا تغییر رمز به تنهایی کافی نیست؟

بعد از یک Incident بسیاری از مدیران فقط رمز Registrar را عوض می‌کنند.

این اقدام لازم است اما کافی نیست.

ممکن است مهاجم قبلاً ایمیل Recovery را تغییر داده باشد، یک Session فعال داشته باشد، API Token ساخته باشد یا اطلاعات DNS را دستکاری کرده باشد.

بنابراین Recovery باید جامع باشد.

تمام Sessionها، روش‌های ورود، تنظیمات Recovery، Roleها، Tokenها، Contactها و تغییرات اخیر باید بررسی شوند.

همین اصل برای ایمیل و DNS Provider نیز وجود دارد.

ارتباط Domain Hijacking با Phishing

سرقت دامنه می‌تواند بستر بسیار قدرتمندی برای Phishing ایجاد کند.

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

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

به همین دلیل حفاظت از دامنه فقط یک مسئله زیرساختی نیست؛ بلکه بخشی از امنیت کاربران است.

ارتباط Domain Hijacking با ایمیل سازمانی

رکوردهای MX مشخص می‌کنند ایمیل یک دامنه چگونه مسیریابی شود.

همچنین رکوردهای SPF، DKIM و DMARC در اعتبارسنجی و سیاست‌های ایمیل نقش دارند.

تغییر غیرمجاز این تنظیمات ممکن است امنیت ارتباطات سازمان را تحت تأثیر قرار دهد.

به همین دلیل بعد از هر حادثه دامنه، فقط رکورد A یا CNAME بررسی نشود.

تمام Zone باید با نسخه معتبر مقایسه شود.

داشتن Backup یا Infrastructure as Code برای DNS می‌تواند بازیابی را سریع‌تر و دقیق‌تر کند.

آیا WHOIS Privacy جلوی سرقت دامنه را می‌گیرد؟

خیر.

WHOIS Privacy یا سرویس‌های مشابه می‌توانند بخشی از اطلاعات تماس مالک را از نمایش عمومی محافظت کنند، اما راه‌حل مستقیم Domain Hijacking نیستند.

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

بنابراین باید بین Privacy و Security تفاوت قائل شد.

مخفی‌کردن بخشی از اطلاعات یک لایه مفید است، اما کنترل دسترسی، 2FA، Lock و Monitoring اهمیت بنیادی‌تری دارند.

بکاپ DNS چرا مهم است؟

بسیاری از مدیران از فایل‌های سایت و دیتابیس Backup می‌گیرند اما DNS را فراموش می‌کنند.

اگر مهاجم Zone را تغییر دهد یا رکوردها حذف شوند، بازسازی دستی تنظیمات ممکن است زمان‌بر باشد.

به‌خصوص در دامنه‌هایی که Subdomainها، سرویس ایمیل، CDN، API، Verification Record و سرویس‌های SaaS زیادی دارند.

داشتن نسخه مستند و به‌روز از DNS Zone باعث می‌شود در Incident بتوان سریع‌تر تغییرات غیرمجاز را تشخیص داد.

البته Backup باید امن نگهداری شود و اطلاعات حساس موجود در آن نباید در اختیار افراد غیرمجاز قرار گیرد.

ثبت تغییرات و Audit Log چه اهمیتی دارد؟

Audit Log مشخص می‌کند چه حسابی، چه زمانی و چه تغییری انجام داده است.

در حالت عادی شاید این اطلاعات اهمیت زیادی به نظر نرسند، اما در Incident Response بسیار ارزشمند هستند.

برای مثال اگر Name Server تغییر کرده باشد، دانستن زمان دقیق تغییر می‌تواند به تیم امنیت کمک کند فعالیت‌های دیگر همان بازه زمانی را بررسی کند.

اگر Registrar یا DNS Provider امکان Export یا نگهداری Log را فراهم می‌کند، برای دامنه‌های حساس باید از آن استفاده شود.

API Tokenها را فراموش نکنید

برخی سازمان‌ها DNS را از طریق API و ابزارهای Automation مدیریت می‌کنند.

در این ساختار ممکن است مهاجم نیازی به ورود به پنل نداشته باشد. سرقت API Token کافی است.

Tokenها باید حداقل Permission لازم را داشته باشند.

Tokenی که فقط برای تغییر یک رکورد مشخص ساخته شده نباید امکان حذف Zone یا مدیریت کل حساب را داشته باشد.

همچنین Tokenهای قدیمی و بدون استفاده باید حذف شوند.

ذخیره API Key در Repository عمومی، فایل تنظیمات ناامن یا Log می‌تواند ریسک جدی ایجاد کند.

استفاده از Change Management برای دامنه

در سازمان‌های حرفه‌ای بهتر است تغییرات DNS و دامنه بدون ثبت درخواست انجام نشوند.

Change Management باعث می‌شود هر تغییر دلیل، مسئول و زمان مشخصی داشته باشد.

در نتیجه اگر تغییری مشاهده شود که هیچ Change Request معتبری برای آن وجود ندارد، سریع‌تر می‌توان آن را مشکوک در نظر گرفت.

این فرآیند به‌خصوص برای شرکت‌هایی که چند مدیر سیستم دارند مفید است.

معماری دفاعی مناسب برای جلوگیری از Domain Hijacking

بهترین راه جلوگیری از سرقت دامنه اتکا به یک کنترل واحد نیست.

امنیت باید چندلایه باشد.

لایه اول امنیت حساب Registrar است: رمز منحصربه‌فرد، 2FA قدرتمند، محدودکردن Session و کنترل Recovery.

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

لایه سوم شامل Registrar Lock یا Registry Lock می‌شود.

لایه چهارم امنیت DNS Provider و APIها است.

لایه پنجم Monitoring و Alerting است.

لایه ششم نیز Incident Response و داشتن اطلاعات لازم برای اثبات مالکیت دامنه است.

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

این همان منطق Defense in Depth یا دفاع چندلایه است.

چک‌لیست جلوگیری از سرقت دامنه

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

1. رمز Registrar کاملاً منحصربه‌فرد و طولانی باشد.
2. رمز در Password Manager امن ذخیره شود.
3. 2FA برای Registrar فعال باشد.
4. در صورت پشتیبانی، از Security Key یا روش مقاوم در برابر Phishing استفاده شود.
5. Registrar Lock همیشه فعال باشد مگر هنگام انتقال برنامه‌ریزی‌شده.
6. برای دامنه‌های بسیار حساس، Registry Lock بررسی شود.
7. ایمیل مدیریتی دامنه فقط برای امور زیرساختی استفاده شود.
8. ایمیل مدیریت نیز 2FA قوی داشته باشد.
9. Recovery Methodها به صورت دوره‌ای بازبینی شوند.
10. Auth Code محرمانه نگهداری شود.
11. دسترسی اعضای تیم براساس Least Privilege باشد.
12. حساب‌های کارکنان سابق فوراً حذف شوند.
13. DNS Provider با همان سطح امنیت Registrar محافظت شود.
14. API Tokenها حداقل Permission را داشته باشند.
15. تغییرات Name Server و DNS مانیتور شوند.
16. هشدارهای امنیتی Registrar فعال باشند.
17. تاریخ انقضای دامنه به شکل مستقل مانیتور شود.
18. Auto-Renew در صورت مناسب‌بودن شرایط فعال باشد.
19. اطلاعات پرداخت دامنه معتبر و به‌روز باشند.
20. نسخه مستند DNS Zone نگهداری شود.
21. فرآیند Incident Response برای دامنه از قبل مشخص باشد.
22. اسناد و اطلاعات مورد نیاز برای اثبات مالکیت در محل امن نگهداری شوند.
23. دسترسی Registrar روی سیستم‌های آلوده یا عمومی انجام نشود.
24. افزونه‌های ناشناس مرورگر روی سیستم مدیریتی حذف شوند.
25. تغییرات حساس با تأیید چندمرحله‌ای سازمانی انجام شوند.

اشتباهات رایج در امنیت دامنه

استفاده از یک رمز برای Registrar و سرویس‌های دیگر

این یکی از خطرناک‌ترین اشتباهات است.

اگر رمز در سرویس دیگری افشا شود، مهاجم می‌تواند Credential Stuffing انجام دهد.

فعال‌نکردن 2FA

Registrar یک حساب عادی نیست.

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

فعال‌نکردن 2FA برای چنین حسابی ریسک غیرضروری ایجاد می‌کند.

استفاده از ایمیل عمومی برای Registrar

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

هرچه Exposure یک حساب بیشتر باشد، احتمال دریافت Phishing و حملات Credential بیشتر می‌شود.

ارسال Auth Code در گروه‌های کاری

فرستادن EPP Code در گروه پیام‌رسان یا نگهداری دائمی آن در فایل مشترک، سطح دسترسی به اطلاعات حساس را بی‌دلیل افزایش می‌دهد.

دادن دسترسی کامل به همه اعضای تیم

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

دسترسی باید براساس وظیفه تعریف شود.

اعتماد کامل به SMS

SMS یک لایه امنیتی مفید است اما برای دارایی‌های بسیار حساس بهتر است در صورت امکان روش‌های مقاوم‌تر استفاده شوند.

بی‌توجهی به DNS Provider

برخی مدیران Registrar را کاملاً امن می‌کنند اما حساب DNS با رمز ضعیف باقی می‌ماند.

مهاجم ممکن است از همان مسیر DNS را دستکاری کند.

نداشتن Monitoring

اگر کسی متوجه تغییر Name Server نشود، مهاجم ممکن است زمان بیشتری برای ادامه حمله داشته باشد.

نداشتن برنامه بازیابی

Incident Response نباید زمانی طراحی شود که دامنه از دست رفته است.

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

ثبت دامنه با حساب شخصی پیمانکار

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

این موضوع هم امنیتی است و هم می‌تواند در آینده مسئله حقوقی ایجاد کند.

یک سناریوی ساده از Domain Hijacking

فرض کنید یک شرکت دامنه اصلی خود را سال‌ها قبل ثبت کرده است.

حساب Registrar با ایمیل شخصی یکی از مدیران ایجاد شده و 2FA نیز فعال نیست.

مدیر برای چند سرویس مختلف از رمز مشابه استفاده کرده است.

یکی از آن سرویس‌ها دچار Data Breach می‌شود و اطلاعات حساب در اختیار مهاجمان قرار می‌گیرد.

مهاجم ایمیل و رمز را روی Registrar امتحان می‌کند و موفق به ورود می‌شود.

اگر هیچ هشدار یا قفل مؤثری وجود نداشته باشد، ممکن است Name Server تغییر داده شود.

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

تیم فنی ابتدا تصور می‌کند سرور هک شده است و چند ساعت مشغول بررسی فایل‌های وردپرس، Database و Logها می‌شود.

در حالی که سرور اصلی هیچ تغییری نکرده است.

این مثال نشان می‌دهد چرا هنگام Incident باید DNS و Domain Layer نیز بررسی شوند.

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

کاربران وردپرس معمولاً تمرکز زیادی روی Plugin، Theme، Login Page و WAF دارند.

این اقدامات ضروری هستند، اما امنیت وردپرس فقط یک لایه از امنیت سایت است.

ممکن است وردپرس کاملاً سالم باشد اما دامنه به سرور دیگری اشاره کند.

در چنین حالتی نصب Security Plugin روی وردپرس اصلی کمکی به جلوگیری از هدایت کاربران نخواهد کرد.

برای سایت وردپرسی باید حداقل چهار حوزه جداگانه در نظر گرفته شود:

امنیت حساب دامنه، امنیت DNS، امنیت هاست یا سرور و امنیت خود WordPress.

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

امنیت دامنه فروشگاه‌های ووکامرسی

برای WooCommerce اهمیت موضوع حتی بیشتر است.

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

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

حتی اگر Payment Gateway واقعی روی سرور اصلی همچنان سالم باشد، کاربران ممکن است در سایت جعلی اطلاعات حساس دیگری وارد کنند.

بنابراین فروشگاه‌های اینترنتی باید Domain Security را بخشی از برنامه امنیت تجارت الکترونیک خود بدانند.

نقش آموزش کارکنان در جلوگیری از Domain Hijacking

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

اگر مدیر سایت نتواند یک ایمیل Phishing را تشخیص دهد، مهاجم ممکن است از مسیر انسانی وارد شود.

افرادی که به Registrar، DNS یا ایمیل‌های مدیریتی دسترسی دارند باید آموزش ببینند.

آن‌ها باید بدانند درخواست فوری برای تمدید دامنه، هشدار جعلی Suspension، درخواست Auth Code یا لینک Login می‌تواند بخشی از حمله باشد.

بهتر است ورود به Registrar از Bookmark از قبل ذخیره‌شده انجام شود و کاربران برای ورود روی لینک موجود در ایمیل‌های مشکوک کلیک نکنند.

چگونه درخواست‌های حساس را تأیید کنیم؟

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

فرض کنید مدیر فنی در پیام‌رسان می‌نویسد: «EPP Code را برای من بفرست.»

اگر حساب پیام‌رسان او تصاحب شده باشد، درخواست ظاهراً معتبر خواهد بود.

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

برای مثال تماس مستقیم یا سیستم Change Management داخلی.

این روش مفهوم Out-of-Band Verification را پیاده‌سازی می‌کند.

آیا تغییر Registrar امنیت را افزایش می‌دهد؟

همیشه نه.

اگر Registrar فعلی قابلیت‌های امنیتی ضعیفی دارد، مهاجرت به سرویس حرفه‌ای‌تر می‌تواند مفید باشد.

اما تغییر Registrar به خودی خود مشکل رمزهای ضعیف، ایمیل ناامن یا مدیریت دسترسی نامناسب را حل نمی‌کند.

قبل از مهاجرت باید بررسی شود ارائه‌دهنده جدید چه قابلیت‌هایی برای 2FA، Lock، Role، Audit Log، Recovery و Support Verification دارد.

دامنه‌های اصلی و دامنه‌های جانبی را جدا مدیریت کنیم؟

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

دامنه اصلی شرکت، دامنه ایمیل و دامنه‌های سرویس‌های حیاتی باید بالاترین سطح حفاظت را داشته باشند.

دامنه‌های مربوط به Campaign یا Redirect ممکن است اهمیت کمتری داشته باشند، اما همچنان نباید بدون کنترل امنیتی رها شوند.

مدیریت Asset Inventory کمک می‌کند تیم بداند چه دامنه‌هایی در اختیار سازمان است، مالک هر کدام چه کسی است، چه زمانی منقضی می‌شوند و چه سرویس‌هایی به آن‌ها وابسته‌اند.

اهمیت Asset Inventory

یکی از مشکلات شرکت‌های بزرگ Shadow IT است.

ممکن است یک تیم سال‌ها قبل دامنه‌ای برای پروژه‌ای ثبت کرده باشد و بعداً کسی مسئولیت آن را به‌طور رسمی برعهده نداشته باشد.

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

Inventory باید شامل دامنه، Registrar، تاریخ انقضا، مالک سازمانی، DNS Provider، ایمیل مدیریتی و وضعیت کنترل‌های امنیتی باشد.

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

چرخه عمر امن دامنه

امنیت دامنه فقط هنگام ثبت آن مطرح نیست.

چرخه عمر دامنه از زمان خرید تا تمدید، انتقال یا کنارگذاشتن آن ادامه دارد.

هنگام ثبت باید مالکیت صحیح و کنترل‌های امنیتی ایجاد شوند.

در دوره استفاده باید Monitoring و Access Review انجام شود.

در زمان تغییر تیم، دسترسی افراد قبلی حذف شود.

هنگام انتقال، Auth Code و فرآیند تأیید با دقت مدیریت شوند.

اگر دامنه دیگر استفاده نمی‌شود نیز نباید بدون بررسی وابستگی‌های قبلی فوراً رها شود.

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

آیا Domain Hijacking همیشه قابل بازیابی است؟

نه لزوماً.

در بسیاری از موارد می‌توان با همکاری Registrar و ارائه مدارک مالکیت فرآیند بازیابی را آغاز کرد، اما نتیجه و زمان لازم به شرایط حادثه بستگی دارد.

نوع دامنه، Registrar، Registry، وضعیت انتقال و مدارک موجود همگی می‌توانند مؤثر باشند.

به همین دلیل پیشگیری بسیار بهتر از وابستگی کامل به Recovery بعد از حادثه است.

دامنه‌ای که بخش اصلی کسب‌وکار است باید مانند یک Asset حیاتی محافظت شود.

سؤالات متداول درباره Domain Hijacking

Domain Hijacking چیست؟

Domain Hijacking یا سرقت دامنه به تصاحب غیرمجاز کنترل یک دامنه گفته می‌شود. مهاجم ممکن است حساب Registrar، تنظیمات DNS، Name Server یا فرآیند انتقال دامنه را تحت کنترل بگیرد و از این دسترسی برای هدایت کاربران یا اختلال در سرویس‌ها استفاده کند.

آیا هک دامنه همان هک سایت است؟

خیر. ممکن است دامنه تصاحب شود در حالی که سرور و فایل‌های سایت کاملاً سالم هستند. برعکس، ممکن است وردپرس هک شود اما مالکیت و DNS دامنه هیچ تغییری نکرده باشد.

بهترین راه جلوگیری از سرقت دامنه چیست؟

یک راه واحد وجود ندارد. استفاده هم‌زمان از رمز منحصربه‌فرد، Password Manager، 2FA قوی، Registrar Lock، Registry Lock در صورت نیاز، امنیت ایمیل، Least Privilege و Monitoring بهترین رویکرد است.

آیا 2FA به تنهایی کافی است؟

خیر. 2FA یکی از مهم‌ترین کنترل‌ها است اما امنیت ایمیل، Session، Recovery Method، DNS Provider و فرآیند پشتیبانی نیز باید در نظر گرفته شوند.

Registrar Lock چه کاری انجام می‌دهد؟

Registrar Lock برای جلوگیری از انتقال غیرمجاز دامنه به Registrar دیگر استفاده می‌شود. بهتر است در حالت عادی فعال باشد و فقط هنگام انتقال برنامه‌ریزی‌شده غیرفعال شود.

Registry Lock چه تفاوتی با Registrar Lock دارد؟

Registry Lock معمولاً یک لایه حفاظتی قوی‌تر در سطح Registry ایجاد می‌کند و برای انجام تغییرات حساس فرآیندهای تأیید بیشتری در نظر می‌گیرد. جزئیات آن به Registrar، Registry و پسوند دامنه بستگی دارد.

آیا DNSSEC جلوی Domain Hijacking را می‌گیرد؟

DNSSEC برای اعتبارسنجی داده‌های DNS و مقابله با برخی انواع جعل پاسخ DNS طراحی شده است، اما جایگزین امنیت حساب Registrar نیست. DNSSEC باید بخشی از Defense in Depth باشد.

آیا WHOIS Privacy برای جلوگیری از هک دامنه کافی است؟

خیر. WHOIS Privacy ممکن است میزان اطلاعات عمومی مالک دامنه را کاهش دهد، اما از تصاحب حساب Registrar یا ایمیل جلوگیری نمی‌کند.

اگر دامنه هک شد ابتدا چه کاری انجام دهیم؟

اگر هنوز دسترسی دارید، از یک دستگاه امن رمزها را تغییر دهید، Sessionها و 2FA را بررسی کنید و تنظیمات DNS و Name Server را بازبینی کنید. اگر دسترسی از بین رفته است، سریعاً با Registrar تماس بگیرید و فرآیند بازیابی و اثبات مالکیت را آغاز کنید.

آیا دامنه منقضی‌شده همان Domain Hijacking است؟

خیر. انقضای دامنه معمولاً نتیجه عدم تمدید است، در حالی که Domain Hijacking شامل تصاحب غیرمجاز کنترل دامنه می‌شود. با این حال از دست رفتن دامنه منقضی‌شده می‌تواند پیامدهای بسیار مشابهی ایجاد کند.

آیا وردپرس می‌تواند از Domain Hijacking جلوگیری کند؟

خیر. WordPress در لایه Application قرار دارد و کنترل Registrar خارج از آن است. افزونه امنیتی وردپرس نمی‌تواند از تصاحب حساب Registrar جلوگیری کند.

آیا استفاده از CDN جلوی سرقت دامنه را می‌گیرد؟

CDN ممکن است امنیت و پایداری وب‌سایت را افزایش دهد، اما اگر مهاجم کنترل دامنه یا DNS را در دست بگیرد، CDN به تنهایی مانع Domain Hijacking نمی‌شود.

آیا باید رمز Registrar را به شرکت طراحی سایت بدهیم؟

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

هر چند وقت یک‌بار امنیت دامنه را بررسی کنیم؟

برای دامنه‌های حساس بهتر است Monitoring مداوم فعال باشد و Access Review، Recovery Method، وضعیت Lock، اطلاعات تماس و تاریخ انقضا نیز به صورت دوره‌ای بررسی شوند.

جمع‌بندی

Domain Hijacking یکی از مهم‌ترین تهدیدهای امنیتی زیرساخت وب است، زیرا مهاجم برای ایجاد خسارت الزاماً نیازی به نفوذ مستقیم به سرور یا WordPress ندارد. اگر کنترل دامنه یا DNS در اختیار فرد غیرمجاز قرار بگیرد، ممکن است کاربران به سایت جعلی هدایت شوند، ایمیل سازمانی دچار اختلال شود یا سرویس‌های مختلف متصل به دامنه از دسترس خارج شوند.

مهم‌ترین نکته این است که دامنه باید یک دارایی امنیتی حیاتی در نظر گرفته شود، نه صرفاً چیزی که سالی یک‌بار تمدید می‌شود.

استفاده از رمز منحصربه‌فرد و Password Manager، فعال‌سازی 2FA، حفاظت از ایمیل مدیریتی، فعال نگه‌داشتن Registrar Lock، استفاده از Registry Lock برای دامنه‌های حساس، محدودکردن دسترسی‌ها، حفاظت از Auth Code و API Tokenها و مانیتورینگ تغییرات DNS از مهم‌ترین اقدامات پیشگیرانه هستند.

همچنین سازمان باید از قبل برای Incident Response آماده باشد. اطلاعات مالکیت، سوابق پرداخت، تنظیمات DNS، روش تماس با Registrar و مسئولیت افراد باید مشخص باشند تا در صورت مشاهده نشانه‌های سرقت دامنه زمان از دست نرود.

در نهایت امنیت واقعی زمانی ایجاد می‌شود که Registrar، DNS، ایمیل، Endpoint، سرور و Application به‌عنوان بخش‌های یک زنجیره واحد دیده شوند. ضعف هر یک از این حلقه‌ها می‌تواند امنیت کل سرویس را تحت تأثیر قرار دهد.

Domain Hijacking نشان می‌دهد امنیت وب فقط به جلوگیری از XSS، SQL Injection، Brute Force یا نفوذ به وردپرس محدود نیست. گاهی مهم‌ترین دارایی سایت همان نام دامنه‌ای است که کاربران هر روز به آن اعتماد می‌کنند.