چگونه زیرساخت شبکه خود را کنترل کنیم فصل سه. امنیت شبکه. بخش دوم

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

В بخش اول در این فصل، برخی از جنبه‌های امنیت شبکه در بخش مرکز داده را بررسی کردیم. این بخش به بخش «دسترسی به اینترنت» اختصاص خواهد یافت.

چگونه زیرساخت شبکه خود را کنترل کنیم فصل سه. امنیت شبکه. بخش دوم

دسترسی به اینترنت

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

هنگام حسابرسی این بخش، به جنبه های زیر توجه کنید:

  • طرح
  • تنظیمات BGP
  • حفاظت از DOS/DDOS
  • فیلتر کردن ترافیک روی فایروال

طرح

به عنوان نمونه ای از طراحی این بخش برای یک شبکه سازمانی، من توصیه می کنم رهبری از داخل سیسکو مدل های ایمن.

البته، شاید راه حل سایر فروشندگان برای شما جذاب تر به نظر برسد (نگاه کنید به. Gartner Quadrant 2018)، اما بدون تشویق شما به دنبال کردن این طرح با جزئیات، هنوز درک اصول و ایده های پشت آن را مفید می دانم.

توجه داشته باشید

در SAFE، بخش "دسترسی از راه دور" بخشی از بخش "دسترسی به اینترنت" است. اما در این سری مقالات به طور جداگانه به بررسی آن خواهیم پرداخت.

مجموعه استاندارد تجهیزات در این بخش برای شبکه سازمانی است

  • روترهای مرزی
  • فایروال ها

تذکر 1

در این سری از مقالات، وقتی در مورد فایروال صحبت می کنم، منظورم این است NGFW.

تذکر 2

من از در نظر گرفتن انواع مختلف راه حل های L2/L1 یا پوشش L2 بر روی L3 که برای اطمینان از اتصال L1/L2 لازم است صرف نظر می کنم و خودم را فقط به مسائل در سطح L3 و بالاتر محدود می کنم. تا حدی، مسائل L1/L2 در فصل "مورد بحث قرار گرفت.نظافت و مستندسازی".

اگر در این بخش فایروال پیدا نکرده اید، نباید عجله کنید تا نتیجه گیری کنید.

بیایید همان کار را انجام دهیم قسمت قبلیبیایید با این سوال شروع کنیم: آیا استفاده از فایروال در این بخش در مورد شما ضروری است؟

می توانم بگویم که به نظر می رسد اینجا موجه ترین مکان برای استفاده از فایروال ها و اعمال الگوریتم های پیچیده فیلتر ترافیک است. که در قطعات 1 ما به 4 عاملی اشاره کردیم که ممکن است در استفاده از فایروال در بخش مرکز داده اختلال ایجاد کند. اما در اینجا آنها دیگر چندان قابل توجه نیستند.

به عنوان مثال 1. تاخیر انداختن

تا جایی که به اینترنت مربوط می شود، صحبت از تاخیر حتی در حدود 1 میلی ثانیه بی فایده است. بنابراین تأخیر در این بخش نمی تواند عامل محدود کننده استفاده از فایروال باشد.

به عنوان مثال 2. کارایی

در برخی موارد این عامل ممکن است هنوز قابل توجه باشد. بنابراین، ممکن است مجبور شوید به مقداری از ترافیک (به عنوان مثال، ترافیک از بار متعادل کننده ها) اجازه دهید تا فایروال را دور بزند.

به عنوان مثال 3. قابلیت اطمینان

این عامل هنوز باید در نظر گرفته شود، اما هنوز هم با توجه به غیرقابل اعتماد بودن خود اینترنت، اهمیت آن برای این بخش به اندازه مرکز داده قابل توجه نیست.

بنابراین، بیایید فرض کنیم که سرویس شما در بالای http/https (با جلسات کوتاه) زندگی می کند. در این صورت می توانید از دو باکس مستقل (بدون HA) استفاده کنید و در صورت مشکل مسیریابی یکی از آنها، تمام ترافیک را به دومی منتقل کنید.

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

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

مهم!

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

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

مثال

