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

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

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

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

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

дизайн
настройките на BGP
Защита от DOS/DDOS
филтрацията на трафика на фаервола

Дизайн

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

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

Бележка
В SAFE, сегментът „Remote Access“ е част от „Internet Access“. Но в тази поредица от статии ние ще го разглеждаме отделно.

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

гранични маршрутизатори (border routers)
фаерволи

Забележка 1
В тази поредица от статии, когато говоря за фаерволи, имам предвид NGFW.

Забележка 2
Пропускам разглеждането на различни L2/L1 или оверлейни L2 over L3 решения, необходими за осигуряване на L1/L2 свързаност и се ограничавам само до въпросите на ниво L3 и нагоре. Отчасти въпросите L1/L2 бяха разгледани в глава „Почистване и документиране«.

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

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

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

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

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

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

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

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

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

Пример
Ако вие сте доставчик на съдържание, с мрежа CDN (вижте, например, серия от статии), така че може да не искате да изграждате десетки, а дори стотици точки за присъствие на инфраструктурата с помощта на отделни устройства за маршрутизиране и филтриране на трафик. Това ще е скъпо и би могло просто да е излишно.
За BGP не е абсолютно необходимо да имате отделни маршрутизатори, можете да използвате open-source инструменти, например, Quagga. Така че, вероятно всичко, от което се нуждаете, е един или няколко сървъра, превключвател и BGP.
В този случай вашият сървър или няколко сървъра могат да играят роля не само на CDN сървър, но и на маршрутизатор. Разбира се, има много детайли (например как да осигурите балансировка), но това е осъществимо и този подход успешно го приложихме за един от нашите партньори.
Можете да имате няколко дата центъра с пълна защита (фаерволове, услуги за защита от DDoS, предоставяни от вашите интернет доставчици) и десетки или стотици «опростени» точки за присъствие, само с L2 превключватели и сървъри.
А какво ще кажете за защитата в този случай?
Нека разгледаме, например, популярната напоследък DDoS атака с DNS усилване. Нейната опасност се състои в това, че се генерира голямо количество трафик, който просто «задръства» 100% от вашите uplinks.
Какво имаме в случая на нашия дизайн.

Ако използвате AnyCast, трафикът се разпределя между вашите точки за присъствие. Ако общата пропускателна способност е терабити, това само по себе си фактически (все пак напоследък имаше няколко атаки с злонамерен трафик около терабит) ви предпазва от «препълване» на uplinks.

Ако все пак някои uplinks «задръстят», просто извеждате този сайт от обслужване (спирате да анонсирате префикса).

Можете също така да увеличите дялa на трафика, който идва от вашите «пълноценни» (и съответно защитени) дата центрове, по този начин отстранявайки съществена част от злонамерения трафик от незанимаваните точки за присъствие.
И още едно малко забележка към този пример. Ако достатъчно голямо количество трафик предавате през IX-ите, това също намалява вашата подложеност на подобни атаки.

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

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

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

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

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

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

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

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

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

ripe.net
bgp.he.net

Пример
Ще дам само един малък пример.
Предполагаме, че вашият дата център се намира в Москва и имате единствена връзка – Ростелеком (AS12389). В този случай (single homed) BGP не ви е нужен, и вероятно използвате адресен пул от Ростелеком за публични адреси.
Предполагаме, че предлагате някаква услуга и имате достатъчно клиенти от Украйна, и те се оплакват от големи забавяния. При изследването установихте, че IP адресите на някои от тях се намират в мрежата 37.52.0.0/21.
След извършване на traceroute, видяхте, че трафикът преминава през AS1299 (Telia), а след извършване на ping, получихте среден RTT от 70 — 80 милисекунди. Можете да видите това и на looking glass на Ростелеком.
С помощта на утилитата whois (на сайта ripe.net или локалната утилита) лесно можете да определите, че блок 37.52.0.0/21 принадлежи на AS6849 (Ukrtelecom).
След това, отивайки на bgp.he.net виждате, че AS6849 няма отношения с AS12389 (те не са нито клиенти, нито uplinks един на друг, също така нямат и пиринг). Но ако погледнете на списъка с пирове за AS6849, ще видите например AS29226 (Mastertel) и AS31133 (Megafon).
Намирайки looking glass на тези доставчици, можете да сравните пътя и RTT. Например, за Mastertel RTT ще бъде около 30 милисекунди.
Ако разликата между 80 и 30 милисекунди е значима за вашия сервис, може би е време да помислите за свързаност, да получите свой номер AS в RIPE, свой пул от адреси и да свържете допълнителни uplinks или да създадете точки на присъствие в IX-ите.

