Тази статия е четвъртата от поредицата „Как да поемете контрола над вашата мрежова инфраструктура“. Можете да намерите съдържанието на всички статии от поредицата и връзките тук.

В първата част В тази глава разгледахме някои аспекти на мрежовата сигурност в сегмента на центъра за данни. Тази част ще бъде посветена на сегмента „Достъп до Интернет“.

Достъп до Интернет

Темата за сигурността несъмнено е една от най-сложните теми в света на мрежите за данни. Както и в предишните случаи, без да претендирам за дълбочина и пълнота, тук ще разгледам доста прости, но според мен важни въпроси, отговорите на които, надявам се, ще помогнат за повишаване на нивото на сигурност на вашата мрежа.

Когато одитирате този сегмент, обърнете внимание на следните аспекти:

• дизайн
• BGP настройки
• DOS/DDOS защита
• филтриране на трафика на защитната стена

Дизайн

Като пример за дизайна на този сегмент за корпоративна мрежа бих препоръчал ръководство от Cisco в рамките БЕЗОПАСНИ модели.

Разбира се, може би решението на други доставчици ще ви изглежда по-привлекателно (вижте. Квадрант на Gartner 2018 г), но без да ви насърчавам да следвате този дизайн в детайли, все пак намирам за полезно да разбера принципите и идеите зад него.

забележка

В SAFE сегментът „Отдалечен достъп“ е част от сегмента „Достъп до Интернет“. Но в тази поредица от статии ще го разгледаме отделно.

Стандартният набор от оборудване в този сегмент за корпоративна мрежа е

• гранични рутери
• защитни стени

Забележка 1

В тази поредица от статии, когато говоря за защитни стени, имам предвид NGFW.

Забележка 2

Пропускам разглеждането на различни видове L2/L1 или наслагване на L2 върху L3 решения, необходими за осигуряване на L1/L2 свързаност, и се ограничавам само до проблеми на ниво L3 и по-високо. Частично проблемите на L1/L2 бяха обсъдени в главата „Почистване и документация".

Ако не сте намерили защитна стена в този сегмент, тогава не трябва да бързате със заключенията.

Да направим същото като в предишна частДа започнем с въпроса: необходимо ли е използването на защитна стена в този сегмент във вашия случай?

Мога да кажа, че това изглежда най-оправданото място за използване на защитни стени и прилагане на сложни алгоритми за филтриране на трафика. IN 1 части Споменахме 4 фактора, които могат да попречат на използването на защитни стени в сегмента на центровете за данни. Но тук те вече не са толкова значими.

Пример 1. закъснение

Що се отнася до интернет, няма смисъл да говорим за закъснения дори от около 1 милисекунда. Следователно забавянето в този сегмент не може да бъде фактор, ограничаващ използването на защитната стена.

Пример 2. продуктивност

В някои случаи този фактор все още може да бъде значителен. Следователно може да се наложи да позволите на известен трафик (например трафик от балансиращите на натоварването) да заобиколи защитната стена.

Пример 3. Надеждност

Този фактор все още трябва да се вземе предвид, но все пак, като се има предвид ненадеждността на самия интернет, значението му за този сегмент не е толкова голямо, колкото за центъра за данни.

И така, нека приемем, че вашата услуга живее върху http/https (с кратки сесии). В този случай можете да използвате две независими кутии (без HA) и ако има проблем с маршрутизирането с една от тях, прехвърлете целия трафик към втората.

Или можете да използвате защитни стени в прозрачен режим и, ако не успеят, да позволите на трафика да заобиколи защитната стена, докато решавате проблема.

Следователно най-вероятно просто цена може да бъде факторът, който ще ви принуди да се откажете от използването на защитни стени в този сегмент.

Важно!

Има изкушение да комбинирате тази защитна стена със защитната стена на центъра за данни (използвайте една защитна стена за тези сегменти). Решението по принцип е възможно, но трябва да разберете това, защото Защитната стена за достъп до интернет всъщност е в челните редици на вашата защита и „поема“ поне част от злонамерения трафик, тогава, разбира се, трябва да вземете предвид повишения риск тази защитна стена да бъде деактивирана. Тоест, като използвате едни и същи устройства в тези два сегмента, вие значително ще намалите наличността на вашия сегмент от център за данни.