اگر شما یک ارائه‌دهنده محتوا با شبکه CDN هستید (به عنوان مثال نگاه کنید به سری مقالات، ممکن است نخواهید زیرساختی را در ده ها یا حتی صدها نقطه حضور با استفاده از دستگاه های جداگانه برای مسیریابی و فیلتر کردن ترافیک ایجاد کنید. گران خواهد بود و ممکن است به سادگی غیر ضروری باشد.

برای BGP لزوماً لازم نیست روترهای اختصاصی داشته باشید، می توانید از ابزارهای منبع باز مانند کواگا. بنابراین شاید تنها چیزی که نیاز دارید یک سرور یا چندین سرور، یک سوئیچ و BGP باشد.

در این حالت سرور شما یا چندین سرور می توانند نه تنها نقش یک سرور CDN، بلکه یک روتر را نیز ایفا کنند. البته هنوز جزئیات زیادی وجود دارد (مانند نحوه اطمینان از تعادل)، اما قابل انجام است، و این رویکردی است که ما با موفقیت برای یکی از شرکای خود استفاده کرده ایم.

شما می توانید چندین مرکز داده با حفاظت کامل (دیوارهای آتش، خدمات حفاظت DDOS ارائه شده توسط ارائه دهندگان اینترنت شما) و ده ها یا صدها نقطه حضور «ساده شده» تنها با سوئیچ ها و سرورهای L2 داشته باشید.

اما در مورد حفاظت در این مورد چطور؟

بیایید به عنوان مثال به محبوبیت اخیر نگاه کنیم تقویت DNS حمله DDOS. خطر آن در این واقعیت نهفته است که حجم زیادی از ترافیک ایجاد می شود، که به سادگی 100٪ تمام لینک های شما را مسدود می کند.

در مورد طراحی خود چه داریم؟

  • اگر از AnyCast استفاده می کنید، ترافیک بین نقاط حضور شما توزیع می شود. اگر پهنای باند کل شما ترابیت است، پس این به خودی خود در واقع (اما اخیرا چندین حمله با ترافیک مخرب به ترتیب ترابیت صورت گرفته است) شما را از "سرریز" لینک های بالا محافظت می کند.
  • با این حال، اگر برخی از لینک های آپلود مسدود شوند، به سادگی این سایت را از سرویس حذف می کنید (تبلیغ پیشوند را متوقف کنید)
  • همچنین می توانید سهم ترافیک ارسال شده از مراکز داده "کامل" (و بر این اساس، محافظت شده) خود را افزایش دهید، بنابراین بخش قابل توجهی از ترافیک مخرب را از نقاط حضور محافظت نشده حذف کنید.

و یک نکته کوچک دیگر به این مثال. اگر ترافیک کافی را از طریق IX ارسال کنید، آسیب پذیری شما در برابر چنین حملاتی نیز کاهش می یابد

راه اندازی BGP

در اینجا دو موضوع وجود دارد.

  • قابلیت اتصال
  • راه اندازی BGP

ما قبلاً کمی در مورد اتصال در صحبت کرده ایم قطعات 1. نکته این است که اطمینان حاصل کنید که ترافیک مشتریان شما مسیر بهینه را دنبال می کند. اگرچه بهینه بودن همیشه فقط مربوط به تأخیر نیست، تأخیر کم معمولاً شاخص اصلی بهینه بودن است. برای برخی از شرکت ها این مهم تر و برای برخی دیگر کمتر است. همه چیز به خدماتی که ارائه می دهید بستگی دارد.

به عنوان مثال 1

اگر شما یک صرافی هستید و فواصل زمانی کمتر از میلی ثانیه برای مشتریان شما مهم است، مطمئناً اصلاً نمی توان صحبت از هر نوع اینترنت کرد.

به عنوان مثال 2

اگر شما یک شرکت بازی هستید و ده ها میلی ثانیه برای شما مهم است، پس مطمئناً اتصال برای شما بسیار مهم است.

به عنوان مثال 3

همچنین باید بدانید که به دلیل ویژگی‌های پروتکل TCP، سرعت انتقال داده در یک جلسه TCP به RTT (زمان رفت و برگشت) نیز بستگی دارد. شبکه‌های CDN نیز برای حل این مشکل با نزدیک‌تر کردن سرورهای توزیع محتوا به مصرف‌کننده این محتوا ساخته می‌شوند.

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

منابع مفید:

ripe.net
bgp.he.net

مثال

من فقط یک مثال کوچک می زنم.

بیایید فرض کنیم که مرکز داده شما در مسکو واقع شده است و شما یک Uplink واحد دارید - Rostelecom (AS12389). در این مورد (تک خانه) شما نیازی به BGP ندارید و به احتمال زیاد از مجموعه آدرس Rostelecom به عنوان آدرس عمومی استفاده می کنید.

بیایید فرض کنیم که شما خدمات خاصی ارائه می دهید و تعداد کافی مشتری از اوکراین دارید و آنها از تاخیرهای طولانی شکایت می کنند. در طول تحقیقات خود متوجه شدید که آدرس IP برخی از آنها در شبکه 37.52.0.0/21 قرار دارد.

با اجرای یک traceroute، دیدید که ترافیک از طریق AS1299 (Telia) می‌گذرد، و با اجرای یک پینگ، میانگین RTT 70 - 80 میلی‌ثانیه دریافت می‌کنید. شما همچنین می توانید این را در Rostelecom شیشه ای.

با استفاده از ابزار whois (در ripe.net یا یک ابزار محلی)، به راحتی می توانید تعیین کنید که بلوک 37.52.0.0/21 متعلق به AS6849 (Ukrtelecom) است.

بعد، با رفتن به bgp.he.net می بینید که AS6849 هیچ رابطه ای با AS12389 ندارد (آنها نه مشتری هستند و نه پیوندهای بالا به یکدیگر دارند و نه همتاسازی دارند). اما اگر نگاه کنید لیست همتایان برای AS6849، به عنوان مثال، AS29226 (Mastertel) و AS31133 (Megafon) را خواهید دید.

پس از یافتن نمای این ارائه دهندگان، می توانید مسیر و RTT را با هم مقایسه کنید. به عنوان مثال، برای Mastertel RTT حدود 30 میلی ثانیه خواهد بود.

بنابراین، اگر تفاوت بین 80 و 30 میلی‌ثانیه برای سرویس شما قابل توجه است، شاید لازم باشد در مورد اتصال فکر کنید، شماره AS، مخزن آدرس خود را از RIPE دریافت کنید و لینک‌های آپلود اضافی را متصل کنید و/یا نقاط حضور در IX ایجاد کنید.

هنگامی که از BGP استفاده می کنید، نه تنها فرصتی برای بهبود اتصال دارید، بلکه به طور مضاعف اتصال اینترنت خود را نیز حفظ می کنید.

این سند حاوی توصیه هایی برای پیکربندی BGP است. علیرغم این واقعیت که این توصیه ها بر اساس "بهترین عملکرد" ​​ارائه دهندگان توسعه داده شده اند، با این وجود (اگر تنظیمات BGP شما کاملاً ابتدایی نیستند) بدون شک مفید هستند و در واقع باید بخشی از سخت شدنی باشند که در مورد آن بحث کردیم. بخش اول.

حفاظت از DOS/DDOS

اکنون حملات DOS/DDOS برای بسیاری از شرکت ها به یک واقعیت روزمره تبدیل شده است. در واقع، شما اغلب به یک شکل یا شکل دیگر مورد حمله قرار می گیرید. این واقعیت که شما هنوز متوجه این موضوع نشده اید، تنها به این معنی است که هنوز یک حمله هدفمند علیه شما سازماندهی نشده است، و اقدامات حفاظتی که شما استفاده می کنید، حتی شاید بدون اطلاع از آن (محافظت های داخلی مختلف سیستم عامل ها)، برای اطمینان حاصل کنید که کاهش خدمات ارائه شده برای شما و مشتریانتان به حداقل می رسد.

منابع اینترنتی وجود دارد که بر اساس گزارش های تجهیزات، نقشه های حمله زیبایی را در زمان واقعی ترسیم می کنند.

اینجا می توانید لینک های آنها را پیدا کنید.

مورد علاقه من نقشه از CheckPoint

محافظت در برابر DDOS/DOS معمولاً لایه لایه است. برای درک دلیل، باید بدانید که چه نوع حملات DOS/DDOS وجود دارد (برای مثال، به اینجا یا اینجا)

یعنی ما سه نوع حمله داریم:

  • حملات حجمی
  • حملات پروتکلی
  • حملات برنامه

اگر بتوانید خود را در برابر دو نوع حمله آخر با استفاده از فایروال‌ها محافظت کنید، نمی‌توانید از حملاتی که با هدف «غلبه‌کردن» لینک‌هایتان انجام می‌شود محافظت کنید (البته اگر ظرفیت کل کانال‌های اینترنتی شما برحسب ترابیت محاسبه نشود، یا بهتر است در ده ترابیت).

بنابراین، اولین خط دفاعی محافظت در برابر حملات "حجمی" است و ارائه دهنده یا ارائه دهندگان شما باید این محافظت را برای شما فراهم کنند. اگر هنوز متوجه این موضوع نشده اید، پس در حال حاضر فقط خوش شانس هستید.

مثال

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

در این مورد، شما باید تا حدی اتصال را در طول حمله قربانی کنید. ولی

  • این فقط برای مدت حمله است. در صورت حمله، می توانید به صورت دستی یا خودکار BGP را مجدداً پیکربندی کنید تا ترافیک فقط از طریق ارائه دهنده ای که "چتر" را در اختیار شما قرار می دهد، انجام شود. پس از پایان حمله، می توانید مسیریابی را به حالت قبلی برگردانید
  • نیازی به انتقال تمام ترافیک نیست. برای مثال، اگر می‌بینید که هیچ حمله‌ای از طریق برخی لینک‌ها یا همتاها وجود ندارد (یا ترافیک قابل توجه نیست)، می‌توانید به تبلیغ پیشوندهایی با ویژگی‌های رقابتی نسبت به این همسایگان BGP ادامه دهید.

همچنین می توانید محافظت در برابر "حملات پروتکل" و "حملات برنامه" را به شرکای خود واگذار کنید.
در اینجا این است اینجا شما می توانید یک مطالعه خوب بخوانید (ترجمه). درست است، مقاله دو ساله است، اما به شما ایده ای در مورد روش هایی می دهد که چگونه می توانید از خود در برابر حملات DDOS محافظت کنید.

در اصل، شما می توانید خود را به این محدود کنید و حفاظت خود را کاملاً برون سپاری کنید. این تصمیم مزایایی دارد، اما یک عیب آشکار نیز دارد. واقعیت این است که ما می توانیم (باز هم بسته به اینکه شرکت شما چه می کند) در مورد بقای کسب و کار صحبت کنیم. و به اشخاص ثالث اعتماد کنید...

بنابراین، بیایید به نحوه سازماندهی خطوط دفاعی دوم و سوم (به عنوان افزودنی برای محافظت از ارائه دهنده) نگاه کنیم.

بنابراین، دومین خط دفاعی فیلترینگ و محدود کننده های ترافیک (پلیس) در ورودی شبکه شما است.

به عنوان مثال 1

بیایید فرض کنیم که با کمک یکی از ارائه دهندگان، خود را با یک چتر در برابر DDOS پوشانده اید. بیایید فرض کنیم که این ارائه دهنده از Arbor برای فیلتر کردن ترافیک و فیلترها در لبه شبکه خود استفاده می کند.

پهنای باندی که Arbor می تواند "پردازش" کند، محدود است و ارائه دهنده، البته، نمی تواند به طور مداوم ترافیک تمام شرکای خود را که این سرویس را سفارش می دهند از طریق تجهیزات فیلتر عبور دهد. بنابراین در شرایط عادی ترافیک فیلتر نمی شود.

بیایید فرض کنیم یک حمله سیل SYN وجود دارد. حتی اگر سرویسی را سفارش داده باشید که در صورت حمله، ترافیک را به‌طور خودکار به فیلتر کردن تغییر می‌دهد، این بلافاصله اتفاق نمی‌افتد. برای یک دقیقه یا بیشتر در معرض حمله قرار می گیرید. و این می تواند منجر به خرابی تجهیزات شما یا تخریب سرویس شود. در این حالت، محدود کردن ترافیک در مسیریابی لبه، اگرچه منجر به عدم برقراری برخی از جلسات TCP در این مدت می شود، اما زیرساخت شما را از مشکلات بزرگتر نجات می دهد.

به عنوان مثال 2

تعداد غیرعادی زیادی از بسته های SYN ممکن است نه تنها نتیجه یک حمله سیل SYN باشد. بیایید فرض کنیم که شما سرویسی ارائه می دهید که در آن می توانید به طور همزمان حدود 100 هزار اتصال TCP (به یک مرکز داده) داشته باشید.

فرض کنید در نتیجه یک مشکل کوتاه مدت با یکی از ارائه دهندگان اصلی شما، نیمی از جلسات شما از بین می رود. اگر برنامه شما به گونه ای طراحی شده است که بدون دوبار فکر کردن، بلافاصله (یا پس از مدتی فاصله زمانی که برای همه جلسات یکسان است) سعی در برقراری مجدد اتصال کند، حداقل 50 هزار بسته SYN تقریباً دریافت خواهید کرد. همزمان.

برای مثال، اگر مجبور باشید در بالای این جلسات، که شامل مبادله گواهی‌ها می‌شود، دست دادن ssl/tls را اجرا کنید، از نقطه نظر کاهش منابع برای متعادل‌کننده بار، این یک «DDOS» بسیار قوی‌تر از یک ساده خواهد بود. سیل SYN. به نظر می رسد که متعادل کننده ها باید از عهده چنین اتفاقاتی برآیند، اما... متاسفانه ما با چنین مشکلی مواجه هستیم.

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

سومین سطح محافظت در برابر DDOS/DOS تنظیمات فایروال شماست.

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

نکته

سعی کنید تا حد امکان به فایروال کمتر کار کنید و تا حد امکان در دو خط دفاعی اول فیلتر کنید. و به همین دلیل.

آیا تا به حال برای شما اتفاق افتاده است که به طور تصادفی، هنگام ایجاد ترافیک برای بررسی، به عنوان مثال، مقاومت سیستم عامل سرورهای شما در برابر حملات DDOS، فایروال خود را "کشت" کنید، آن را تا 100 درصد بارگذاری کنید، با ترافیک با شدت عادی. ? اگر نه، شاید به این دلیل است که شما امتحان نکرده اید؟

به طور کلی، فایروال، همانطور که گفتم، چیز پیچیده ای است و با آسیب پذیری های شناخته شده و راه حل های آزمایش شده به خوبی کار می کند، اما اگر چیزی غیرعادی ارسال کنید، فقط مقداری زباله یا بسته هایی با هدرهای نادرست، آنگاه با برخی هستید، نه با با چنین احتمال کمی (بر اساس تجربه من)، می توانید حتی تجهیزات سطح بالا را هم خفه کنید. بنابراین، در مرحله 2، با استفاده از ACL های معمولی (در سطح L3/L4)، تنها به ترافیکی که باید وارد شبکه شما شود اجازه دهید.

فیلتر کردن ترافیک روی فایروال

بیایید گفتگو را در مورد فایروال ادامه دهیم. باید بدانید که حملات DOS/DDOS تنها یکی از انواع حملات سایبری هستند.

علاوه بر محافظت از DOS/DDOS، می‌توانیم چیزی شبیه به لیست زیر از ویژگی‌ها نیز داشته باشیم:

  • فایروال برنامه
  • پیشگیری از تهدید (آنتی ویروس، ضد جاسوس افزار و آسیب پذیری)
  • فیلتر کردن URL
  • فیلتر کردن داده ها (فیلتر محتوا)
  • مسدود کردن فایل (انواع فایل مسدود شده)

این شما هستید که تصمیم می گیرید از این لیست به چه چیزی نیاز دارید.

ادامه

منبع: www.habr.com

اضافه کردن نظر