DNS Hijacking چیست؟ بررسی ربوده شدن DNS سایت و روش‌های جلوگیری

DNS Hijacking یا ربوده شدن DNS به شرایطی گفته می‌شود که مهاجم یا یک عامل غیرمجاز بتواند فرایند تبدیل نام دامنه به مقصد واقعی آن را دست‌کاری کند و کاربران را به سرور، وب‌سایت یا سرویس دیگری هدایت کند. این دست‌کاری ممکن است از طریق حساب رجیسترار، پنل DNS، Name Serverها، Recursive Resolver، روتر کاربر یا زیرساخت شبکه انجام شود.

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

دفاع مؤثر در برابر ربوده شدن DNS سایت فقط با یک تنظیم انجام نمی‌شود. استفاده از MFA، محافظت از حساب رجیسترار، Domain Lock، DNSSEC، کنترل دسترسی محدود، مانیتورینگ تغییرات DNS، محافظت از API Keyهای ارائه‌دهنده DNS و داشتن برنامه Incident Response از مهم‌ترین لایه‌های دفاعی هستند.

DNS چیست و چرا امنیت آن برای سایت حیاتی است؟

برای درک DNS Hijacking ابتدا باید نقش Domain Name System یا DNS را بشناسیم.

کاربران معمولاً برای ورود به یک سایت آدرس قابل فهمی مانند:

example.com

را وارد می‌کنند.

اما شبکه برای ارتباط با Serverها به اطلاعاتی مانند IP Address نیاز دارد. DNS وظیفه دارد نام دامنه را به اطلاعات مورد نیاز برای پیدا کردن سرویس تبدیل کند.

می‌توان DNS را تا حدی شبیه دفترچه آدرس اینترنت در نظر گرفت؛ با این تفاوت که DNS یک سامانه توزیع‌شده و چندلایه است و انواع مختلفی از Recordها را مدیریت می‌کند.

برای مثال:

• A برای نگاشت نام به IPv4
• AAAA برای IPv6
• CNAME برای Alias
• MX برای Mail Server
• TXT برای اطلاعات متنی و برخی مکانیزم‌های تأیید
• NS برای مشخص کردن Name Server
• CAA برای سیاست‌های مربوط به صدور Certificate
• رکوردهای مرتبط با DNSSEC

وقتی کاربر وارد یک سایت می‌شود، چند سیستم مختلف ممکن است در Resolution نام دامنه نقش داشته باشند.

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

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

DNS Hijacking چیست؟

DNS Hijacking به دست‌کاری غیرمجاز فرایند DNS گفته می‌شود؛ به شکلی که Query مربوط به یک Domain به مقصد مورد نظر مالک واقعی دامنه ختم نشود.

فرض کنید دامنه واقعی یک کسب‌وکار باید به این ساختار برسد:

کاربر → DNS → IP واقعی سایت → Server اصلی

در حالت DNS Hijacking ممکن است مسیر به شکل زیر تغییر کند:

کاربر → DNS دست‌کاری‌شده → IP مهاجم → Server جعلی

در این سناریو Browser کاربر همچنان ممکن است نام دامنه مورد انتظار را نشان دهد، زیرا مشکل در مرحله Resolution اتفاق افتاده است.

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

اگر مهاجم کنترل کافی روی Domain Validation، DNS Configuration یا سایر بخش‌های زیرساخت پیدا کرده باشد، ممکن است حمله بسیار پیچیده‌تر شود.

بنابراین DNS Hijacking یک مشکل زیرساختی است، نه صرفاً یک Redirect ساده داخل سایت.

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

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

Domain Hijacking معمولاً به ربوده شدن کنترل مالکیتی یا مدیریتی خود Domain Registration اشاره دارد.

برای مثال مهاجم وارد Account رجیسترار شده و کنترل دامنه را به دست می‌آورد یا Transfer غیرمجاز انجام می‌دهد.

اما در DNS Hijacking تمرکز روی دست‌کاری Resolution و DNS Configuration است.

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

اگر مهاجم Account رجیسترار را تصاحب کند، ممکن است Name Server دامنه را نیز تغییر دهد و در نتیجه DNS Hijacking انجام دهد.

بنابراین Domain Hijacking می‌تواند یکی از مسیرهای رسیدن به DNS Hijacking باشد.

تفاوت DNS Hijacking با DNS Spoofing چیست؟

DNS Spoofing معمولاً به ارائه پاسخ جعلی DNS گفته می‌شود.

مهاجم تلاش می‌کند Resolver یا Client یک DNS Response غیرواقعی را به عنوان پاسخ معتبر بپذیرد.

DNS Hijacking اصطلاح وسیع‌تری است و می‌تواند شامل تغییر واقعی DNS Records، Name Server، تنظیم Resolver یا سایر بخش‌های زنجیره باشد.

به بیان ساده:

DNS Spoofing بیشتر روی جعل پاسخ DNS تمرکز دارد.

DNS Hijacking بیشتر روی تغییر مسیر Resolution به مقصد غیرمجاز تمرکز می‌کند.

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

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

DNS Cache Poisoning نوع خاصی از حمله به DNS است که در آن Resolver اطلاعات نادرست را Cache می‌کند.

Resolver برای افزایش سرعت پاسخ، نتایج DNS را برای مدت مشخصی ذخیره می‌کند.

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

در مقابل، DNS Hijacking ممکن است اصلاً Cache را هدف قرار ندهد.

برای مثال مهاجم می‌تواند وارد Account ارائه‌دهنده DNS شود و A Record واقعی سایت را مستقیماً تغییر دهد.

در این حالت DNS Authoritative Source خودش Record مخرب را ارائه می‌کند.

تفاوت DNS Hijacking با Pharming

Pharming حمله‌ای است که کاربر را بدون نیاز به کلیک روی لینک Phishing به مقصد جعلی هدایت می‌کند.

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

برای مثال کاربر:

bank-example.com

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

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

تفاوت DNS Hijacking با BGP Hijacking

BGP Hijacking و DNS Hijacking هر دو می‌توانند باعث انحراف ترافیک شوند، اما در لایه‌های متفاوتی عمل می‌کنند.

DNS Hijacking روی Name Resolution تمرکز دارد.

BGP Hijacking روی Routing شبکه و مسیر رسیدن Packetها در اینترنت تمرکز می‌کند.

در DNS Hijacking ممکن است IP اشتباهی به Client داده شود.

در BGP Hijacking ممکن است IP درست باشد، اما مسیر شبکه به سمت زیرساختی غیرمنتظره منحرف شود.

تشخیص تفاوت این دو در Incident Response اهمیت زیادی دارد.

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

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

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

یعنی به جای حمله مستقیم به Cryptography یا Protocol، سراغ Account، Password، API Token، Session یا تنظیمات می‌رود.

چند نقطه مهم حمله عبارت‌اند از:

