مجله بلاگ
امنیت DNS سازمانی؛ راهنمای طراحی DNS امن و مقاوم
امنیت DNS سازمانی فقط به انتخاب یک سرور نام مطمئن محدود نمی‌شود. DNS نام سرویس‌ها را به مقصد قابل دسترسی تبدیل می‌کند و اختلال یا دست‌کاری آن می‌تواند ورود کاربران، ایمیل، نرم‌افزار مالی، تلفن سازمانی و سرویس‌های ابری را مختل کند. طراحی درست باید پاسخ‌های قابل اعتماد، دسترس‌پذیری و امکان پیگیری رخداد را کنار هم فراهم کند.
این راهنما برای مدیران فناوری اطلاعات و کارشناسان پشتیبانی شبکه نوشته شده است. ابتدا معماری DNS امن را مشخص می‌کنیم، سپس سراغ تنظیمات دامنه ویندوز، DNSSEC، DNS رمزنگاری‌شده، مانیتورینگ و آزمون بازیابی می‌رویم. هدف، ساختن یک برنامه اجرایی قابل تحویل است؛ برنامه‌ای که مالک هر تنظیم، نتیجه آزمون و مسیر بازگشت آن روشن باشد.
چرا DNS باید در برنامه امنیت شبکه جایگاه مستقل داشته باشد؟
وقتی یک سامانه با نشانی IP پاسخ می‌دهد ولی با نام باز نمی‌شود، بررسی DNS یکی از اولین گام‌های عیب‌یابی است. البته پاسخ‌ندادن به پینگ به‌تنهایی خرابی DNS را ثابت نمی‌کند؛ ممکن است ICMP مسدود باشد یا خود برنامه مشکل داشته باشد. تیم پشتیبانی باید ترجمه نام، اتصال شبکه و سلامت برنامه را جداگانه آزمایش کند.
ریسک‌ها نیز متفاوت‌اند: تغییر غیرمجاز رکورد، سوءاستفاده از resolver باز، نشت اطلاعات نام‌های داخلی و قطع دسترسی به سرور نام، هرکدام کنترل مخصوص خود را می‌خواهند. خرید یک محصول فیلترینگ تمام این مسئله‌ها را حل نمی‌کند. در طرح امنیت شبکه سازمانی، DNS را مانند یک سرویس زیرساختی دارای مالک، سطح دسترسی، نسخه پشتیبان و معیار سلامت تعریف کنید.
معماری پیشنهادی برای امنیت DNS سازمانی
نقش پاسخ‌گوی داخلی و مرجع عمومی را جدا کنید
Resolver درخواست کاربر را دریافت و پاسخ را پیدا یا از کش ارائه می‌کند؛ سرور Authoritative مرجع رکوردهای یک ناحیه است. کاربران شرکت به حل نام داخلی و بیرونی نیاز دارند، اما سرور مرجع عمومی فقط باید نقش تعریف‌شده خود را برای دامنه‌های عمومی انجام دهد. ترکیب بی‌برنامه این نقش‌ها، دامنه دسترسی و عیب‌یابی را پیچیده می‌کند.
فهرست نام سرورها، تجهیزات مدیریتی و سرویس‌های خصوصی را در DNS عمومی منتشر نکنید. اگر برای یک نام، پاسخ داخلی و بیرونی متفاوت لازم است، طراحی Split DNS را مستند کنید: هر پاسخ از کجا می‌آید، چه کسی آن را تغییر می‌دهد و کاربر VPN کدام پاسخ را می‌بیند؟ وجود دو نسخه از یک رکورد بدون فرایند هماهنگی، منبع خطای عملیاتی است.
افزونگی را بر اساس نقاط خرابی طراحی کنید
دو resolver که روی یک میزبان مجازی، یک ذخیره‌ساز یا یک مسیر برق قرار دارند، ممکن است هم‌زمان از دسترس خارج شوند. پیشنهاد عملی این است که وابستگی‌های مشترک را ثبت کنید و متناسب با اهمیت سرویس، میزبان، برق و مسیر شبکه مستقل در نظر بگیرید. برای شعب نیز بررسی کنید که قطع ارتباط با مرکز چه اثری بر نام‌های داخلی و سرویس‌های محلی دارد.
دو نشانی DNS به‌تنهایی تضمین تداوم خدمت نیستند. داده‌ها، سیاست فیلترینگ و مسیر دسترسی هر دو باید سازگار باشند. زمان بازیابی را از دید یک کاربر واقعی اندازه بگیرید؛ روشن‌بودن ماشین مجازی یا پاسخ‌دادن سرویس از داخل اتاق سرور، تجربه کاربر شعبه را نشان نمی‌دهد.
دامنه عمومی و حساب مدیریت آن را فراموش نکنید
برای پنل ثبت‌کننده دامنه و ارائه‌دهنده DNS عمومی، حساب‌های مشخص، احراز هویت چندعاملی در صورت پشتیبانی و مسیر بازیابی کنترل‌شده داشته باشید. تغییر Name Server یا رکوردهای حساس باید صاحب درخواست و سابقه تغییر داشته باشد. دسترسی فردی که از سازمان خارج شده را بازبینی کنید و اطلاعات بازیابی حساب را به ایمیلی وابسته نکنید که در سناریوی قطعی همان دامنه از دسترس خارج می‌شود.
تنظیم DNS در Active Directory؛ یک نمونه مستند
Microsoft در راهنمای رسمی تنظیم DNS کلاینت توضیح می‌دهد که اشاره مستقیم کنترل‌کننده دامنه یا سرور عضو دامنه به DNS ارائه‌دهنده اینترنت می‌تواند عضویت و ورود به دامنه را مختل کند. این نمونه واقعی از یک خطای پیکربندی مستند است: اینترنت ظاهراً کار می‌کند، اما رکوردهای مورد نیاز Active Directory پیدا نمی‌شوند.
برای این سیستم‌ها resolver داخلیِ آگاه از فضای نام دامنه را تنظیم کنید و حل نام‌های بیرونی را از مسیر forwarder مناسب انجام دهید. DNS عمومی را صرفاً با تصور «پشتیبان اینترنت» در فهرست Alternate قرار ندهید. همان راهنمای Microsoft یادآور می‌شود که پاسخ معتبر اما نادرست لزوماً باعث رفتن کلاینت به سرور بعدی نمی‌شود؛ سازگاری پاسخ‌ها اهمیت دارد.
در بازبینی عملی، تنظیم DHCP، کارت شبکه سرورها، VPN و تجهیزات دارای تنظیم دستی را کنار هم بررسی کنید. یک رایانه ممکن است در دفتر درست کار کند اما پس از اتصال VPN مسیر دیگری برای DNS داشته باشد. این کنترل را همراه با چک‌لیست سخت‌سازی Active Directory انجام دهید تا مجوز حساب‌ها و تنظیمات نام دامنه جدا از یکدیگر بررسی نشوند.
سخت‌سازی DNS؛ دسترسی‌ها، انتقال ناحیه و به‌روزرسانی
Recursion را فقط به مبدأهای مجاز ارائه دهید
درخواست بازگشتی کاربران داخلی باید از شبکه‌های مجاز پذیرفته شود؛ سرور عمومی نباید ناخواسته به resolver آزاد اینترنت تبدیل شود. نقش‌ها و قواعد فایروال را بر اساس نیاز واقعی تعریف کنید. خاموش‌کردن سراسری recursion روی resolver داخلی راهکار عمومی مناسبی نیست: در Windows DNS این کار استفاده از forwarder را هم غیرفعال می‌کند. جزئیات در مستند پرس‌وجوها و جست‌وجوهای DNS مایکروسافت آمده است.
انتقال و تغییر رکوردها را کنترل کنید
اگر Zone Transfer لازم است، آن را فقط به سرورهای ثانویه مشخص محدود کنید؛ اگر استفاده‌ای ندارد، فعال نگهش ندارید. تکثیر ناحیه AD-integrated میان کنترل‌کننده‌های دامنه از سازوکار Active Directory استفاده می‌کند و نباید با انتقال معمول AXFR یکسان فرض شود. راهنمای انواع ناحیه DNS مبنای مناسبی برای تشخیص این تفاوت است.
برای ناحیه AD-integrated، به‌روزرسانی پویا را متناسب با طراحی روی حالت امن تنظیم کنید و مالکیت رکوردها و مجوز حساب‌های DHCP را بررسی کنید. گزینه Secure only جای بررسی دسترسی‌ها را نمی‌گیرد. همچنین DNSSEC مجوز تغییر رکورد را مدیریت نمی‌کند. توضیحات این سازوکار در مستند Dynamic Update مایکروسافت ارائه شده است.
- مدیریت DNS را به حساب‌های مشخص و مسیر مدیریتی مجاز محدود کنید.
- تغییر رکوردهای حساس را با درخواست، تأیید مسئول سرویس و مقدار قبلی ثبت کنید.
- پیش از حذف رکورد ظاهراً قدیمی، مالک سرویس و وابستگی آن را پیدا کنید.
- به‌روزرسانی سیستم‌عامل و سرویس DNS را در فرایند مدیریت وصله شبکه سازمانی قرار دهید.
برای DNS معمولی هر دو مسیر UDP و TCP را بررسی کنید
TCP روی پورت ۵۳ فقط برای انتقال ناحیه نیست؛ در پاسخ‌های بزرگ و کاربردهای DNSSEC نیز اهمیت دارد. بستن TCP درحالی‌که UDP باز است می‌تواند به خطا و انتظار طولانی برنامه‌ها منجر شود. استاندارد RFC 7766 درباره DNS روی TCP این نیاز را توضیح می‌دهد. دسترسی را بین مبدأ و مقصدهای مجاز تعریف کنید؛ پشتیبانی از TCP به معنی بازکردن بی‌قیدوشرط سرور به اینترنت نیست.
تفاوت DNSSEC، DoH و DoT چیست؟
DNSSEC برای بررسی اصالت پاسخ است
DNSSEC با امضاهای رمزنگاری‌شده، اصالت مبدأ و تمامیت داده DNS را قابل اعتبارسنجی می‌کند. این قابلیت پرس‌وجو را محرمانه نمی‌کند و وجود یک امضا در پاسخ، به‌تنهایی اثبات اعتبارسنجی موفق نیست؛ resolver باید زنجیره اعتماد را بررسی کند. دامنه امضاشده نیز الزاماً وب‌سایتی قابل اعتماد ندارد. این تمایز در مبانی DNSSEC در RFC 4033 تشریح شده است.
برای فعال‌سازی سازمانی، ابتدا مسئول نگهداری کلیدها، کنترل انقضای امضا و فرایند تغییر را تعیین کنید. آزمون را در محیط تحت کنترل انجام دهید و شکست اعتبارسنجی را از قطعی ارتباط تشخیص دهید. غیرفعال‌کردن دائمی اعتبارسنجی برای پنهان‌کردن یک خطای پیکربندی، راه‌حل پایدار نیست؛ علت خطا باید پیدا و اصلاح شود.
DoH و DoT مسیر ارتباط با resolver را رمز می‌کنند
DoH درخواست DNS را از طریق HTTPS منتقل می‌کند و DoT از TLS، معمولاً روی TCP/853، استفاده می‌کند. این روش‌ها به‌تنهایی جای DNSSEC را نمی‌گیرند و resolver همچنان درخواست را می‌بیند. منابع فنی این تفاوت، ملاحظات امنیتی RFC 8484 و استاندارد DNS over TLS هستند.
در سازمان، مقصد مجاز را مشخص کنید و تنظیم مرورگر و سیستم‌عامل را هماهنگ نگه دارید. رمزنگاری مطلوب است، اما انتخاب خودسرانه resolver بیرونی ممکن است سیاست فیلترینگ یا حل نام داخلی را دور بزند. سیاست را ابتدا روی گروه آزمایشی اجرا کنید و رفتار هنگام قطع مقصد، اعتبار گواهی و بازگشت احتمالی به DNS معمولی را بررسی کنید.
مانیتورینگ DNS و فیلترینگ تهدید چگونه انجام شود؟
داشبورد باید بین سلامت سرویس و نشانه امنیتی تفاوت بگذارد. برای سلامت، زمان پاسخ از هر شعبه، نرخ timeout، خطای SERVFAIL و امکان ترجمه نام‌های حیاتی را ثبت کنید. برای بررسی امنیتی، تغییرات مدیریتی، درخواست به resolver غیرمجاز و افزایش غیرعادی نام‌های ناموجود را کنار داده‌های endpoint و فایروال تحلیل کنید.
افزایش NXDOMAIN به‌تنهایی حمله را ثابت نمی‌کند؛ یک برنامه بدپیکربندی نیز ممکن است چنین الگویی بسازد. آستانه هشدار را از خط مبنای همان شبکه به دست آورید. هشدار خوب باید نام دستگاه، زمان، نوع خطا و اقدام اولیه را نشان دهد. برای اتصال این داده‌ها به فرایند بررسی رخداد، راهنمای مدیریت متمرکز لاگ و SIEM را ببینید.
فیلترینگ دامنه‌های مشکوک را همراه با مسیر رسیدگی به خطای مثبت کاذب اجرا کنید. درخواست رفع مسدودی باید مالک کسب‌وکار، دلیل نیاز و نتیجه بررسی داشته باشد. لاگ DNS می‌تواند الگوی استفاده کاربران را نشان دهد؛ دسترسی، زمان نگهداری و سطح جزئیات آن را بر اساس نیاز عملیاتی تعیین کنید و از جمع‌آوری نامحدود بدون هدف بپرهیزید.
برنامه اجرایی و آزمون پذیرش DNS امن
- موجودی تهیه کنید: resolverها، zoneها، forwarderها، رکوردهای حساس، مسئول هر سرویس و مسیرهای شعبه و VPN را در یک سند ثبت کنید.
- خط مبنا بسازید: پیش از تغییر، پاسخ نام داخلی، نام عمومی و رکوردهای SRV دامنه را از شبکه‌های مختلف ثبت کنید تا مقایسه ممکن باشد.
- تغییر را مرحله‌ای اجرا کنید: ابتدا یک گروه محدود، سپس یک شعبه و بعد کل سازمان. معیار توقف و مسئول تصمیم‌گیری را از قبل مشخص کنید.
- قواعد دسترسی را آزمایش کنید: کاربر مجاز باید پاسخ بگیرد و مبدأ غیرمجاز نباید recursion یا انتقال ناحیه دریافت کند.
- خرابی کنترل‌شده ایجاد کنید: در پنجره نگهداری، دسترسی کلاینت آزمایشی به یک resolver را قطع و زمان بازیابی سرویس واقعی را ثبت کنید.
- بازیابی را تمرین کنید: تنظیمات و داده پشتیبان را در محیط جداگانه بازیابی و صحت رکوردهای ضروری را بررسی کنید.
این مراحل طرح آزمون پیشنهادی‌اند و باید با معماری سازمان تطبیق داده شوند. در آزمون، پاسخ UDP و TCP را جدا بررسی کنید. برای DNSSEC از ناحیه آزمایشی تحت کنترل با امضای سالم و نامعتبر استفاده کنید. برای DNS رمزنگاری‌شده نیز مقصد واقعی و رفتار شکست اتصال را ثبت کنید؛ سبزبودن یک گزینه تنظیمات کافی نیست.
| آزمون | شرط قبولی پیشنهادی | مدرک تحویل |
|---|---|---|
| نام‌های داخلی و عمومی | پاسخ مطابق فهرست مصوب از دفتر، شعبه و VPN | نتیجه ثبت‌شده برای هر مسیر |
| قطع یک resolver | ادامه سرویس در زمان بازیابی مورد توافق | زمان اختلال و نتیجه آزمون برنامه |
| درخواست غیرمجاز | رد recursion و انتقال ناحیه خارج از مجوز | لاگ رد درخواست از مبدأ آزمایشی |
| بازیابی پشتیبان | بازگشت رکوردها و تنظیمات ضروری در محیط جدا | صورت‌جلسه بازیابی و اختلاف‌های احتمالی |
سناریوی کاربردی: شعبه‌ای که ارتباطش با مرکز قطع می‌شود
فرض کنید یک شعبه دارای کاربران دامنه و یک نرم‌افزار محلی است و هر دو resolver آن در مرکز قرار دارند. این مثال آموزشی است، نه گزارش پروژه مشتری. در قطع ارتباط، کش ممکن است موقتاً بعضی نام‌ها را پاسخ دهد، اما جای دسترسی پایدار به رکوردهای مورد نیاز را نمی‌گیرد. تیم باید نام‌های ضروری شعبه و نیاز برنامه به احراز هویت مرکزی را جدا مشخص کند.
راهکار ممکن است resolver محلی با مسیر صحیح برای ناحیه داخلی، سرویس دامنه متناسب با طراحی یا مسیر ارتباطی جایگزین باشد. انتخاب به وابستگی‌ها و محدودیت مدیریت شعبه بستگی دارد. معیار موفقیت، صرفاً بازشدن یک سایت عمومی نیست؛ ورود کاربر، دسترسی به برنامه و رفتار پس از بازگشت ارتباط باید آزمایش شود.
تحویل پروژه شامل چه چیزهایی باشد؟
نقشه مسیر پرس‌وجو، جدول مجوزها، فهرست مالکان رکورد، نتایج آزمون، نسخه تنظیمات و دستورالعمل واکنش را تحویل بگیرید. در برنامه بازیابی پس از بحران فناوری اطلاعات مشخص کنید DNS در چه مرحله‌ای و با چه وابستگی‌هایی برمی‌گردد. تهیه فایل پشتیبان بدون آزمون بازیابی، اطمینان کافی برای زمان حادثه ایجاد نمی‌کند.
پرسش‌های متداول امنیت DNS سازمانی
آیا استفاده از DNS عمومی برای شرکت کافی است؟
انتخاب باید با نیاز نام‌های داخلی، سیاست امنیتی و شیوه ثبت رخداد سازگار باشد. DNS عمومی می‌تواند بخشی از مسیر حل نام بیرونی باشد، اما جای resolver آگاه از فضای نام داخلی سازمان را نمی‌گیرد. تنظیم نهایی را از دید کاربران دفتر، شعبه و VPN آزمایش کنید.
آیا DNSSEC جلوی همه حملات DNS را می‌گیرد؟
خیر. همچنان به کنترل حساب مدیریت، مجوز تغییر رکورد، حفاظت زیرساخت، پایش و برنامه تداوم نیاز دارید. DNSSEC یکی از لایه‌های طراحی است و نباید باعث حذف کنترل‌های عملیاتی دیگر شود.
در قطعی DNS اولین اقدام تیم پشتیبانی چیست؟
دامنه اثر را مشخص کنید: یک دستگاه، یک شعبه یا همه سازمان؟ سپس ترجمه نام داخلی و عمومی را از resolverهای مجاز جدا آزمایش و تغییرات اخیر را بررسی کنید. تغییر شتاب‌زده DNS همه کاربران به مقصد بیرونی می‌تواند مشکل را گسترده‌تر و شواهد عیب‌یابی را مخدوش کند.
هر چند وقت یک‌بار باید تنظیمات بازبینی شوند؟
پایش سلامت باید مستمر باشد. برای بازبینی دسترسی‌ها، رکوردهای بلااستفاده و تمرین بازیابی، دوره مشخص متناسب با حساسیت سرویس تعیین کنید؛ بازبینی فصلی می‌تواند نقطه شروع باشد. پس از تغییر شبکه، مهاجرت سرور یا اضافه‌شدن شعبه، آزمون مرتبط را دوباره انجام دهید.
جمع‌بندی و گام بعدی
امنیت DNS سازمانی از معماری روشن، مجوز محدود، پاسخ‌های سازگار، افزونگی آزموده و پایش قابل اقدام ساخته می‌شود. از شناسایی resolverها و وابستگی‌های واقعی شروع کنید؛ سپس تغییرات را مرحله‌ای اجرا کنید و نتیجه را با آزمون کاربر نهایی بسنجید. این روش، عیب‌یابی را نیز دقیق‌تر می‌کند و مسئولیت‌ها را برای تیم پشتیبانی روشن نگه می‌دارد.
برای ارزیابی وضعیت DNS و طراحی برنامه اصلاح، از خدمات پشتیبانی شبکه سازمانی نصیر ارتباط استفاده کنید. در پشتیبانی ماهانه، دامنه خدمت می‌تواند تمام زنجیره از کاربر و تجهیزات شبکه تا زیرساخت و سرورها را پوشش دهد. درخواست ارزیابی را همراه با تعداد کاربران، شعب و شرح اختلال‌های تکرارشونده ثبت کنید تا محدوده بررسی و اقدامات پیشنهادی مشخص شود.
