مسابقه 1 – Static Routing

سلام.
تصمیم داریم هر از گاهی مسابقه‌ای برگزار کنیم و با طرح سوالات مفهومی (نه بر اساس سناریوی configuration یا تکنولوژی Vendor خاصی)، و به بهترین پاسخ‌ها جایزه‌ی ناقابلی تقدیم کنیم. سوالات هم مختلف خواهد بود، گاهی احتمالاً خیلی ساده اما پایه‌ای، گاهی هم ممکنه مربوط به مباحث پیشرفته و جدید، یا حتی از مطالب وبلاگ.
امیدواریم که با پیش‌بردن این وبلاگ و اینگونه موارد اندک قدمی در راستای تعالی شبکه‌ها! در کشور عزیزمان داشته باشیم.

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

و اما اولین مسابقه:

  1. آیا بهتر است روت Static به سمت next-hop نوشته شود و یا به سمت Interface؟ چرا؟
    عرف پیاده‌سازی Static Routing به سه صورت است:
    • استفاده از Interface خروجی: در این حالت، در پیاده‌سازی اغلب وندورها روتر فرض را بر Connected بودن مقصد گذاشته و  در جدول مسیریابی Route را با Administrative Distance صفر درج می‌کند که در Best Practice های امروز اتفاق جالبی نیست.
      مهم تر از همه، استفاده از پورت خروجی، باعث ARP lookup های متعدد شده و در لینک‌های Broadcast منجر به پخش شدن بیهوده‌ی ترافیک ARP می‌شود. فرض کنید برای یک subnet بزرگ مثل 10.0.0.0/8، که احتمالاً شامل host های متعددی خواهد بود، روتر برای هر host یک lookup کند، و یک entry در ARP Table اضافه کند؛ این امر نه تنها باعث استفاده غیربهینه از Memory شده، بلکه تاثیر بسازیی در افزایش CPU Utilization تجهیز خواهد داشت.
    • استفاده از next-hop: در این حالت نسبت به مورد قبل، صرفاً یک ARP Entry برای یک Subnet بزرگ ثبت می‌شود اما فرض کنیم که به دلیلی پورتی که next-hop توسط آن reachable بود down شود؛ در این حالت درصورت وجود یک route برای آن next-hop، روت از جدول مسیریابی حذف نمی‌شود چرا که روتر بصورت recursive عمل مسیریابی به مقصد اصلی را انجام می‌دهد (که معمولاً اینکار ناخواسته هست، چرا که در این شرایط احتمالاً استفاده از Dynamic Routing Protocol ها استفاده می‌شد).
      این امر حتی ممکن است برخلاف سیاست‌های امنیتی باشد چرا که مثلاً ممکن است در مسیر next-hop، یک IPS یا فایروال یا هر تجهیزی که در لایه‌ی Network Interface (لایه 2 OSI) عملی روی packet انجام می‌داده bypass شود. همچنین در چنین شرایطی، روتر می‌بایست دائماً برای پیدا کردن next-hop جدول مسیریابی را بررسی کند که امری ناخواسته است. (نکته: فرض کنید در شبکه‌ای که بدرستی طراحی نشده، next-hop پس از down شدن interface، در Routing Table بصورت recursive با یک route دیگر match شود و packet به جایی فرستاده شود، که نباید!)
    • ترکیبی از هر دو مورد: در این حالت حتی اگر interface مرتبط با next-hop به هردلیلی down شود و next-hop توسط یک مسیر دیگر بصورت recursive قابل دسترسی باشد، Route از Routing Table حذف می‌شود و هیچکدام از معایب روش‌های قبل رخ نمی‌دهد. ضمناً این نوع تنظیم، در پیاده‌سازی اغلب وندورها همچون مورد قبل دارای Administrative Distance یک خواهد بود. این مورد نکته‌ی اصلی سوال و جواب مدنظر ما بود که کمتر به آن اشاره شد.
  2. فرض کنید در شبکه‌ی زیر، روی روتر R0 قصد دارید یک Static Route برای 10.0.0.0/8 تنظیم کنید. بهینه‌ترین حالت تنظیم این روت چگونه خواهد بود؟