• حساب Registrar
• پنل DNS Provider
• Cloud Account
• Hosting Control Panel
• API Key مدیریت DNS
• Name Server
• Recursive Resolver
• Router
• Client Configuration
• حساب Email مرتبط با بازیابی Domain

هر کدام از این بخش‌ها Threat Model متفاوتی دارند.

ربوده شدن حساب Registrar

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

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

اگر مهاجم به این حساب دسترسی پیدا کند، بسته به امکانات Registrar ممکن است بتواند:

• Name Server را تغییر دهد.
• اطلاعات Domain را تغییر دهد.
• Transfer تنظیم کند.
• DNS Configuration را تغییر دهد.
• تنظیمات Security را غیرفعال کند.

به همین دلیل Password معمولی به تنهایی برای Accountهای حساس Registrar مناسب نیست.

MFA و ترجیحاً روش‌های مقاوم‌تر در برابر Phishing باید در صورت پشتیبانی فعال شوند.

سرقت Credential پنل DNS

در بسیاری از زیرساخت‌ها Registrar و DNS Provider یک شرکت نیستند.

برای مثال Domain ممکن است در یک Registrar ثبت شده باشد اما DNS توسط سرویس دیگری مدیریت شود.

در این حالت Compromise شدن Account سرویس DNS می‌تواند برای تغییر Recordها کافی باشد، حتی اگر Registrar کاملاً امن باقی مانده باشد.

مهاجم ممکن است A، AAAA، CNAME یا MX Record را تغییر دهد.

بنابراین Security Account ارائه‌دهنده DNS به اندازه Hosting Account اهمیت دارد.

تغییر غیرمجاز Name Server

یکی از سناریوهای خطرناک، تغییر NS Recordهای Domain است.

در حالت عادی Domain ممکن است از Name Serverهای مشخصی استفاده کند.

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

در نتیجه تعداد زیادی از Recordهای Domain ممکن است هم‌زمان تحت تأثیر قرار بگیرند.

این وضعیت بسیار خطرناک‌تر از تغییر یک A Record منفرد است.

سرقت API Key سرویس DNS

بسیاری از سرویس‌های Cloud و DNS امکان مدیریت Recordها از طریق API را فراهم می‌کنند.

این قابلیت برای Automation، CI/CD و Infrastructure as Code بسیار مفید است.

اما API Key یا Token مربوط به DNS یک Secret بسیار حساس محسوب می‌شود.

اگر Token سطح دسترسی گسترده داشته باشد، مهاجم ممکن است بدون ورود تعاملی به Dashboard بتواند DNS Recordها را تغییر دهد.

API Tokenهای DNS نباید:

• داخل Source Code باشند.
• وارد Git شوند.
• در Log نمایش داده شوند.
• بین چند پروژه به اشتراک گذاشته شوند.
• Permission بیش از نیاز داشته باشند.

بهتر است برای هر Automation، Token مستقل با Scope محدود ایجاد شود.

DNS Hijacking از طریق Hosting Panel

بعضی Hosting Providerها مدیریت DNS را داخل همان Control Panel هاست ارائه می‌کنند.

در چنین محیطی Compromise شدن Hosting Account می‌تواند علاوه بر فایل‌های سایت، DNS Zone را نیز تحت تأثیر قرار دهد.

یعنی یک Password ضعیف ممکن است هم‌زمان:

• File Manager
• Database
• Email
• DNS

را در اختیار مهاجم قرار دهد.

این مسئله اهمیت MFA و جداسازی دسترسی‌ها را نشان می‌دهد.

ربوده شدن DNS از طریق Email Account

Email معمولاً نقش مهمی در Recovery Accountها دارد.

اگر Email مرتبط با Registrar یا DNS Provider تصاحب شود، مهاجم ممکن است از Password Reset برای دسترسی به Account استفاده کند.

سناریوی خطرناک‌تر زمانی است که Email Recovery روی همان Domain قرار داشته باشد.

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

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

DNS Hijacking در سطح Router

همه DNS Hijackingها از سمت مالک سایت اتفاق نمی‌افتند.

ممکن است Domain کاملاً سالم باشد اما Router کاربر یا شبکه محلی DNS Server دیگری را به Client معرفی کند.

اگر Router با Password ضعیف، Firmware آسیب‌پذیر یا Configuration ناامن Compromise شود، تنظیم DNS آن نیز ممکن است تغییر کند.

در این سناریو فقط کاربران پشت همان Router یا Network تحت تأثیر قرار می‌گیرند.

این تفاوت مهمی با Hijacking Authoritative DNS دارد که می‌تواند کاربران گسترده‌تری را تحت تأثیر قرار دهد.

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

Malware یا Configuration غیرمجاز ممکن است DNS Setting خود Operating System را تغییر دهد.

در چنین حالتی کاربر Queryهای DNS را به Resolver تحت کنترل مهاجم ارسال می‌کند.

حتی اگر Authoritative DNS کاملاً سالم باشد، Client ممکن است پاسخ متفاوت دریافت کند.

به همین دلیل هنگام بررسی گزارش‌های DNS Hijacking باید ابتدا مشخص شود مشکل:

• Global است؟
• مربوط به ISP است؟
• مربوط به Network خاص است؟
• یا فقط روی یک Device اتفاق می‌افتد؟

DNS Resolver مخرب یا آلوده

Recursive Resolver واسطه‌ای است که Queryهای DNS کاربران را Resolution می‌کند.

اگر Resolver مخرب، Compromised یا Misconfigured باشد، می‌تواند پاسخ نامعتبر ارائه دهد.

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

DNS Hijacking چه نشانه‌هایی دارد؟

نشانه‌های DNS Hijacking بسته به نوع حمله متفاوت هستند.

گاهی تغییر بسیار واضح است و سایت کاملاً به صفحه‌ای دیگر هدایت می‌شود.

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

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

• IP دامنه بدون تغییر برنامه‌ریزی‌شده عوض شده است.
• Name Server تغییر کرده است.
• MX Record جدید مشاهده می‌شود.
• کاربران به صفحه Login متفاوتی هدایت می‌شوند.
• Certificate Warning ظاهر می‌شود.
• سایت برای بعضی کشورها یا Resolverها مقصد متفاوتی دارد.
• DNSSEC Validation Fail مشاهده می‌شود.
• Emailها به مقصد صحیح نمی‌رسند.
• TTL یا Recordهایی بدون اطلاع تیم تغییر کرده‌اند.
• Alert سرویس DNS درباره تغییر Zone ثبت شده است.
• Account Registrar Login ناشناخته دارد.
• API Token جدید ایجاد شده است.
• Domain Lock غیرفعال شده است.

هیچ‌کدام از این موارد به تنهایی DNS Hijacking را اثبات نمی‌کنند، اما نیازمند بررسی هستند.

خطر DNS Hijacking برای کاربران سایت چیست؟

DNS Hijacking فقط Availability سایت را تهدید نمی‌کند.

مهاجم ممکن است هدفی بسیار مهم‌تر از Down کردن سایت داشته باشد.

