چرا آنها هک می شوند

بررسی شیوه ی بکار رفته در نفوذ به سایت پرشین بلاگ

جلال روحانی، مدتی پیش در تکوپیدیا مطلبی نوشته بودم با عنوان DNS Cache Poisoning که چون متاسفانه برای مدتی تکوپیدیا در دسترس نیست، نمی توانم لینکی از آن را ارائه بدهم. برای این که دوست ندارم خلاصه ای از مطلب رو بیان کنم تر جیح می دهم کل مطلب رو در ادامه ذکر کنم.

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

ابتدای تاریخچه کشف DNS Cache Poisoning (http://en.wikipedia.org/wiki/DNS_cache_poisoning) مربوط می شود به سال ۱۹۹۳ و یافتن ایرادهایی منطقی که در تعریف DNS وجود داشت و منجر به اولین مورد های DNS Cache Poisoning شد. برای مطالعه کامل در مورد تاریخچه و روند بررسی تا به امروز بخوانید : DNS Cache Poisoning ۶۵۵۳۳; The Next Generation. (http://www.lurhq.com/dnscache.pdf)

مدتی پیش در یعنی ماه مارس ۲۰۰۵ یک حمله بسیار گسترده در این مورد انجام شد. بیش از ۵۰۰ موسسه بزرگ دنیا قربانی شدند و در سه حمله متوالی وب سایت های آن ها به سایت های دیگری ( مثل abx۴.com ) منحرف شدند. این حمله ها آغازی بود برای بررسی بیشتر بر روی این نقص و ارایه راه کار های مختلف.

در همین زمینه SANS یک گزارش کامل تهیه کرد که پیش نهاد می کنم آن را کامل مطالعه کنید. در این گزارش آغاز حمله و آمار های زیادی وجود دارد :

March ۲۰۰۵ DNS Poisoning Summary

(http://isc.sans.org/presentations/dnspoisoning.php)

برای اینکه به صورت عملی این ایراد را ببینید ( البته در صورتی که DNS سرور مورد استفاده شما آسیب پذیر باشد.) این صفحه (http://ketil.froyn.name/poison.html) را ببینید.

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

روش هایی که برای پیشگیری از این موارد ( و شاید سایر آسیب پذیری ها ) وجود دارند:

- همیشه DNS سرور شبکه خود را بروز کنید. اگر مانند اکثر شبکه ها از BIND استفاده می کنید، حتما به نسخه ای بالاتر از ۹.۲.۵ مهاجرت کنید و اگر این امکان را ندارید از DNSSec استفاده کنید. برای آشنایی بیشتر با DNSSec (http://www.dnssec.net/) این مقاله را بخوانید : The Basics of DNSSEC (http://www.onlamp.com/pub/a/onlamp/۲۰۰۴/۱۰/۱۴/dnssec.html)

- اگر کمی حوصله دارید و کنجکاو هستید از djbdns استفاده کنید. djbdns (http://cr.yp.to/djbdns.html) نوشته Dan Bernstein (http://cr.yp.to/djb.html) ( همان خالق qmail ) می باشد که با هدف بر از بین بردن آسیب پذیری های BIND و مانند سایر محصولات او با تفکر امنیتی خلق شده است. اگر شبکه شما در حد متوسط است و تحمل چند ساعت اختلال برای آن امکان پذیر است پیشنهاد می کنم از این محصول استفاده کنید. هم تجربه تازه ای است و هم خود را از بسیاری آسیب پذیری ها دور نگه داشته اید. برای شروع نصب می توانید از این راهنما استفاده کنید :

Installing djbdns for Name Service (http://www.securityfocus.com/infocus/۱۴۳۸)

همچنین ایشون نوشته ای در مورد Domain Name System دارند که بسیار آموزنده است. مخصوصا در مورد مفاهیم امنیتی به شما کمک ویژه ای خواهد کرد. اگر به مفاهیم شبکه علاقه مند هستید این نوشته جزو Most Read شما است :

Notes on the Domain Name System (http://cr.yp.to/djbdns/notes.html)

چند توصیه هم در آخر که هرکدام بسته به شرایط شما می توانید برای شبکه ای امن تر مفید واقع شود. تمامی این موارد بدون توجه به name server شما قابل توجه هستند:

- در صورت امکان name server های خود را به صورت جداگانه در سگمنت های مختلف شبکه پیاده کنید. در این حالت می توانید redundancy را در مورد name server های خودتان پیاده کنید. دقت داشته باشید در این حالت می بایست برای یک راه حل جهت هماهنگی بین آن ها نیز تصمیم گیری کنید.

- در صورت که این امکان را دارید name server داخلی و خارجی شبکه خود را از هم مجزا کنید و از forwarder ها برای شبکه داخلی استفاده کنید. سرویس دهنده نام خارجی می بایست به هر درخواستی پاسخ دهد به جز forwarder ها.

- اگر امکان دارید dynamic DNS updates را محدود کنید. البته در صورتی که از Directory Service ها استفاده کنید ممکن است نتوانید از این مورد بهره جویید.

- روش دیگری که در مورد بسیاری از سرویس های حیاتی شبکه شما می تواند مهم باشد پنهان کردن ورژن برنامه سرویس دهنده است. اگر از BIND استفاده می کنید حتما این کار را انجام دهید.

- سرویس های اضافه را بر روی ماشین سرور غیر فعال کنید و از یک فایروال که به خوبی برای پاسخ به درخواست های مربوطه تنظیم شده است استفاده کنید.

لطفا برای کامل کردن این نوشته نظرات خود را اضافه کنید. هر تجربه برای شبکه ای امن تر مفید است.

دلیل اینکه به این مطلب اشاره شد، تقریبا برای شما که این مطلب رو می خوانید روشن است. امروز تعداد زیادی از وب سایت های پرمخاطب ایرانی مورد حمله قرار گرفت. هنوز اطلاعات کاملی از نوع حمله ها منتشر نشده است ولی حداقل در مورد پایگاه پرشین بلاگ به آلوده سازی DNS سرور در سمت سرویس دهنده های ایرانی (http://www.persianblog.com/news/entry.asp?module=news&id=۳۸۷) اشاره شده است.

کمی آشنایی با این حمله ها این نکته را یادآور می شود که در واقع تنها ضرری که این حمله به پایگاه های قربانی وارد می کند عدم دسترسی برای آن ها است. اما به این مورد نیز باید توجه داشت علاوه بر نمایش اطلاعات نامربوط ،امکان دزیدن اطلاعات شخصی کاربران نیز وجود خواد داشت. همینطور می بایست یادآوری شود امکان جلوگیری از این حمله ها برای دیتا سنتر های بزرگ امکان پذیر است.

امیدوارم اطلاعات کامل تر و دقیق تری درباره ماهیت این حمله ها منتشر شود. در هر صورت باید به خاطر داشته باشیم حق تمامی کاربران است تا از اتفاقاتی که می افتد آگاه باشند!

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