مرگ دنیای وِب از ۲۰۱۴ شروع شد!
📡 @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-روس

قطعا بارها با مفهوم Load Balancing یا به عبارتی تعادل (توازن) بار مواجه شدید. با یه سرچ تو گوگل اکثر مقالاتی که در رابطه با load balance پیدا میشن، توضیح این مفهوم از دید تجاری و از نقطه نظر وندورهای مختلف هستن و کم تر مطلبی پیدا میشه که این مفهوم رو با جزئیات، الگوریتم ها، معماری های مختلف برای پیاده سازی و ... شرح داده باشه. اما در مقاله ی زیر سعی شده تا این مفهوم در دنیای شبکه با جزییات تکنیکی و فارغ از دید تجاری مورد بررسی قرار بگیره که خوندنش خالی از لطف نیست:

📡 @networkz

👇👇👇
https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236

دنبال ایده و هدف هستین تا در سال جدید لینوکسی چیکار کنین؟ اینم چندتا پیشنهاد.

https://goo.gl/ysk6fC
📡 @networkz

پیرو باگ‌های اخیری که کشف شد (Spectre و Meltdown) و هزاران باگی که قبلاً کشف شدن، و امنیت اطلاعات رو بشدت تحت تاثیر قرار دادن، داشتم فکر میکردم که “بهترین، راحت‌ترین، ساده‌ترین، کارامدترین و اساسی‌ترین” راه‌کارهای امنیت اطلاعات چیا هستن که یکی بتونه حتی به پدر و مادر مسن آموزش بده؟ چند مورد به ذهنم رسید که در ادامه ذکر می‌کنم

📡 @networkz

🌐 https://fa.ip.engineering/پدر-بزرگ-و-حفظ-امنیت-اطلاعات/#more-1150

✅ همیشه یک طراحی/ایده/تصمیم خوب نیازمنده صرف زمانه. حتی اگر حرفه ای هم هستید هیچ وقت طراحی/ایده/تصمیم خوب خودتون رو قربانی سرعت عمل بیشتر برای کاهش زمان نکنید!

📡 @networkz

بازار تشنه‌ی متخصصین دنیای متن‌باز هست!
منبع: The Linux Foundation

📡 @networkz
https://goo.gl/2n2XX6

چند سالی هست که در حوزه ی Routing صحبت از راهکاری به اسم Segment Routing یا اختصارا SR هست (قبلا در پست دیگه ای در بلاگ به طور مفصل تاریخچه ی ظهور این راهکار و دلایل و مشکلاتی که باعث تولد این راهکار شدند رو بررسی کردیم) .

درواقع Segment Routing تکنولوژی نه چندان جدید برای انجام Source Routing محسوب میشه. در این روش، مبدا مسیری را انتخاب میکنه و اون رو در قالب لیستی از سگمنت ها در هدر پکت قرار میده. segment ها مشخص کننده ی رفتار و عملی هستند که باید در قبال پکت صورت بگیره. پس به زبون ساده، با استفاده از این روش دیگه نیازی نیست که منطق ارسال پکت ها در شبکه ها، حتما بر اساس یک application خاص یا بر اساس یک جریان خاص باشه. تو این روش forward پکت ها می تونه تنها بر اساس همون دستورالعملی باشه که توسط سگمنت ها مشخص میشن.

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

📡 @networkz

👇👇👇
https://fa.ip.engineering/segment-routing-بررسی-مفاهیم-پایه-عملکرد

‏سولوشن مستندسازی شبکه در Scale بالا ، بصورت استاندارد، کامل ، قابل اطمینان و Automate شده در کمپانی های بزرگ غیر ایرانی چیست ؟ غالبا برای این مورد چه کاری انجام میشه ؟
https://goo.gl/MSBVhy

‌‎بنظرم، دنبال ابزار بودن خوبه، اما اول باید پروسه‌های ‎#مستندسازی و بروزنگهداری (هر چند ساده) تعیین کرد؛ همینطور اینکه چه چیزهایی و مخصوصاً «چرایی» اِلمان‌های مختلف در شبکه (چه ابزارها چه تصمیمات طراحی)، مستند بشن. همینطور سطح دسترسی افراد به مستندات.
فکر می‌کنم این موارد حداقل هاس
https://goo.gl/sWYYAc

‌‎برای شخص من، همیشه «چرایی» مهم‌تر «چی» یا «چگونگی» هست. چون چه یک مستند یا دیاگرام توسط انسان تهیه بشه چه توسط افراد فرقی نمی‌کنه و هر دو میتونن یکسری تجهیزات و ارتباطات رو نشون بدن، اما شخصی که اون مستند رو نگاه می‌کنه باید بفهمه چی میگذره
https://goo.gl/gEa1UG

‌‎برخلاف تصوری که شاید خیلیا داشته باشن، در بسیاری از Enterpriseها هم از ابزارهای معمولی مثل Excel و Visio و ... استفاده می‌شه اما خب در یک ابزار متمرکز نگهداری می‌شه و قابلیت مشخص کردن سطح دسترسی و ...
https://goo.gl/WJyp9B