سرقت نام کاربری و رمز عبور

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

کاربر Domain درست را وارد می‌کند و انتظار دارد به سرویس اصلی متصل شود.

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

برای سرویس‌هایی که MFA ندارند، این موضوع می‌تواند به Account Takeover منجر شود.

سرقت اطلاعات مالی

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

مهاجم ممکن است تلاش کند:

• اطلاعات کارت
• اطلاعات حساب
• Credential
• Invoice
• آدرس Wallet
• اطلاعات شخصی

را هدف قرار دهد.

البته HTTPS و کنترل‌های پرداخت می‌توانند محدودیت ایجاد کنند، اما نباید فرض کرد صرفاً وجود HTTPS تمام خطر را حذف می‌کند.

نشت اطلاعات شخصی

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

در نتیجه DNS Incident می‌تواند به Data Breach نیز تبدیل شود.

اختلال کامل سرویس

گاهی هدف مهاجم سرقت داده نیست و صرفاً می‌خواهد سرویس را از دسترس خارج کند.

تغییر DNS به IP نامعتبر می‌تواند سایت، API یا سایر Serviceها را از دسترس خارج کند.

این نوع حمله می‌تواند برای کسب‌وکارهایی که به Availability وابسته‌اند خسارت جدی ایجاد کند.

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

DNS فقط برای Website نیست.

رکوردهای MX مسیر Email را مشخص می‌کنند.

تغییر غیرمجاز تنظیمات Email می‌تواند پیام‌های سازمانی را تحت تأثیر قرار دهد.

همچنین رکوردهایی مانند SPF، DKIM و DMARC بخشی از معماری امنیت Email هستند.

بنابراین Incident DNS باید Email Infrastructure را نیز پوشش دهد.

فقط بررسی A Record سایت کافی نیست.

آسیب به اعتبار برند

کاربر معمولاً تفاوت بین هک شدن Website و DNS Hijacking را نمی‌داند.

اگر Domain رسمی یک سازمان کاربران را به صفحه Phishing هدایت کند، اعتماد کاربران آسیب می‌بیند.

حتی اگر مشکل از Hosting Application نباشد، از نگاه کاربر «سایت هک شده است».

بنابراین Incident Communication بخش مهمی از Response است.

DNS Hijacking چه خطری برای وردپرس دارد؟

WordPress به خودی خود مانع DNS Hijacking نمی‌شود، زیرا مشکل ممکن است قبل از رسیدن Request به WordPress رخ دهد.

حتی اگر:

• WordPress Core به‌روز باشد.
• Pluginها امن باشند.
• WAF فعال باشد.
• Password مدیر قوی باشد.

باز هم DNS Provider می‌تواند نقطه جداگانه‌ای از خطر باشد.

اگر DNS Record دامنه به Server دیگری تغییر کند، Request ممکن است اصلاً به WordPress واقعی نرسد.

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

امنیت Application و امنیت Domain دو لایه متفاوت هستند.

برای یک سایت WordPress باید علاوه بر پنل مدیریت وردپرس، موارد زیر نیز محافظت شوند:

• Registrar
• DNS Provider
• CDN
• Hosting Account
• Email Recovery
• Cloud Account

ضعیف‌ترین Account این زنجیره ممکن است کل دامنه را در معرض خطر قرار دهد.

آیا HTTPS جلوی DNS Hijacking را می‌گیرد؟

HTTPS لایه بسیار مهمی از امنیت وب است، اما پاسخ ساده «بله» یا «خیر» برای این سؤال دقیق نیست.

اگر DNS کاربر به Server جعلی اشاره کند اما آن Server Certificate معتبر برای Domain نداشته باشد، Browser معمولاً Certificate Error نمایش می‌دهد.

این مسئله می‌تواند حمله را متوقف کند.

اما این به معنی بی‌اهمیت شدن DNS Security نیست.

کنترل DNS در بعضی معماری‌ها ممکن است روی فرایندهای Domain Validation نیز اثر بگذارد و مهاجم ممکن است در شرایط خاص تلاش کند Certificate معتبری دریافت کند.

همچنین کاربران ممکن است هشدارهای امنیتی را نادیده بگیرند.

بنابراین HTTPS یک لایه مهم است اما نباید تنها دفاع مقابل DNS Hijacking باشد.

CAA چه نقشی دارد؟

CAA Record به مالک Domain اجازه می‌دهد مشخص کند کدام Certificate Authorityها مجاز به صدور Certificate برای آن Domain هستند.

این کنترل می‌تواند سطح سیاست‌گذاری Certificate Issuance را بهتر کند.

اما CAA نیز جایگزین امنیت Registrar و DNS نیست.

اگر مهاجم کنترل گسترده DNS داشته باشد، Threat Model پیچیده‌تر می‌شود.

CAA باید بخشی از معماری دفاعی باشد، نه کل آن.

DNSSEC چیست؟

DNSSEC یا Domain Name System Security Extensions مجموعه‌ای از قابلیت‌های امنیتی برای اضافه کردن Cryptographic Authentication به DNS است.

هدف اصلی DNSSEC این است که Resolver بتواند بررسی کند داده DNS دریافت‌شده:

• از منبع معتبر آمده است.
• در مسیر دست‌کاری نشده است.

DNSSEC با Digital Signature روی DNS Data کار می‌کند.

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

• DNSKEY
• DS
• RRSIG

نقش مهمی در Chain of Trust دارند.

اگر Validation به‌درستی انجام شود، Resolver می‌تواند پاسخ جعلی یا تغییرکرده را تشخیص دهد.

DNSSEC چه مشکلی را حل می‌کند؟

DNSSEC به‌خصوص در برابر دسته‌ای از حملات جعل یا دست‌کاری DNS Response اهمیت دارد.

بدون Authentication رمزنگاری‌شده، DNS سنتی برای اثبات اصالت داده محدودیت‌هایی دارد.

DNSSEC باعث می‌شود Validator بتواند Signature را بررسی کند.

این مسئله امنیت و Integrity پاسخ DNS را افزایش می‌دهد.

DNSSEC چه مشکلاتی را حل نمی‌کند؟

این قسمت بسیار مهم است.

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

DNSSEC از موارد زیر به تنهایی جلوگیری نمی‌کند:

• سرقت Password رجیسترار
• Compromise شدن DNS Provider
• سرقت API Token
• Social Engineering
• Malware روی دستگاه Admin
• دسترسی غیرمجاز داخلی
• ضعف Recovery Process

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

DNSSEC نباید جایگزین Account Security، MFA، Least Privilege و Monitoring در نظر گرفته شود.

خطای DNSSEC هم می‌تواند سایت را از دسترس خارج کند

DNSSEC باید با دقت مدیریت شود.

اگر DS Record در Parent Zone با DNSKEY فعال Zone هماهنگ نباشد، Resolverهای Validating ممکن است پاسخ را معتبر تشخیص ندهند.

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

این اتفاق به معنی DNS Hijacking نیست؛ ممکن است صرفاً DNSSEC Misconfiguration باشد.

