📝 از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.

به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.


📡 @networkz

👇👇👇
https://fa.ip.engineering/mpls-mpls-te

خانه🏠 و آپارتمان🏢
#VM #Container #Docker

📡 @networkz

https://twitter.com/moghaddas_it/status/894175404621262848

📝 در RFC های BGP که تا الان منتشر شدن، هیچ اشاره ی مستقیمی نشده به این که "رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها وقتی هیچ Policy خاصی اعمال نشده" چطور باشه، و این باعث می شد که هر وِندوری رفتار سلیقه ای خودش رو در این مورد داشته باشه. همین موضوع باعث به وجود اومدن مشکلاتی مثل ترانزیت شدن ناخواسته ی یک AS بین AS های دیگه می شد.

حدود یک ماه قبل با انتشار RFC8212 در Standards Track تمامی وندورها ملزم شدن که رفتار پیش‌فرض در همسایگی eBGP را به “عدم ارسال هیچ روتی” تغییر بدن.

در این مقاله قصد داریم تا بیشتر با جزییات و اهمیت RFC 8212 آشنا بشیم.

📡 @networkz

👇👇👇
https://fa.ip.engineering/تغییر-رفتار-پیش‌فرض-ebgp-با-rfc8212

مهاجرت به IPv6: راهکار NAT64

📡 @networkz

👇
https://fa.ip.engineering/مهاجرت-به-ipv6-nat64

در تاریخ 25 آگوست 2017، برخی از کاربران اینترنت که بخش بزرگی از اون ها را کاربران ژاپنی تشکیل میدادند، در ارتباطات اینترنت خودشون شاهد کندی و در مواردی قطعی ارتباطات اینترنت میشن. گستردگی این اختلالات و قطعی ارتباطات در ژاپن به حدی می رسه که باعث میشه وزارت ارتباطات ژاپن پیگیر دلیل بروز این قطعی بشه.

در بررسی هایی که انجام میشه، مشخص میشه که گوگل prefix‌های که در بستر داخلی IXPها جهت peering استفاده می‌شدند رو announce می‌کرده خب این نشون دهنده ی این بوده که یه چیزی در تبلیغات BGP گوگل درست انجام نمی شده. اما علت چی بوده؟

گوگل یکی از بزرگترین CDN های دنیاست و از طرف دیگه مرجع حجم عظیمی از ترافیک وب سایت های مشهوری مثل یوتیوب، گوگل درایو و ... هست. در نتیجه خیلی از شبکه ها در حال تبادل حجم قابل توجهی از ترافیک خودشون فقط با گوگل هستن و به همین دلیل سعی می کنن تا با ترفندهای traffic engineering کاری بکنن که ترافیکشون از طریق لینک های ارتباطی درستی که با گوگل دارن، ارسال بشه.

یکی از این ترفندها، عدم تجمیع و تبلیغ prefix های more specific (یا همون prefix های خاص تر) هست. با این روش طول AS-Path یا local prefernces ای که گوگل تعیین میکنه دیگه مهم نیستن، همیشه prefix خاص تر ترجیح داده میشه.

در زمان رخ دادن این اختلالات، بررسی ها تعداد زیادی prefix های خاص؛ یعنی prefix هایی که در حالت عادی نباید در global internet routing table باشن و فقط به جهت رفع نیازهای مهندسی ترافیک بین گوگل و همسایگانش استفاده میشن؛ رو نشون میدن. مثلا prefix ای مثل 114.154.133.0/24 در حالت عادی نباید در اینترنت دیده بشه و باید در قالب یک آدرس تجمیع شده مثل 114.144.0.0/12 قرار بگیره که این آدرس هم از طریق AS4713 NTT OCN که بزرگترین سرویس پروایدر ژاپن هست تبلیغ میشه. اما در زمان بروز اختلالات مشاهده میشه که بیش از 20,000 از این prefix های خاص که در اصل باید در قالب آدرس های تجمیع شده می بودن (عمدتا /11 یا /12 یا /13 یا /14 یا 1/5)، به همین صورت در اینترنت از جانب OCN تبلیغ می شدن.

در واقع OCN از این Prefix های خاص به جهت کنترل ترافیکی که از جانب گوگل دریافت میکرده، استفاده میکرده و قرار نبوده این prefix ها وارد دنیای اینترنت بشن، اما گوگل این prefix ها رو برای Verizon تبلیغ می کنه و به این ترتیب این prefix ها وارد دنیای اینترنت شدن و چون این prefix ها خاص تر بودن، ترافیک های مربوط به این prefix ها به سمت گوگل و Verizon ارسال میشدن و به این ترتیب ترفند مهندسی ترافیک محلی OCN به یک راهکار مهندسی ترافیک جهانی تبدیل شده بوده! :))

شرحی که داده شد بخشی از مقاله ی زیر هست که با جزییات دقیق به بررسی این مساله پرداخته:

📡 @networkz

👇👇👇
https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/

برای اولین بار، ICANN در حال تغییر کلیدهای رمزنگاری به منظور کمک به امنیت DNS در دنیای اینترنت هست. بر طبق گفته ی دیوید کونراد، مدیر ارشد تکنولوژی ICANN، تمام ISP ها و اپراتورهای شبکه در سراسر دنیا باید اطمینان حاصل کنن که برای این تغییر آماده هستن. چون در غیر این صورت کاربرانشون دیگه قادر به انجام domain lookup نخواهند بود و در نتیجه به هیچ سایتی در اینترنت دسترسی نخواهند داشت.

هم چنین بر طبق گفته ی کنراد، اپراتورهای شبکه باید مطمئن بشن که نرم افزارهاشون از DNSSEC پشتیبانی می کنن و می تونن به صورت خودکار کلیدهاشون رو به روز رسانی کنن و یا اگر امکان به روز رسانی خودکار نیس، به صورت دستی این فرآیند رو باید در تاریخ 11 اکتبر انجام بدن.

