درباره ی فناوری اطلاعات، شبکه، امنیت شبکه و سه نقطه!
روز اول سال جدید رو با دونستن تعداد IPv6 شروع کنیم 😬
میدونین در بدن انسان در حالت معمول چند اتم وجود داره؟ حتماً می‌پرسین خب چه ربطی داره به شبکه؛ حق دارین.
در بدن انسان 27^10 * 7 (7,000,000,000,000,000,000,000,000,000) اتم وجود داره.
اگر به هر اتم موجود در بدن تمام انسان ها!! یک آدرس IPv6 داده بشه، بازهم معادل 3e+38 آدرس باقی می مونه 😁
زمانی که عنوان این مطلب را می‌نوشتم، برای خودم نیز خیلی سخت بود اما حس کردم این عنوان عجیب شاید بیشتر در ذهن بماند. امیدوارم در انتهای مطلب شاید کمی تعریف آن مشخص شود.
اگر دو روتر BGP مستقیما بطور فیزیکی متصل باشند و یا از مکانیزم‌های Fault-detection مانند BFD استفاده کنند، زمانی که یک peer از دسترس خارج شود، این قطعی بلافاصله به Control Plane اطلاع داده شده و همسایگی BGP قطع می‌شود و نهایتاً مسیرهایی که روتر همسایه مسئول آن‌ها بوده تغییر می‌کنند.
اما فرض کنید که BGP Speaker ها در یک بستر لایه 2 مانند یک IXP به یکدیگر متصل هستند و به دلایلی استفاده از مکانیزمی مانند BFD وجود ندارد.
در محیط های IXP به تعدد پیش می‌آید که یکی از اعضا قصد تغییر تجهیز، بروزرسانی نرم‌افزار روتر خود، تغییر پورت یک peering و … را داشته باشد. در چنین شرایطی، همسایگان این روتر از این قطعی بلافاصله مطلع نمی‌شوند و در نتیجه بسته‌هایی که به سمت این روتر از طریق BGP مسیردهی می‌شدند، پس از سپری شدن Hold Timer (که معمولا زمانی بین 90 تا 180 ثانیه هست) از BGP Table حذف خواهند شد.
در واقع در این زمان ترافیک به اصطلاح blackhole شده است. در نظر داشته باشید که برخی IXP ها در دنیا سهم مهمی در وجود اینترنت دارند و blackhole شدن ترافیک ممکن است منجر به تأثیرات زیادی در دنیای اینترنت شود. ادامه خواندن “BGP Session Culling و انتزاع رخنه‌گر”
این روزها اتفاقات زیادی در دنیای امنیت رخ داده است که شاید بزرگترین آن‌ها اولین حمله تصادم SHA-1 بوده باشد؛ اما اتفاقی که کمتر به آن پرداخته شد واقعه‌ی ناگوار Cloudbleed یا خون‌ریزی ابری هست که برای شرکت Cloudflare رخ داد.
شرکت Cloudflare به جهت سرویس گسترده CDN و DDoS Protection بسیار شناخته شده است و متاسفانه/خوشبختانه در ایران نیز کاربران فراوانی دارد. در حال حاضر حدود 4 میلیون دامنه (Domain) در بستر Cloudflare سرویس‌دهی می‌شوند.
جمعه‌ی گذشته آقای Tavis Ormandy از تیم معروف Google Project Zero متوجه شد که نسبت به برخی درخواست های HTTP که توسط سرورهای Cloudflare سرویس‌دهی می‌شدند، پاسخ‌های بی‌معنی دریافت می‌کند و نهایتاً به یک مشکل امنیتی جدی در سرویس Cloudflare پی بُرد که منجر به نشت اطلاعات فراوانی از وب‌سایت ها و Web Application های تحت سرویس CDN گردیده است. این اطلاعات می‌تواند شامل نام کاربری و رمز عبور، پیام‌های رد و بدل شده در چَت ها، و کلاً هرگونه اطلاعاتی که توسط آن می‌توان شخصی را شناسایی کرد (PII)، باشد.
متاسفانه عمق فاجعه جایی است که این اطلاعات توسط اغلب Search Engine ها Cache شده اند و احتمالاً در بسیاری از سرویس‌های تجزیه/تحلیل اطلاعاتی ذخیره شده اند.
در بین جستجوگرها می‌توان به Google، Bing، DuckDuckGo و Baidu اشاره کرد.
این اتفاق به این معنی است که اطلاعات شخصی میلیون ها کاربر اینترنتی در خطر قرار گرفته است!
این نشت اطلاعاتی از تاریخ 22 سپتامبر 2016 تا 18 فوریه 2017 ادامه داشته اما اوج آن بین 13 تا 18 فوریه بوده که از هر 3.300.000 درخواست HTTP، یک درخواست منجر به نشت اطلاعات گردیده است؛ یعنی روزانه حدود 100 تا 200 هزار صفحه با اطلاعات شخصی افراد! ادامه خواندن “خون‌ریزی ابری در Cloudflare!”
حتماً شنیدین که “لنگر کشتی خورد به کابلِ اینترنت و فیبر قطع شد و …” و حتماً میدونین که واقعاً فیبرهایی وجود دارن که packet هارو از دورن دریاها و اقیانوس ها میرسونن به نقاط مختلف دنیا.
ویکی‌پدیا میگه: کابل ارتباطی زیردریایی، کابلی مستقر در بستر دریا و میان دو ایستگاه زمینی است که انتقال سیگنال‌های مخابراتی را در امتداد اقیانوس ممکن می‌سازد.
در حال حاضر 428 کابل دریای این وظیفه رو بعهده دارن که طول مجموع این کابل ها به 1.1 میلیون کیلومتر میرسه! قطر این کابل‌ها عموماً برابر با یک شیلنگ آبِ باغ هست و در کف دریا قرار می‌گیرند.
یکی از سیستم‌های جدید کابل دریای بنام MAREA Cable قرار هست ظرفیتی معادل 160 ترابیت در ثانیه داشته باشه! جالبه بدونین این سیستم توسط Facebook و Microsoft در حال اجرا هست.
اینجا میتونین نقشه‌ی این کابل هارو در سطح آب‌های دنیا ببینین.
در این مطلب به سوالاتی که عموماً درباره‌ی Submarine Cables ها پرسیده میشه، پاسخ داده شده و خوندنش خالی از لطف نیست.
خیلی اوقات مشکلات Performance نرم‌افزارها به ضعف یا مشکلات در شبکه نسبت داده می‌شوند و اتفاقاً Troubleshooting این دسته از مشکلات یکی از طاقت‌فرساترین کارها است. عموماً هم، کاربر یا توسعه‌دهنده‌ی Application از کند بودن همه‌چیز گلایه دارند و خب دیواری کوتاه‌تر از شبکه وجود ندارد.
البته که در بسیاری از موارد نیز گره حل این مشکلات در شبکه می‌باشد، از طراحی و تتظیمات اشتباه گرفته، تا نیاز به بهینه‌سازی های اولیه. خیلی اوقات نیز عدم وجود پیش‌بینی و برنامه‌ریزی از نیاز و ظرفیت شبکه (Capacity Planning/Management) باعث بروز چنین مشکلاتی در طول زمان می‌گردد.
چهت بررسی این دسته از مشکلات و اندازه‌گیری Performance، در کنار KPI های مرتبط با نرم‌افزار، روش‌ها و ابزارهای متعددی نیز از دیدگاه شبکه وجود دارد مانند RTT بین دو node توسط ping time، تغییرات مسیر بین دو Node، میزان تغییرات زمان دریافت بسته‌ها (Jitter)، میزان گذردهی شبکه (Throughput) و یا موارد اولیه مانند مقدار زمانی که طول میکشد تا یک اتفاق خاص صورت پذیرد. یکی دیگه از ابزارهای مهم در این زمینه نیز Capture کردن ترافیک و بررسی بسته ها در لایه‌های مختلف هست (توسط ابزارهایی مانند tcpdump، Wireshark و …)
اما در کنار تمام این ابزارهای ذکر شده و استفاده از آن‌ها توأم با بروز بودن مستندسازی شبکه، نکته‌ی مهم دیگر مستندسازی و ثبت اندازه‌گیری‌ها حین Troubleshooting می‌باشد که می‌تواند شامل درج ابزار استفاده شده، screenshot گرفتن، ذخیره‌کردن Logها، و ثبت محل اندازه‌گیری و … باشد.
در این مطلب، یک نمونه سناریو Network Performance Troubleshooting و متدولوژی استفاده شده در دنیای واقعی بیان شده است که مطالعه آن پیشنهاد می‌شود.