در این سوال با توجه به ترسیم ساختار بصورت point-to-point، حتی با اینکه پورت xe یعنی 10GigabitEthernet، اما استفاده از هر سه حالت از لحاظ عملکرد و بار روی تجهیز تفاوتی ایجاد نخواهد کرد (بجز یک ARP Entry درصورت استفاده از interface که در دنیای امروز قابل چشم‌پوشی است)؛ اما شاید از دیدگاه نگهداری و مدیریت configuration، استثنائاً در این حالت استفاده از Next-hop به تنهایی بهتر باشد؛ شاید در شرایطی Network Engineer مسئول این شبکه، مجبور شد پورت تجهیز را تعویض کند، و لذا با توجه به استفاده از Next-hop، نیازی به پاک کردن و تنظیم روت جدید نخواهد بود. البته هر سه پاسخ قابل قبول است.
برخی دوستان اشاره کرده بودند که استفاده از /31 اشتباه است چرا که در این حالت Net ID و Broadcast Address درنظر گرفته نشده است. این تصور متاسفانه اشتباه هست. اینجا یک مطلب خوب در اینباره نوشته شده است. کلاً استفاده از /31 در این شکل هیچ دلیل خاصی نداشت و صرفاً جهت آشنایی و شاید اضافه کردن نمک به سوال بود 🙂

لطفاً پاسخ خود به هردو سوال را بعنوان نظر درج کنید. نظرات بمدت 48 ساعت از زمان انتشار مطلب منتشر نخواهند شد.
به اولین پاسخ کامل جایزه‌ی ناقابلی تعلق خواهد گرفت.

بروزرسانی 30 آبان

فکر می‌کنم شروع خوبی داشتیم و استقبال مناسبی شد، برای همین اول از همه از 34 عزیزی که در مسابقه شرکت کردند تشکر می‌کنیم.
برخی از پاسخ‌ها طولانی و حقیقتاً فاصله‌دار از جوابی بود که مدنظر ما بود. برخی از پاسخ‌ها نیز کلاً در رابطه با Static Routing و موارد دیگر توضیح داده اند اما به نکات اصلی سوال و یا جواب سوال دوم اشاره‌ای نشده بود.
پاسخ سوال همراه با توضیحات مناسب با رنگ سبز زیر هر سوال درج شده اند.

سه پاسخ نزدیک بهم و تقریباً درست دریافت کردیم، که باعث سخت شدن انتخاب بود، اما نهایتاً این پاسخ از آقای Mahmood Sebtonabi صحیح‌تر از دیگران بود و ایشون برنده‌ی اولین مسابقه‌ی شبکه‌ها هستن که با ایشون توسط ایمیل مکاتبه می‌کنیم.

بروزرسانی 16 آذر

در تصویر زیر آقای محمود سبط النبی برنده این مسابقه رو در کنار یادگاریِ خیلی خیلی ناقابل مسابقه می‌بینین.

ضمناً برای مطلع شدن از مسابقات بعدی فراموش نکنین که عضو خبرنامه وبلاگ و کانال تلگرام شبکه‌ها! بشین 🙂

خواندنی: پروتکل‌های جدید باید IPv6 محور باشند

روز به روز تاکید بر مهاجرت به IPv6 داره بیشتر میشه؛ طبق آمار گوگل حدود ۱۴.۶ درصد ترافیک جستجوها تحت IPv6 هست.

گروه IAB هم IETF رو ملزوم کرده که در طراحی پروتکل های جدید وابستگی به IPv4 زیاد مدنظر نباشه و تمرکز بر طراحی حول محور IPv6 باشه.

IAB Statement on IPv6

IPv4 is OVER. Really. So quit relying on it in new protocols, sheesh

