Mohsen

در این نوشته کوتاه به DNS Zone Transfer و اهمیت آن از نظر امنیتی برای سایت ها و وب سرورها می پردازم .
DNS ها و تنظیماتش به عنوان یکی از کارهای ساده در راه اندازی وب سایت ها و یا جزو تنظیمات معمول در شبکه های داخلی است . و کمتر به اهمیت آن از نظر امنیتی پرداخته شده است .
کار یک DNS Server تبدیل یا map کردن HostName به IP و یا برعکس می باشد.
Forward Look Up Zone (Forward Look UP Query)y به عمل تبدیل شدن یک HostName به IP گفته می شود . و Reverse Look UP Zone (Reverse LookUP Query)y به عمل تبدیل شدن یک IP به هاست نیم ...

یک DNS Server برای جستجو در Name Resolution یعنی Forward LookUP Zone بر روی پورت UDP 53 و برای Zone Transfer ها یعنی Reverse LookUP Zone بر روی پورت TCP 53 به صورت Listen قرار می گیرد.

حملاتی که روی DNS ها انجام می گیرد عمدتا 3 روش زیر می باشد :

Buffer Overflow Attack

Information Disclosure Attacks

Cache Poisoning Attacks

از روش های فوق روش آخر خطرناک ترین می باشد اما در این مورد خاص تاکیدم روی روش دوم است که به DNS Zone Transferمعروف است.

به خاطر اهميت سرويس DNS ، از حداقل دو DNS استفاده می شود كه اولي master يا primary هست و وظيفه ترجمه آدرس ها را به عهده دارد ، و دومي slave يا secondary هست و وظيفه كمكي. حالا طبق اصول مديريتي شبكه ، اطلاعاتي كه در DNS اولي هست ، بايد طبق يك برنامه زمان بندي شده ( يا درخواست مستقيم DNS دومي ) به DNS دوم هم منتقل شود كه اين DNS هم اطلاعاتش به روز باشد . حالا اگر تنظيمات در سرور DNS اول طوري باشد ، كه اين اطلاعات درخواستي را براي هر سيستمي كه درخواست كرد ، بفرستد ، مشكل Zone Transfer دارد ، و اگر يك همچين سروري پيدا شود ، هكر مي تواند تمام اطلاعات ركورد شده روي DNS را كه شامل آدرس هاي خصوصي شبكه هم مي شود به دست بيارد و به اين شكل اطلاعات كاملي از نقشه شبكه ي هدف به چنگ بياورد .( به نقل از Prince of hacking )

در حملات DNS poisoning or spoofingهکر می تواند اطلاعات DNS را به چیز دیگری تغییر دهد . بسته به ضعف سرور متدها و روش های مختلفی برای این کار وجود دارد از جمله حملات معروفی که به A man in the middle معروف است و خصوصا برای سایت های استفاده کننده از سیستم امنیتی SSL می تواند اطلاعات رد و بدل شده بین مشتری و سرور را به نوعی شنود کند .

اما چگونه ؟

یکی از این متد ها و روش ها حمله Denial of Service attack بر روی DNS اولی یا primary و به نوعی مشغول کردن آن می باشد به طوری که دیگر نتواند به DNS کوئری ها پاسخ دهد .در این هنگام هکر که identity دی ان اس اصلی را دارد از طریق هاست خود اطلاعات جعلی یا متفاوتی را برای دی ان اس دوم یا کل شبکه اینترنت ( مراجعه کنندگان ) ارسال می کند .

اطلاعات مربوط به DNS Zone file وبسایت به علت config و تنظیمات نادرست سرور به راحتی برای هر کس ( هر سرور ) ارسال می شود . این اطلاعات معمولا شامل رکوردها است که علایم اختصاری تعدادی از آنها در زیر اشاره می کنم :

Value Description :
A Specifies a computer's IP address.
ANY Specifies all types of data.
CNAME Specifies a canonical name for an alias.
GID Specifies a group identifier of a group name.
HINFO Specifies a computer's CPU and type of operating system.
MB Specifies a mailbox domain name.
MG Specifies a mail group member.
MINFO Specifies mailbox or mail list information.
MR Specifies the mail rename domain name.
MX Specifies the mail exchanger.
NS Specifies a DNS name server for the named zone.
PTR Specifies a computer name if the query is an IP address; otherwise, specifies the pointer
to other information.
SOA Specifies the start-of-authority for a DNS zone.
TXT Specifies the text information.
UID Specifies the user identifier.
UINFO Specifies the user information.
WKS Describes a well-known service.