С използването на BGP не само че подобрявате свързаността, но и резервирате вашето интернет свързване.

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

Защита от DOS/DDOS

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

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

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

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

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

Тоест имаме три типа атаки:

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

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

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

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

това е само временно по време на атаката. Можете при атака да пренастройвате BGP ръчно или автоматично, така че трафикът да минава само през доставчика, който ви осигурява „зонтик“. След като атаката приключи, можете да върнете маршрутизацията в предишното й състояние.

не е задължително да пренасочвате целия трафик. Ако, например, виждате, че през определени uplink-ове или P2P не се извършват атаки (или трафикът не е значителен), можете да продължите да обявявате префикси с конкурентни атрибути към тези BGP съседи.

Защита срещу „protocol attacks“ и „application attacks“ можете също да поверите на партньорите си.
Ето тук. можете да прочетете добро проучване (превод). Вярно е, че статията е на две години, но това ще ви даде представа за подходите, с които можете да се защитите от DDoS атаки.

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

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

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

Пример 1
Предположим, че сте „закрили се под зонтика“ от DDoS с помощта на един от доставчиците. Нека да предположим, че този доставчик използва Arbor за филтрация на трафика и филтри на границата на собствената си мрежа.
Профилът, който Arbor може „да обработва“, е ограничен и доставчикът, разбира се, не може постоянно да пропуска трафика на всичките си партньори, задействали тази услуга, през филтриращото оборудване. Затова в нормални условия трафикът не се филтрира.
Нека предположим, че се извършва SYN flood атака. Дори ако сте наели услуга, при която трафикът автоматично се пренасочва за филтриране при атака, това не става мигновено. В продължение на минута или повече оставате под атака. И това може да доведе до повреда на вашето оборудване или до влошаване на услугата. В този случай ограничаването на трафика на граничния маршрутизатор, макар и да доведе до това, че някои TCP сесии през това време няма да могат да се установят, ще спаси инфраструктурата ви от по-мащабни проблеми.

Пример 2
Аномално голямо количество SYN пакети може да бъде не само резултат от SYN flood атака. Нека предположим, че предоставяте услуга, при която в един и същи дата център може да имате около 100 000 TCP свързвания едновременно.
Предположим, че в резултат на краткотрайна проблема с един от вашите основни доставчици, половината от сесиите ви са „изхвърлени“. Ако вашето приложение е проектирано така, че веднага (или след определен, одинаков за всички сесии времеви интервал) да опитва отново да установи връзката, то вие приблизително едновременно ще получите поне 50 000 SYN пакета.
Ако на тези сесии, например, трябва да работи ssl/tls handshake, който предполага обмен на сертификати, от гледна точка на изчерпването на ресурсите за вашия балансировчик на натоварването, това ще бъде много по-силен „DDOS“ от обикновен SYN flood. Изглежда, че балансировчиците трябва да се справят с такива събития, но... за съжаление, ние сме се сблъскали с този проблем напълно.
И разбира се, policer на граничния маршрутизатор ще спаси вашето оборудване и в този случай.

Третият слой защита от DDOS/DOS – това е настройките на вашия фаервол.

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

Съвет
Опитайте се да дадете на фаервола колкото се може по-малко работа, филтрирайте колкото се може повече на първите две линии на защита. И ето защо.
Никога не сте изпитвали ситуация, в която случайно, генерирайки трафик, за да проверите, например, колко устойчива е операционната система на вашите сървъри към DDOS атаки, „убивате“ вашия фаервол, натоварвайки го на 100 процента с нормален интензитет на трафика? Ако не, може би просто защото не сте пробвали?
По принцип, фаерволът, както споменах, е сложна система и работи добре с известни уязвимости и тествани решения, но ако изпратите нещо необичайно, просто някакъв боклук или пакети с грешни заглавия, то с определена, не чак толкова малка (въз основа на опита ми) вероятност, можете да объркате и най-висококачественото оборудване. Затова, на етап 2, с помощта на обикновени ACL (на ниво L3/L4), допускайте в мрежата си само онзи трафик, който наистина трябва да може да влезе.