خلاصه ای کوتاه درباره‌ی حملات DDoS در چندین ماه اخیر

حتماً در جریان هستین که طی ماه های اخیر حملات DDoS نه تنها قوی تر و طولانی تر، بلکه هوشمندتر شدن. یکی از بدترین انواع اون تقریباً زمانی بود که زیرساخت DNS شرکت Dyn رو تحت تاثیر قرار داد.
البته عمده ی این قطعی ها صرفاً در شمال آمریکا حس میشد چون شرکت Dyn در اقصی نقاط دنیا DNS Server داره و خب جوری طراحی شده که مثلا کاربران آسیا از نزدیک ترین DNS Server جواب میگیرن (Anycast).

میدونیم که DNS مثه دفترچه تلفن اینترنت هست و با توجه به اینکه Dyn یکی از بزرگترین DNS Provider ها هست، خیلی از وبسایت های مهم دنیا هم طی این حملات از دسترس خارج شدن.
نکته ی خیلی بد درمورد این وبسایت ها این بود که فقط از یک DNS Provider استفاده می کردن که به نوعی SPoF محسوب میشه. البته عدم استفاده از چند DNS Provider هم دلایل خاص خودش رو داره که مهمترینش بنظرم سخت شدن نگهداری و مدیرت هست چون باید همیشه مطمئن باشید که هردو Provider رکوردهای یکسان دارند. و خب چه بسی با پیشرفته تر شدن حملات، همزمان چند DNS Provider تحت حمله قرار بگیرن.

نکته‌ی جالب در رابطه با این حمله استفاده از “چیزهای متصل به اینترنت” بود (Internet of Things). شخصاً همیشه از Internet of Things ترس داشتم و هیچوقت بهش مطمئن نبودم و اینبار خودش رو نشون داد. نمیدونم، اما امیدوارم یک روز این اتفاقات جنبه‌ی خطرات انسانی پیدا نکنه. فکر میکنم بهتره اگر خودمون از اینگونه اشیاء استفاده میکنم سعی کنیم از امنیتشون مطمئن بشیم و اگر در توسعه و تولید این اشیاء نقش داریم روی مباحث امنیتیشون بیشتر و دقیق تر کار کنیم.

یک موضوع مرتبط با این قضیه هم قراری هست تحت عنوان MANRS که مخفف Mutually Agreed Norms for Routing Security هست. هدف MANRS این هست که پروایدر در کنار هم روی یکسری مکانیزم های امنیتی در روتینگ تفاهم داشته باشن. پیشنهاد میکنم حتماً در اینباره مطالعه کنین.

پیچیدگی در امنیت شبکه

بحث پیچیدگی کلاً جالبه علی‌الخصوص در شبکه؛ تاجایی که خوندم و شنیدم اولین بار بحث Complexity رو آقای David Mayer مطرح کرد و حتی برای این موضوع در IRTF هم یک Working-group بنام Network Complexity Research Group درنظر گرفته شد. امیدوارم به مرور بتونم بیشتر راجبش بخونم، بهفمم و بیشتر بنویسم.
اولین مطلب در این بحث رو با امنیت شبکه و کارهایی که میکنیم تا جلوی مخاطرات امنیتی رو بگیریم شروع میکنم.

روز به روز ابزارهای جدید امنیتی تولید می‌شن و با کلی تبلیغات و به‌به و چه‌چه روونه‌ی بازار. و از دست بد روزگار گاهی بدون برنامه و با توهم اشتباه اینکه این ابزار مشکلات امنیتی‌مون رو حل می‌کنه، سریع میایم قوی‌ترین فایروال‌ها و آنتی،ویروس‌ها و … خرید میکنیم و یکجوری می‌گنجونیم توی شبکه. حالا هزینه‌های فجیعی که در خرید و نصب و راه‌اندازی میشه که هیچ… از برگزاری منافصه گرفته تا هزینه‌ی مشاور و ناظر و خرید و اجرا و نگهداری و … نمیدونم، گاهی فکر میکنم شاید این بحث‌های صرفه‌جوئی در هزینه و کاهش هزینه‌ها و … فقط حرف هست علی‌الخصوص در سازمان‌ها و شرکت‌های بزرگ، بالاخره بودجه‌اش یجوری میرسه یا یکی میرسونه یا یکی میخواد و میرسونَدِش 🙂

