https://virgool.io/feed/@m.hashemi SyS Admin fa 2026-06-10 14:17:41 https://files.virgool.io/upload/users/26302/avatar/99MwzL.png?height=120&width=120 https://virgool.io/@m.hashemi https://virgool.io/@m.hashemi/ip-spoofing-%DA%86%DB%8C%D8%B3%D8%AA-mzy2ksuuhjhz جعل آدرس IP یا IP Spoofing در واقع ایجاد بسته (packet) هایی که دارای یک آدرس مبدا (Source Address) دستکاری شده به منظور پنهان کردن هویت فرستنده ، جعل هویت کاربر دیگر و یا هر دوی این موارد است . قابلیت جعل Source Address نوعی آسیب پذیری است که در بسیاری از حملات DDoS مورد سو استفاده قرار می گیرد که چالش های جدیدی را برای ارایه دهندگان خدمات اینترنت (ISP) و جوامع امنیت شبکه ایجاد کرده است تا برای مقابله با این دست حملات راهکار ها و روش های جدید و خلاقانه ای را ارایه دهند. به زبان ساده تر اغلب در شبکه های کامپیوتری گیرنده (Destination) به منظور جلوگیری از دریافت داده های متفرقه و حملات احتمالی منابع ناشناس با استفاده از تجهیزاتی همچون فایروال اقدام به محدود نمودن آدرس های IP مجاز برای ارسال داده به خود استفاده می کند ، از این رو هکر ها با استفاده از تکنیک IP Spoofing اقدام به جعل آدرس IP مبدا مجاز نموده و داده های خود را به نام مبدا مجاز به مقصد مورد نظر ارسال می کنند. برای آشنایی بیشتر می توانید RFC 2827 را مطالعه نمایید .مکانیزم جعل آدرس IPبرای درک بهتر چگونگی جعل آدرس IP و انجام حمله IP Spoofing می بایست با ساختار درونی Packet بیشتر آشنا شویم . در شکل زیر header یک packet شبکه مبتنی بر IPv4 را مشاهده می کنید .همانگونه که مشخص است یکی از بخش های یک بسته ، Source IP Address می باشد که در حمله جعل آدرس IP هکر با استفاده از تکنیک هایی ابتدا یک آدرس IP معتبر و مجاز برای برقراری ارتباط با سرور و یا مقصد مورد نظر یافته سپس در هدر پکت آدرس IP مبدا را تغییر و IP مورد نظر خود را جایگزین می نماید . درخواست هکر تحت عنوان مبدا مجاز به سمت سرور ارسال و با توجه به مجاز بودن آدرس IP ذکر شده در Source IP به درخواست ارسال شده پاسخ داده می شود .در ادامه به برخی از انواع حملات احتمالی که با استفاده از مکانیزم IP Spoofing انجام می شود به صورت مختصر اشاره خواهیم کرد.حملات Man in the Middleهمانگونه که از نام این حمله مشخص است این نوع حمله زمانی رخ می دهد که هکر ها به منظور دریافت و بررسی محتوای برخی پکت های ارسالی و دریافتی میان فرستنده و گیرنده قرار می گیرند و با جعل آدرس مبدا ، اطلاعات درخواستی را به سمت مقصد ارسال و دیتا مورد نظر را دریافت ، بررسی ، دستکاری و در نهایت پاسخ را به سمت مبدا مجاز ارسال می کنند . این بدین معناست که گیرنده اطلاعات دستکاری شده را دریافت کرده است که با اصل داده متفاوت است .حملات Blindingاین شکل از حمله زمانی اتفاق می افتد که هکر یک رشته از packet های دستکاری شده را به هدفی مشخص ارسال می کند در حالی که مطمئن نیست چگونه بسته ها در طول مسیر شبکه به مقصد می رسند. در واقع هکر هیچ دید مشخصی از مسیری که دیتا از طریق آن به مقصد می رسد ندارد . هکر در حالی که هویت خود را پنهان می کند از این واقعیت استفاده می کند که به داده ها دسترسی پیدا کرده و داده دستکاری شده مد نظر خود را در packet ها بدون شناسایی خود یا اطلاع از هویت خود در داده اصلی تزریق می کند. در مقصد ، گیرنده داده های دستکاری شده را دریافت می کند و بر این باور است که داده های دریافتی همان دیتایی است که از فرستنده اصلی ارسال شده است بدون اینکه بداند داده ها حاوی اطلاعات نادرست و دستکاری شده هستند که توسط هکر به داده اصلی تزریق شده است .حملات Non-Blindingدر این حملات ، هکر در همان شبکه هدف مستقر می شود تا بتواند در فرآیند انتقال یا دسترسی به دیتا های مورد نظر خللی ایجاد کند. پس از دسترسی به داده ها ، هکر می تواند خود را به عنوان مقصد دریافت کننده اطلاعات جا بزند که در نهایت منجر به هایجک شدن دیتا در آن شبکه می شود .حملات Service Denialدر این نوع از حمله ، هکر برای پنهان ماندن هویت خود در زمان حمله سیل عظیمی از داده ها و درخواست ها را به سمت سیستم ارسال می کند تا یافتن منبع حمله را دشوار کند . این حملات اغلب در مقیاس وسیع انجام می شود که منجر به از سرویس خارج شدن چندین سرور خواهد شد .جلوگیری از IP Spoofingبا توجه به آنچه تا کنون اشاره شد در حملات جعل آدرس IP هکر پس از یافتن آدرس IP مبدا مجاز اقدام به انجام تغییرات در header بسته ها نموده و مقادیر Source IP Address را مقدار دهی می کند . پس از آن اقدام به ارسال پکت های خود به سمت مقصد مورد نظر نموده و از آنجایی که در packet رسیده به مقصد آدرس IP مبدا مجاز وجود دارد ، گیرنده درخواست فرستنده جعلی را بررسی و به آن پاسخ می دهد . با استفاده از مکانیزم حمله جعل آدرس IP چندین نوع حمله دیگر همانند : Man in the Middle , Blinding , Non-blinding , Service denial قابل انجام است .در زیر به معرفی و تشریح برخی از تکنیک هایی که می توان برای جلوگیری از جعل IP انجام داد ، خواهیم پرداخت .تغییر روش احراز هویت : رمزنگاری بین میزبان ها و سرویس دهنده ها می تواند از جعل IP جلوگیری کند . تبادل کلید (key) بین دو سیستم که قصد مبادله اطلاعات را دارند می تواند تا حد زیادی از بروز این نوع جمله جلوگیری کند .تعریف فیلتر : این فیلتر باید در سیستمی تعریف شود که قصد دارد مانع جعل IP به ویژه در ترافیک داده های ورودی شود می بایست مورد استفاده قرار گیرد .پیکر بندی سوییچ ها و روتر ها : اگر در پیکر بندی تجهیزات شما ترافیک ورودی و خروجی کنترل نمی شود می بایست در این سیاست تجدید نظر کنید . با پیکر بندی مجدد از ورود داده های ناشناس که ممکن است از منابع مختلف در سطح شبکه ارسال شود ممانعت کنید .محدود سازی ترافیک آدرس های Private : پیکر بندی سیستم و یا شبکه به منظور مسدود سازی یا غیرمجاز اعلام کردن ترافیک private IP addresses که منشا خارج از سیستم دارند.رمزنگاری session ها : این پیکر بندی باید به گونه ای باشد که تنها شبکه های مجاز و مورد تایید بتوانند به شبکه شما دسترسی داشته و تعامل داشته باشند . روتر شما می بایست به نحوی کانفیگ شود که فقط به منابع مجاز اجازه دسترسی و تبادل ترافیک دهد . سید مجید هاشمی سید مجید هاشمی Wed, 09 Dec 2020 08:47:59 +0330 https://virgool.io/@m.hashemi/ttl-%DA%86%DB%8C%D8%B3%D8%AA-bacqdnap5hvh به مدت زمان زنده ماندن (اعتبار داشتن) یک packet در سطح شبکه Time to Live یا به اختصار TTL گفته می شود. هر بسته (Packet) در طول مسیر مبدا تا رسیدن به مقصد از دستگاه‌هایی عبور می کند که به هر کدام از آن‌ها یک hop گفته می شود. طول عمر یا همان TTL بسته رابطه مستقیم با تعداد hop های مسیری که بسته در حال طی کردن آن است دارد. بدین صورت که با عبور از هر hop یک واحد از TTL آن کم می شود. TTL علاوه بر مسیریابی در شبکه در مفاهیمی همچون DNS Caching و CDN Caching نیز استفاده می شود.یکی از دلایل استفاده از این پارامتر در بسته‌های اینترنتی جلوگیری از ارسال نامحدود و پی در پی بسته‌ها بین مسیریاب ها و تجهیزات شبکه است. TTL به نوعی تاریخ انقضا بسته محسوب می شود و از سوی دیگر این قابلیت را به ارسال کننده می‌دهد که از تعداد hop های در طول مسیر مطلع شود.بر اساس پروتکل IP (Internet Protocol) پارامتر TTL یک فیلد 8 بیتی در هدر بسته های IP v4 است. حداکثر مقدار TTL برابر 255 می تواند باشد که مقدار پیش فرض و پیشنهادی آن 64 است. TTL توسط فرستنده در ساختار بسته تعریف می شود و پس از گذشت از هر دستگاه از مقدار آن یک واحد کم می شود. اگر قبل از رسیدن بسته به مقصد مقدار TTL آن صفر شود همان دستگاه یا hopی که بسته در آخرین مقدار 1 به آن رسیده است بسته را دور می اندازد و یک پیغام خطا با استفاده از پروتکل ICMP به فرستنده بسته ارسال می شود. این فرآیند را در تصویر زیر مرحله به مرحله مشاهده می کنید.همانگونه که گفته شد TTL افزون بر بسته‌های اینترنتی در طول مسیریابی شبکه در مکانیزم‌هایی همچون DNS Caching و CDN Caching هم کاربرد دارد. TTL برای هر رکورد DNS مقدار دهی می شود و مشخص می کند یک سرور Resolver چه مدت زمانی می تواند کوئری DNS را به اصطلاح cache نماید. مزایای قابلیت caching در سرویس DNS بر کسی پوشیده نیست و می دانیم که با این قابلیت سرعت ترجمه نام دامنه و در نتیجه بارگزاری صفحات وب سایت‌ها سریعتر خواهد شد. به این دلیل که فرآیند بررسی درخواست در سرور پاسخ دهنده Local شما که رکورد DNS درخواستی شما در آن cache شده است به مراتب سریعتر از ارسال و دریافت پاسخ از DNS سرور‌های بالادستی در سطح اینترنت خواهد بود. از سوی دیگر نوعی تقسیم بار در سرورهای سطح شبکه اینترنت رخ خواهد داد که به جای ارسال درخواست همه کاربران به چند سرور، درخواست ها بین سرور ها تقسیم خواهند شد.حال در نظر بگیرید تغییری در یک رکورد DNS رخ دهد! در این حالت قابلیت cache در سرویس DNS کمی دارای اشکال می شود. بدین صورت که رکورد مربوط به یک وب سایت در سطح DNS های جهانی تغییر و به روز رسانی شده است ولیکن DNS سرور های محلی و سطح پایین همچنان رکورد قبل از تغییرات را در حافظه خود دارند. در این حالت پاسخی که به کاربر برای ترجمه نام دامنه درخواستی به آدرس IP بازگردانده خواهد شد اشتباه خواهد بود و عملکرد سرویس DNS را زیر سوال می برد. در این شرایط TTL به کمک سرویس DNS آمده و با تعیین تاریخ انقضا و مدت زمان اعتبار هر کوئری DNS در حافظه cache مشخص می کند Resolver حداکثر تا چه مدتی می تواند از یک کوئری استفاده کند و پس از انقضا می بایست اطلاعات cache خود را با استفاده از سرور های بالادستی به روز کند.چرخه به روز رسانی حافظه cache سرور های DNS بسیار حائز اهمیت است. تصور کنید رکوردهای DNS دامنه شما در DNS سروی تنظیم شده است که TTL آن 1 روز است . این بدین معناست که اگر شما در همین لحظه تغییراتی در رکورد DNS وب سایت خود اعمال کنید حداقل 1 روز زمان خواهد برد تا سرور های DNS بالادستی و به صورت کلی در سطح شبکه اینترنت رکورد وب سایت شما را به روز کنند. در نتیجه طولانی بودن زمان TTL یک رکورد در cache سرویس DNS ممکن است تغییرات شما در رکورد DNS وب سایت تان را با مشکل مواجه کند. پس طولانی شدن مقدار TTL ممکن است مزایای استفاده از cache در سرویس DNS را تحت تاثیر قرار دهد.دیگر کاربرد TTL در حافظه cache سرویس های شتاب دهنده یا همان CDN ها است. شرکت‌های ارایه دهنده خدمات CDN ، با استفاده از TTL مشخص می کنند هر محتوای ذخیره شده در حافظه cache تا چه مدت زمانی می بایست توسط یک سرور شتاب دهنده edge منتشر شود. همچنین بازه زمانی رجوع به سرور مبدا و به روز رسانی تغییرات محتوا را نیز تعیین می کند. اگر این بازه زمانی به درستی تنظیم شود، CDN ها قادر به ارائه محتوای به روز سرورهای مبدا خود می باشند بدون آن که نیاز باشد به صورت مکرر به سرور مبدا درخواست آپدیت محتوا دهند. این بهینه‌سازی به CDNها اجازه می دهد تا ضمن کاهش پهنای باند مورد نیاز سرور شتاب دهنده Edge تا مبدا ، محتوا را سریعتر و به روز تر در اختیار کاربر قرار دهند. سید مجید هاشمی سید مجید هاشمی Wed, 25 Nov 2020 07:40:25 +0330 https://virgool.io/@m.hashemi/%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%AF%D8%B1-%D9%BE%D8%B1%D9%88%D8%AA%DA%A9%D9%84-bgp-bgpsec-%D8%A8%D8%A7-rpki-%DA%86%D9%87-%D8%AA%D9%81%D8%A7%D9%88%D8%AA%DB%8C-%D8%AF%D8%A7%D8%B1%D8%AF-e80hvnomxqro همانگونه که میدانید BGP (Border Gateway Protocol) پروتکلی است که در سراسر اینترنت برای تبادل اطلاعات مسیریابی بین شبکه ها استفاده می شود . در واقع این پروتکل زبان مشترک روتر ها در دنیای اینترنت برای تعیین چگونگی ارسال packet از یک روتر به روتر دیگر برای رسیدن به مقصد نهایی است . می توان گفت در حال حاضر BGP ستون فقرات شبکه اینترنت در دنیاست . برای آشنایی بیشتر با ساختار این پروتکل می توانید RFC 4271 را مطالعه نمایید . چالش اصلی که BGP با آن مواجه است ، نبود ساز و کار امنیتی مشخص و اعتماد به متولیان شبکه مبنی بر عدم ارسال اطلاعات نادرست و تضمین صحت عملکرد سیستم شان است . از این رو خرابکاران با ارسال داده های غیرواقعی (جداول مسیریابی تقلبی) می توانند موجب بروز اشتباهاتی در مکانیزم مسیریابی در سطح این پروتکل شوند .در این نوشته به بررسی راهکار های امن سازی پروتکل BGP که منجر به ارتقا امنیت این پروتکل و افزایش تاب آوری در کلیه سطوح زیرساخت های مسیریابی اینترنت می شود ، خواهیم پرداخت. برای درک بهتر این مبحث می توانید RFC 7454 سازمان Internet Engineering Task Force یا همان IETF با عنوان “BGP Operations and Security“ مطالعه نمایید .همانگونه که گفته شد بزرگترین چالش پروتکل BGP نداشتن مکانیزم امنیتی به صورت پیش فرض است که به همین دلیل هر شبکه (ASN) می تواند هر رنج IP ی را Advertise نماید . در این صورت دغدغه هایی پیش رو خواهد بود : خطاهای نوشتاری (Typing Errors) که با عنوان "Fat Fingers" نیز شناخته می شوند و به دلیل نزدیک بودن دکمه های کی بورد بروز این دست اشتباهات رایج است . کافیست در تایپ یک آدرس IP به جای عدد 2 عدد 3 را تایپ کنید .نقض قوانین مسیریابی (Routing Policy violations) که اغلب با اعمال تنظیمات و فیلتر نادرست به اشتباه (غیر عمد) ، بروز می دهد . به عنوان مثال یک ASN رنج IP که متعلق به شبکه دیگری است را اشتباهاً Advertise می نماید . حملات مخرب (Malicious attacks) که از سوی خرابکاران با هدف هدایت ترافیک رنج IP خاص به مقصد مورد نظر صورت می پذیرد . به این نوع حملات Route Hijacking نیز گفته می شود . اخیراً نوع جدیدی از این حملات به صورت ترکیبی از حملات BGP Hijacking و Man in The Middle انجام میگیرد . بدین صورت که ترافیک به مقصد خاص ارسال و پس از دستکاری و اعمال تغییرات از مقصد خاص به مقصد اصلی ارسال خواهد شد . در نتیجه در صورتیکه ترافیک به صورت غیر رمز ارسال گردد براحتی توسط فرد خرابکار قابل مشاهده و تغییر خواهد بود . در ادامه به چند نمونه از این حملات و رخداد ها در دنیای واقعی اشاره خواهیم کرد . هایجک شدن ترافیک YouTube توسط پاکستان : روز یکشنبه ، 24 فوریه 2008 ، مخابرات پاکستان (AS17557) زمانیکه تصمیم گرفت سایت YouTube را برای کاربران این کشور فیلتر کند ، به اشتباه شروع به Advertise رنج 208.65.153.0/24 کرد . از سوی دیگر PCCW Global (AS3491) تامین کننده بالادست پاکستان تلکام نیز این رنج را به سمت BGP Peer's های خود ارسال نمود که منجر به hijacking ترافیک YouTube در مقیاس جهانی شد . هایجک شدن ترافیک انگلستان توسط اکراین : روز شنبه ، 12 مارس 2015 ، شرکت Vega یکی از ارائه دهندگان خدمات اینترنت در اوکراین شروع به Advertise چهارده رنج آی پی British Telecom نمود که منجر به تغییر مسیر ترافیک اینترنت شمار زیادی از کاربران انگلستان به سمت اوکراین شد . هایجک شدن ترافیک بین الملل توسط شرکت مخابرات ایران : روز دوشنبه ، 8 مرداد 1397 ، شرکت مخابرات ایران (AS58224) در پروسه "عملیات تغییر توپولوژی و تجمیع شبکه استانی" به علت غیرفعال نمودن یکی از Prefix Filtering های فی مابین BGP Peer این شرکت با اپراتور های بین الملل باعث اختلال در سیستم روتینگ بین الملل شده و باعث گردید بلافاصله تمامی مسیریابهای بین الملل جداول مسیریابی خود را بروزرسانی کنند و ترافیکهای غیر مرتبط به شبکه شرکت مخابرات ایران و به روتر استان خراسان شمالی مسیریابی شود.سازمان  IETF اقدامات قابل توجهی همچون تشکیل کار گروه های RPSL و SIDR به منظور امن سازی route ها انجام داده‌ است . کارگروه SIDR راهکارهایی به منظور تامین و ارتقا امنیت BGP ارائه و توسعه می دهد . از این رو هدف اصلی SIDR کاهش ایرادات امنیتی در Inter-domain Routing system ها می باشد . دغدغه های اصلی که بیشترین تمرکز این گروه بر روی آن ها معطوف است را می توان بدین صورت عنوان نمود : آیا یک AS اجازه ایجاد یک روت برای IP Prefix مورد نظر خود را دارد؟آیا AS-Path ارائه‌شده در route همان مسیری میباشد که NLRI از آن استفاده کرده است؟برای حل مورد اول می توان از متد RPKI و برای حل مورد دوم بر روی راهکار BGPSec که AS Path Validation را انجام می دهد تمرکز شده‌ است. در ادامه به بررسی متد BGPsec و تفاوت های آن با رویکرد RPKI خواهیم پرداخت . برای درک بهتر ابتدا به تشریح راهکار RPKI می پردازیم .طرح مساله : از آنجاییکه همه داده های IRR (Internet Routing Registry) به دلایلی همچون : عدم دقت در درج اطلاعات ، وجود داده های ناقص و عدم نگهداری مداوم قابل اعتماد نیستند و از سوی دیگر هر RIR (Regional Internet registry) مانند APNIC، ARIN، AFRINIC، LACNIC و RIPE NCC دارای IRR مجزا نیست که به ناچار می بایست از بانک های اطلاعاتی ثانویه همانند RADB ها و دیتا اپراتور ها استفاده نمود و از طرفی صحت اینکه IP/ASN ها متعلق به چه کسی است و توسط چه کسانی نگهداری می شود ، منجر به ایجاد Resource Public Key Infrastructure یا به اختصار RPKI گردید . Resource Public Key Infrastructure (RPKI)متد RPKI از سال 2008 و پس از شدت گرفتن حوادث BGP Hijacking توسط همه RIR ها مورد استفاده قرار گرفت و استاندارد سازی آن را IETF عهده دار شد . در این راهکار امنیتی آدرس های IP و ASN ها را به Public Key ها متصل نمود . پارامتر crypto-security را به IP ها و ASN های افزود که در نتیجه داده هایی که از جداول مسیریابی به پروایدر ها می رسید قابل اطمینان بود .متد RPKI را می توان یک framework امنیتی به منظور تصدیق و تایید ارتباط دارندگان منابع (resource holders) و منابع اینترنتی شان (Internet resources) تعریف کرد (RFC6480) . با مطالعه استاندارد RFC6480 در خواهیم یافت ، متد RPKI سازو کاری برای بهبود Routing Security می باشد که از تجمیعIP Address Range ها و ASN ها از طریق Cryptographic Signature ها انجام می گردد. RKPI همچنین از گواهینامه X.509 استفاده می کند. هنگامیکه که LIR ها از RIR ها درخواست منابع می کنند این گواهی (Certificate) ها توسط RIR ها برای نگهدارندگان منابع (Resource Holder) صادر می شود . متد RPKI به اپراتور های شبکه این امکان را می دهد که یک اطلاعیه Encrypt و validate شده به منظور route announcement هایی که آنها توسط ASN و IP Prefix های خود مجاز به انتشار هستند ، ایجاد کنند. به این اطلاعیه ها Route Origin Authorizations یا به اختصار ROA گفته می شود . برای بررسی و اعتبار سنجی رنج هایی که یک AS مجاز به Advertise آنها می باشد می توانید از ابزار RIPE NCC RPKI Validator استفاده نمایید و یا با مراجعه به سایت lg.he.net شبکه AS مورد نظر را جستجو نمایید . تصویر زیر نمونه ای از رنج های مجاز به انتشار پژوهشگاه دانش‌هاي بنيادي (IPM) را مشاهده می نمایید . علامت کلید سبز نشانه ROA امضاء شده و معتبر استمطابق آنچه گفته شد RPKI تنها یکی از مراحل رسیدن به اعتبارسنجی در BGP است که در آن تنها اعتبار نگهدارنده منابع و مجوز انتشار رنج IP بررسی و تایید می شود ولیکن مسیر route ها فاقد اعتبار خواهند بود . برای اعتبار بخشی به AS-Path از متد های دیگری همچون BGPSec , ASPA , AS-Cones استفاده می شود که در حال حاضر تنها BGPsec به مرحله استاندارد سازی و پیاده سازی رسیده است و موارد دیگر به صورت پیش نویس در IETF در حال بررسی می باشند . BGPSecهمانگونه که گفته شد RPKI در برابر حملات تغییرات مسیر روت محافظتی نمی کند . برای این منظور به روشی برای تایید AS-Path نیازمندیم همچنین میبایست اطمینان حاصل شود کسی اطلاعات مربوط به مسیر منتهی به روتر های ما را دستکاری نمی کند . با استفاده از BGPsec ، پارامتر AS-Path با استفاده از گواهی (Certificate) از RPKI اپراتور به صورت رمزنگاری شده امضا می شود . به منظور اعتبار سنجی AS-Path ، روتر ها زنجیره های (Chains) مورد اطمینان از کلیه signature ها از AS-Path را تایید می کنند. به تصویر زیر دقت کنید : زنجیره کلید و امضاء در BGPsecمتد BGPSec سعی‌ بر آن دارد که اطمینان دهد BGP Update دریافت شده توسط BGP Peer بدرستی مسیری را ارائه‌ می دهد که اصل پیغام Update از فرستنده تا گیرنده طی کرده است. همانگونه که اشاره شد  IETF این استاندارد را تحت RFC8205 ارائه و در حال تکمیل آن است . پس از آن نیز استاندارد های تکمیلی در این حوزه ارائه گردید که در زیر به برخی از آنها اشاره شده است:ـ RFC 8205 - مشخصات BGPSec Protocolـ RFC 8206 - ملاحظات BGPSec برای انتقال ASـ RFC 8207 - ملاحظات عملیاتی BGPSecـ RFC 8208 - الگوریتم‌ها، کلیدها و امضاهای BGPSecـ RFC 8209 - گواهی‌نامه‌های BGPSecدر سند RFC8205 بیان شده است که BGPSec یک افزونه برای روتینگ پروتکل BGP می باشد که میتواند توسط BGP Update Message ها امنیت را برای مسیرها فراهم کند. BGPSec می تواند توسط یکPath Attribute اختیاری در BGP به‌نام BGPsec_Path ، پیاده‌سازی شود. این مشخصه حاوی یک Digital Signature می باشد که می تواند توسط هر AS که Update message را منتشر می کند ، ایجاد شود. Digital Signature به‌ ما این قابلیت را می دهد که فقط ASهای موجود در "لیست AS های Update message" اجازه Advertise کردن route را داشته‌ باشد.هدف اصلی از ایجاد BGPSec ،فراهم کردن مکملی برای BGP Origin Validation است ، تا در زمانی که عمل Origin Validation(تصدیق مبدا) انجام می شود ، بتوان بصورت همزمان از عمل Route Hijacking هم جلوگیری به عمل آورد . درصورت استفاده از BGPSec ، نیاز به استفاده از یک BGP attribute دیگر و Negotiation با دیگر eBGP Peer ها درمورد BGP capability است ؛ پس در نتیجه به مرور به Peer های ما پیشنهاد داده می شود که با یکدیگر به توافق برسند و از این پس ، با استفاده از BGPSec بایکدیگر صحبت کنند. در آینده ، Interconnected AS هایی که از BGPSec استفاده می کنند، قادر به تضمین این مورد می باشند که تمامی Routeهای Advertise شده بدرستی و بدون اشکال توزیع شده‌اند ، اگرچه هدف نهایی BGP امن شده ، رسیدن به مرحله ای است که non-BGPSec speakers کمتری در Routing Path ها وجود داشته باشد.منابع : https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdfhttps://dyn.com/blog/uk-traffic-diverted-ukraine/https://www.ripe.net/publications/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-studyhttps://dyn.com/blog/pakistan-hijacks-youtube-1/https://www.cra.ir/Portal/View/Page.aspx?PageId=8df53126-079b-4bca-b313-bbd3f9e2d732&ObjectId=9de7c856-d4d2-4166-85b2-eec54f12b397&WebpartId=3c86ca2e-19a0-4742-ad64-9f751b225d82 سید مجید هاشمی سید مجید هاشمی Tue, 17 Dec 2019 17:47:21 +0330 https://virgool.io/@m.hashemi/%D8%B1%D8%A7%D9%87-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C-%D9%82%D8%AF%D9%85-%D8%A8%D9%87-%D9%82%D8%AF%D9%85-docker-private-registery-igx2qkcmthcr داکر ریجیستری چیست ؟با فرض اینکه شما میدونید داکر چی هست و با مفاهیم اولیه مثل داکر فایل ، ایمیج ، رجیستری ، ریپوزیتوری و ... آشنایی دارید این راهنمای قدم به قدم رو شروع می کنیم . اگر این مواردی که بهش اشاره کردم رو نمیدونید و باهاش آشنا نیستید پیشنهاد می کنم مقاله دوست خوبم نریمان رو در اینجا بخونید . داکر رجیستری در حقیقت انبار (repository) ی از ایمیج های مختلف با ورژن های مختلف هست که این امکان را به کاربران میده تا با دسترسی به این انبار از ایمیج های مد نظر خودشون استفاده کنن و container شون رو اجرا کنن.در حال حاضر DockerHub یکی از قوی ترین repository های موجود برای کاربران داکر هست که می تونن به راحتی ایمیج هایی که میخوان رو ازش بگیرن. حتی این امکان وجود داره که با ساخت اکانت ، registry خودتون رو در این repository راه اندازی کنید . اما بیشتر سازمان ها و شرکت ها ترجیح میدن registry داخلی (local) خودشون رو داشته باشن تا کنترل و مدیریت قوی تری روی تمامی image هاشون داشته باشن .برای این کار نیاز هست یه docker private registry راه اندازی بشه.شاید مهمترین و اصلی ترین مزیت private registry نسبت به public registry در این باشد که مدیریت ایمیج ها کاملا در اختیار سازمان/شرکت هاست. راه اندازی داکر رجیستری داخلیخب بازم با فرض اینکه داکر رو نصب دارید و آماده هستید برای ساخت یک کانتینر ، راه اندازی یک رجیستری داخلی رو شروع می کنیم . در واقع registry خودش یک ایمیج هست که به صورت container و با دستور زیر راه اندازی میشه :$ docker run -d -p 5000:5000 --restart=always --name local_registry registry:2قاعدتاً بعد از اجرای این دستور شما با خطای "Unable to find image 'registry:2' locally" مواجه میشید و برای رفع این خطا باید با استفاده از اکانتی که در سایت داکرهاب ساختید روی سرورتون لاگین کنید . برای این کار می تونید از دستور ساده زیر استفاده کنید : $ docker loginخب بعد از اینکه با موفقیت لاگین کردین دوباره دستور ساخت کانتینر رجیستری رو اجرا کنید . بعد از اینکه پروسه pull شدن ایمیج registry تموم شد شما می تونید با کامند "docker ps" کانیتنر ایجاد شده رو ببینید : CONTAINER ID IMAGE STATUS PORTS NAMES 5f74098ecd3b registry:2 Up 4 seconds 0.0.0.0:5000->5000/tcp local_registryحالا برای تست رجیستری یک image اوبونتو رو از داکر هاب گرفته (pull) و بعد از اصلاح tag اون رو درون رجیستری داخلی مون push می کنیم . $ docker pull ubuntuخروجی دستور "docker images" رو با هم ببینیم : REPOSITORY TAG IMAGE ID CREATED SIZE ubuntu latest 775349758637 5 weeks ago 64.2MB registry 2 f32a97de94e1 9 months ago 25.8MBبا این دستور tag ایمیج مورد نظرمون رو تغیبر میدیم :$ docker image tag ubuntu localhost:5000/myubuntuهمونجور که میبینید ساختار تغییر و افزودن tag به ایمیج به صورت "hostname:port/imagename:ver" هست . حالا دیگه وقتشه که ایمیج اختصاصی خودمون رو درون رجیستری داخلی push کنیم : $ docker push localhost:5000/myubuntuو در نهایت خروجی دستور "docker images" :REPOSITORY TAG IMAGE ID SIZE ubuntu latest 775349758637 64.2MB localhost:5000/myubuntu latest 775349758637 64.2MBسوالی که شاید براتون پیش بیاد اینکه این image در کدام مسیر درون کانتینر رجیستری قرار گرفته؟ برای فهمیدن این موضوع به کانتینر local_registry وارد میشیم و محتویات مسیر زیر رو چک می کنیم : $ docker exec -it local_registry /bin/sh / # ls /var/lib/registry/docker/registry/v2/repositories/ myubuntuحال برای اینکه بفهمیم در هاست اصلی این مسیر کجاست از دستور زیر استفاده می کنیم : $ docker inspect local_registry | grep -i mounts -A10 &quotMounts&quot: [ { &quotType&quot: &quotvolume&quot, &quotName&quot: &quot44558ee189235a5...&quot, &quotSource&quot: &quot/var/lib/docker/volumes/44558ee189235a5.../_data&quot, &quotDestination&quot: &quot/var/lib/registry&quot, &quotDriver&quot: &quotlocal&quot, &quotMode&quot: &quot&quot, &quotRW&quot: true, &quotPropagation&quot: &quot&quot } $ ls /var/lib/docker/volumes/44558ee189235a5.../_data/docker/registry/v2/repositories /myubuntuنکته : در صورت نیاز می تونید مسیر های مورد نظر رو تغییر بدید ، برای این کار در زمان اجرا کردن کانتینر رجیستری از سوییچ "v /yourpath/registry:/var/lib/registry-" استفاده کنید. ساخت رجیستری با دسترسی خارجییک داکر رجیستری در محیط عملیاتی باید توسط پروتکل هایی مثل TLS امن سازی بشه و مکانیزم های دسترسی به اون رعایت بشه . در محیط هایی که از چند نود(node) داکر استفاده میشه ، همه نود ها باید به رجیستری دسترسی داشته باشن . برای این منظور نیاز هست که رجیستری بر بستر پروتکل امن TLS تنظیم بشه و به نود ها سرویس بده . این کار رو مرحله به مرحله جلو میبریم : قدم اول : ساخت گواهی self-signedهمونجور که گفتیم برای برقراری ارتباط امن بین رجیستری داخلی و نود های داکر و ایجاد بستر امن بین اونها می بایست از پروتکل های امن مثل TLS استفاده کرد. برای این منظور از opelssl برای ساخت گواهی self-signed استفاده می کنیم . برای این کار نیاز دارید که پکیج openssl روی سرورتون نصب باشه . برای ادامه مراحل زیر رو دنبال کنید :$ mkdir /etc/certs $ cd /etc/certs $ openssl req -newkey rsa:4096 -nodes -sha256 -keyout ca.key -x509 -days 365 -out ca.crtدر پروسه ساخت گواهی سوالاتی از شما پرسیده میشه که با توجه به اطلاعات خودتون بهش پاسخ بدید . بعد از تموم شدن ساخت گواهی شما دو فایل با پسوند crt. و key. خواهید داشت . قدم دوم : اجرای رجیستری بر روی پورت 443خب قدم بعدی برای داشتن یک داکر رجیستری امن ، اجرای کانیتنر رجیستری بر روی پورت 443 و استفاده از پورتکل های امن سازی هست . حتماً میدونید که قبلش باید کانتینر رجیستری قبلی رو متوقف و یا پاک کنید . برای ساخت کانتینر جدید بر روی پورت 443 دستور کمی متفاوت خواهد بود : $ docker run -d --restart=always --name registry -v /etc/certs:/certs -e REGISTRY_HTTP_ADDR=0.0.0.0:443 -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/ca.crt -e REGISTRY_HTTP_TLS_KEY=/certs/ca.key -p 443:443 registry:2خب تقریبا چیز عجیب و غریبی در دستور نیست . از سوییچ "v-" برای تعریف environment variable ها استفاده کردیم . به این صورت که فایل های Certificate رو از مسیر جاری سرور میزبان (host) به درون کانتینر اصطلاحاً bind mount کردیم و گفتیم که می خواییم این کانتینر بر روی پورت 443 اجرا بشه . خب در این مرحله یک ایمیج رو tag میزنیم و به رجیستری جدیدمون push می کنیم : $ docker tag alpine localhost:443/alpine:new_v1 $ docker push localhost:443/alpine:new_v1بعد از اینکه همچنان گواهی ساخته شده ما قابل قبول نخواهد بود به دلیل اینکه به صورت پیش فرض در داکر استفاده از پروتکل امن TLS فعال نیست و ارتباطات بین docker daemon و docker client بر بستر امن HTTPS نمی باشد . اما کانتینری که در دستور بالا اجرا کردیم اولین قدم برای فراهم کردن بستر امن ارتباطی هست و در حقیقت در دستور run فقط فایل های مربوط به Certificate رو به کانتینر معرفی کردیم تا ازشون استفاده کنه . اما قدم بعدی تنظیم docker daemon برای استفاده از گواهی های ساخته شده اس. قدم سوم : معرفی گواهی ها به Docker Daemonبرای معرفی گواهی های Custom (اختصاصی) به docker daemon باید در مسیر مشخص تمامی نود ها برید و دایرکتوری به نام registry hostname بسازید و فایل ca.crt رو در اون قرار بدید و سرویس داکر رو ریستارت کنید :$ mkdir -p /etc/docker/certs.d/localhost:443/ $ cp /etc/certs/ca.crt /etc/docker/certs.d/localhost:443/ $ systemctl restart dockerبرای اطمینان از صحت عملکرد یه ایمیج رو داخل رجیستریمون push می کنیم : $ docker push localhost:443/alpine:new_v1و حالا برای گرفتنش از رجیستری داخلی مون ایمیج رو pull می کنیم : $ docker pull localhost:443/alpine:new_v1همونطور که خواهید دید نسخه جدید تر ایمیج مورد نظر از رجیستری داخلی مون بارگزاری میشه.به زودی در بخش دوم این آموزش نحوه ی راه اندازی ساز و کار احراز هویت (Authentication) نود ها برای دسترسی به local registry رو با هم بررسی می کنیم . موفق باشیدمنبع : https://docs.docker.com/registry/deploying/ سید مجید هاشمی سید مجید هاشمی Tue, 10 Dec 2019 10:19:25 +0330 https://virgool.io/@m.hashemi/%D8%AE%D8%B7%D8%A7%DB%8C-insufficient-permissions-%D8%AF%D8%B1-vmware-workstation-ih3imx6cfofw صورت مسله : اگر شما از نرم افزار VMware Workstation استفاده کنید و از ماشین مجازیتون در وضعیت مورد نظرتون snapshot بگیرید و ماشین مجازی رو در وضعیت suspend قرار داده و سیستم میزبان (Host) رو ریست کنید ممکنه بعد از بالا اومدن سیستمتون برای اجرای ماشین های مجازیتون یا برگردوندن snapshot با خطای زیر مواجه بشید : Error restoring snapshot: Insufficient permissions.یاUnable to restore snapshot: Insufficient permissions.راه حل :این مشکل زمانی اتفاق میوفته که دایرکتوری که فایل های ماشین مجازیتون توش قرار داده تغییر داشته باشه ، وقتی این اتفاق میوفته ویندوز وضعیت دایرکتوری رو به Read-Only تغییر میده که مانع اجرای ماشین مجازی یا برگردوندن snapshot میشه . برای حل این مشکل یا باید تغییرات روی دایرکتوری رو به حالت اول برگردونید یا از کامند attrib استفاده کنید . برای این کار CMD رو باز کنید و از دستور زیر استفاده کنید : attrib -S -H -R "C:\Users\user\Documents\Virtual Machines" یه توضیح کوچیکی راجع به سوئیچ های این کامند رو در زیر میبینید : -s Clears the system attribute.-h Clears the hidden attribute.-r Clears the read-only attribute.مشخصه با این کامند و سوئیچ هاش خصیصه (attribute) های سیستمی ، پنهان شده و فقط-خواندنی اون مسیر رو حذف کردیم . نکته دیگه اینکه اگر به هر دلیل کامند attrib کار نکرد شاید نیاز باشه مقدار DWORD رو در مسیر کلید رجیستری زیر اضافه کنید : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Explorerبرای این کار می تونید از مستندات مایکروسافت که به Microsoft Knowledge Base معروف هستن کمک بگیرید . منبع : https://kb.vmware.com/s/article/2027 سید مجید هاشمی سید مجید هاشمی Sun, 06 Oct 2019 14:10:24 +0330 https://virgool.io/@m.hashemi/%D8%A7%D9%85%DA%A9%D8%A7%D9%86%D8%A7%D8%AA-%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%B4%D8%AF%D9%87-%D8%AF%D8%B1-red-hat-enterprise-linux-8-gszp4rhkjfkh ماه گذشته Red Hat Summit 019 برگزار شد و این گردهمایی با خبر ویژه انتشار رسمی RHEL 8 همراه بود . در ساختار این توزیع به روز رسانی هایی شده است . شرکت ردهت تلاش کرده است یک سیستم عامل بسیار کارآمد در همه زمینه ها ارائه کند، از کانتینرها و رایانش ابری گرفته تا هوش مصنوعی و ابزارهایی برای توسعه دهندگان که در این مستند بیشتر به آن ها خواهیم پرداخت.Kernelردهت 8 بر روی کرنل نسخه 4.18 اجرا خواهد شد و از نسخه 28 فدورا به عنوان Source Code آن استفاده شده است . از دیگر ویژگی های جدید این نسخه پشتیبانی از Control Group V2 می باشد و منابع سیستمی را به شکل بهتری در مقایسه با نسخه‌های قبل، مدیریت و توزیع می‌کند . Control Group V2 سلسله مراتبی دارد که فرایندها را براساس نقش owner دسته‌بندی کرده و سیاست‌های متضادی که به علت سلسله مراتب‌های مختلف ایجاد شده‌اند را حذف می‌کند.از دیگر قابلیت های این نسخه پشتیبانی از Paging سطح 5 می باشد که این امکان را تا میزان 4 پتابایت از Physical Memory فراهم می سازد . به RHEL 8 امکان پشتیبانی از بیش از 4 PB حافظه فیزیکی را داده است. نسخه قبل RHEL 7 صفحه‌بندی 4 سطحی داشت که اجازه فضای 256 TiB را می‌داد، که به 128 PiB افزایش یافت و درنتیجه فضای آدرس فیزیکی به بیش از 4 Pib افزایش یافت.Software Managementسیستم عامل RHEL 8 ابزار مدیریت بسته را بهبود بخشیده است و حال براساس تکنولوژی DNF (Dandified Yum) است که پیشرفته بوده و عملکرد بهتری با پشتیبانی از محتوای ماژولار، دارد. RPM نسخه 4.14 در RHEL 8 توزیع شده است و rpm حال محتوای بسته را قبل از شروع نصب، از نظر اعتبار بررسی می‌کند. پشتیبانی از فایل‌های بسته‌بندی بالای 4GB اضافه شده است.ابزار dnf اجازه نصب و به روزرسانی بسته‌ها را می‌دهد.File System and Storageفایل سیستم XFS از shared copy-on-write پشتیبانی می‌کند که اجازه به اشتراک گذاری یک مجموعه بلاک داده‌ ای برای دو فایل یا بیشتر را می‌ دهد که سریع و از نظر فضای لازم برای ذخیره‌ سازی، مفید و کارآمد است. LUKS2 جایگزین فرمت LUKS1 شده است. LUKS2 مقادیر رمز گذاری شده فراهم کرده است که از بازیابی اتوماتیک در موارد خرابی ‌های metadata ، پشتیبانی می‌کند.Cockpitواسط وب Cockpit می‌تواند برای مدیریت ماشین‌ها از راه دور استفاده شود. Cockpit با بسیاری از مرورگرهای موبایل سازگار است ، در نتیجه سیستم ‌های مدیریتی که از دستگاه های موبایل استفاده می ‌کنند، هم اکنون کاربردی می ‌شوند. صفحه Cockpit درباره به روزرسانی‌های انجام نشده هشدار می‌دهد و اطلاعاتی دراین مورد می‌دهد. واسط Cockpit می‌تواند برای اعمال قوانین رمزگشایی مبتنی بر خط مشی‌ها استفاده شود و به دیسک‌های روی سیستم‌ها نیز اعمال شود.ماشین‌های مجازی می‌توانند با استفاده از Cockpit ایجاد شده و مدیریت شوند. یکی دیگر از پیشرفت ها در این زمینه ، Networking page اجازه تغییر رول های فایروال را می‌ دهد.Replacement of nfsnobody user with nobodyدر RHEL 7 کاربر nfsnobody و nobody با 65534 و 99 ID ایجاد می گردید ، اکنون با نصب RHEL 8 تنها یک کاربر nobody با ID 65534 ساخته می شود و دیگر کاربر nfsnobody ایجاد نمی‌ کند.Databases, webservers, languages سرویس های Database و برخی Application ها در RHEL 8 :· MySQL 8.0, MariaDB 10.3, PostgreSQL 9.6 و PostgreSQL 10، Redis4· Python 3 .6 · Ruby 2.5· PHP 7.2· Perl 5.26· Apache HTTP Server 2.4.35در RHEL 8 پکیج Nginx 1.14 در Main Repository قابل دسترسی است . Desktopمحیط دسکتاپ RHEL 8 با GNOME 3.28 ساخته شده است که شامل ویژگی‌های جدیدی همانند کیبورد مجازی است که پشتیبانی بیشتری از Device ها فراهم کرده است . Wayland جایگزین X.org مربوط به نسخه قبلی RHEL شده است و صفحه نمایش پیش فرض در RHEL 8 است که مزایایی مثل پشتیبانی چند رسانه‌ ای بهبود یافته ، UI مقیاس پذیر دارد.Networkingدر این سیستم عامل nftables جایگزین iptables به عنوان ساختار فیلترینگ پیش فرض شده است که جانشین iptables ها ، arptable ها و ابزارهای ebtable شده است.پکیج nftable مزایای زیادی دارند مثلا یک ساختار تنها برای پروتکل ‌های فیلترینگ بسته ipv4 و ipv6 دارند. nftrace دیگر که فراهم شده است به debugging و tracing پروتکل ها کمک می‌کند.همچنین TCP Networking Stack نسخه 4.16 در RHEL 8 توزیع شده است که ثبات و عملکرد بهتری دارد. به طور پیش فرض، فایروال از nftable استفاده می‌کند.Virtualizationویژگی‌های جدید زیادی همانند KVM اضافه شده است که از Paging سطح 5 پشتیبانی می‌کند، اطلاعات crash اضافی در مورد crash های میزبان KVM، ذخیره ‌سازی Ceph که جدیداً پشتیبانی می‌ شود نیز اضافه شده‌ اند.سیستم عامل RHEL 8 با qemu–kvm 2.12 با ویژگی‌های جدید مثل پشتیبانی از نوع ماشین میزبان Q35، UEFI guest boot ، UEFI guest boot ، Guest I/O threading توزیع شده است.Securityپکیج OpenSSH به نسخه 7.8p1 به روز شده است که پشتیبانی ازپروتکل ssh نسخه 1 از آن حذف شده است ، بهبود در rsyslog نیز با rsyslog نسخه 8.37.0 به روز شده ، همراه است.Containers without daemonsدر RHEL 8 ، Podman و buildah aka CRI-Oرا به عنوان جایگزین Docker معرفی نموده و می‌توانند برای مدیریت کانتینر ها به کار روند.منبع : https://linuxforgeek.com/rhel-8-new-features/ سید مجید هاشمی سید مجید هاشمی Tue, 25 Jun 2019 16:40:35 +0430 https://virgool.io/@m.hashemi/%D8%AA%D8%B3%D8%AA-%D8%B3%D8%B1%D8%B9%D8%AA-%D8%AF%D8%B1-%D9%85%D8%AD%DB%8C%D8%B7-cli-%D9%84%DB%8C%D9%86%D9%88%DA%A9%D8%B3-xscxlfck2qmg سلام ، ممکنه براتون اتفاق افتاده باشه با سرور لینوکسی کار کنید که روش محیط گرافیکی یا GUI نصب نشده باشه (خب طبیعیه نبایدم نصب باشه D:) و بخوایین از سرویس Speed Test برای بررسی سرعت اینترنت سرورتون استفاده کنید . جای نگرانی نیست با یه ابزار کوچیک به اسم speedtest-cli می تونید این کار رو انجام بدید . بریم در توزیع های مختلف نصبش رو ببینیم :دستور نصبش در توزیع های خانواده Red Hat : sudo yum install python2-speedtest-cliدستور نصبش در توزیع های خانواده Debian : sudo apt install speedtest-cliخب حالا بریم نتیجه این دستور رو روی یکی از سرورهای تست رو ببینیم: [root@localhost ~]# speedtestRetrieving speedtest.net configuration...Testing from My ISP ...Retrieving speedtest.net server list...Selecting best server based on ping...Hosted by ParsOnline (Tehran): 13.431 msTesting download speed...................................................................................................Download: 0.43 Mbit/sTesting upload speed.......................................................................................................Upload: 3.96 Mbit/sخب همونجور که می بینید تست توسط ISP من و با میزبانی سرور های شرکت پارس آنلاین انجام شد . نتایج خیلی امیدوار کننده نیست ): اشکالی نداره چون این سرور عملیاتی نیست و صرفاً یه ماشین مجازی روی سیستم من هستش و محدودیت پهنای باند روش اعمال شده ... شاد باشید (: سید مجید هاشمی سید مجید هاشمی Mon, 18 Mar 2019 12:20:48 +0330