وقتی در اوایل سال 2000 سفر خود را در بخش فناوری شروع کردم ، دنیای شبکه از ساختارهای ساده ای تشکیل شده است. من به یاد می آورم چندین سایت شعبه استاندارد را که به یک دفتر مرکزی متصل هستند پیکربندی کرده است. فقط تعداد معدودی از رزمندگان از راه دور بودند که به آنها اعزام می شدند و معمولاً فقط چند مقام عالی رتبه.
با افزایش وابستگی به شبکه ، همین مسئله باعث پیچیدگی طراحی شبکه شد. یک سایت واحد استاندارد با اتصال افزون به ارائه دهندگان مختلف ، تکنیک های پیشرفته عدم موفقیت و طراحی در دسترس بالا ، پایه و اساس دوگانه شد. تعداد کارگران از راه دور افزایش یافت و سرانجام ، در طراحی شبکه من سوراخ های امنیتی باز شد.
متأسفانه پیشرفت های اتصال به شبکه با پیشرفت های مناسب در زمینه امنیت همراه نبود و همه افراد را مجبور به بازگشت به صفحه ترسیم کرد. بدون امنیت کافی ، اتصال شبکه ای که به صورت پیش فرض در اختیار شما قرار دارد ، کاملاً ناامن است و قادر به تأیید اعتبار منبع یا امنیت بسته های جداگانه نیست. اگر نمی توانید به شبکه اعتماد کنید ، باید به نوعی آن را تأمین کنید. ما اتصالات را از طریق واسطه های نا امن برقرار کردیم که منجر به اجرای VPN های مبتنی بر IPSec به همراه تمام چمدان های پیچیده آنها شد.
انواع فروشندگان SD-WAN وجود دارد که تقسیم ترافیک را به عنوان سرویس اصلی ارائه می دهند. با این وجود ، این امر به روش های مختلفی قابل اجرا است. برخی با اصول اولیه IPSec پیاده سازی می کنند ، برخی دیگر به امنیت لایه حمل و نقل دیتاگرام (DTLS) حرکت می کنند و شرکت هایی مانند مجموعه ویژگی های شبکه Lavelle از یک مکانیسم اختصاصی تونل سازی استفاده می کنند.
از تجربیات گذشته من ، معرفی پیچیدگی دشمن شماره یک امنیت است. . تمام پارامترهای پیکربندی VPN مبتنی بر IPSec مرا از چاقوی ارتش سوئیس یادآوری می کند. این می تواند بسیاری از کارها را انجام دهد اما هیچ کس خیلی خوب نیست.
به طور مشابه ، IPSec از جهات مختلفی کوتاه می آید. بخش های متحرک زیادی بین هواپیماهای کنترل و داده وجود دارد. این تاریخچه طولانی از مشکلات قابلیت همکاری دارد که با طراحی شبکه های پیشرفته سطح آن را به چالش می کشد. در نتیجه ، عدم وجود معیارهای عملکرد باعث می شود IPSec را به عنوان یک چارچوب امنیتی ضعیف ارزیابی کنم. بگذارید نقص های اصلی IPSec را که IPSec را به عنوان یک چاقوی لشکر ارتش سوئیس در نظر می گیرد ، مرور کنیم.
بسیاری از قسمت های متحرک منجر به سازش می شوند
IPSec شامل مجموعه ای از پروتکل هایی است که یک کانال کنترل و سپس یک کانال داده را آغاز می کنند. هر دو کانال ابتدا باید همزمان شوند. در نتیجه ، بسیاری از قطعات متحرک قبل از تبادل ایمن داده ها وجود دارد.
هواپیمای کنترل تبادل کلید اینترنت (IKE) از پروتکل داده های کاربر کاربر (UDP) برای حمل و نقل استفاده می کند. مانند سایر هواپیماهای کنترلی ، این مورد نیاز به ایجاد و نگهداری دارد ، و نگهداری دولت را ایجاد می کند ، که خود می تواند قربانی یک حمله شود.
اولین بار شبکه ای را که در آن شرکت داشتم به یاد دارم هک شد. این به دلیل پیش فرض تنبل یک مدیر غیرمجاز است که پیکربندی VPN مبتنی بر IPSec یک شریک را تنظیم کرده است. تنظیمات IKE ناپاک برای بازیگر بد بهشت است و درها را باز می کند. هنگامی که یک بازیگر خوب ماهر شبکه را به خطر بیاندازد ، بازیگر بد می تواند به راحتی از مکانیسم های دفاعی استاندارد دور بزند در حالی که به صورت جانبی در سراسر شبکه حرکت می کند. این منجر به نقض داده ها و لایه برداری می شود ، که غالباً ماه ها مورد توجه قرار نمی گیرد.
متخصصان امنیت باید اقدامات لازم را برای اطمینان از محافظت از فرایند IKE انجام دهند. در یک شبکه یا لوازم امنیتی ، این ممکن است تعدادی از پارامترهای مختلف پیکربندی مانند زیرساخت ACL یا پلیس کنترل هواپیما (CoPP) را شامل شود.
IKEv1 مدت زمان طولانی است و هکرها ابزارهایی را برای حمله به مذاکرات آن ایجاد کرده اند. IKEv2 نسبت به IKEv1 از امنیت بیشتری برخوردار است اما با عقب سازگار نیست. اجرای IKEv2 نیز بسیار اخیر است ، بنابراین ما درسهایی از پروتکل و مسائل مربوط به سازگاری با آن آموخته ایم.
قابلیت همکاری
اگر یک فروشنده از این دستگاه ها تجهیزات و لوازم نهایی را ارائه می داد. IPSec به این اندازه مشکل ساز نبود. آیا تاکنون سعی کرده اید یک VPN مبتنی بر IPSec بین فروشندگان مختلف ایجاد کنید؟ به عنوان مثال ، یک روتر IOS Cisco و یک Juniper NetScreen یا Apple MAC به یک سیستم عامل مایکروسافت؟
از حافظه ، ایجاد یک VPN سایت به سایت بین یک روتر IOS Cisco و یک دستگاه Juniper NetScreen کار من را در آخر هفته ها کشید. . این سر و صداهای بیش از حد ایجاد کرد و سرانجام ، یک بار همه اردک ها را پشت سر هم کردم ، مشکل پوسته پوسته و سخت بود. استانداردهای IPSec وجود دارد که فروشندگان باید از آنها پیروی کنند اما از راههای مختلفی قابل اجرا هستند. بسیاری از فروشندگان برای برآورده کردن الزامات خاص ، عملکردهای دیگری را اضافه می کنند ، در نتیجه ، به پیچیدگی می افزایند.
من خودم بارها شلیک کرده ام. زمینه صدور گواهینامه را می توان متفاوت تفسیر کرد ، عدم تطابق پارامترهای پیش فرض ، پشتیبانی از الگوریتم های مختلف رمزگذاری و فشرده سازی منجر به سردرد و شبهای طولانی شد. هرچه قابلیت تعامل شما با سایر سیستم ها بیشتر باشد ، راه اندازی آن پیچیده تر خواهد بود. این پیچیدگی به خودی خود می تواند به یک خطر امنیتی تبدیل شود.
چالش هایی با طرح های پیشرفته
IPSec در مورد ارتباطات چند سایت پیچیده و در دسترس بودن زیاد به اندازه کافی خوب نیست. به طور پیش فرض ، IPSec طراحی استاتیک را نشان می دهد ، برای معماری پیشرفته چابک ، باید با پروتکل های سطح بالاتر همراه شود. علاوه بر این ، klud های اضافی لازم برای کارکرد IPSec به پیچیدگی شبکه افزوده است که برای امنیت امنیت قاتل است.
IPSec معماری نقطه به نقطه است نه سایت به سایت. این امر منجر به پیچیدگی در هنگام داشتن یک سایت متصل دوگانه ، تعدادی پیوند به ارائه دهندگان خدمات مختلف می شود. IPSec در صورت داشتن پیوندهای اضافی عملکرد خوبی ندارد. در صورت نیاز به عدم موفقیت IPSec ، باید پروتکل مسیریابی را اضافه کنید یا از مکانیزم افزودنی دیگری استفاده کنید. با این حال ، اینها باید به درستی یکپارچه شوند و بنابراین ، عیب یابی پیچیده می شود.
شکی نیست که ترجمه آدرس شبکه (NAT) جایی در مسیر شبکه خواهد بود. NAT مواردی مانند آدرس IP ، بررسی هدر ، شماره درگاه ، شماره دنباله TCP را تغییر می دهد ، اتصال به پایان را قطع می کند. IPSec سنتی را نمی توان از طریق یک دستگاه Nat ارسال کرد و از بین رفتن اتصال کامل به پایان می تواند باعث قابلیت همکاری با تنظیمات NAT شود. راه حل هایی وجود دارد اما در عین حال ، ممکن است همه فروشندگان آنها را پیاده سازی نکنند.
من به تعدادی از وسایل فروشنده مراجعه کردم که از ترافیک چند مرحله ای در داخل تونل IPSec پشتیبانی نمی کنند. این کار مرا مجبور به استفاده از محوطه سازی مسیریابی عمومی (GRE) کرد. GRE لایه دیگری از پیچیدگی را با پتانسیل مسیریابی بازگشتی اضافه می کند و از این طریق باعث ایجاد فلپ های GRE می شود. در اصل ، من مجبورم IPSec را برای شبکه های با اندازه کوچک و GRE بیش از IPSec برای شبکه های متوسط و بزرگ پیکربندی کنم.
عدم وجود متریک عملکرد
اگر تونل های IPSec اضافی را پیکربندی کرده اید ، انتخاب تونل IPSec مبتنی بر یک هوشمند نیست. متریک با این حال ، برنامه های امروز معیارهای هوشمند را بطور پیش فرض ضمانت می کنند. برای مثال ، IPSec کیفیت لینک ، تأخیر یا افت بسته را در نظر نمی گیرد. تا زمانی که تونل به ضربان قلب ساده ای پاسخ دهد ، فقط می تواند فکر کند که کارش خوب است ، بنابراین ، معیارهای عملکرد کلیدی لینک را از دست نمی دهد.
چارچوب های قدیمی مانند IPSec به اندازه کافی مناسب برای پشتیبانی از الزامات چالاکی امروز نیستند. شبکه های چابک نیاز به یک رویکرد جدید برای امنیت دارند و IPSec لایه های زیادی دارد که باید کاملاً درک شود. در اصل ، به جای سخت شدن دروازه های شبکه ، به دلیل داشتن پیکربندی های پیچیده و متنوع ، به طور بالقوه آنها را باز می کند. مطمئناً یک کفش هنگام تنظیم IPSec مناسب نیست.
این مقاله به عنوان بخشی از شبکه مشارکت کنندگان IDG منتشر می شود. می خواهید بپیوندید؟