اما ای دریغ که بزرگترین مشکلات امنیتی انقدر بزرگ هستند که دیده نمیشن! و حتی گاهی همون پیچیدگی‌ها به ندیدنشون دامن می‌زنه.

یکی از اولین قدم‌های امنیت اطلاعات، فرهنگ‌سازی در سازمانه؛ در معماری کلان فناوری اطلاعات یک سازمان حتماً باید آموزش‌هایی ساده جهت آشنایی و روش‌های جلوگیری از درز اطلاعات برای کاربران خیلی معمول درنظر گرفته بشه.  مثل اینکه اطلاعات سازمانی رو روی نرم‌افزارهای چت نباید رد و بدل کرد، نباید روی سرویس‌های ثالث مثل Google Drive و Dropbox و … گذاشت و ازین قبیل موارد.

قطعاً در کنار این موارد هم باید یکسری سیاست‌های امنیتی و بقولی Enforcement وجود داشته باشه؛ مثلاْ محدود کردن پورت‌های USB، اجبار استفاده از رمز مناسب، محدود کردن دسترسی به اینترنت برای کاربران و سرورها، گذردادن ترافیک اینترنت از یک پروکسی و …

راهکارهای سخت‌افزاری و نرم‌افزاری امنیتی جزو ملزومات هستن اما باید مراقب بود که طراحی پیچیده نشه؛ جوری نباشه که اگه ساعت ۲ شب با مهندس شیفت تماس گرفته شد سرش رو بکوبونه به میز و نتونه بفهمه مشکل کجاس.
مثلا یک اتفاقی که خیلی جدیداً شنیده میشه اینه که کلاً بیایم و ترافیک مدیریتی شبکه، ترافیک دیتای داخلی، ترافیک اینترنت و .. رو بطور فیزیکی از هم جدا کنیم. متاسفانه خودم هم دوبار همچین طرحی رو مجبور شدم که بنویسم… خب این کار در کنار هزینه‌های سرسام‌آوری که داره، پیچیدگی‌های خاص خودش رو هم خواهد داشت؛ قبلاً شما داشتین فقط یک شبکه رو نگهداری می‌کردین اما حالا چند شبکه! قبول دارم که بعضی سناریوهای خاص لازمه اما نه اینکه همه‌گیر بشه این کار.
در عمده‌ی شبکه‌های بسیار گسترده، تمام این ترافیک‌ها روی یک بستر فیزیکی هستن اما خب طبعاً با استفاده از راه‌کاری‌های مختلف امنیتی که گاهش شامل مجازی‌سازی هم میشه مثل درنظرگرفتن VLAN مجزا (بله VLAN هم نوعی راه‌کار مجازی‌سازی محسوب میشه) یا VRF مجزا (بحث مجازی‌سازی شبکه هم بسیار شیرین هست و سر فرصت خودش انشاالله راجبش می‌نویسم)

احتمالاً همچین اتفاقی رو خیلیا شاهدش بودن:

هیچوقت یادم نمیره زمانی که وارد بازار کار شدم و در اولین کارم بعنوان یک ادمین مشغول شده بودم، تصمیم گرفتیم که سیاست‌های رمزگذاری در شبکه تعیین کنیم (Password Policy). بعد از کلی مشقات تاییدیه گرفتیم و اجرا شد.
یک روز رفته بودم واحد حسابداری برای فیش حقوقی ام که دیدم یکی از کارمندای حسابداری نام کاربری و رمز ورودش به سیستم حسابداری رو روی برگه نوشته و به خیال خودش کلی امنیت به خرج داده بود و چسبونده بود زیر کیبورد!