بنابراین هنگام Migration بین DNS Providerها باید Chain of Trust با دقت مدیریت شود.

فعال بودن DNSSEC بدون فرایند تغییر مناسب می‌تواند Availability را تحت تأثیر قرار دهد.

Domain Lock چیست؟

Registrar Lock یا وضعیت‌های مشابه برای جلوگیری از بعضی تغییرات یا Transferهای غیرمجاز Domain استفاده می‌شوند.

برای Domainهای مهم بهتر است Lock در شرایط عادی فعال باشد.

در برخی Registrarها سرویس‌های قوی‌تری مانند Registry Lock نیز ارائه می‌شوند که برای تغییرات حساس نیازمند مراحل تأیید بیشتری هستند.

هر سازمان باید امکانات Registrar خود را بررسی کند.

هدف این است که تغییرات بسیار حساس Domain نتوانند تنها با Compromise شدن یک Session معمولی انجام شوند.

تفاوت Registrar Lock و Registry Lock

Registrar Lock معمولاً در سطح Registrar اعمال می‌شود و می‌تواند بعضی عملیات مانند Transfer را محدود کند.

Registry Lock در سرویس‌هایی که آن را ارائه می‌کنند می‌تواند فرایند قوی‌تری برای محافظت از تغییرات حساس Domain فراهم کند.

برای Domainهای حیاتی تجاری، بررسی وجود چنین قابلیتی ارزشمند است.

بااین‌حال نام و جزئیات سرویس ممکن است بین TLDها و Providerها متفاوت باشد.

MFA برای Registrar و DNS ضروری است

Domain یکی از مهم‌ترین دارایی‌های دیجیتال سازمان است.

با این وجود گاهی Account Registrar با Passwordی محافظت می‌شود که ضعیف‌تر از Password پنل WordPress است.

این رویکرد منطقی نیست.

روی Registrar و DNS Provider باید در صورت امکان MFA فعال باشد.

برای Accountهای بسیار حساس، روش‌های مقاوم در برابر Phishing مانند Security Key یا Passkey در صورت پشتیبانی می‌توانند گزینه مناسب‌تری نسبت به OTPهای ساده باشند.

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

Password حساب DNS باید مستقل باشد

Password Registrar، Hosting، Email و WordPress نباید مشترک باشند.

Reuse شدن Password باعث ایجاد Domino Effect می‌شود.

اگر یک سرویس Breach شود و Password مشترک باشد، مهاجم ممکن است Accountهای دیگر را نیز امتحان کند.

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

Email بازیابی Domain را محافظت کنید

Recovery Email یکی از مهم‌ترین بخش‌های Account Security است.

برای آن:

• Password مستقل استفاده کنید.
• MFA فعال کنید.
• Recovery Methodها را بررسی کنید.
• Loginهای مشکوک را Monitor کنید.
• Accountهای بلااستفاده را حذف کنید.

برای Domainهای حساس بهتر است تیم بداند در صورت از دست رفتن دسترسی به Email چه فرایند Recovery رسمی با Registrar وجود دارد.

دسترسی DNS را بین افراد به اشتراک نگذارید

استفاده از یک Username و Password مشترک بین چند Administrator باعث کاهش Accountability می‌شود.

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

Permission باید براساس Least Privilege باشد.

برای مثال شخصی که فقط باید یک Subdomain خاص را مدیریت کند، نباید در صورت امکان اجازه:

• Transfer Domain
• تغییر Name Server
• حذف Zone
• مدیریت Billing
• تغییر Recovery Email

داشته باشد.

از Root API Token استفاده نکنید

Automation نباید با قوی‌ترین Token موجود اجرا شود مگر در شرایطی که واقعاً ضروری باشد.

Token مربوط به ایجاد یک TXT Record برای Certificate Automation نیازی به Permission تغییر تمام Zoneهای Account ندارد.

Scope محدود باعث کاهش Blast Radius می‌شود.

اگر Token لو برود، مهاجم تنها Permissionهای همان Token را خواهد داشت.

API Keyهای DNS را Rotate کنید

API Tokenهای بلندمدت باید Lifecycle مشخصی داشته باشند.

برای هر Secret بهتر است بدانید:

• چه سیستمی از آن استفاده می‌کند؟
• Owner آن چه کسی است؟
• Scope آن چیست؟
• چه زمانی ایجاد شده؟
• آخرین Rotation چه زمانی بوده؟
• چگونه Revoke می‌شود؟

Tokenی که هیچ‌کس نمی‌داند کجا استفاده می‌شود، در زمان Incident مشکل بزرگی ایجاد می‌کند.

تغییرات DNS باید Audit شوند

هر تغییر مهم DNS باید قابل Attribution باشد.

باید بتوان پاسخ داد:

چه کسی Record را تغییر داد؟

چه زمانی؟

از چه IP یا Session؟

Record قبلی چه بود؟

مقدار جدید چیست؟

از Dashboard انجام شد یا API؟

داشتن Audit Log خوب زمان Incident Response را بسیار کاهش می‌دهد.

Alert تغییرات DNS فعال کنید

اگر Provider امکان Notification دارد، برای تغییرات حساس Alert تنظیم کنید.

به‌خصوص:

• تغییر Name Server
• تغییر A/AAAA
• تغییر MX
• تغییر DNSSEC
• حذف Zone
• ایجاد API Token
• تغییر User
• غیرفعال کردن MFA

می‌توانند اهمیت بالایی داشته باشند.

در زیرساخت حرفه‌ای بهتر است Monitoring مستقلی نیز وجود داشته باشد که فقط به Alert خود Provider وابسته نباشد.

DNS Monitoring چیست؟

DNS Monitoring یعنی وضعیت Domain به شکل دوره‌ای از منابع مستقل بررسی شود.

موارد قابل پایش می‌توانند شامل:

• A Record
• AAAA
• NS
• MX
• CNAME
• TXTهای حساس
• DNSSEC
• DS
• DNSKEY

باشند.

اگر Record مهمی خارج از Change Window تغییر کند، تیم باید Alert دریافت کند.

مانیتورینگ از چند Region یا Resolver می‌تواند به تشخیص تفاوت‌های جغرافیایی کمک کند.

چرا مانیتورینگ از یک Resolver کافی نیست؟

DNS Cache و Propagation باعث می‌شوند Resolverهای مختلف در یک لحظه پاسخ یکسانی نداشته باشند.

اگر فقط یک Resolver بررسی شود ممکن است:

• تغییر جدید هنوز Cache نشده باشد.
• مشکل منطقه‌ای دیده نشود.
• Resolver خاص رفتار متفاوتی داشته باشد.

برای Domainهای حساس بهتر است داده از چند نقطه جمع‌آوری شود.

TTL چیست و چه نقشی در Incident دارد؟

TTL یا Time To Live مشخص می‌کند Resolver چه مدت می‌تواند DNS Record را Cache کند.

اگر TTL یک ساعت باشد، Resolver ممکن است پاسخ قبلی را تا یک ساعت نگه دارد.

بنابراین وقتی DNS Record اصلاح می‌شود، تمام کاربران الزاماً بلافاصله مقدار جدید را نمی‌بینند.

این موضوع در Incident Response اهمیت دارد.

ممکن است شما Record صحیح را Restore کرده باشید اما بعضی کاربران هنوز پاسخ قبلی را در Cache داشته باشند.

آیا TTL پایین‌تر امنیت را بیشتر می‌کند؟

نه به شکل مطلق.

TTL پایین باعث می‌شود تغییرات سریع‌تر در Resolverها Refresh شوند، اما Query Load را افزایش می‌دهد و Trade-offهای عملیاتی دارد.

TTL یک مکانیزم Access Control یا Authentication نیست.

بنابراین پایین آوردن TTL را نباید راهکار اصلی DNS Hijacking دانست.

قبل از Migration برنامه‌ریزی‌شده معمولاً TTL می‌تواند موقتاً کاهش یابد، اما سیاست دائمی باید براساس معماری سرویس انتخاب شود.

از DNS Provider معتبر استفاده کنید

انتخاب Provider فقط بر اساس قیمت مناسب نیست.

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

ویژگی‌های مفید عبارت‌اند از:

• MFA
• Security Key یا Passkey
• Role-based Access
• Audit Log
• API Token Scope
• DNSSEC
• Change Notification
• Account Activity
• Backup یا Zone Export
• Support Incident Response

هیچ Providerی امنیت مطلق ایجاد نمی‌کند، اما امکانات مناسب امکان پیاده‌سازی Defense in Depth را افزایش می‌دهند.

تغییر DNS باید Change Management داشته باشد

DNS تغییر کوچکی به نظر می‌رسد اما می‌تواند روی کل سرویس اثر بگذارد.

برای Domainهای سازمانی بهتر است تغییرات مهم DNS:

• Ticket داشته باشند.
• Owner مشخص داشته باشند.
• قبل و بعد از تغییر ثبت شوند.
• در صورت حساسیت Approval داشته باشند.
• Rollback Plan داشته باشند.

اگر نیمه‌شب NS Record تغییر کند، تیم باید بتواند تشخیص دهد این یک Deployment برنامه‌ریزی‌شده بوده یا Incident.

Backup از DNS Zone

داشتن نسخه شناخته‌شده از DNS Zone می‌تواند Recovery را سریع‌تر کند.

Backup باید شامل Recordهای مهم باشد.

اما Backup نیز باید محافظت شود، زیرا ممکن است ساختار Infrastructure را آشکار کند.

همچنین نباید فرض کرد Restore اتوماتیک یک Zone همیشه بدون بررسی مناسب است.

ابتدا باید مطمئن شد Account مهاجم دیگر دسترسی ندارد؛ در غیر این صورت ممکن است Recordهای اصلاح‌شده دوباره تغییر کنند.

چگونه DNS Hijacking را تشخیص دهیم؟

اگر به DNS Hijacking مشکوک هستید، ابتدا باید Scope مشخص شود.

سؤال‌های کلیدی:

آیا همه کاربران مشکل دارند؟

آیا فقط یک ISP مشکل دارد؟

آیا روی Mobile Data هم مشکل وجود دارد؟

آیا DNS Resolverهای مختلف پاسخ یکسان دارند؟

آیا NSها تغییر کرده‌اند؟

آیا Dashboard Registrar تغییر ثبت کرده است؟

آیا DNS Provider Audit Log مشکوک است؟

آیا DNSSEC Validation درست است؟

آیا فقط Website تحت تأثیر است یا Email هم مشکل دارد؟

این سؤال‌ها کمک می‌کنند Root Cause سریع‌تر محدود شود.

اولین اقدام در Incident DNS Hijacking چیست؟

اولین اولویت بازپس‌گیری Control Plane است.

اگر مهاجم هنوز به Registrar یا DNS Provider دسترسی دارد، تغییر Recordها به مقدار صحیح ممکن است موقتی باشد.

پس ابتدا باید Access Security بررسی شود.

به طور کلی:

• Sessionهای ناشناس Revoke شوند.
• Password تغییر کند.
• MFA بازبینی شود.
• API Tokenهای مشکوک Revoke شوند.
• Userهای ناشناس حذف شوند.
• Domain Lock فعال شود.
• Recovery Email بررسی شود.

بعد از تثبیت کنترل Account، DNS Configuration بازگردانده شود.

مرحله اول: وضعیت DNS فعلی را ثبت کنید

قبل از تغییر گسترده، وضعیت موجود را در صورت امکان مستند کنید.

ثبت:

• NS
• A/AAAA
• MX
• CNAME
• TXT
• DNSSEC
• Timestamp

می‌تواند در Forensics بعدی مفید باشد.

هدف این مرحله طولانی کردن Incident نیست؛ بلکه جلوگیری از نابودی کامل Evidence است.

مرحله دوم: Account Registrar را امن کنید

اگر احتمال Compromise وجود دارد:

Credential حساب تغییر کند.

Sessionهای فعال بررسی شوند.

MFA مجدداً تأیید شود.

Userها و Delegated Access بررسی شوند.

Recovery Methodها بررسی شوند.

API Access بررسی شود.

اگر Registrar سرویس Lock قوی‌تری ارائه می‌دهد، برای Domain حساس فعال شود.

مرحله سوم: DNS Provider را امن کنید

اگر DNS جداگانه مدیریت می‌شود، همان بررسی برای Provider انجام شود.

به‌خصوص:

• API Token
• User
• Role
• Audit Log
• Login History
• MFA
• Zone Change History

مهم هستند.

مرحله چهارم: Name Serverها را بررسی کنید

NSهای Domain باید با مقادیر مورد انتظار مقایسه شوند.

اگر Delegation تغییر کرده، بازگرداندن Zone داخلی کافی نیست.

باید Name Server نیز اصلاح شود.

در Domainهای دارای DNSSEC تغییر NS ممکن است نیازمند توجه ویژه به Chain of Trust باشد.

مرحله پنجم: DNS Recordها را Restore کنید

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

فقط A Record را بررسی نکنید.

موارد مهم عبارت‌اند از:

• A
• AAAA
• CNAME
• MX
• TXT
• CAA
• NS
• رکوردهای DNSSEC

در بعضی Incidentها مهاجم ممکن است Website را دست‌کاری نکرده باشد و فقط Email Route را تغییر داده باشد.

مرحله ششم: DNSSEC را بررسی کنید

اگر DNSSEC فعال بوده، وضعیت DS و DNSKEY باید بررسی شود.

Misconfiguration در این بخش می‌تواند پس از Recovery نیز باعث Resolution Failure شود.

اگر DNSSEC قبلاً فعال نبوده، فعال‌سازی آن می‌تواند بخشی از Hardening آینده باشد، اما نباید وسط Incident بدون برنامه و شناخت Provider عجولانه انجام شود.

