DNS Cache Poisoning

اين مدت مطالب بسياري
بوده است كه سعي مي كنم در صورت لزوم به برخي اشاره كنم. يكي از اين موارد DNS
poisoning مي باشد. با اينكه مورد بسيار مهمي است اما كمتر به آن اشاره شده است. من
سعي مي كنم در اين نوشته به اختصار توضيحي روان براي آن ارائه بدهم  و 
بيشتر به موارد مرجع اشاره كنم.

ابتداي تاريخچه كشف
DNS Cache Poisoning
مربوط مي شود به سال ۱۹۹۳ و يافتن ايرادهايي منطقي كه در تعريف DNS
وجود داشت و منجر به اولين مورد هاي DNS Cache Poisoning شد. براي مطالعه كامل در
مورد تاريخچه و روند بررسي تا به امروز بخوانيد :
DNS Cache Poisoning – The Next
Generation
.
مدتي پيش در يعني ماه مارس ۲۰۰۵ يك حمله بسيار گسترده در اين مورد انجام شد. بيش از 
۵۰۰ موسسه بزرگ دنيا قرباني شدند و در سه حمله متوالي وب سايت هاي آن ها به سايت
هاي ديگري ( مثل abx4.com ) منحرف شدند. اين حمله ها آغازي بود براي بررسي بيشتر بر
روي اين نقص و ارايه راه كار هاي مختلف. در همين زمينه SANS
يك گزارش كامل تهيه كرد كه پيش نهاد مي كنم آن را كامل مطالعه كنيد. در اين گزارش
آغاز حمله و آمار هاي زيادي وجود دارد :
March 2005 DNS
Poisoning Summary

براي اينكه به صورت عملي اين ايراد را ببينيد ( البته در صورتي كه
DNS سرور مورد استفاده شما آسيب پذير باشد.)
اين صفحه را ببينيد.

اهميت اين ايراد امنيتي
به دليل خطري است كه براي تجارت شما و يا اطلاعات شخصي افراد مي تواند داشته باشد.
بيشترين ضرري كه اين مورد تا به حال وارد كرده است بر اثر سرقت اطلاعات كارت هاي
اعتباري مي باشد. فرض كنيد كاربر شبكه شما قصد خريد آنلاين داشته باشد و به علت نقص
DNS سرور شما اطلاعات او دزديده شود. و يا شريك تجاري شما
قصد بازديد از وب سايت شركت شما را داشته باشد ولي به علت ايراد يك DNS
سرور به سايت مستهجن هدايت شود.

روش هايي كه براي
پيشگيري از اين موارد ( و شايد ساير آسيب پذيري ها ) وجود دارند :
    – هميشه DNS سرور شبكه خود را بروز
كنيد. اگر مانند اكثر شبكه ها از BIND استفاده مي كنيد،
حتما
به نسخه اي بالاتر از ۹٫۲٫۵ مهاجرت كنيد و اگر اين امكان را نداريد از
DNSSec استفاده كنيد. براي آشنايي بيشتر با
DNSSec اين مقاله را بخوانيد :
The Basics
of DNSSEC

    –
اگر كمي حوصله داريد و كنجكاو هستيد از
djbdns
استفاده كنيد. djbdns نوشته Dan
Bernstein
( همان خالق qmail ) مي باشد كه با هدف بر از
بين بردن آسيب پذيري هاي BIND و مانند ساير محصولات او با
تفكر امنيتي خلق شده است. اگر شبكه شما در حد متوسط است و تحمل چند ساعت اختلال
براي آن امكان پذير است پيشنهاد مي كنم از اين محصول استفاده كنيد. هم تجربه تازه
اي است و هم خود را از بسياري آسيب پذيري ها دور نگه داشته ايد. براي شروع نصب مي
توانيد از اين راهنما استفاده كنيد :
Installing djbdns for Name
Service
– همچنين ايشون نوشته اي در مورد Domain Name System
دارند كه بسيار آموزنده است. مخصوصا در مورد مفاهيم امنيتي به شما كمك ويژه اي
خواهد كرد. اگر به مفاهيم شبكه علاقه مند هستيد اين نوشته جزو Most Read
شما است : Notes on the Domain Name
System


چند توصيه هم در آخر كه هركدام بسته به شرايط شما مي توانيد براي
شبكه اي امن تر مفيد واقع شود. تمامي اين موارد بدون توجه به name server
شما قابل توجه هستند:
    – در صورت امكان name server هاي خود را
به صورت جداگانه در سگمنت هاي مختلف شبكه پياده كنيد. در اين حالت مي توانيد
redundancy را در مورد name server هاي خودتان پياده كنيد.
دقت داشته باشيد در اين حالت مي بايست براي يك راه حل جهت هماهنگي بين آن ها نيز
تصميم گيري كنيد.
    – در صورت كه اين امكان را داريد name server