Както винаги, трябва да разберете, че в зависимост от услугата, която компанията предоставя, дизайнът на този сегмент може да варира значително. Както винаги, можете да изберете различни подходи в зависимост от вашите изисквания.

Пример

Ако сте доставчик на съдържание с CDN мрежа (вижте например поредица от статии), тогава може да не искате да създавате инфраструктура в десетки или дори стотици точки на присъствие, като използвате отделни устройства за маршрутизиране и филтриране на трафика. Ще бъде скъпо и може просто да е ненужно.

За BGP не е задължително да имате специални рутери, можете да използвате инструменти с отворен код като Куага. Така че може би всичко, от което се нуждаете, е сървър или няколко сървъра, суич и BGP.

В този случай вашият сървър или няколко сървъра могат да играят ролята не само на CDN сървър, но и на рутер. Разбира се, има още много подробности (като например как да се осигури балансиране), но това е изпълнимо и това е подход, който успешно използвахме за един от нашите партньори.

Можете да имате няколко центъра за данни с пълна защита (защитни стени, услуги за защита от DDOS, предоставени от вашите интернет доставчици) и десетки или стотици „опростени“ точки на присъствие само с L2 комутатори и сървъри.

Но какво да кажем за защитата в този случай?

Нека разгледаме, например, популярните напоследък DNS Amplification DDOS атака. Опасността му се крие във факта, че се генерира голямо количество трафик, който просто „запушва“ 100% от всичките ви връзки нагоре.

Какво имаме в случая с нашия дизайн.

• ако използвате AnyCast, тогава трафикът се разпределя между вашите точки на присъствие. Ако общата ви честотна лента е терабита, тогава това само по себе си всъщност (обаче наскоро имаше няколко атаки със злонамерен трафик от порядъка на терабита) ви предпазва от „препълване“ на връзките нагоре
• Ако обаче някои връзки нагоре се задръстят, тогава просто премахвате този сайт от обслужване (спрете да рекламирате префикса)
• можете също да увеличите дела на трафика, изпратен от вашите „пълни“ (и съответно защитени) центрове за данни, като по този начин премахнете значителна част от злонамерения трафик от незащитени точки на присъствие

И още една малка забележка към този пример. Ако изпращате достатъчно трафик през IXs, това също намалява уязвимостта ви към подобни атаки

Настройка на BGP

Тук има две теми.

• Свързаност
• Настройка на BGP

Вече говорихме малко за свързаността в 1 части. Въпросът е да гарантирате, че трафикът към вашите клиенти следва оптималния път. Въпреки че оптималността не винаги е само латентност, ниската латентност обикновено е основният индикатор за оптималност. За някои компании това е по-важно, за други е по-малко. Всичко зависи от услугата, която предоставяте.

Пример 1

Ако сте борса и времеви интервали от по-малко от милисекунди са важни за вашите клиенти, тогава, разбира се, изобщо не може да се говори за какъвто и да е вид интернет.

Пример 2

Ако сте компания за игри и десетките милисекунди са важни за вас, тогава, разбира се, свързаността е много важна за вас.

Пример 3

Трябва също така да разберете, че поради свойствата на TCP протокола, скоростта на трансфер на данни в рамките на една TCP сесия също зависи от RTT (Round Trip Time). CDN мрежите също се изграждат за решаване на този проблем чрез преместване на сървърите за разпространение на съдържание по-близо до потребителя на това съдържание.

Изследването на свързаността е интересна тема сама по себе си, достойна за собствена статия или серия от статии и изисква добро разбиране на това как „работи“ интернет.

Полезни ресурси:

ripe.net
bgp.he.net

Пример

Ще дам само един малък пример.

Да приемем, че вашият център за данни се намира в Москва и имате една връзка нагоре - Rostelecom (AS12389). В този случай (single homed) нямате нужда от BGP и най-вероятно използвате адресния пул от Rostelecom като публични адреси.

Да предположим, че предоставяте определена услуга и имате достатъчен брой клиенти от Украйна и те се оплакват от големи закъснения. По време на вашето проучване открихте, че IP адресите на някои от тях са в мрежата 37.52.0.0/21.