مرحله هفتم: تمام Credentialهای مرتبط را Rotate کنید

اگر مشخص شد Account DNS یا Cloud Compromised شده است، احتمال Exposure Secretهای مرتبط باید بررسی شود.

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

• Password
• API Token
• Deployment Key
• Cloud Credential
• Webhook Secret

تغییر کنند.

Rotation باید براساس Dependency Mapping انجام شود تا Downtime ناخواسته ایجاد نشود.

مرحله هشتم: Certificateها را بررسی کنید

Certificate Transparency Monitoring می‌تواند برای بررسی Certificateهای صادرشده برای Domain مفید باشد.

اگر Certificate غیرمنتظره مشاهده شود، باید علت صدور آن بررسی شود.

همچنین CAA Policy و وضعیت Certificateهای فعلی بررسی شوند.

مرحله نهم: Email Infrastructure را بررسی کنید

در DNS Incident، Email را فراموش نکنید.

MX Record

SPF

DKIM

DMARC

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

اگر Mail Routing تحت تأثیر بوده است، ممکن است نیاز به Incident Response جداگانه برای Email وجود داشته باشد.

مرحله دهم: Cache و Propagation را در نظر بگیرید

حتی پس از Restore، کاربران ممکن است مدتی پاسخ قبلی را دریافت کنند.

TTLهای قبلی تعیین می‌کنند Cache تا چه زمانی باقی بماند.

مالک Domain معمولاً نمی‌تواند تمام Recursive Resolverهای اینترنت را مجبور کند Cache خود را همان لحظه پاک کنند.

بنابراین Recovery باید با Monitoring مداوم همراه باشد.

مرحله یازدهم: Logها را بررسی کنید

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

• Registrar Audit Log
• DNS Provider Log
• Cloud Audit Log
• WAF
• Web Server
• CDN
• Email
• Identity Provider
• API Activity

هدف فقط پیدا کردن IP مهاجم نیست.

باید Timeline ساخته شود:

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

اولین Record Change چه زمانی بود؟

کدام Credential استفاده شد؟

چه تغییراتی انجام شدند؟

آیا Persistence ایجاد شده؟

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

اگر احتمال ورود کاربران به صفحه جعلی یا سرقت Credential وجود داشته است، مسئله فقط فنی نیست.

ممکن است لازم باشد کاربران:

• Password خود را تغییر دهند.
• Sessionها را Revoke کنند.
• MFA را بررسی کنند.
• پیام‌های مشکوک را نادیده بگیرند.

نوع Communication به Scope Incident و قوانین مرتبط بستگی دارد.

Incident تمام شده است یا فقط DNS درست شده؟

بازگرداندن DNS به مقدار صحیح به معنی پایان Incident نیست.

Root Cause باید مشخص شود.

برای مثال:

• Password Reuse؟
• نبود MFA؟
• Phishing؟
• API Token افشاشده؟
• Account مشترک؟
• Recovery Email Compromised؟
• Social Engineering؟
• Insider Access؟

تا زمانی که علت اصلی اصلاح نشده باشد، امکان تکرار Incident وجود دارد.

DNS Hijacking و Zero Trust

Zero Trust فقط برای شبکه داخلی نیست.

اصل «اعتماد پیش‌فرض نداشته باش» در مدیریت DNS نیز کاربرد دارد.

هر Administrator باید Identity مستقل داشته باشد.

Permissionها محدود باشند.

تغییرات حساس Audit شوند.

Credentialهای دائمی کاهش پیدا کنند.

Accountهای بلااستفاده حذف شوند.

Automation با Token محدود اجرا شود.

هدف این است که Compromise یک Identity نتواند کل Domain Portfolio را در اختیار مهاجم قرار دهد.

DNS Hijacking در سازمان‌های دارای چند دامنه

هرچه تعداد Domainها بیشتر شود، Asset Management اهمیت بیشتری پیدا می‌کند.

سازمان ممکن است Domainهای قدیمی داشته باشد که:

• هنوز Resolve می‌شوند.
• به Account قدیمی متصل‌اند.
• MFA ندارند.
• Owner مشخص ندارند.
• Auto-renew آن‌ها خاموش است.
• DNS Provider متفاوت دارند.

همین Domainهای فراموش‌شده می‌توانند Attack Surface ایجاد کنند.

Domain Inventory باید شامل موارد زیر باشد:

• Registrar
• Expiration Date
• Owner
• DNS Provider
• DNSSEC Status
• MFA Status
• Lock Status
• Name Server
• Business Criticality

Expiration Domain با DNS Hijacking متفاوت است

منقضی شدن Domain دقیقاً DNS Hijacking نیست، اما پیامد آن می‌تواند بسیار خطرناک باشد.

اگر سازمان Domain مهمی را از دست بدهد و شخص دیگری آن را ثبت کند، Email، Linkهای قدیمی، Subdomainها و اعتماد کاربران ممکن است مورد سوءاستفاده قرار گیرند.

بنابراین Auto-renew و Monitoring تاریخ انقضا نیز بخشی از Domain Security است.

امنیت Registrar باید مثل Root Account باشد

برای بسیاری از کسب‌وکارها Domain نقطه اتصال کاربران به تمام سرویس‌ها است.

اگر Domain از کنترل خارج شود، مهاجم می‌تواند تعداد زیادی Service را تحت تأثیر قرار دهد.

به همین دلیل Account Registrar باید مانند یک Privileged Account مدیریت شود:

• Password منحصر‌به‌فرد
• MFA
• حداقل Administrator
• Monitoring
• Recovery امن
• Lock
• Documentation

این Account نباید با Credential ساده‌ای که بین اعضای تیم در پیام‌رسان ارسال شده مدیریت شود.

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

اشتباه اول: تصور اینکه Cloudflare یا CDN به تنهایی کافی است

CDN و DNS Providerهای حرفه‌ای قابلیت‌های امنیتی زیادی دارند، اما اگر Account Admin با Password ضعیف محافظت شود، بسیاری از این مزایا از بین می‌روند.

Security Feature باید همراه با Identity Security استفاده شود.

اشتباه دوم: فعال نکردن MFA

Domain Management یکی از بدترین مکان‌ها برای اتکا به Password تنها است.

اشتباه سوم: استفاده از Password مشترک

Credential مشترک Accountability را کاهش می‌دهد و Rotation را دشوار می‌کند.

اشتباه چهارم: ذخیره DNS API Key در Git

Token مدیریت DNS ممکن است امکان تغییر Recordهای حیاتی را فراهم کند.

Source Code محل مناسبی برای نگهداری آن نیست.

اشتباه پنجم: استفاده از Token با Permission کامل

Automation کوچک نباید Administrator کل Account باشد.

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

تیم فقط A Record را بررسی می‌کند اما مهاجم می‌تواند Delegation را تغییر دهد.

اشتباه هفتم: فراموش کردن MX Record