با توجه به توضیحات بند بالا در این حالت هکر به راحتی دومین را hijack می کند و هکر می تواند با انتشار اطلاعات غلط DNS انواع حملات و یا هدف های سوء را در نظر بگیرد از جمله :

1. هکر به راحتی می تواند یک وب سایت دقیقا شامل کدهای صفحه ی وب سایت اصلی و با همان عکس ها و طرح درست کند ( به راحتی ! ) و با درست کردن این صفحه ی تقلبی به راحتی مشتریان و مراجعه کنندگان را فریب دهد

تا پسورد و اطلاعات حساس حساب خود را در صفحه ای که موقعیت واقعی آن بر روی سرور هکر است ( و نه سرور اصلی ) ارسال کند . همین طور هکر می تواند به راحتی هر نوع سیستم امنیتی را روی سرور خود نصب کند از جمله SSL تا به این وسیله به قربانیان حس امنیت بیشتر بدهد و حتی افراد مطلع را نیز فریب دهد .

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

2. هکر می تواند رکورد های MX را به میل سرور دیگر بفرستد ! و به این ترتیب تمام نامه های الکترونیک ( ایمیل ها ) به سرور هکر ارسال شوند .

3. هکر می تواند ftp را نیز به سرور دیگری ری دایرکت کند در نتیجه تمام اطلاعات در حال آپلود روی سرور از جمله آپدیت های احتمالی مورد سرقت قرار گیرد.و هکر به اطلاعات نرم افزاری نیز دسترسی پیدا کند.

4. بسته به نوع فرآیند امنیت دامین ها چنانچه ایمیل اکانت پنل دامین نیز از ایمیل دامین اصلی باشد هکر به راحتی می تواند DNS های واقعی دامین اصلی را هم به سرور خود تغییر دهد ! در نتیجه با یک حمله ی موقتی پس از تعویض دی ان اس های واقعی دامین تمام مشتریان را به سرور خود ارجاع دهد ( بدون اینکه مشتریان قادر به تشخیص این موضوع باشند) و چون آپدیت شدن دی ان اس ها هم در ISP های مختلف متفاوت است و از 12 ساعت تا حتی 72 ساعت ممکن است طول بکشد . در این حالت با فرض اینکه مسئولین فنی سرور هم متوجه شوند تا مدت زمان طولانی که همه ی DNS سرورها در آی اس پی ها و شرکت های ارایه دهنده ی خدمات اینترنتی آپدیت شوند واقعا هیچ کاری از دستشان برنخواهد آمد.

5. و .... ( بسته به خلاقیت هکر هزاران مورد دیگر ... )

دو نوع Zone Transfer داريم . يكي Full يا AXFR كه تمامي اطلاعات ارسال مي شود و ديگري هم Incremental يا IXFR كه آخرين تغييرات بعد از آخرين ارسال.

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

Name Servers, host names, MX records, CNAME records,glue records (delegation for child Domains), zone serial number, Time To Live(TTL) records

تمام آدرس های ساب دومین ها نیز از dns zone transfer به دست می آید !

چنانچه سرور درست کانفیگ شده باشد به کوئری خواسته شده که از طرف هکر یا سرور وی ارسال می شود این گونه پاسخ خواهد داد :

کد:

; (1 server found)
 ; Transfer failed.
 ;; global options: +cmd

یعنی رکورد ها را فقط برای DNS Server صاحب اصلی یا همان Trusted ip ارسال می کند . برای رفع این خطا کافی است در سرورهای لینوکسی در پوشه ی etc فایل named.conf را ویرایش کنیم و بین قسمت options آن این کد را قرار دهیم :

کد:

allow-transfer {xx.xx.xxxx.xx;xxx.xxx.xxxx.xx;};

x ها باید با آی پی DNS Server جایگزین شود . trusted ip

در سرور ویندوزی هم کافی است تیک مقابل Allow-AXFR را برداریم .

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

در مورد اهمیت موضوع :

در acunetix این ایراد به عنوان High level در نظر گرفته شده . و همین طور یک مقاله بسیار مفید و جدید از یکی از متخصصین Kaspersky دراینجا ( کلیک کنید ) هست که هم به طور آماری بررسی کرده است و هم یک نمونه قرار داده .