مشاهده نسخه کامل
: Hoom@n
17-02-2006, 00:58
جلال روحانی، مدتی پیش در تکوپیدیا مطلبی نوشته بودم با عنوان DNS Cache Poisoning که چون متاسفانه برای مدتی تکوپیدیا در دسترس نیست، نمی توانم لینکی از آن را ارائه بدهم. برای این که دوست ندارم خلاصه ای از مطلب رو بیان کنم تر جیح می دهم کل مطلب رو در ادامه ذکر کنم.
این مدت مطالب بسیاری بوده است كه سعی می كنم در صورت لزوم به برخی اشاره كنم. یكی از این موارد DNS poisoning می باشد. با اینكه مورد بسیار مهمی است اما كمتر به آن اشاره شده است. من سعی می كنم در این نوشته به اختصار توضیحی روان برای آن ارائه بدهم و بیشتر به موارد مرجع اشاره كنم.
ابتدای تاریخچه كشف DNS Cache Poisoning ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]) مربوط می شود به سال 1993 و یافتن ایرادهایی منطقی كه در تعریف DNS وجود داشت و منجر به اولین مورد های DNS Cache Poisoning شد. برای مطالعه كامل در مورد تاریخچه و روند بررسی تا به امروز بخوانید : DNS Cache Poisoning � The Next Generation. ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مدتی پیش در یعنی ماه مارس 2005 یك حمله بسیار گسترده در این مورد انجام شد. بیش از 500 موسسه بزرگ دنیا قربانی شدند و در سه حمله متوالی وب سایت های آن ها به سایت های دیگری ( مثل abx4.com ) منحرف شدند. این حمله ها آغازی بود برای بررسی بیشتر بر روی این نقص و ارایه راه كار های مختلف.
در همین زمینه SANS یك گزارش كامل تهیه كرد كه پیش نهاد می كنم آن را كامل مطالعه كنید. در این گزارش آغاز حمله و آمار های زیادی وجود دارد : March 2005 DNS Poisoning Summary ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
برای اینكه به صورت عملی این ایراد را ببینید ( البته در صورتی كه DNS سرور مورد استفاده شما آسیب پذیر باشد.) این صفحه ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]) را ببینید.
اهمیت این ایراد امنیتی به دلیل خطری است كه برای تجارت شما و یا اطلاعات شخصی افراد می تواند داشته باشد. بیشترین ضرری كه این مورد تا به حال وارد كرده است بر اثر سرقت اطلاعات كارت های اعتباری می باشد. فرض كنید كاربر شبكه شما قصد خرید آنلاین داشته باشد و به علت نقص DNS سرور شما اطلاعات او دزدیده شود. و یا شریك تجاری شما قصد بازدید از وب سایت شركت شما را داشته باشد ولی به علت ایراد یك DNS سرور به سایت مستهجن هدایت شود.
روش هایی كه برای پیشگیری از این موارد ( و شاید سایر آسیب پذیری ها ) وجود دارند:
- همیشه DNS سرور شبكه خود را بروز كنید. اگر مانند اكثر شبكه ها از BIND استفاده می كنید، حتما به نسخه ای بالاتر از 9.2.5 مهاجرت كنید و اگر این امكان را ندارید از 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 استفاده می كنید حتما این كار را انجام دهید.
- سرویس های اضافه را بر روی ماشین سرور غیر فعال كنید و از یك فایروال كه به خوبی برای پاسخ به درخواست های مربوطه تنظیم شده است استفاده كنید.
لطفا برای كامل كردن این نوشته نظرات خود را اضافه كنید. هر تجربه برای شبكه ای امن تر مفید است.
دلیل اینکه به این مطلب اشاره شد، تقریبا برای شما که این مطلب رو می خوانید روشن است. امروز تعداد زیادی از وب سایت های پرمخاطب ایرانی مورد حمله قرار گرفت. هنوز اطلاعات کاملی از نوع حمله ها منتشر نشده است ولی حداقل در مورد پایگاه پرشین بلاگ به آلوده سازی DNS سرور در سمت سرویس دهنده های ایرانی ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]) اشاره شده است.
کمی آشنایی با این حمله ها این نکته را یادآور می شود که در واقع تنها ضرری که این حمله به پایگاه های قربانی وارد می کند عدم دسترسی برای آن ها است. اما به این مورد نیز باید توجه داشت علاوه بر نمایش اطلاعات نامربوط ،امکان دزیدن اطلاعات شخصی کاربران نیز وجود خواد داشت. همینطور می بایست یادآوری شود امکان جلوگیری از این حمله ها برای دیتا سنتر های بزرگ امکان پذیر است.
امیدوارم اطلاعات کامل تر و دقیق تری درباره ماهیت این حمله ها منتشر شود. در هر صورت باید به خاطر داشته باشیم حق تمامی کاربران است تا از اتفاقاتی که می افتد آگاه باشند!
اگر کمی وقت داشتید چند لینک معرفی شده اطلاعات بسیار خوبی را در اختیار شما خواهند گذاشت.
مشاهده: DNS Cache Poisoning Security Research - LURHQ ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مشاهده: DNS Pharming: Someone's poisoned the water hole! ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مشاهده: DNS Cache Poisoning Security Research - LURHQ ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مرجع: techopedia ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
این مدت مطالب بسیاری بوده است كه سعی می كنم در صورت لزوم به برخی اشاره كنم. یكی از این موارد DNS poisoning می باشد. با اینكه مورد بسیار مهمی است اما كمتر به آن اشاره شده است. من سعی می كنم در این نوشته به اختصار توضیحی روان برای آن ارائه بدهم و بیشتر به موارد مرجع اشاره كنم.
ابتدای تاریخچه كشف DNS Cache Poisoning ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]) مربوط می شود به سال 1993 و یافتن ایرادهایی منطقی كه در تعریف DNS وجود داشت و منجر به اولین مورد های DNS Cache Poisoning شد. برای مطالعه كامل در مورد تاریخچه و روند بررسی تا به امروز بخوانید : DNS Cache Poisoning � The Next Generation. ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مدتی پیش در یعنی ماه مارس 2005 یك حمله بسیار گسترده در این مورد انجام شد. بیش از 500 موسسه بزرگ دنیا قربانی شدند و در سه حمله متوالی وب سایت های آن ها به سایت های دیگری ( مثل abx4.com ) منحرف شدند. این حمله ها آغازی بود برای بررسی بیشتر بر روی این نقص و ارایه راه كار های مختلف.
در همین زمینه SANS یك گزارش كامل تهیه كرد كه پیش نهاد می كنم آن را كامل مطالعه كنید. در این گزارش آغاز حمله و آمار های زیادی وجود دارد : March 2005 DNS Poisoning Summary ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
برای اینكه به صورت عملی این ایراد را ببینید ( البته در صورتی كه DNS سرور مورد استفاده شما آسیب پذیر باشد.) این صفحه ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]) را ببینید.
اهمیت این ایراد امنیتی به دلیل خطری است كه برای تجارت شما و یا اطلاعات شخصی افراد می تواند داشته باشد. بیشترین ضرری كه این مورد تا به حال وارد كرده است بر اثر سرقت اطلاعات كارت های اعتباری می باشد. فرض كنید كاربر شبكه شما قصد خرید آنلاین داشته باشد و به علت نقص DNS سرور شما اطلاعات او دزدیده شود. و یا شریك تجاری شما قصد بازدید از وب سایت شركت شما را داشته باشد ولی به علت ایراد یك DNS سرور به سایت مستهجن هدایت شود.
روش هایی كه برای پیشگیری از این موارد ( و شاید سایر آسیب پذیری ها ) وجود دارند:
- همیشه DNS سرور شبكه خود را بروز كنید. اگر مانند اكثر شبكه ها از BIND استفاده می كنید، حتما به نسخه ای بالاتر از 9.2.5 مهاجرت كنید و اگر این امكان را ندارید از 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 استفاده می كنید حتما این كار را انجام دهید.
- سرویس های اضافه را بر روی ماشین سرور غیر فعال كنید و از یك فایروال كه به خوبی برای پاسخ به درخواست های مربوطه تنظیم شده است استفاده كنید.
لطفا برای كامل كردن این نوشته نظرات خود را اضافه كنید. هر تجربه برای شبكه ای امن تر مفید است.
دلیل اینکه به این مطلب اشاره شد، تقریبا برای شما که این مطلب رو می خوانید روشن است. امروز تعداد زیادی از وب سایت های پرمخاطب ایرانی مورد حمله قرار گرفت. هنوز اطلاعات کاملی از نوع حمله ها منتشر نشده است ولی حداقل در مورد پایگاه پرشین بلاگ به آلوده سازی DNS سرور در سمت سرویس دهنده های ایرانی ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]) اشاره شده است.
کمی آشنایی با این حمله ها این نکته را یادآور می شود که در واقع تنها ضرری که این حمله به پایگاه های قربانی وارد می کند عدم دسترسی برای آن ها است. اما به این مورد نیز باید توجه داشت علاوه بر نمایش اطلاعات نامربوط ،امکان دزیدن اطلاعات شخصی کاربران نیز وجود خواد داشت. همینطور می بایست یادآوری شود امکان جلوگیری از این حمله ها برای دیتا سنتر های بزرگ امکان پذیر است.
امیدوارم اطلاعات کامل تر و دقیق تری درباره ماهیت این حمله ها منتشر شود. در هر صورت باید به خاطر داشته باشیم حق تمامی کاربران است تا از اتفاقاتی که می افتد آگاه باشند!
اگر کمی وقت داشتید چند لینک معرفی شده اطلاعات بسیار خوبی را در اختیار شما خواهند گذاشت.
مشاهده: DNS Cache Poisoning Security Research - LURHQ ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مشاهده: DNS Pharming: Someone's poisoned the water hole! ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مشاهده: DNS Cache Poisoning Security Research - LURHQ ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])
مرجع: techopedia ([ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ])