لینوکس : دستوراتی که هر مدیر شبکه ای باید آن ها را بداند!

به عنوان یک مدیر شبکه آشنایی با دستورات لینوکس ، حتی الامکان در حد دستورات پایه، امری ضروری محسوب می شود. به همین دلیل سعی گردید تا دستورات مهمی که یک ادمین شبکه برای کار با سیستم عامل های Debian Base باید با آن ها آشنایی داشته باشد، در قالب فایلی آماده و ارائه گردد. تصویر زیر صفحه ای از صفحات این فایل است که نسخه ی کامل آن را می توانید از طریق این لینک دریافت نمایید. ادامه خواندن “لینوکس : دستوراتی که هر مدیر شبکه ای باید آن ها را بداند!”

DNSSEC حقیقتی فراموش شده (قسمت دوم: عملکرد)

در مقاله ی قبل در رابطه با عملکرد DNS، تهدیدات و مشکلاتی که بر سر راه آن وجود داشت، به طور مفصل بحث گردید. در انتها آن چه راه نجات DNS برای در امان ماندن از تهدیدات امنیتی معرفی شد، پروتکلی با نام DNSSEC بود.

قبل از پرداختن به مفاهیم و اصطلاحات DNSSEC، شاید بد نباشد که ابتدا مروری بر مفاهیم Cryptography (رمزنگاری) داشته باشیم.

رمزنگاری (Cryptography):

Cryptography روشی برای رمزگذاری یا تولید hash برای محتویات است. با استفاده از رمزنگاری می توان امنیت و/یا قابل تایید و تصدیق بودن را برای اطلاعاتی که میخواهیم، فراهم آوریم. گاهی اوقات هدف از رمزنگاری تنها مخفی کردن محتویات پیام ها نیست. به عنوان مثال در DNSSEC هدف از رمزنگاری، تایید و تصدیق اطلاعات می باشد.

روش های مختلفی برای رمزنگاری وجود دارد که متداولترین این روش ها، رمزنگاری کلید عمومی یا Public Key Cryptography می باشد. با استفاده از این روش هم امنیت و هم تصدیق اعتبار را می توان از طریق encryption، signature و یا هردو، فراهم آورد.

برای encryption معمولا از یک جفت کلید که یکی اصطلاحا private و دیگری public خطاب می شود، استفاده می گردد. اطلاعاتی که توسط یک کلید encrypt شوند، تنها توسط جفت کلید دیگر قابل decrypt شدن هستند. به عبارت بهتر اگر اطلاعاتی توسط private key رمزگذاری شده باشند، تنها توسط public key قابل دست یابی خواهند بود و بالعکس.

منظور از signature تولید یک امضای دیجیتال با استفاده از مقدار hash به دست آمده از تابع hash ای است که اطلاعات به آن داده شده، به علاوه ی Private key (یا public key) می باشد. نحوه ی اعتبارسنجی یک امضای دیجیتال به این طریق است که: بعد از دریافت یک پیام (یا هرنوع داده ای) به همراه امضای دیجیتال، ابتدا امضا decrypt می گردد (از طریق public key). پس از decrypt امضا، آنچه به دست می آید یک مقدار hash است. گیرنده، پیام دریافت کرده را به یک تابع hash میدهد تا یک مقدار hash به دست آید. اگر مقدار hash به دست آمده توسط تابع hash در سمت گیرنده با مقدار hash دریافت شده (مقدار hash ای که پس از decrypt امضا به دست آمده)، یکسان باشد به این معنی است که داده ها درست بوده و تایید اعتبار می شوند.

DNSSEC: اصطلاحات و مفاهیم پایه

DNSSEC با افزودن یک امضای دیجیتال به رکوردهای DNS موجود، یک دامنه ی نام امن ایجاد می کند. این امضاهای دیجیتال یا اصطلاحا digital signature ها همانند سایر رکورد type های رایج چون: A یا AAAA یا CNAME، در سرورهای DNS ذخیره می شوند. با بررسی امضای اختصاص یافته به یک رکورد می توان مطمئن شد که رکورد DNS دریافت شده، از جانب یک DNS سرور مجاز است و یا رکوردی جعلی است که از طریق حمله ی man-in-the-middle تزریق شده است. ادامه خواندن “DNSSEC حقیقتی فراموش شده (قسمت دوم: عملکرد)”