DNS Incident می‌تواند Email را نیز تحت تأثیر قرار دهد.

اشتباه هشتم: فعال کردن DNSSEC بدون برنامه Migration

DNSSEC بسیار مفید است، اما Misconfiguration می‌تواند Availability Domain را مختل کند.

اشتباه نهم: نداشتن Backup معتبر از Zone

در Incident ممکن است تیم نداند مقدار صحیح Recordها چه بوده است.

اشتباه دهم: اعتماد کامل به HTTPS

HTTPS و DNS Security مکمل یکدیگرند و یکی جایگزین دیگری نیست.

اشتباه یازدهم: استفاده از Recovery Email ضعیف

گاهی قوی‌ترین Registrar Account با یک Email ضعیف قابل Reset شدن است.

اشتباه دوازدهم: نداشتن Incident Runbook

هنگام DNS Hijacking زمان اهمیت زیادی دارد.

تیم نباید در زمان Incident برای اولین بار دنبال شماره Support Registrar بگردد.

چک‌لیست جلوگیری از DNS Hijacking

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

• Registrar معتبر استفاده شود.
• Password Registrar کاملاً منحصر‌به‌فرد باشد.
• MFA فعال باشد.
• در صورت امکان Security Key یا Passkey استفاده شود.
• Domain Lock فعال باشد.
• قابلیت Registry Lock برای Domainهای بسیار حساس بررسی شود.
• Recovery Email امن باشد.
• Accountهای قدیمی حذف شوند.
• دسترسی Administrator محدود باشد.
• DNS Provider از Registrar مستقل باشد، اگر معماری چنین نیازی دارد.
• MFA روی DNS Provider فعال باشد.
• API Tokenها Scope محدود داشته باشند.
• Secretها داخل Git قرار نگیرند.
• API Keyهای DNS Rotate شوند.
• Audit Logging فعال باشد.
• Alert تغییر DNS فعال باشد.
• NS Recordها Monitoring شوند.
• A و AAAA Monitoring شوند.
• MX Monitoring شود.
• DNSSEC در صورت پشتیبانی و مدیریت صحیح فعال شود.
• DS/DNSKEY هنگام Migration کنترل شوند.
• CAA Policy بررسی شود.
• DNS Zone Backup داشته باشد.
• Domain Expiration Monitoring فعال باشد.
• Auto-renew با روش پرداخت معتبر تنظیم شود.
• Contact Information به‌روز باشد.
• Change Management برای DNS تعریف شود.
• Incident Response Runbook آماده باشد.
• اطلاعات تماس اضطراری Registrar از قبل مشخص باشد.

چک‌لیست مخصوص سایت وردپرسی

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

• Domain Registrar
• DNS Provider
• CDN Account
• Hosting Panel
• WordPress Admin
• Email Admin

همگی Credential مستقل داشته باشند.

همچنین:

MFA روی سرویس‌های پشتیبان فعال شود.

API Keyهای Pluginها داخل Repository عمومی قرار نگیرند.

DNS Management به همه Administratorهای WordPress داده نشود.

Hosting Staff تنها دسترسی لازم را داشته باشند.

NS و A Record مانیتور شوند.

DNSSEC در صورت امکان بررسی شود.

Backup Zone نگهداری شود.

این نکته مهم است که دادن Administrator Role در WordPress لزوماً نباید به معنی دسترسی به Registrar باشد.

معماری پیشنهادی دفاع چندلایه DNS

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

لایه اول: Registrar Security

Password قوی، MFA، Domain Lock و Recovery امن.

لایه دوم: DNS Provider Security

MFA، RBAC، API Token محدود و Audit Log.

لایه سوم: DNSSEC

اعتبارسنجی رمزنگاری‌شده داده DNS در مسیرهایی که Validation انجام می‌شود.

لایه چهارم: Certificate Security

HTTPS، CAA و Monitoring Certificate.

لایه پنجم: Monitoring

بررسی NS، A، MX، DNSSEC و Change Alert.

لایه ششم: Secret Management

عدم Hardcode کردن API Key و Rotation.

لایه هفتم: Incident Response

فرایند از پیش آماده برای بازپس‌گیری کنترل Domain.

این همان Defense in Depth است.

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

برنامه Incident Response پیشنهادی برای DNS

تیم فنی بهتر است قبل از وقوع Incident یک Runbook آماده داشته باشد.

این Runbook می‌تواند شامل:

۱. Contact List

اطلاعات Registrar

DNS Provider

Hosting Provider

CDN

مدیر امنیت

مدیر فنی

Legal/Communication

۲. فهرست Domainهای حیاتی

دامنه اصلی

دامنه API

Domain Email

Domainهای Login

Domainهای Payment

۳. Baseline DNS

نسخه معتبر Recordها.

۴. Recovery Procedure

روش Lock کردن Domain.

روش Revoke کردن API Token.

روش Restore Zone.

روش تماس اضطراری.

۵. Communication Plan

چه کسی تصمیم می‌گیرد کاربران مطلع شوند؟

۶. Post-Incident Review

Root Cause

Timeline

Impact

Control Failure

Preventive Action

وجود این سند هنگام Incident می‌تواند زمان تصمیم‌گیری را به‌شدت کاهش دهد.

آیا می‌توان DNS Hijacking را صددرصد متوقف کرد؟

در امنیت معمولاً تضمین مطلق وجود ندارد.

هدف کاهش احتمال موفقیت حمله، محدود کردن Blast Radius و افزایش سرعت Detection و Recovery است.

ممکن است Provider دچار Breach شود.

ممکن است Administrator فریب Phishing را بخورد.

ممکن است Secret از Pipeline نشت کند.

اما اگر:

MFA،

Least Privilege،

Domain Lock،

DNSSEC،

Monitoring،

Audit

و Incident Response

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

این تفاوت معماری مقاوم با یک Account ساده دارای Password است.

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

DNS Hijacking چیست؟

DNS Hijacking یا ربوده شدن DNS به دست‌کاری غیرمجاز فرایند تبدیل نام دامنه به مقصد واقعی گفته می‌شود. مهاجم ممکن است DNS Record، Name Server، Resolver یا تنظیمات دستگاه را تغییر دهد و کاربران را به مقصد دیگری هدایت کند.

آیا DNS Hijacking همان Domain Hijacking است؟

خیر. Domain Hijacking بیشتر به تصاحب کنترل Registration دامنه اشاره دارد، درحالی‌که DNS Hijacking روی Resolution و تنظیمات DNS متمرکز است. البته تصاحب Registrar Account می‌تواند به DNS Hijacking منجر شود.

DNS Hijacking چه خطری دارد؟

می‌تواند باعث Phishing، سرقت Credential، هدایت ترافیک، اختلال سایت، آسیب به Email، نشت اطلاعات و خسارت اعتباری شود.

آیا DNSSEC از DNS Hijacking جلوگیری می‌کند؟