تغییر یا اصطلاحا rolling کلیدها، گامی مهم در حفظ امنیت DNS در اینترنت محسوب میشه. بر طبق گفته ی کنراد، پلتفرم آزمایشی راه اندازی شده که اپراتورهای شبکه برای اطمینان از این که برای این تغییر کلید قبل از 11 اکتبر، آماده هستن می تونن به اون ( یعنی آدرس: https://go.icann.org/KSKtest) مراجعه کنن و این تست رو انجام بدن. از طرف دیگه کاربران اینترنت هم می تونن با ISP های خودشون تماس حاصل کنن و مطمئن بشن که برای این تغییر آمادگی دارن یا نه.

لازم به ذکر هست که ICANN با همکاران فنی خودش مثل Regional Internet Registries، Network Operations Groups و ... در ارتباط بوده تا مطمئن بشن که تمام کسانی که تحت تاثیر این تغییر قرار میگیرن، از اون آگاه باشن.

متن اصلی این خبر رو می تونید از طریق لینک زیر مطالعه کنید:

📡 @networkz

👇👇👇
http://www.domainpulse.com/2017/08/20/changing-keys-internets-addressing-system/

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

📡 @networkz

👇
https://fa.ip.engineering/مهاجرت-به-ipv6-464xlat

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

اما هکرها هم در این حین بیکار نموندن، اون ها هم روز به روز حملاتشون رو هوشمندانه تر از قبل کردن. به عنوان مثال در یک حمله ی application-base، تعدادی request برای اطلاعاتی که نیازمند منابع زیادی هستن به سمت اپلیکیشن ارسال میشه و کاری میکنه که اپلیکیشن از کار بیوفته. حجم این پیام ها میتونه انقد کم باشه که اصلا تصور نشه که یک حمله ی DDoS اتفاق افتاده.

به همین دلیل توصیه میشه که به جای استفاده از روش های قدیمی DDoS mitigation، از چند لایه ی حفاظتی در برابر حملات استفاده بشه. به عنوان مثال در روترهای لبه ی ساختار، جلوی حملات حجمی گرفته بشه و بعد از این که پیام ها از این لایه ی اول امنیتی عبور کردن، برای یک scrubbing server ارسال بشن تا ترافیک خوب از بد جدا بشه.

از طرف دیگه گاهی یک وب سایت یا یک دیتاسنتر مستقیما مورد حمله قرار نمی گیره و این حمله برای یک DNS server رخ میده. در همچین شرایطی پیشنهاد میشه از خدمات کلودی استفاده بشه که اون وندور از چندین DNS server مختلف بهره میگیره. اینطوری اگر یک DNS server مورد حمله واقع بشه، DNS server دیگه میتونه پکت ها رو به سمت کلود هدایت کنه.

متن بالا بخشی از مقاله ای هست که می تونید کاملش رو از طریق لینک زیر مطالعه کنید:

📡 @networkz

👇👇👇
http://www.datacenterknowledge.com/security/how-fight-new-breed-ddos-attacks-data-centers

ارتباطات در دنیای اینترنت بر مبنای پروتکل BGP هست به این معنی که روترهای Core در دنیای اینترنت برای هدایت ترافیک به مقاصد مختلف از BGP استفاده می کنن.

در اواخر دهه ی 1980 بود که BGP رسما منتشر شد و با استفاده از اون روترها می تونستن به تبادل اطلاعات با هم بپردازن و از میون تعداد بیشماری مسیر برای ارسال داده ها در دنیای اینترنت، بتونن بهترین مسیر رو انتخاب کنن. در اون زمان، امنیت یک مساله ی مهم و جدی به حساب نمیومد و مثل خیلی از پروتکل های دیگه ای که در اون زمان معرفی شدن و برای اون ها هیچ ملاحظات امینتی در نظر گرفته نمی شد، BGP هم از این قاعده مستثنی نبود.

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

اما مجموعه ای از استانداردها تحت عنوان Secure Inter-Domain Routing ( یا SIDR) توسط IETF منتشر شدن که نشون دهنده ی اولین تلاش ها برای دفاع از سیستم مسیریابی اینترنتی در برابر حملات هستن.

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

1- Resource Public Key Infrastructure (RPKI)
که در واقع به دارندگان بلوک هایی از آدرس های اینترنتی مثل فراهم کنندگان خدمات ابری، این امکان رو میده که تعیین کنن چه شبکه هایی می تونن یک direct connection با آدرس های بلوکشون داشته باشن.

2- BGP Origin Validation
که به روترها این امکان رو میده که با استفاده از اطلاعات RPKI بتونن مسیرهای BGP تبلیغی که غیرمجاز هستن رو فیلتر بکنن و به این ترتیب جلوی حملاتی مثل hijack مسیرها گرفته بشه.

3- BGP Path Validation
که تحت عنوان BGPsec شناخته میشه و RFC مربوط به اون اخیرا توسط IETF منتشر شده، در واقع نوآوری جدیدی هست که این امکان رو برای روترها فراهم میکنه تا با استفاده از امضای دیجیتال مطمئن بشن که کل مسیردر دنیای اینترنت از شبکه های مجاز عبور کرده.

از طریق صفحه ی مربوط به SIDR (لینک زیر) در وب سایت IETF، می تونید این استانداردها، روند پیشرفتشون و آخرین تغییراتشون رو پیگیری کنید:

📡 @networkz

👇👇👇
https://datatracker.ietf.org/wg/sidr/documents/

خیلی اوقات هست که وقتی به خروجی traceroute نگاه می‌کنیم، بعد از هاپ اول یا دوم، delay بطرز ناگهانی خیلی افزایش پیدا می‌کنه اما پس از اون تا انتهای مسیر تقریباً یکسان می‌مونه.
خیلی دیده شده که شخصی که با اون بستر آشنایی نداشته گفته: «ببین، مشکل از لینک بین هاپ اول و دومه، چون ازونجا یکهو RTT رفته بالا»....
اما اغلب اوقات این افزایش قابل انتظار هست، چرا که یک مسیر MPLS بین مبدأ تا مقصد وجود داره.
مطلب زیر به خوبی و سادگی این مورد رو شرح داده

📡 @networkz

http://movingpackets.net/2017/10/06/misinterpreting-traceroute/

📡 @networkz

WPA2 vulnerability: just a small update!

مرگ دنیای وِب از ۲۰۱۴ شروع شد!
📡 @networkz
تقریباً ازون موقع همه‌چی همینطوری مونده، ظاهر صفحات، فیچرهای تحت وب و ... اما چیزی که خیلی تغییر کرده زیرساخت ها است.
از همه مهمتر نکته جالب و در عین حال ترسناک قضیه اینه که گوگل و فیسبوک بیش از ۷۰ درصد ترافیک دنیا رو کنترل می‌کنن.

مقاله زیر برمبنای یکسری تحقیقات و حقایق انجام شده و خوندنش خالی از لطف نیست.

https://staltz.com/the-web-began-dying-in-2014-heres-how.html

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

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

📡 @networkz

👇👇👇
https://fa.ip.engineering/dnssec-عملکرد

📣 به عنوان ادمین شبکه آشنایی داشتن با دستورات لینوکس یه امر ضروری هست. پس سعی کردیم تا فایلی از مهمترین این دستورات رو آماده و ارائه کنیم 👇

📡 @networkz
https://fa.ip.engineering/لینوکس-دستورات-ضروری

آیا همیشه اصطلاحا کشتن فرآیندها (kill processes) در هنگام تامین امنیت یک راهکار خوب محسوب میشه؟ تا حالا شده قبل از انجام کاری یا تعریف سیاستی یا فراهم آواردن خدمتی، دقیق کارتون رو بررسی کنید و ببینید که نتیجه ی حاصل از کار یا خدمتی که فراهم می کنید، بر چه بخش هایی ممکنه اثرگذار باشه و چه تاثیری بر اون ها میذاره و آیا این تاثیرات مثبت هستن یا منفی؟

📡 @networkz

اگر شما جز افرادی هستید که در حوزه ی امنیت فعالیت می کنید یا کلا فردی هستید که خدمتی رو برای دیگران فراهم می کنید که این خدمت شما بر بخش های مختلفی تاثیرگذار هست، خوندن این مطلب خالی از لطف نیست:

👇👇
https://lkml.org/lkml/2017/11/21/356

وقتی مدیر شبکه هستی و خیلی منطقی وظایف کاربرا و خودت رو در هنگام رخ دادن مشکل، براشون شرح میدی! 🙄😁

📡 @networkz

📣 12 گام برای مهاجرت ISP ها به IPv6 (اینفوگرافیک)

دریافت نسخه ی باکیفیت از طریق لینک زیر 👇
https://fa.ip.engineering/مهاجرت-ipv6-isp

📡 @networkz

‏برخی از [امنیت]شبکه‌کارها بر این تصورن که اگر در ورودیِ سرویسی، محدودیت بر مبنای IP مبدأ تنظیم بشه، امنیت بطور خوبی برقرار شده.
ولی من فکر می‌کنم فایده‌ی این به تنهایی همونقدره که روی در تابلو بزنین «🚷لطفا وارد نشوید». طرف هم میگه: چشم وارد نمیشم جلوی در هم پارک نمی‌کنم. 😎
📡 @networkz

https://goo.gl/G2fru2

‏استفاده از Wildcard SSL certificateها بخاطر سادگی پیاده‌سازی اولیه و مقرون به صرفه بودن جذابه. شاید برای یک ‎#استارتاپ کوچک منطقی باشه، اما در یک Enterprise باید شرایط متعددی رو قبل از تصمیم‌گیری بین Ordinary یا Wildcard بودن Certificate سنجید.
مثلا بلابدور که Private Key نشت کنه!

https://blog.sean-wright.com/2017/11/wildcard-certs-not-quite-star.html

https://goo.gl/ddzxN4

وقتی بچه های تیم برنامه نویسی سازمان مدام تکرار میکنن: "مشکل از شبکه‌اس!" 😎😁

📡 @networkz

در 12 دسامبر 2017، سرویس مانیتورینگ دنیای اینترنت، BGPMon، اتفاقی عجیب رو گزارش کرد که بر طبق اون ترافیک شبکه هایی مثل گوگل، مایکروسافت، فیسبوک، اپل و ... برای مدت زمان مشخصی از طریق یک ISP ناشناخته ی روسی مسیریابی شدن.

این اتفاق سبب شد تا بار دیگه این سوال مطرح بشه که آیا ارتباطات در دنیای اینترنت امن و قابل اعتماد هستن؟ به بیان بهتر، آیا پروتکل BGP که وظیفه ی برقراری ارتباطات بین backbone ها، ISP ها و شبکه های بزرگ رو در دنیا به عهده داره، دارای مکانیسم های امنیتی کافی هست؟

این رویداد در بردارنده ی چندتا نکته ی قابل توجه و البته قابل تامل بود که سعی شده تا در پست زیر به بررسی اونها پرداخته بشه.

📡 @networkz

👇👇👇
https://fa.ip.engineering/امنیت-bgp-تغییر-ترافیک-مقاصد-محبوب-به-isp-روس