مکانیزم های مهاجرت به IPv6: راهکار ۴۶۴XLAT

با استفاده از راهکار NAT64 دستگاه‌های موبایل IPv6-only توانایی برقراری ارتباط با سرورهای IPv4-only را داشتند. اما NAT64 به تنهایی جوابگوی نیازهای شبکه های موبایل نبود چرا که اکثر نرم‌افزارهای موبایل هم چنان بر مبنای IPv4 می باشند. به همین دلیل راهکار دیگری با نام ۴۶۴XLAT معرفی گردید.

با استفاده از این مکانیزم آدرس IPv4 آن دسته از کاربران (بیشتر موبایل و نرم‌افزارهای موبایلی) که IPv6 را پشتیبانی نمی کنند، توسط نرم‌افزاری با نام Customer-side Translator یا به اختصار CLAT، به یک آدرس IPv6 با mask ای خاص، /۹۶، ترجمه شده و پکت از طریق ساختار IPv6 به سمت PLAT یا Provider-site Translator ارسال می شود.

PLAT با گشودن پکت IPv6 به آدرس های Private IPv4 مبدا و مقصد داخل پکت دست یافته و پکت را به مقصد مورد نظر ارسال می کند. به عبارتی در این روش کلاینت و سرور فقط از طریق Private IPv4 خود در بستری مبتنی بر IPv6 می توانند با یکدیگر ارتباط برقرار نمایند.

روش ۴۶۴XLAT تنها از مدل های کلاینت-سروری پشتیبانی می کند و نمی‌توان از طریق آن یک ارتباط peer-to-peer بر اساس IPv4 Private را برقرار ساخت. ویدیوی زیر از RIPE NCC به تشریح عملکرد این مکانیزم می پردازد (به جهت سهولت دسترسی هم وطنان داخل کشور، این ویدیو در آپارات آپلود شده است).

ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار ۴۶۴XLAT”

مکانیزم های مهاجرت به IPv6: راهکار NAT64

یکی از مشکلات بر سر راه Mobile Provider ها فراهم کردن شرایطی است که هاست های IPv6-only بتوانند با سرورهای IPv4-only ارتباط برقرار نمایند. NAT64 مکانیزمی است بر پایه ی Network Address Translation (NAT) که با نگاشت آدرس IPv6 هاست متصل به پروایدر به یک آدرس IPv4، این مشکل را برطرف می سازد. ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار NAT64”

تغییر رفتار پیش‌فرض eBGP با RFC8212

پیرو Route Leakage‌های مختلفی که در دنیای اینترنت رخ داده‌است، و همینطور نیاز مبرم Service Providerها، از اواسط سال ۲۰۱۵، در IETF گروه GROW بحثی شروع شد مبنی بر طراحی یک رفتار پیش‌فرض BGP در رابطه با تبادل روت‌ها با همسایگان خارجی (eBGP).
همانطور که می‌دانید در RFCهای مرتبط با BGP، علی‌الخصوص RFC4271، تابحال توضیحی در رابطه با رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها زمانی که Policy خاصی اعمال نشده، ارائه نشده است، و این امر باعث شده که هر وِندوری رفتار سلیقه‌ای داشته باشد.

فارغ از جزئیات، بعنوان نمونه می‌توان به مدل‌های پیاده‌سازی زیر اشاره کرد:

  • بطور پیش‌فرض دو همسایه eBGP، زمانی که Policy خاصی روی ارتباطات eBGP تنظیم نشده باشد، روت‌های انتخاب‌شده در BGP Table خود را به یکدیگر ارسال می‌کنند و از یکدیگر قبول می‌کنند.
  • هیچ روتی ارسال نمی‌شود و هیچ روتی قبول نمی‌شود (discard) مگر اینکه Policy متناسبی تنظیم شده باشد.
  • برخی پیاده‌سازی‌ها هیچ روتی قبول نمی‌کنند و فقط روت‌های مربوط به AS خود را advertise می‌کنند.

مثلاً در حالت مثال اول، یکی از مخاطرات ممکن زمانی است که یک AS ناخواسته ترانزیت ارتباط بین ASهای دیگر می‌شود (در RFC7908 توضیح خوبی درباره‌ی Lateral ISP-ISP-ISP Leak همراه با دو بررسی دقیق در قسمت منابع، ارائه شده) ادامه خواندن “تغییر رفتار پیش‌فرض eBGP با RFC8212”