داخلي و خارجي شبكه خود را از هم مجزا كنيد و از forwarder ها براي شبكه داخلي
استفاده كنيد. سرويس دهنده نام خارجي مي بايست به هر درخواستي پاسخ دهد به جز
forwarder ها.
    – اگر امكان داريد dynamic DNS updates
را محدود كنيد. البته در صورتي كه از Directory Service ها
استفاده كنيد ممكن است نتوانيد از اين مورد بهره جوييد.
    – روش ديگري كه در مورد بسياري از سرويس هاي حياتي شبكه شما مي
تواند مهم باشد پنهان كردن ورژن برنامه سرويس دهنده است. اگر از BIND
استفاده مي كنيد حتما اين كار را انجام دهيد.
    – سرويس هاي اضافه را بر روي ماشين سرور غير فعال كنيد و از يك
فايروال كه به خوبي براي پاسخ به درخواست هاي مربوطه تنظيم شده است استفاده كنيد.

—– لطفا براي كامل
كردن اين نوشته نظرات خود را اضافه كنيد. هر تجربه براي شبكه اي امن تر مفيد است.

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

2 فکر می‌کنند “DNS Cache Poisoning

  1. سلام . مطلب جالبی رو ارائه کرده بودید ممنون
    چون گفته بودین که اگه مطالب بیشتری دارین در قسمت نظرات ارائه کنید گفتم قسمتی از مطالبی رو که در سایت نوشته بودم رو اینجا عنوان کنم …

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

    DNS که یکی از پرکاربرد ترین پروتکول های اینترنت هستش هنوز مسائل امنیتی مرتبط با خودش رو در پی داره . این مقاله در واقع حرف جدیدی در مورد امنیت دی ان اس نداره ولی خوب مطالب مختلف از جاهای دیگه رو گردهم اورده و در اینجا یکجا به شما تقدیم میشه .
    در ضمن این مقاله هم شامل مطالب مقدماتی و هم پیشرفته میشه . حال شروع کنیم :

    + حمله به DNS

    DNS در واقع خلاصه شده Domain Name System هستش و از اون در جهت تبدیل نام دامین به IP استفاده میشه . یک دی ان اس سرور بر روی UDP پورت شماره ۵۳ به انتظار میشینه تا درخواست های تبدیل نام رو انجام بده هم چنین بر روی TCP پورت شماره ۵۳ منتظر درخواست انتقال ناحیه مشه که معمولا توسط دی ان اس سرورهای دیگه انجام میشه .
    Berkley Internet Name Service یا BIND متدوال ترین گونه استفاده شده برای دی ان اس سرورها در اینترنت هستش . BIND عموما بر روی سیستم های UNIX قابل اجراست . دی ان اس رور اطلاعات مرتبط با دامین را در فایل های متنی با عنوان فایل های zone ذخیره می کنه .
    یک کلاینت دی ان اس سرویس رو اجرا می کنه که resolver نام داره که resolver تمامی فعل و انفعالات رو با دی ان اس سرور انجام میده تا نام یک دامین با استفاده از چیزی که records نامیده میشه به آی پی ترجمه بشه , اقسام مختلفی از records وجود داره که مهروف ترین اون ها A و CNAME و MX records نام دارن .
    کلاینت خود مقدار کمی از cache داخلی رو نگهداری میکنه که اول به اون مراجعه می کنه و بعد سراغ فایل هاست میره و در آخر به دی ان اس سرور مراجعه می کنه . به هر حال نتیجه ای که در آخر به کلاینت می رسه واسه مدت کوتاهی cache میشه .

    وقتی دی ان اس سرور ازش در مورد یک تبدیل نام به آی پی درخواستی صورت می گیره اگه درخواست معتبر باشه ( یعنی اینکه پاسخی واسه اون درخواست در بانک اطلاعاتی وجود داشته باشه ) اون موقع جواب واسه کلاینت فرستاده می شه و چنانچه پاسخی واسه درخواست کلاینت پیدا نشد دی ان اس سرور با دی ان اس یرورهای دیگه ارتباط برقرار می کنه و پاسخی رو در اخر واسه کلاینت می فرسته , که این عمل با نام recursion شناخته شده است.
    یاداور بشم که خود کلاینت هم واسه این کار از دی ان اس سرورهای دیگه هم کمک میگیره …

    + حملات رایج دی ان اس :

    دی ان اس سرورها توسط تعدادی از تکنیک ها بهشون حمله میشه که شامل :
    ++ حملات بافر سر ریز که باعث دسترسی به خط فرمان میشه که نفوذگر میتونه فایل های zone رو تغییر بده .

    ++ حملات فاش سازی اطلاعات شامل zone transfer
    ++ حملات Cache poisoning که cache دی ان اس مورد پویش ضعف امنیتی نفوذگر قرار میگیره . این روش با استفاده از تغییر ID دی ان اس , نقطه ضعف را یافتن امکان پذیر هستش .

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

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد.