❇️ #گوگل امروز از ساخت رایانه کوانتومی جدید خود Sycamore با قدرت پردازشگر باورنکردنی 54 کوبیت خبر داد.
💪گوگل ادعا می کند که این رایانه مسائلی که یک ابر رایانه برای حل آن به حدود ده هزار سال زمان نیاز دارد را در کمتر از 💥سه و نیم دقیقه 💥پردازش می کند.
👇👇👇
👌در رایانه‌های کوانتومی به جای بیت از بیت کوانتومی یا کوبیت بجای 0 و 1 ها برای ذخیره‌سازی و انتقال داده‌های دیجیتالی استفاده می‌شود که در نتیجه سرعت فوق العاده ای را نسبت به یک رایانه کلاسیک به ارمغان می آورد.
💪گوگل ادعا می کند که این رایانه مسائلی که یک ابر رایانه برای حل آن به حدود ده هزار سال زمان نیاز دارد را در کمتر از 💥سه و نیم دقیقه 💥پردازش می کند.
👇👇👇
👌در رایانه‌های کوانتومی به جای بیت از بیت کوانتومی یا کوبیت بجای 0 و 1 ها برای ذخیره‌سازی و انتقال داده‌های دیجیتالی استفاده می‌شود که در نتیجه سرعت فوق العاده ای را نسبت به یک رایانه کلاسیک به ارمغان می آورد.
ا DNS یک دیتابیس توزیع شده، سلسه مراتبی و پویاست که وظیفه‌ی آن فراهم کردن اطلاعاتی در رابطه با یک دامنه و آدرس‌های IP مرتبط با آن است. در این مطلب سعی شده تا مروری بر تاریخچه DNS ، مشکلات امنیتی آن و آن‌چه سبب خلق راهکار DNSSEC شد، پرداخته شود.
تاریخچه DNS
زمانی‌که مفهوم اینترنت به گستردگی حال حاضر نبود، سیستم‌ها برای برقراری ارتباط با یک‌دیگر، از آدرس IP استفاده می‌کردند. با رشد اینترنت و افزایش تعداد دستگاه‌هایی که قادر به اتصال به اینترنت بودند، تصمیم بر آن شد که سیستم‌ها با نام، یک‌دیگر را فرابخوانند. به همین دلیل نیاز به مکانیزمی برای مشخص کردن آدرس IP متناظر با هر نام بود.
نخستین راه‌حلی که برای این مشکل مطرح شد، استفاده از فایلی با نام host بود. در این فایل آدرس IP متناظر با هر نام درج شده و به هر سیستمی که قصد ارتباط با سایر سیستم‌ها با نام را داشت، منتقل می‌شد. اما با گسترده‌تر شدن دنیای اینترنت و اضافه شدن میلیون‌ها دستگاه به این ساختار، در عمل استفاده از فایل host و انتقال آن به هر سیستم، کاری ناممکن بود. همین عامل سبب معرفی سرویسی با نام Domain Name Service (DNS) شد.
عملکرد DNS
در DNS، اطلاعات مربوط به یک دامنه و آدرس‌های IP مرتبط با آن به‌وسیله‌ی Resource Recordها مشخص می‌شوند که انواع مختلفی دارند و مشهورترین آن‌ها رکورد A، رکورد MX، رکورد AAAA و رکورد NS هستند. با ساخت یک دامنه، برای آن یک zone ساخته می‌شود که RRهای مرتبط با آن در فایلی با نام DNS zone file که یک فایل متنی ساده است، ذخیره می‌شوند. پس به‌شکل خلاصه، وظیفه‌ی DNS، نگهداری و فراهم کردن فایل DNS zone است.
آدرس‌های DNS از چند label ساخته می‌شوند که هر label مشخص‌کننده‌ی سلسله مراتبی است که به‌ترتیب باید به سراغ آن‌ها رفت. این labelها از راست به چپ بررسی می‌شوند. برای نمونه نشانی .www.example.com دارای چهار label است؛“www“ که در این سلسله مراتب leaf به‌شمار می‌آید،“example” که یک دامنه است،“com“ که یک TLD یا Top Level Domain است و درنهایت “.” که نشان‌دهنده‌ی Root Server است.
زمانی‌که در مرورگر خود نشانی www.example.com را وارد می‌کنید، در نخستین گام سیستم‌عامل Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر هیچ آدرس IP پیدا نکند،recursive query را به‌سمت Recursive Resolver ارسال می‌کند.
در DNS از دو نوع query استفاده می‌شود. Recursive و iterative. تفاوت این دو query عبارت است از:
یکrecursive query حتمن باید با ارسال یک response پاسخ داده شود.
iterative query نیازی به دریافت response ندارد.
ا Recursive resolver می‌تواند DNS سروری فراهم شده به‌وسیله‌ی ISP یا هر name server دیگری باشد که از سایر DNS سرورهایی که می‌توانند در رابطه با آدرس IP دامنه‌ی www.example.com پاسخ دهند، آگاهی دارد. Recursive Resolver با دریافت query از سمت مرورگر، ابتدا Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر آدرسی پیدا نکند، با بررسی labelهای دامنه‌ی www.example.com. از چپ به راست (نخستین برچسب . است) متوجه می‌شود که اولین مکانی که برای پیدا کردن آدرس IP مربوطه باید به سراغ آن برود Root Server است.
اکنون سیزده Root Server در سراسر دنیا وجود دارند که دربردارنده‌ی اطلاعات DNS مربوط به Top Level Domainها یا TLDها هستند. TLDها در واقع دامنه‌هایی مانند .com، .org و… هستند. پس Recursive Resolver با ارسال یک iterative query از Root Server در رابطه با TLD .com سوال می‌کند و Root Server نیز در پاسخ، برای آن آدرس IP مربوط به TLD .com را ارسال می‌کند.
در گام بعد Recursive Resolver یک iterative request برای TLD که آدرس IP آن را از Root Server دریافت کرده است، ارسال می‌کند و در رابطه با example.com می‌پرسد. TLDها، DNS serverهایی هستند که اطلاعات DNS مربوط به زیردامنه‌های خود را نگهداری می‌کنند (در اینجا TLD .com دارنده‌ی اطلاعات example.com است). TLD با دریافت درخواست، آدرس IP مربوط به example.com را برای Recursive Resolver ارسال می‌کند.
در مرحله‌ی بعد Recursive Resolver با ارسال یک iterative query برای example.com، آدرس IP متعلق به رکورد www.example.com را خواستار می‌شود. example.com نیز در پاسخ آدرس IP مربوط به رکورد www.example.com را برای Recursive Resolver ارسال می‌کند. درنهایت، Recursive Resolver که به آدرس IP مربوط به www.example.com دست یافته، آن را برای مرورگر ارسال می‌کند و صفحه‌ی مربوط به این دامنه در مرورگر (البته با چشم‌پوشی از چند مرحله‌ی دیگر که ارتباطی با DNS ندارند) باز می‌شود. تمام این اتفاقات در کمتر از چند ثانیه رخ می‌دهند.
تصویر زیر بیان‌گر مراحلی است که گفته شد.
تاریخچه DNS
زمانی‌که مفهوم اینترنت به گستردگی حال حاضر نبود، سیستم‌ها برای برقراری ارتباط با یک‌دیگر، از آدرس IP استفاده می‌کردند. با رشد اینترنت و افزایش تعداد دستگاه‌هایی که قادر به اتصال به اینترنت بودند، تصمیم بر آن شد که سیستم‌ها با نام، یک‌دیگر را فرابخوانند. به همین دلیل نیاز به مکانیزمی برای مشخص کردن آدرس IP متناظر با هر نام بود.
نخستین راه‌حلی که برای این مشکل مطرح شد، استفاده از فایلی با نام host بود. در این فایل آدرس IP متناظر با هر نام درج شده و به هر سیستمی که قصد ارتباط با سایر سیستم‌ها با نام را داشت، منتقل می‌شد. اما با گسترده‌تر شدن دنیای اینترنت و اضافه شدن میلیون‌ها دستگاه به این ساختار، در عمل استفاده از فایل host و انتقال آن به هر سیستم، کاری ناممکن بود. همین عامل سبب معرفی سرویسی با نام Domain Name Service (DNS) شد.
عملکرد DNS
در DNS، اطلاعات مربوط به یک دامنه و آدرس‌های IP مرتبط با آن به‌وسیله‌ی Resource Recordها مشخص می‌شوند که انواع مختلفی دارند و مشهورترین آن‌ها رکورد A، رکورد MX، رکورد AAAA و رکورد NS هستند. با ساخت یک دامنه، برای آن یک zone ساخته می‌شود که RRهای مرتبط با آن در فایلی با نام DNS zone file که یک فایل متنی ساده است، ذخیره می‌شوند. پس به‌شکل خلاصه، وظیفه‌ی DNS، نگهداری و فراهم کردن فایل DNS zone است.
آدرس‌های DNS از چند label ساخته می‌شوند که هر label مشخص‌کننده‌ی سلسله مراتبی است که به‌ترتیب باید به سراغ آن‌ها رفت. این labelها از راست به چپ بررسی می‌شوند. برای نمونه نشانی .www.example.com دارای چهار label است؛“www“ که در این سلسله مراتب leaf به‌شمار می‌آید،“example” که یک دامنه است،“com“ که یک TLD یا Top Level Domain است و درنهایت “.” که نشان‌دهنده‌ی Root Server است.
زمانی‌که در مرورگر خود نشانی www.example.com را وارد می‌کنید، در نخستین گام سیستم‌عامل Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر هیچ آدرس IP پیدا نکند،recursive query را به‌سمت Recursive Resolver ارسال می‌کند.
در DNS از دو نوع query استفاده می‌شود. Recursive و iterative. تفاوت این دو query عبارت است از:
یکrecursive query حتمن باید با ارسال یک response پاسخ داده شود.
iterative query نیازی به دریافت response ندارد.
ا Recursive resolver می‌تواند DNS سروری فراهم شده به‌وسیله‌ی ISP یا هر name server دیگری باشد که از سایر DNS سرورهایی که می‌توانند در رابطه با آدرس IP دامنه‌ی www.example.com پاسخ دهند، آگاهی دارد. Recursive Resolver با دریافت query از سمت مرورگر، ابتدا Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر آدرسی پیدا نکند، با بررسی labelهای دامنه‌ی www.example.com. از چپ به راست (نخستین برچسب . است) متوجه می‌شود که اولین مکانی که برای پیدا کردن آدرس IP مربوطه باید به سراغ آن برود Root Server است.
اکنون سیزده Root Server در سراسر دنیا وجود دارند که دربردارنده‌ی اطلاعات DNS مربوط به Top Level Domainها یا TLDها هستند. TLDها در واقع دامنه‌هایی مانند .com، .org و… هستند. پس Recursive Resolver با ارسال یک iterative query از Root Server در رابطه با TLD .com سوال می‌کند و Root Server نیز در پاسخ، برای آن آدرس IP مربوط به TLD .com را ارسال می‌کند.
در گام بعد Recursive Resolver یک iterative request برای TLD که آدرس IP آن را از Root Server دریافت کرده است، ارسال می‌کند و در رابطه با example.com می‌پرسد. TLDها، DNS serverهایی هستند که اطلاعات DNS مربوط به زیردامنه‌های خود را نگهداری می‌کنند (در اینجا TLD .com دارنده‌ی اطلاعات example.com است). TLD با دریافت درخواست، آدرس IP مربوط به example.com را برای Recursive Resolver ارسال می‌کند.
در مرحله‌ی بعد Recursive Resolver با ارسال یک iterative query برای example.com، آدرس IP متعلق به رکورد www.example.com را خواستار می‌شود. example.com نیز در پاسخ آدرس IP مربوط به رکورد www.example.com را برای Recursive Resolver ارسال می‌کند. درنهایت، Recursive Resolver که به آدرس IP مربوط به www.example.com دست یافته، آن را برای مرورگر ارسال می‌کند و صفحه‌ی مربوط به این دامنه در مرورگر (البته با چشم‌پوشی از چند مرحله‌ی دیگر که ارتباطی با DNS ندارند) باز می‌شود. تمام این اتفاقات در کمتر از چند ثانیه رخ می‌دهند.
تصویر زیر بیان‌گر مراحلی است که گفته شد.
حمله‌ی DNS Spoofing
در ابتدای معرفی DNS هیچ تصوری از ایجاد مشکلات امنیتی برای این سرویس محبوب نبود. البته این موضوع برای تمام سرویس‌ها و پروتکل‌هایی که در ابتدای دهه‌ی 1980 معرفی می‌شدند، صدق می‌کرد. همین موضوع سبب شد تا آسیب‌های امنیتی جدی برای DNS ایجاد شوند.
مسایل امنیتی DNS به‌طور کلی در دسته‌های زیر قرار می‌گیرند:
استفاده از reverse DNS برای جعل هویت کاربران
خطاهای نرم‌افزاری (مانند سرریز بافر و…)
رمزنگاری بد (مانند توالی‌های پیش‌بینی‌پذیر و…)
نشت اطلاعات (مانند داده‌های نامعتبر یا افشای محتویات Cache)
قرار دادن داده‌های نامناسب در Cache یا در اصطلاح Cache poisoning
نخستین مشکل امنیتی که در DNS کشف شد، Cache Poisoning بود که از آن با نام DNS Spoofing نیز یاد می‌شود. DNS Cache Poisoning زمانی اتفاق می‌افتد که سرور DNS پایین دست (Recursive Resolver)، داده‌ها یا IP نادرستی را ارسال کند. در این حمله مهاجم با در اصطلاح، سمی کردن Cache سرور DNS پایین‌دست، سبب می‌شود که این DNS سرور در مقابل درخواست‌هایی که دریافت می‌کند، پاسخ‌های اشتباه و مورد دل‌خواه مهاجم را ارسال کند.
برای درک بهتر این حمله، تصویر زیر را در نظر بگیرید. در این تصویر قالب قدیمی پیامی حاوی داده‌های DNS نشان داده شده که در آن، فیلدهای مهم مورد استفاده در حمله‌ی Cache poisoning با رنگ آبی کم رنگ متمایز شده‌اند.
در ابتدای معرفی DNS هیچ تصوری از ایجاد مشکلات امنیتی برای این سرویس محبوب نبود. البته این موضوع برای تمام سرویس‌ها و پروتکل‌هایی که در ابتدای دهه‌ی 1980 معرفی می‌شدند، صدق می‌کرد. همین موضوع سبب شد تا آسیب‌های امنیتی جدی برای DNS ایجاد شوند.
مسایل امنیتی DNS به‌طور کلی در دسته‌های زیر قرار می‌گیرند:
استفاده از reverse DNS برای جعل هویت کاربران
خطاهای نرم‌افزاری (مانند سرریز بافر و…)
رمزنگاری بد (مانند توالی‌های پیش‌بینی‌پذیر و…)
نشت اطلاعات (مانند داده‌های نامعتبر یا افشای محتویات Cache)
قرار دادن داده‌های نامناسب در Cache یا در اصطلاح Cache poisoning
نخستین مشکل امنیتی که در DNS کشف شد، Cache Poisoning بود که از آن با نام DNS Spoofing نیز یاد می‌شود. DNS Cache Poisoning زمانی اتفاق می‌افتد که سرور DNS پایین دست (Recursive Resolver)، داده‌ها یا IP نادرستی را ارسال کند. در این حمله مهاجم با در اصطلاح، سمی کردن Cache سرور DNS پایین‌دست، سبب می‌شود که این DNS سرور در مقابل درخواست‌هایی که دریافت می‌کند، پاسخ‌های اشتباه و مورد دل‌خواه مهاجم را ارسال کند.
برای درک بهتر این حمله، تصویر زیر را در نظر بگیرید. در این تصویر قالب قدیمی پیامی حاوی داده‌های DNS نشان داده شده که در آن، فیلدهای مهم مورد استفاده در حمله‌ی Cache poisoning با رنگ آبی کم رنگ متمایز شده‌اند.
پایه و اساس این حمله بر دو موضوع استوار بود؛ نخست آن که در آن زمان، سرورهای DNS برای هر Query که تولید می‌کردند در فیلد Query ID (QID) (یا Transaction ID که از آن برای ره‌گیری queryها و responseهای آن‌ها استفاده می‌شود) مقداری عددی قرار می‌دادند که به‌ازای هر پیام جدید، به این مقدار یک واحد اضافه می‌شد. به بیان دیگر، شماره QIDها یک رشته از اعداد متوالی بودند، پس با به‌دست آوردن یک QID ،QID پیام بعدی به‌راحتی حدس زده می‌شد.
مورد دوم آن‌که DNS از UDP استفاده می‌کرد. به‌همین دلیل، زمان ارسال یک Query روی یک پورت UDP، منتظر دریافت پاسخ مربوط به آن، از روی همان پورت می‌ماند و به‌محض دریافت نخستین پاسخ درست، پاسخ پذیرفته می‌شد و سایر پیام‌ها رد می‌شدند.
مهاجم ابتدا برای به‌دست آوردن QID و شماره پورت، یک Host (تصور کنید یک وب‌سایت جعلی) در DNS server متعلق به خود ایجاد و سپس به‌سمت Recursive Resolver، کوئری را برای دسترسی به این Host ارسال می‌کرد. چون در آن زمان سرورهای DNS، شماره پورتی تصادفی و خالی را در اختیار می‌گرفتند و برای تمام پیام‌های بعدی که قرار بر ارسال آن‌ها بود از همین شماره پورت به‌عنوان شماره پورت مبدا در هِدر پیام UDP استفاده می‌کردند، و از سوی دیگر چون شماره QIDها به‌شکل متوالی افزایش پیدا می‌کردند، مهاجم تنها با شنود ترافیک DNS جاری شده به‌سمت سرور خود می‌توانست به‌راحتی به این دو مورد دست پیدا کند.
مرحله‌ی بعد، سمی کردن رکورد مربوط به Host مورد حمله در DNS سرور Recursive Resolver بود. ابتدا مهاجم با ارسال Query، از Recursive Resolver آدرس IP مربوط به Host مورد نظر را پرس‌وجو می‌کرد. Recursive Resolver نیز برای پیدا کردن آدرس آن Host (البته اگر آن را در Cache خود ذخیره نداشت) به سراغ Root Server می‌رفت. همزمان با این که Recursive Resolver پیام Query را برای یافتن آدرس IP دامنه‌ی مورد نظر برای Root Server ارسال می‌کرد، مهاجم نیز شروع به ارسال پی‌درپی responseهایی با آدرس IP جعلی و QIDهایی در بازه‌ی QID به‌دست آورده، می‌کرد.
نخستین QID که با QID مربوط به Query ارسال شده مطابقت پیدا می‌کرد، Recursive Server همان را به‌عنوان پاسخ درست می‌پذیرفت و در Cache خود ذخیره می‌کرد و حتا اگر پس از آن سرور اصلی مربوط به آن Host نیز، پاسخ درست را ارسال می‌کرد، آن پاسخ دیگر پذیرفته نمی‌شد.
تصویر زیر بیان‌گر اتفاقاتی است که گفته شد.
مورد دوم آن‌که DNS از UDP استفاده می‌کرد. به‌همین دلیل، زمان ارسال یک Query روی یک پورت UDP، منتظر دریافت پاسخ مربوط به آن، از روی همان پورت می‌ماند و به‌محض دریافت نخستین پاسخ درست، پاسخ پذیرفته می‌شد و سایر پیام‌ها رد می‌شدند.
مهاجم ابتدا برای به‌دست آوردن QID و شماره پورت، یک Host (تصور کنید یک وب‌سایت جعلی) در DNS server متعلق به خود ایجاد و سپس به‌سمت Recursive Resolver، کوئری را برای دسترسی به این Host ارسال می‌کرد. چون در آن زمان سرورهای DNS، شماره پورتی تصادفی و خالی را در اختیار می‌گرفتند و برای تمام پیام‌های بعدی که قرار بر ارسال آن‌ها بود از همین شماره پورت به‌عنوان شماره پورت مبدا در هِدر پیام UDP استفاده می‌کردند، و از سوی دیگر چون شماره QIDها به‌شکل متوالی افزایش پیدا می‌کردند، مهاجم تنها با شنود ترافیک DNS جاری شده به‌سمت سرور خود می‌توانست به‌راحتی به این دو مورد دست پیدا کند.
مرحله‌ی بعد، سمی کردن رکورد مربوط به Host مورد حمله در DNS سرور Recursive Resolver بود. ابتدا مهاجم با ارسال Query، از Recursive Resolver آدرس IP مربوط به Host مورد نظر را پرس‌وجو می‌کرد. Recursive Resolver نیز برای پیدا کردن آدرس آن Host (البته اگر آن را در Cache خود ذخیره نداشت) به سراغ Root Server می‌رفت. همزمان با این که Recursive Resolver پیام Query را برای یافتن آدرس IP دامنه‌ی مورد نظر برای Root Server ارسال می‌کرد، مهاجم نیز شروع به ارسال پی‌درپی responseهایی با آدرس IP جعلی و QIDهایی در بازه‌ی QID به‌دست آورده، می‌کرد.
نخستین QID که با QID مربوط به Query ارسال شده مطابقت پیدا می‌کرد، Recursive Server همان را به‌عنوان پاسخ درست می‌پذیرفت و در Cache خود ذخیره می‌کرد و حتا اگر پس از آن سرور اصلی مربوط به آن Host نیز، پاسخ درست را ارسال می‌کرد، آن پاسخ دیگر پذیرفته نمی‌شد.
تصویر زیر بیان‌گر اتفاقاتی است که گفته شد.
شاید این حمله به گفتار ساده باشد اما در حقیقت دارای پیچیدگی‌های بسیاری است:
نخست آن که دامنه‌ی مورد حمله نباید در Cache سرور Recursive موجود باشد وگرنه آن‌چه در بالا توضیح داده شد، رخ نمی‌دهد و Recursive Resolver بی‌درنگ با دریافت Query از جانب سیستم مهاجم، آدرس IP که در Cache خود ذخیره دارد را برای آن ارسال می‌کند.
دوم آن که مهاجم باید توانایی حدس زدن QID را داشته باشد.
مورد سوم آن که، سیستم مهاجم باید سرعت عملی بیش‌تر از ارتباط میان Recursive Resolver و Root Server داشته باشد تا بتواند پاسخی با QID مورد انتظار در Recursive Resolver را سریع‌تر از Name Server اصلی ارسال کند.
این مشکل نخستین‌بار به‌وسیله‌ی Computer Science Research Group (CSRG) در دانشگاه Berkeley در سال 1989 کشف شد و از آن جایی دارای اهمیت بود که دو برنامه‌ی مشهور UNIX در آن زمان (rsh و rlogin) از DNS برای احراز هویت کاربرانی که قصد ریموت زدن به آن‌ها را داشتند، استفاده می‌کردند. این دو برنامه به آدرس IP نگاهی می‌انداختند و متناسب با آن، hostname را به‌دست می‌آوردند و بدون هیچ پرسش اضافه‌تری که آیا این کاربر معتبر است یا نه، آن را می‌پذیرفتند. پس یک مهاجم به‌راحتی می‌توانست با یک کاربر جعلی به این برنامه‌ها دسترسی پیدا کند. CSRG برای حل این مشکل، Query رکورد PTR علاوه‌بر رکورد A را پیشنهاد کرد. اما این روش نیز با DNS cache poisoning قابل دور زدن بود.
راه‌حل دیگر استفاده ازTransaction ID های تصادفی برای BIND بود. اما بیش‌تر راه‌حل‌های پیشنهادی برای امن‌سازی DNS چندان هم خوب به نظر نمی‌رسیدند و نیاز به یک روش بهتر، هم‌چنان احساس می‌شد. در سال 1997 نهاد IETF نخستین RFC (2065) را در رابطه با راه‌حلی بهتر برای امن‌سازی DNS ارایه کرد. این راه‌حل Domain Name System Security Extensions (DNSSEC) نام داشت اما جز برای محققانی که به‌خوبی بر مشکلات بسیار DNS آگاهی داشتند، مورد استقبال قرار نگرفت و بنا به هر دلیلی، جدی قلمداد نشد.
باگ Kaminsky
در سال 2008، محققی به نام Dan Kaminsky اعلام کرد که شیوه‌ی جدیدی از حملات Cache Poisoning را کشف کرده که بسیار بدتر از انواع قبلی است.
همان‌طور که در بخش قبل توضیح داده شد، در حمله‌ی Cache Poisoning مهاجم قادر بود تا با سمی کردن رکورد مربوط به Host مورد حمله در Cache مربوط به Recursive Server، کاری کند که درخواست کاربران برای دسترسی به آن Host، به‌سمت سرور جعلی او منتقل شوند. اما Kaminsky کشف کرد که مهاجم می‌تواند یک گام فراتر رود و به‌جای سمی کردن رکورد مربوط به یک Host، کاری کند که تمام درخواست‌هایی که مربوط به یک دامنه‌ی خاص هستند، سمی شوند. برای نمونه فرض کنید در تصویر بالا تمام درخواست‌هایی که مربوط به دامنه‌ی example.com هستند (example.com، example2.com و…) به‌سمت سرور جعلی مهاجم منتقل شوند.
در این حمله مهاجم به‌جای هدف قرار دادن رکورد A در پیام DNS، به سراغ Authority رکوردها می‌رود و این‌گونه ادعا می‌کند که name server مورد درخواست نیست اما از آن اطلاع دارد و می‌تواند پاسخ درخواست‌های مربوط به این name server را بدهد. به بیان بهتر خود را به‌عنوان یک Authoritative name server جا می‌زند. به این ترتیب هر درخواستی که به دست Recursive Resolver برسد که مربوط به دامنه‌ی هدف باشد، به‌سمت مهاجم ارسال می‌شود.
پیدا شدن این باگ جامعه‌ی اینترنت را مجاب به یافتن راهی برای حل این مشکل کرد. راه‌حل پیشنهادی، افزایش سایز QID از 16 بیت به 32 بیت، هم‌چنین استفاده از شماره پورت‌های تصادفی برای هر پیام DNS به‌جای یک پورت UDP یک‌سان برای همه‌ی پیام‌ها بود. این راه‌حل‌ها هر چند سبب سخت‌تر شدن کار مهاجمان برای انجام این حمله می‌شدند اما آن را به یک امر ناممکن مبدل نمی‌‌ساختند. پس باز هم نیاز به روشی برای امن‌تر کردن DNS هم‌چنان احساس می‌شد.
تمام این موارد سبب شدند تا ضرورت توسعه و استفاده از DNSSEC که پیش‌تر به‌وسیله‌ی IETF معرفی شده بود، بیش از پیش احساس شود.
نخست آن که دامنه‌ی مورد حمله نباید در Cache سرور Recursive موجود باشد وگرنه آن‌چه در بالا توضیح داده شد، رخ نمی‌دهد و Recursive Resolver بی‌درنگ با دریافت Query از جانب سیستم مهاجم، آدرس IP که در Cache خود ذخیره دارد را برای آن ارسال می‌کند.
دوم آن که مهاجم باید توانایی حدس زدن QID را داشته باشد.
مورد سوم آن که، سیستم مهاجم باید سرعت عملی بیش‌تر از ارتباط میان Recursive Resolver و Root Server داشته باشد تا بتواند پاسخی با QID مورد انتظار در Recursive Resolver را سریع‌تر از Name Server اصلی ارسال کند.
این مشکل نخستین‌بار به‌وسیله‌ی Computer Science Research Group (CSRG) در دانشگاه Berkeley در سال 1989 کشف شد و از آن جایی دارای اهمیت بود که دو برنامه‌ی مشهور UNIX در آن زمان (rsh و rlogin) از DNS برای احراز هویت کاربرانی که قصد ریموت زدن به آن‌ها را داشتند، استفاده می‌کردند. این دو برنامه به آدرس IP نگاهی می‌انداختند و متناسب با آن، hostname را به‌دست می‌آوردند و بدون هیچ پرسش اضافه‌تری که آیا این کاربر معتبر است یا نه، آن را می‌پذیرفتند. پس یک مهاجم به‌راحتی می‌توانست با یک کاربر جعلی به این برنامه‌ها دسترسی پیدا کند. CSRG برای حل این مشکل، Query رکورد PTR علاوه‌بر رکورد A را پیشنهاد کرد. اما این روش نیز با DNS cache poisoning قابل دور زدن بود.
راه‌حل دیگر استفاده ازTransaction ID های تصادفی برای BIND بود. اما بیش‌تر راه‌حل‌های پیشنهادی برای امن‌سازی DNS چندان هم خوب به نظر نمی‌رسیدند و نیاز به یک روش بهتر، هم‌چنان احساس می‌شد. در سال 1997 نهاد IETF نخستین RFC (2065) را در رابطه با راه‌حلی بهتر برای امن‌سازی DNS ارایه کرد. این راه‌حل Domain Name System Security Extensions (DNSSEC) نام داشت اما جز برای محققانی که به‌خوبی بر مشکلات بسیار DNS آگاهی داشتند، مورد استقبال قرار نگرفت و بنا به هر دلیلی، جدی قلمداد نشد.
باگ Kaminsky
در سال 2008، محققی به نام Dan Kaminsky اعلام کرد که شیوه‌ی جدیدی از حملات Cache Poisoning را کشف کرده که بسیار بدتر از انواع قبلی است.
همان‌طور که در بخش قبل توضیح داده شد، در حمله‌ی Cache Poisoning مهاجم قادر بود تا با سمی کردن رکورد مربوط به Host مورد حمله در Cache مربوط به Recursive Server، کاری کند که درخواست کاربران برای دسترسی به آن Host، به‌سمت سرور جعلی او منتقل شوند. اما Kaminsky کشف کرد که مهاجم می‌تواند یک گام فراتر رود و به‌جای سمی کردن رکورد مربوط به یک Host، کاری کند که تمام درخواست‌هایی که مربوط به یک دامنه‌ی خاص هستند، سمی شوند. برای نمونه فرض کنید در تصویر بالا تمام درخواست‌هایی که مربوط به دامنه‌ی example.com هستند (example.com، example2.com و…) به‌سمت سرور جعلی مهاجم منتقل شوند.
در این حمله مهاجم به‌جای هدف قرار دادن رکورد A در پیام DNS، به سراغ Authority رکوردها می‌رود و این‌گونه ادعا می‌کند که name server مورد درخواست نیست اما از آن اطلاع دارد و می‌تواند پاسخ درخواست‌های مربوط به این name server را بدهد. به بیان بهتر خود را به‌عنوان یک Authoritative name server جا می‌زند. به این ترتیب هر درخواستی که به دست Recursive Resolver برسد که مربوط به دامنه‌ی هدف باشد، به‌سمت مهاجم ارسال می‌شود.
پیدا شدن این باگ جامعه‌ی اینترنت را مجاب به یافتن راهی برای حل این مشکل کرد. راه‌حل پیشنهادی، افزایش سایز QID از 16 بیت به 32 بیت، هم‌چنین استفاده از شماره پورت‌های تصادفی برای هر پیام DNS به‌جای یک پورت UDP یک‌سان برای همه‌ی پیام‌ها بود. این راه‌حل‌ها هر چند سبب سخت‌تر شدن کار مهاجمان برای انجام این حمله می‌شدند اما آن را به یک امر ناممکن مبدل نمی‌‌ساختند. پس باز هم نیاز به روشی برای امن‌تر کردن DNS هم‌چنان احساس می‌شد.
تمام این موارد سبب شدند تا ضرورت توسعه و استفاده از DNSSEC که پیش‌تر به‌وسیله‌ی IETF معرفی شده بود، بیش از پیش احساس شود.
رییس کمیته پدافند غیرعامل وزارت فاوا:
مانور تست پایداری شبکه ملی اطلاعات برگزار شد
رییس کمیته پدافند غیرعامل وزارت ارتباطات از برگزاری مانور تست پایداری شبکه ملی اطلاعات همزمان با هفته پدافند غیرعامل در شرکت زیرساخت و لایه‌های مختلف خبر داد، اقدامی که به گفته او درصد آمادگی و قابل پیش‌بینی شدن حملات احتمالی را افزایش می‌دهد.
صادق بیک پور با اعلام اینکه اولویت اصلی پدافند غیرعامل در حوزه ارتباطات زیرساخت، توسعه زیرساخت‌ها با رویکرد ملی است، افزود: با توجه به وجود حملات احتمالی در بستر شبکه، این ضرورت احساس می‌شود که تست‌های پایداری شبکه برگزار شود...
#security @unixmens
مانور تست پایداری شبکه ملی اطلاعات برگزار شد
رییس کمیته پدافند غیرعامل وزارت ارتباطات از برگزاری مانور تست پایداری شبکه ملی اطلاعات همزمان با هفته پدافند غیرعامل در شرکت زیرساخت و لایه‌های مختلف خبر داد، اقدامی که به گفته او درصد آمادگی و قابل پیش‌بینی شدن حملات احتمالی را افزایش می‌دهد.
صادق بیک پور با اعلام اینکه اولویت اصلی پدافند غیرعامل در حوزه ارتباطات زیرساخت، توسعه زیرساخت‌ها با رویکرد ملی است، افزود: با توجه به وجود حملات احتمالی در بستر شبکه، این ضرورت احساس می‌شود که تست‌های پایداری شبکه برگزار شود...
#security @unixmens
📊کدام کشورها تا سال 2030، بیشترین تولید ناخالص داخلی را بدلیل تاثیر فناوری 5G در صنعت ساخت خود خواهند داشت؟
🇨🇳چین و 🇺🇸ایالات متحده آمریکا مجموعاً با سهم تقریبی 41 درصد ، بیشترین تولید ناخالص داخلی را خواهند داشت.
🔗منبع: نظرسنجی انجام شده توسط شرکت مشاوره و تحقیقاتی STL Partners از نمایندگان صنایع تولیدی و تلکام 104 کشور در سرتاسر جهان در سال 2019
🇨🇳چین و 🇺🇸ایالات متحده آمریکا مجموعاً با سهم تقریبی 41 درصد ، بیشترین تولید ناخالص داخلی را خواهند داشت.
🔗منبع: نظرسنجی انجام شده توسط شرکت مشاوره و تحقیقاتی STL Partners از نمایندگان صنایع تولیدی و تلکام 104 کشور در سرتاسر جهان در سال 2019
Forwarded from yashar esmaildokht 🐧
جلسه ۴۵۴ - با موضوع چرا پارتیشنینگ در mysql |mariadb - هم بصورت وبینار (آنلاین ) و فیزیکی . https://bit.ly/2CqJkLF
حال با کلودفلر ssl رایگان داشته باشید . Cloudflare, Google Chrome, and Firefox add HTTP/3 support.
zdnet.com/google-amp/article/cloudflare-google-chrome-and-firefox-add-http3-support
zdnet.com/google-amp/article/cloudflare-google-chrome-and-firefox-add-http3-support
yashar esmaildokht 🐧
جلسه ۴۵۴ - با موضوع چرا پارتیشنینگ در mysql |mariadb - هم بصورت وبینار (آنلاین ) و فیزیکی . https://bit.ly/2CqJkLF
امروزه هر کسی با سیستم مدیریت پایگاه داده (dbms) و مفاهیم پایگاه داده درگیر است . از سیستم اتوماسیون اداری گرفته تا وبلاگ و سیستم مهم و حیاتی در بیمارستان و ...
پس عملکرد و سرعت پایگاه داده بسیار حائز اهمیت است . (performance tuning ) .حال سوال این است چه راهکارهایی برای افزایش pt را دارا می باشیم . در اینجا بصورت کلی به بررسی این ساختار از محضر پارتیشنینگ خواهیم پرداخت .
نکته : این وبینار و جلسه برای عموم افراد مناسب میباشد . حتی اگر با مفاهیم پایگاه داده بصورت کامل آشنا نباشید .
حال پارتیشن بندی در پایگاه داده به چه معناست ؟
پس عملکرد و سرعت پایگاه داده بسیار حائز اهمیت است . (performance tuning ) .حال سوال این است چه راهکارهایی برای افزایش pt را دارا می باشیم . در اینجا بصورت کلی به بررسی این ساختار از محضر پارتیشنینگ خواهیم پرداخت .
نکته : این وبینار و جلسه برای عموم افراد مناسب میباشد . حتی اگر با مفاهیم پایگاه داده بصورت کامل آشنا نباشید .
حال پارتیشن بندی در پایگاه داده به چه معناست ؟
Academy and Foundation unixmens | Your skills, Your future
امروزه هر کسی با سیستم مدیریت پایگاه داده (dbms) و مفاهیم پایگاه داده درگیر است . از سیستم اتوماسیون اداری گرفته تا وبلاگ و سیستم مهم و حیاتی در بیمارستان و ... پس عملکرد و سرعت پایگاه داده بسیار حائز اهمیت است . (performance tuning ) .حال سوال این است…
نحوه مانت کردن به ceph
https://www.howtoforge.com/tutorial/how-to-mount-cephfs-on-centos-7/
#ceph #storage #sds @unixmens
https://www.howtoforge.com/tutorial/how-to-mount-cephfs-on-centos-7/
#ceph #storage #sds @unixmens
HowtoForge
How to Mount CephFS on CentOS 7
I will show you how to mount Ceph as a File System on CentOS 7 in this third part of the Ceph tutorial series. Ceph is an open source storage platform...
✅ #برترین_پیش_بینی_های_گارتنر از برترین فناوری های IT و چالش های پیش رو از سال 2020 به بعد در مهمترین گردهمایی_جهانی_سالانه_گارتنر در ماه اکتبر امسال در اورلاندو آمریکا با حضور بیش از بیست هزار مدیر ارشد IT – بخش اول
1️⃣افزایش 💥سه برابری💥 معلولان شاغل در حوزه های مختلف کاری به دلیل پیشرفت هوش مصنوعی(AI)، واقعیت افزوده (AR) ، واقعیت مجازی (VR) و سایر فناوری های های نوظهور و کاهش موانع فعالیت های کاری تا سال 2023
👇👇👇
👌در نتیجه این رویکرد، سازمانهایی که افراد دارای معلولیت را استخدام می کنند نه تنها حسن نیت خود را در جامعه گسترش می دهند ، بلکه نرخ افزایش 89 درصدی حفظ نیروی کار ، 72 درصدی بهره وری کارمندان و 29 درصدی افزایش سودآوری را تجربه خواهند کرد.
1️⃣افزایش 💥سه برابری💥 معلولان شاغل در حوزه های مختلف کاری به دلیل پیشرفت هوش مصنوعی(AI)، واقعیت افزوده (AR) ، واقعیت مجازی (VR) و سایر فناوری های های نوظهور و کاهش موانع فعالیت های کاری تا سال 2023
👇👇👇
👌در نتیجه این رویکرد، سازمانهایی که افراد دارای معلولیت را استخدام می کنند نه تنها حسن نیت خود را در جامعه گسترش می دهند ، بلکه نرخ افزایش 89 درصدی حفظ نیروی کار ، 72 درصدی بهره وری کارمندان و 29 درصدی افزایش سودآوری را تجربه خواهند کرد.
#برترین_پیش_بینی_های_گارتنر-بخش سوم
🔵تا سال 2023 ، 30 درصد سازمانهای IT ، سیاست های BYOD (استفاده از دیوایس های شخصی در محیط کار) خود را به منظور تقویت نیروی انسانی و افزایش بهره وری و ایمنی محیط کاری گسترش می دهند.
☑️این افزایش به دلیل پیشرفت در تکنولوژی گجت های پوشیدنی wearable (مانند ساعت های هوشمند، دستبندهای سلامتی و غیره) در اکثر صنایع از جمله صنایع خودرو ، نفت و گاز ، خرده فروشی و پزشکی مشهود خواهد بود.
🔵تا سال 2023 ، 30 درصد سازمانهای IT ، سیاست های BYOD (استفاده از دیوایس های شخصی در محیط کار) خود را به منظور تقویت نیروی انسانی و افزایش بهره وری و ایمنی محیط کاری گسترش می دهند.
☑️این افزایش به دلیل پیشرفت در تکنولوژی گجت های پوشیدنی wearable (مانند ساعت های هوشمند، دستبندهای سلامتی و غیره) در اکثر صنایع از جمله صنایع خودرو ، نفت و گاز ، خرده فروشی و پزشکی مشهود خواهد بود.
📸 درصد نفوذ اینترنت در مناطق مختلف جهان
🔹 ۴.۳۸۸ میلیارد نفرد در جهان از اینترنت استفاده می‌کنند (۵۷ درصد).
🔹آمریکای شمالی و اروپا با ۹۵ درصد بیشترین نفوذ اینترنت در جهان را دارند. در مقابل آفریقای مرکزی با ۱۲ درصد، کمترین نفوذ اینترنت را در بین مناطق جهان دارا میباشد.
🔹ضریب نفوذ اینترنت کشورمان با ۹۰ درصد، بالاتر از میانگین جهانی است. ➖➖➖➖➖
🌐 @unixmens
🔹 ۴.۳۸۸ میلیارد نفرد در جهان از اینترنت استفاده می‌کنند (۵۷ درصد).
🔹آمریکای شمالی و اروپا با ۹۵ درصد بیشترین نفوذ اینترنت در جهان را دارند. در مقابل آفریقای مرکزی با ۱۲ درصد، کمترین نفوذ اینترنت را در بین مناطق جهان دارا میباشد.
🔹ضریب نفوذ اینترنت کشورمان با ۹۰ درصد، بالاتر از میانگین جهانی است. ➖➖➖➖➖
🌐 @unixmens