DNSSEC لایه مهمی برای تأیید اصالت و Integrity داده DNS فراهم می‌کند و در برابر بعضی حملات جعل پاسخ DNS مؤثر است. اما جایگزین امنیت Account Registrar، MFA، Domain Lock و محافظت از DNS Provider نیست.

آیا HTTPS برای مقابله با DNS Hijacking کافی است؟

خیر. HTTPS کنترل امنیتی مهمی است و می‌تواند بسیاری از حملات را دشوارتر کند، اما Domain و DNS نیز باید مستقلاً محافظت شوند.

چگونه بفهمیم DNS سایت تغییر کرده است؟

DNS Monitoring و بررسی Recordهای A، AAAA، NS، MX و DNSSEC از چند Resolver می‌تواند تغییرات غیرمنتظره را آشکار کند. Audit Log ارائه‌دهنده DNS نیز اهمیت زیادی دارد.

Registrar Lock چیست؟

قابلیتی برای محدود کردن بعضی تغییرات یا Transferهای Domain است. Domainهای مهم بهتر است در حالت عادی Lock باشند.

Registry Lock بهتر است یا Registrar Lock؟

این دو در یک سطح عمل نمی‌کنند. Registry Lock در سرویس‌هایی که ارائه می‌شود معمولاً کنترل قوی‌تری برای تغییرات حساس ایجاد می‌کند. برای Domainهای حیاتی می‌توان امکانات هر دو را بررسی کرد.

آیا DNS API Key یک Secret محسوب می‌شود؟

بله. API Token مدیریت DNS می‌تواند بسیار حساس باشد و باید داخل Secret Manager یا محل امن نگهداری شود، Permission محدود داشته باشد و در Source Code قرار نگیرد.

آیا سایت وردپرسی هم به DNSSEC نیاز دارد؟

DNSSEC به CMS وابسته نیست. WordPress یا هر Application دیگری می‌تواند پشت Domain دارای DNSSEC قرار گیرد. تصمیم به فعال‌سازی باید براساس پشتیبانی Registrar و DNS Provider و توان مدیریت صحیح آن گرفته شود.

آیا WAF جلوی DNS Hijacking را می‌گیرد؟

نه به طور کامل. اگر DNS کاربر به Server دیگری اشاره کند، ممکن است Request اصلاً به WAF اصلی نرسد. WAF و DNS Security دو لایه متفاوت هستند.

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

ابتدا کنترل Registrar و DNS Provider را امن کنید، Sessionها و Tokenهای مشکوک را Revoke کنید و سپس Name Server و DNS Recordها را به مقادیر معتبر برگردانید. پس از آن Audit، Rotation Credential و Investigation انجام شود.

چرا بعد از اصلاح DNS بعضی کاربران هنوز سایت اشتباه را می‌بینند؟

به دلیل DNS Cache و TTL ممکن است Resolverها برای مدتی پاسخ قبلی را نگه دارند. مدت آن به TTL و رفتار Resolver بستگی دارد.

آیا پایین آوردن TTL مانع DNS Hijacking می‌شود؟

خیر. TTL مکانیزم امنیتی برای Authentication یا Authorization نیست. فقط مدت Cache شدن Record را کنترل می‌کند.

آیا DNS Hijacking می‌تواند Email را هم تحت تأثیر قرار دهد؟

بله. تغییر MX و سایر رکوردهای مرتبط با Email می‌تواند Mail Flow و امنیت Email Domain را تحت تأثیر قرار دهد.

آیا استفاده از یک DNS Provider معروف کافی است؟

خیر. حتی بهترین Provider در صورت Compromise شدن Account Admin یا API Token نمی‌تواند تمام ریسک را حذف کند. Identity Security همچنان ضروری است.

جمع‌بندی

DNS Hijacking یکی از حملاتی است که نشان می‌دهد امنیت سایت فقط به امنیت کد، WordPress، Server یا WAF محدود نمی‌شود.

ممکن است Application کاملاً سالم باشد، اما اگر مهاجم بتواند کنترل DNS را به دست آورد، کاربران پیش از آنکه به Server واقعی برسند به مقصد دیگری هدایت شوند.

ربوده شدن DNS می‌تواند در نقاط مختلفی رخ دهد؛ از Account Registrar و DNS Provider گرفته تا API Token، Hosting Panel، Recursive Resolver، Router یا حتی Configuration دستگاه کاربر.

شدت Incident نیز به همان نقطه Compromise بستگی دارد.

تغییر Authoritative DNS یک Domain می‌تواند تعداد بسیار زیادی کاربر را تحت تأثیر قرار دهد، درحالی‌که DNS Hijacking روی یک Router خانگی ممکن است تنها دستگاه‌های همان شبکه را هدف قرار دهد.

برای Domainهای مهم، Account Registrar باید مانند یک حساب Privileged بسیار حساس محافظت شود.

Password مستقل، MFA، Domain Lock، Recovery امن، حداقل تعداد Administrator و Monitoring باید به استاندارد تبدیل شوند.

DNS Provider نیز باید دارای کنترل‌های مشابه باشد.

API Token مدیریت DNS یک Secret واقعی است و نباید در Git، Source Code، Log یا فایل‌های عمومی ذخیره شود.

Least Privilege و Rotation برای این Tokenها اهمیت زیادی دارند.

DNSSEC نیز لایه مهمی به امنیت DNS اضافه می‌کند و امکان اعتبارسنجی رمزنگاری‌شده داده DNS را فراهم می‌سازد؛ اما DNSSEC جای Account Security را نمی‌گیرد.

اگر مهاجم Account مدیریتی یا کلیدهای اصلی زیرساخت را تصاحب کند، Threat Model تغییر می‌کند.

به همین دلیل دفاع واقعی باید چندلایه باشد.

مانیتورینگ مداوم NS، A، MX و وضعیت DNSSEC یکی دیگر از کنترل‌های کلیدی است.

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

Detection سریع می‌تواند مدت Exposure را به‌شدت کاهش دهد.

همچنین باید از قبل برای Incident آماده بود.

اطلاعات تماس Registrar، نسخه معتبر DNS Zone، روش Revoke کردن API Tokenها، Recovery Procedure و مسئولیت اعضای تیم باید قبل از وقوع حمله مشخص شوند.

اگر DNS Hijacking اتفاق افتاد، فقط Record را اصلاح نکنید.

ابتدا Control Plane را امن کنید، Credentialها را Rotate کنید، Sessionها را Revoke کنید، Name Server و Zone را بررسی کنید، DNSSEC و Certificateها را Audit کنید، Email Infrastructure را کنترل کنید و سپس Timeline رخداد را بسازید.

در نهایت، امنیت DNS بر یک اصل ساده استوار است:

اگر کاربر نتواند با اطمینان به مقصد واقعی Domain برسد، امنیت Application به تنهایی کافی نیست.

DNS بخشی از مرز اعتماد سایت است و باید همان‌قدر جدی محافظت شود که Server، Database، Source Code و حساب‌های مدیریتی محافظت می‌شوند.