Като изпълните traceroute, видяхте, че трафикът минава през AS1299 (Telia), и като изпълните ping, получихте средно RTT от 70 - 80 милисекунди. Можете също да видите това на огледало Rostelecom.

Използвайки помощната програма whois (на ripe.net или местна помощна програма), можете лесно да определите, че блок 37.52.0.0/21 принадлежи на AS6849 (Ukrtelecom).

След това, като отидете на bgp.he.net виждате, че AS6849 няма връзка с AS12389 (те не са нито клиенти, нито връзки един към друг, нито имат peering). Но ако погледнете списък с връстници за AS6849 ще видите например AS29226 (Mastertel) и AS31133 (Megafon).

След като намерите огледалото на тези доставчици, можете да сравните пътя и RTT. Например за Mastertel RTT ще бъде около 30 милисекунди.

Така че, ако разликата между 80 и 30 милисекунди е значителна за вашата услуга, тогава може би трябва да помислите за свързаност, да вземете своя AS номер, вашия адресен пул от RIPE и да свържете допълнителни връзки нагоре и/или да създадете точки на присъствие на IXs.

Когато използвате BGP, вие не само имате възможност да подобрите свързаността, но също така излишно поддържате вашата интернет връзка.

Този документ съдържа препоръки за конфигуриране на BGP. Въпреки факта, че тези препоръки са разработени въз основа на „най-добрите практики“ на доставчиците, все пак (ако настройките ви за BGP не са съвсем основни) те несъмнено са полезни и всъщност трябва да бъдат част от втвърдяването, което обсъждахме в първата част.

DOS/DDOS защита

Сега DOS/DDOS атаките са станали ежедневна реалност за много компании. Всъщност вие сте атакувани доста често под една или друга форма. Фактът, че все още не сте забелязали това означава само, че все още не е организирана целенасочена атака срещу вас и че инструментите за защита, които използвате, дори може би без да го знаете (различни вградени защити на операционни системи), достатъчни да гарантира, че влошаването на предоставяната услуга е сведено до минимум за вас и вашите клиенти.

Има интернет ресурси, които въз основа на регистрационните файлове на оборудването рисуват красиви карти за атака в реално време.

Тук можете да намерите връзки към тях.

Любимата ми карта от CheckPoint.

Защитата срещу DDOS/DOS обикновено е многослойна. За да разберете защо, трябва да разберете какви видове DOS/DDOS атаки съществуват (вижте например тук или тук)

Тоест имаме три вида атаки:

• обемни атаки
• протоколни атаки
• атаки на приложения

Ако можете да се предпазите от последните два типа атаки, използвайки например защитни стени, тогава не можете да се предпазите от атаки, насочени към „претоварване“ на вашите връзки нагоре (разбира се, ако общият ви капацитет на интернет каналите не се изчислява в терабити, или още по-добре, в десетки терабита).

Следователно, първата линия на защита е защитата срещу „обемни“ атаки и вашият доставчик или доставчици трябва да ви осигурят тази защита. Ако все още не сте осъзнали това, значи засега сте просто късметлии.

Пример

Да приемем, че имате няколко връзки нагоре, но само един от доставчиците може да ви осигури тази защита. Но ако целият трафик минава през един доставчик, тогава какво да кажем за свързаността, която накратко обсъдихме малко по-рано?

В този случай ще трябва частично да пожертвате свързаността по време на атаката. Но

• това е само за времето на атаката. В случай на атака можете ръчно или автоматично да преконфигурирате BGP, така че трафикът да минава само през доставчика, който ви предоставя „чадъра“. След като атаката приключи, можете да върнете маршрута в предишното му състояние
• Не е необходимо да прехвърляте целия трафик. Ако например видите, че няма атаки през някои връзки нагоре или пиъринг (или трафикът не е значителен), можете да продължите да рекламирате префикси с конкурентни атрибути към тези BGP съседи.

Можете също така да делегирате защита от „атаки на протоколи“ и „атаки на приложения“ на вашите партньори.
тук е тук можете да прочетете добро проучване (превод). Вярно, че статията е на две години, но ще ви даде представа за подходите как можете да се предпазите от DDOS атаки.