‌‎در رابطه با بحث ابزار اما، این مورد اصلا در تخصص من نیست و خیلی وقت هم هست که درگیر پروسه‌های مستندسازی یا انتخاب ابزار مستندسازی نبودم و شرکت‌هایی که همکاری می‌کنم محصولاتی استفاده می‌کنن که خودشون تولید کردن و معمولاً بر مبنای راه‌کارهای ‎#متن_باز
https://goo.gl/V6Rf4s

‌‎راه‌کارهای متن‌باز که من دیدم Open-AudIT ، NetDoT ، SYDI و ... یک ابزاری که جایی ندیدم اما بنظرم پروژه جالبی بوده NetBox هست که توسط یکی از مهندسین خوبِ DigitalOcean توسعه داده می‌شه
https://goo.gl/2oJwup

‌‎ولی بجز اونا، ‎@NetBrainTechies راه‌کار خوبی هست. یکسریا هم راه‌کارهای مختلف رو باهم ادغام می‌کنن مثلاً از محصولات BMC و ManageEngine و SolarWinds و ...
https://goo.gl/LJSqrh

‌‎نهایتاً، برمی‌گردم به همون عرض اولم. ابزار زیاده، اما اول باید دید واقعاً چی نیاز هست. برای شروع، ابزاری که نیازهای اولیه رو برطرف کن و یک سروسامونی بده به مستندسازی شبکه کافیه و به مرور میشه بهینه‌تر کار کرد.
https://goo.gl/fndtnG

تعریفی عالی از Bandwidth و Latency !

📡 @networkz

اینم دلیل اینکه چرا میگن تو سطوح مختلف شبکه از برندهای متفاوت فایروال استفاده کنین!🙃

#طنز_اندکی_واقعیت!
https://twitter.com/nixcraft/status/958791981500653568

📡 @networkz

📢 پروژه‌ای جذاب برای دو Network Engineer

محل کار و حقوق: بیشتر در برلین/هامبورگ🇩🇪 همراه با چند سفر به شهر لاهه🇳🇱 ؛ حقوق بصورت نرخ روزانه توافق خواهد شد.
پروژه‌ی مهاجرت از بستر FabricPath سیسکو به بستر QFabric جونیپر
مدت زمان پروژه ۳ماه با امکان افرایش احتمالی تا ۶ماه.
قرارداد بصورت Service Agreement توسط بنده با اشخاصی که اجازه‌ی فعالیت خویش‌فرمایی یا Freelance در اروپا دارند.

حداقل نیازمندی‌ها:
✅ کاملاً مسلط به زبان انگلیسی
✅ آشنایی با یک زبان برنامه‌نویسی مانند Python یا Perl
✅ تسلط بر مفاهیم Routing و Switching
✅ تجربه‌ی پیاده‌سازی QFabric و تجهیزات QFX و EX
✅ آشنایی با MPLS
✅ ترجیحاً تجربه‌ی فعالیت در بستر FabricPath سیسکو
✅ آشنایی اولیه با مفاهیم Cloud Computing و SDN

📡 @networkz

جهت اقدام 👇👇👇
https://fa.ip.engineering/موقعیت‌های-کاری-شبکه-در-اروپا

📣📣 مهم 📣📣

اخیرا حمله ی DDoS جدیدی گزارش شده که از پروتکل Memcached و UDP port 11211 بهره میگیره که بسیار تأثیرگذار بوده و پروایدر های مهم دنیا از جمله NTT بسرعت در حال مقابله با اون هستن و حتی محدودیت‌هایی رو برای این پورت درنظر گرفتن. این حملات طی چند روز اخیر بسیاری شبکه‌های قاره اروپا رو تحت تأثیر قرار داده و کارگروه‌های مختلف در حال بررسی چگونگی مدیریت اون هستن.

به زبون ساده، Memcached ابزاری هست برای ذخیره ی داده ها و کاهش بار منابع ذخیره سازی داده مثل دیسک ها یا دیتابیس ها. معمولا از اون برای سرعت بخشیدن به وب سایت های مبتنی بر پایگاه داده با استفاده از ذخیره ی object ها در RAM و کاهش تعداد دفعاتی که نیاز باشه تا یه منبع داده ی خارجی (مثلا یه پایگاه داده یا API) باید خونده بشه، استفاده میشه. با Memcached نیازی به مکانیزم های احراز هویت نیست. به همین دلیل فقط کافیه تا آدرس های IP ترافیک های UDP مربوط به memcashed سرورها شنود بشن.
در لینک زیر راهکارهایی برای مقابله با این حمله به ISP ها، اپراتورهای موبایل، فراهم کنندگان خدمات ابری و شرکت ها ارایه شده:

📡 @networkz

👇
https://goo.gl/VzBvzJ