می‌بینین؟ فرهنگ‌سازی!

چندسال قبل یک شرکت امنیتی بنام AlgoSec از متخصصان امنیت شبکه نظرخواهی کرده بود و یکی از نتایج جالب اون این بود که بیش از نصف این متخصصین اظهار داشتن پیچیدگی‌های امنیتی و تعدد Security Policy ها بالاخره یک موقعی منجر به درز اطلاعات یا قطعی سرویس شده بوده! حالا بیایم و چندتا فایروال بگذاریم پشت سرِ هم 🙂
نمیخوام وارد بحث معماری و طراحی شبکه و امنیت شبکه بشم اما صرفا در رابطه با همین مورد چند فایروال از شرکت های مختلف: برای یه شبکه معمول، خیلی ساده میشه پیشنهاد کرد که در لایه‌ی ارتباط با اینترنت از یک Firewall (چشم، دیواره‌ی آتش) و یک IPS (سیستم پیشگیری از نفوذ) استفاده کرد که خیلی rule های کلی داشته باشند و از وندور A باشن؛ و حالا در لایه‌های درونی‌تر (برای شبکه‌های بزرگ تر با block های مختلف) از فایروال‌های وندور B با رول‌های خاص و بقولی specific استفاده بشه.

فراموش نکنیم که یک شبکه باید مستندسازی بشه، و پر واضحه که مستندسازی یک شبکه با سیاست‌های امنیتی پیچیده چقدر سخت خواهد بود. اگر میخواین Complexity رو از امنیت شبکه اتون دور کنین، بعد از اینکه این مطلب رو خوندین (و اگر دوس داشتین نظرتون رو گفتین و عضو خبرنامه شدین 🙂 ) برین سراغ مستندسازی شبکه. انشاالله که وجود داره اما اگر نیست، بوجود بیارین.

نه تنها همین مستندسازی باید بروزرسانی بشه، بلکه سیستم‌ها هم باید پس از طی شدن روند حصول اطمینان از پایداری نسخه‌ی جدید، بروزرسانی بشن. کم نبوده نشت اطلاعاتی که بخاطر عدم بروزرسانی یک سیستم‌عامل یا نرم‌افزار رخ داده.

بنظرم پیچیدگی بدترین دشمن امنیت اطلاعات هست! من معتقدم هر چیزی در زندگی باید به اندازه باشه؛ شبکه و امنیت شبکه هم اگر زندگیِ ما نباشه، فارغ از اون نیست.
من بشدت علاقمند به RFC1925 هستم؛ این RFC به زبون ساده 12 حقیقت/قانونِ دنیایِ شبکه رو مطرح می‌کنه و آخرین قانونِ اون خیلی نزدیک به این بحث هست:

وقتی دیگه ویژگی‌ای برای “اضافه کردن” باقی نمونده، به این معنی نیست که طراحی [پروتکل] به کمال رسیده؛ بلکه زمانی که دیگه چیزی برای کم‌کردن نیست به نقطه‌ی کامل‌بودن نزدیک شده.

حرف زیاد است و مجال کم. لطفاً نظرتون رو بگین و تجربیاتتون درباره‌ی پیچیدگی‌های امنیتی بنویسین.

ضمناً به نصیحت برخی دوستان پیرو همه‌گیر شدن تلگرام در ایران، کانالی برای وبلاگ ایجاد کردم که با عضو شدن میتونین براحتی از مطالب جدید مطلع بشین. ID کانال networkz هست؛ میتونین براحتی با کلیک کردن در اینجا کانال رو ببنین.

چی بخونم که بازارش خوب باشه؟