По принцип можете да се ограничите до това, като напълно възложите защитата си на външни изпълнители. Това решение има предимства, но има и очевиден недостатък. Факт е, че можем да говорим (отново в зависимост от това какво прави вашата компания) за оцеляването на бизнеса. И доверете такива неща на трети страни...

Затова нека да разгледаме как да организираме втората и третата линия на защита (като допълнение към защитата от доставчика).

И така, втората линия на защита е филтриране и ограничители на трафика (полицаи) на входа на вашата мрежа.

Пример 1

Да предположим, че сте се покрили с чадър срещу DDOS с помощта на някой от доставчиците. Да приемем, че този доставчик използва Arbor за филтриране на трафика и филтри в края на своята мрежа.

Ширината на честотната лента, която Arbor може да „обработи“, е ограничена и доставчикът, разбира се, не може постоянно да пропуска трафика на всички свои партньори, които поръчват тази услуга, чрез филтриращо оборудване. Следователно при нормални условия трафикът не се филтрира.

Да приемем, че има SYN flood атака. Дори ако сте поръчали услуга, която автоматично превключва трафика към филтриране в случай на атака, това не се случва моментално. За минута или повече оставате атакувани. А това може да доведе до отказ на вашето оборудване или влошаване на услугата. В този случай ограничаването на трафика при крайното маршрутизиране, въпреки че ще доведе до факта, че някои TCP сесии няма да бъдат установени през това време, ще спаси вашата инфраструктура от по-мащабни проблеми.

Пример 2

Ненормално голям брой SYN пакети може да не е само резултат от SYN flood атака. Да приемем, че предоставяте услуга, в която можете едновременно да имате около 100 хиляди TCP връзки (към един център за данни).

Да кажем, че в резултат на краткотраен проблем с един от основните ви доставчици, половината от вашите сесии са изхвърлени. Ако вашето приложение е проектирано по такъв начин, че без да мисли два пъти, то незабавно (или след известен интервал от време, който е еднакъв за всички сесии) се опитва да възстанови връзката, тогава ще получите приблизително поне 50 хиляди SYN пакета едновременно.

Ако, например, трябва да стартирате ssl/tls ръкостискане върху тези сесии, което включва обмен на сертификати, тогава от гледна точка на изчерпване на ресурсите за вашия балансьор на натоварването, това ще бъде много по-силен „DDOS“, отколкото обикновен SYN наводнение. Изглежда, че балансьорите трябва да се справят с подобни събития, но... за съжаление сме изправени пред такъв проблем.

И, разбира се, полицай на крайния рутер ще спаси вашето оборудване и в този случай.

Третото ниво на защита срещу DDOS/DOS са настройките на вашата защитна стена.

Тук можете да спрете и двете атаки от втория и третия тип. Като цяло тук може да се филтрира всичко, което достига до защитната стена.

съвет

Опитайте се да дадете на защитната стена възможно най-малко работа, като филтрирате възможно най-много на първите две линии на защита. И ето защо.

Случвало ли ви се е случайно, докато генерирате трафик, за да проверите например доколко операционната система на вашите сървъри е устойчива на DDOS атаки, да „убиете“ защитната си стена, зареждайки я на 100 процента, с нормална интензивност на трафика ? Ако не, може би просто защото не сте опитвали?

Като цяло защитната стена, както казах, е сложно нещо и работи добре с известни уязвимости и тествани решения, но ако изпратите нещо необичайно, просто някакъв боклук или пакети с неправилни заглавки, тогава вие сте с някои, а не с такава малка вероятност (въз основа на моя опит), можете да зашеметите дори оборудване от най-висок клас. Следователно, на етап 2, използвайки обикновени ACL (на ниво L3/L4), разрешавайте само трафик във вашата мрежа, който трябва да влезе там.

Филтриране на трафика на защитната стена

Нека продължим разговора за защитната стена. Трябва да разберете, че DOS/DDOS атаките са само един вид кибератака.

В допълнение към DOS/DDOS защитата, можем да имаме и нещо като следния списък с функции:

• защитна стена на приложението
• предотвратяване на заплахи (антивирус, антишпионски софтуер и уязвимост)
• URL филтриране
• филтриране на данни (филтриране на съдържание)
• блокиране на файлове (блокиране на типове файлове)

От вас зависи да решите какво ви трябва от този списък.

За да се продължи

Източник: www.habr.com