سلام! به کرّات از من این سوال پرسیده میشه که “چی بخونم؟” “چی یاد بگیرم؟” “کلاسِ چی برم؟” “بازار کارِ چه تخصصی خوبه؟” و من همیشه یک پاسخ میدم: “چیزی رو بخونین که بهش علاقه دارین“.
مطلب امروز صرفاً دیدگاه شخصی من در پاسخ به این سوال هست و سعی میکنم با توجه به حوزه‌ی کاری خودم در زمینه شبکه و امنیت، توضیحات مختصری هم در این رابطه ارائه کنم.
ضمناً روی صحبتم با افرادی هست که قصد متخصص شدن و پیشرفت دارند و نه یک کار روتین، چون بنظرم کار روتین تخصص لازم نداره. هیچ اشکالی هم نداره، هرکسی یک سبک زندگی رو دوست داره و این انتخاب کاملاً شخصی هست.

قبل از شروع بحث اصلی یکسری توضیحات در رابطه با وبلاگ و پاره‌ای از تغییرات عرض کنم:

  • هفته‌ی پیش یکی از بدترین اتفاقاتی که ممکنه برای دیتابیس MySQL بیافته برای وبلاگهای من افتاد و باعث شد مدتی خارج از سرویس باشن. به هرحال این مورد حل شد و تمامی Table ها مجدداً ریکاوری شدن بجز اون اطلاعاتی که مربوط به عزیزانی بود که عضو خبرنامه وبلاگ شدن. برای همین درصورت علاقه با استفاده از همین جعبه‌ی کوچولوی کنار صفحه، قسمت اطلاع رسانی، عضو خبرنامه وبلاگ بشین 🙂
  • همینطور که میبینین وبلاگ تغییرات ظاهری زیادی کرده؛ بررسی‌هایی کردم و به این نتیجه رسیدم که تا امکان داره وبلاگ رو سبک کنم و SEO / Google friendly.
  • به نصیحت برخی دوستان پیرو همه‌گیر شدن تلگرام در ایران، کانالی برای وبلاگ ایجاد کردم که با عضو شدن میتونین براحتی از مطالب جدید مطلع بشین. ID کانال networkz هست؛ میتونین براحتی با کلیک کردن در اینجا کانال رو ببنین.
چی بخونم که بازارش خوب باشه؟

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

بازار کار هم خودِش میاد؛ خودش هم نیاد شما میری بسمتش! اگر واقعاً به تسلط کافی در رشته‌ای برسیم و واقعاً حرفی برای گفتن داشته باشیم همیشه برای اون رشته بازار کار هست. اگر بازار کار کم باشه با سختی بیشتر شاید خودمون بتونیم با خلاقیت براش بازار کار درست کنیم. نکته‌ی خیلی تأثیرگذار در این زمینه خودشناسی هست و اینکه بتونیم خودمون و تخصصمون رو خوب پرزنت کنیم.

البته و صد البته که باید اینجا واقع بینی داشت و یک بررسی کوچولو (پارادوکس) کرد که در محیطی که قصد داریم نوآوری کنیم یا یک رشته ی خاص رو دنبال کنیم، تقاضای عمومی براش هست اصلا؟ آیا فرهنگ اون جامعه علاقه ای ممکنه به اون تکنولوژی یا مفاهیم اون رشته داشته باشه؟ اگه اینجوری نیس فکر میکنم بهتره راهی براش پیدا کنیم و یا اون مفهوم رو بومی سازی کنیم یا بدنبال نمونه ی مشابه و نزدیکی بگردیم که امکان جذب رو داشته باشه. البته بُعد زمان رو از یاد نبریم. نه ما باید زمان رو از دست بدیم نه این رو فراموش کنیم در طول زمان ممکنه یک فرهنگ جا بیافته. بنظرم تصمیم‌گیری در همچین شرایطی ارتباط مستقیم با علاقه و اهمیت شخصی ما به اون مفهوم و شرایط شخصی زندگی مونه داره. مهم اینه که زمان طلاس و وقتی می بینیم امکان بهبود و جاانداختن یک مفهوم نیست، وقت گذر هست. ادامه خواندن “چی بخونم که بازارش خوب باشه؟”