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

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

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

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

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

Аудит на мрежовата сигурност

Ако във вашата организация са внедрени процеси ISO 27k, то одитът на сигурността и промените в мрежата трябва да бъдат органично вписани в общите процеси в рамките на този подход. Но тези стандарти все пак не стават въпрос за конкретни решения, не за конфигурация, не за дизайн... Няма еднозначни съвети, няма стандарти, които детайлно диктуват каква трябва да бъде вашата мрежа, в това е сложността и красотата на тази задача.

Бих изброил няколко възможни одита на мрежовата сигурност:

одит на конфигурацията на оборудването (hardening)
одит на дизайна на сигурността
одит на достъпа
одит на процесите

Одит на конфигурацията на оборудването (hardening)

Изглежда, че в повечето случаи това е най-добрата начална точка за одит и подобряване на сигурността на вашата мрежа. ИМХО, това е добро демонстрация на закона на Парето (20 % усилия дават 80 % резултата, а останалите 80 % усилия – само 20 % резултата).

Същността е, че обикновено имаме препоръки от доставчиците относно „най-добрите практики“ за сигурност при конфигуриране на оборудване. Това се нарича “hardening.”

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

Няколко примера за различни операционни системи Cisco.
Укрепване на конфигурацията на Cisco IOS
Укрепване на конфигурацията на Cisco IOS-XR
Укрепване на конфигурацията на Cisco NX-OS
Списък за основни изисквания за сигурност от Cisco
На базата на тези документи може да бъде създаден списък с изисквания за конфигурация за всеки тип оборудване. Например, за Cisco N7K VDC тези изисквания могат да изглеждат така.

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

Одит на дизайна за сигурност

Обикновено в корпоративната мрежа (enterprise network) в различна форма присъстват следните сегменти:

DC (DMZ за обществени услуги и център за данни Intranet)
Достъп до интернет
VPN за назначения отдалечен достъп
WAN ръб
Клон
Кампус (офис)
Ядро

Имената са взети от Cisco SAFE модели, но не е задължително да се привързвате точно към тези имена и тази модел. Все пак е хубаво да говорим за същността и да не се заплитаме в формалности.

За всеки от тези сегменти изискванията за ниво на сигурност, рисковете и съответните решения ще се различават.

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

Не съществува идеално решение (поне за сега). Винаги е компромис. Но е важно решението, което е приложено, да бъде направено съзнателно, с разбиране на своите плюсове и минуси.

Data Center

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

Нужен ли е фаервол?

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

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

Пример 2. Производителност.
Пропускателната способност на водещите L3 комутатори обикновено е значително по-висока от пропускателната способност на най-мощните фаерволи. Затова, при интензивен трафик, вероятно ще трябва да пропуснете този трафик през фаерволите.

Пример 3. Надеждност.
Фаерволите, особено съвременните NGFW (Next-Generation FW) – сложни устройства. Те са значително по-сложни от L3/L2 комутаторите. Те предлагат голям брой услуги и конфигурационни възможности, затова не е изненадващо, че тяхната надеждност е значително по-ниска. Ако непрекъснатостта на услугата е критична за мрежата, тогава, може би, ще трябва да изберете какво ще доведе до по-добра наличност — сигурност чрез фаервол или простота на мрежата, изградена на комутатори (или различни видове фабрики) с използване на обикновени ACL.

В случая на посочените примери, вероятно (както обикновено) ще трябва да намерите компромис. Помислете за следните решения:

ако решите да не използвате фаерволи вътре в дата центъра, трябва да помислите как максимално да ограничите достъпа по периферията. Например, можете да отворите само необходимите портове от интернет (за клиентския трафик) и административни достъпи до дата центъра само от джамп хостове. На джамп хостовете извършвайте цялата необходима проверка (аутентификация/авторизация, антивирус, логване, …)
можете да използвате логическо разделяне на мрежата на дата центъра на сегменти, подобно на схемата, описана в PSEFABRIC. пример p002. Маршрутизация трябва да бъде настроена така, че трафикът, чувствителен на закъснения или интензивен трафик, да минава «вътре» в един сегмент (в случай на p002, VRF-а) и да не преминава през фаервола. Трафикът между различни сегменти все още ще преминава през фаервола. Може да се използва и route leaking между VRF-ите, за да се избегне пренасочване на трафика през фаервола.
може също така да се използва фаервол в transparent mode и само за тези VLAN-ове, където тези фактори (закъснение/производителност) не са съществени. Но е необходимо внимателно да се проучат ограниченията, свързани с използването на този режим, за всеки доставчик.
можете да обмислите прилагане на архитектура service chain. Това ще позволи да се насочва през фаервола само необходимия трафик. Теоретично звучи добре, но никога не съм виждал това решение в продукция. Тествахме service chain за Cisco ACI/Juniper SRX/F5 LTM преди около 3 години, но тогава това решение ни се стори «сурово».

Уровень защита

Сега трябва да отговорите на въпроса какви инструменти искате да използвате за филтриране на трафика. Ето някои от възможностите, които обикновено присъстват в NGFW (например, тук):

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

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

колкото повече от гореспоменатите функции на фаервола използвате, толкова по-естествено това ще стане по-скъпо (лицензионни такси, допълнителни модули).
Използването на някои алгоритми може съществено да намали пропускната способност на фаервола, както и да увеличи закъсненията, вижте например тук
както и при всяко сложно решение, използването на сложни методи за защита може да намали надеждността на вашето решение, например, при използване на application firewalling съм се сблъсквал с блокиране на някои напълно стандартно работещи приложения (dns, smb).

Както обикновено, трябва да намерите оптималното решение за вашата мрежа.

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

Следователно, в критични сегменти, добро решение може да бъде използването на оферти от различни компании. Например, можете да включите антивирус на защитната стена, но също така да използвате антивирусна защита (на друг производител) локално на хостовете.

Сегментиране

Става дума за логическа сегментация на мрежата на дата центъра. Например, разделянето на VLAN-и и подсетки – това също е логическа сегментация, но няма да я разглеждаме, поради очевидността й. Интересна е сегментацията, като се вземат предвид такива единици като зони на защита от FW, VRF (и техните аналози, приложими за различни производители), логически устройства (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Пример за такава логическа сегментация и търсен дизайн на дата център е представен в p002 проекта PSEFABRIC.

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

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

Често сегментацията се основава само на зоните на защита от FW. Тогава трябва да отговорите на следните въпроси:

какви зони на защита са ви нужни
какво ниво на защита искате да приложите на всяка от тези зони
дали intra-zone трафикът ще бъде разрешен по подразбиране
ако не, какви политики за филтриране на трафика ще се прилагат вътре в всяка от зоните
какви политики за филтриране на трафика ще се прилагат за всяка двойка зони (source/destination)

TCAM

Често срещан проблем е недостатъкът на TCAM (Ternary Content Addressable Memory), както за маршрутизиране, така и за достъпи. ИМХО, това е един от най-важните въпроси при избора на оборудване, затова трябва да се отнесете към този въпрос с подходяща степен на внимание.

Пример 1. Forwarding Table TCAM.
Нека разгледаме Palo Alto 7k защитна стена.
Виждаме, че размерът на IPv4 forwarding таблица* = 32K
Като се има предвид, това количество рутове е общо за всички VSYS-ове.
Предположим, че в съответствие с вашия дизайн, решихте да използвате 4 VSYS-а.
Все тези VSYS-ове по BGP са свързани с две PE MPLS облака, които използвате като BB. Така 4 VSYS-а обменят всички специфични маршрути помежду си и имат таблица за предаване с приблизително еднакви набори от маршрути (но различни NH). Тъй като всеки VSYS има по 2 BGP сесии (с еднакви настройки), то всеки маршрут, получен чрез MPLS, има 2 NH и, съответно, 2 FIB записа в таблицата за предаване. Ако предположим, че това е единственият фаервол в дата центъра и той трябва да знае за всички маршрути, то това означава, че общият брой маршрути в нашия дата център не може да бъде повече от 32K/(4 * 2) = 4K.
Сега, ако предположим, че имаме 2 дата центъра (с еднакъв дизайн) и искаме да използваме VLAN-ове, „разширени“ между дата центровете (например, за vMotion), то за да решим проблема с маршрутизацията, трябва да използваме хостови маршрути. Но това означава, че за 2 дата центъра можем да имаме не повече от 4096 възможни хостове и, разбира се, това може да не е достатъчно.

Пример 2. ACL TCAM.
Ако планирате да филтрирате трафика на L3 комутатори (или други решения, използващи L3 комутатори, например Cisco ACI), то при избора на оборудване трябва да обърнете внимание на ACL TCAM.
Предполагам, че искате да контролирате достъпа на SVI интерфейсите на Cisco Catalyst 4500. Тогава, както може да се види от тази статия, за контрол на изходящия (както и на входящия) трафик на интерфейсите можете да използвате само 4096 реда TCAM. Което при използване на TCAM3 дава около 4000 ACE (реда ACL).

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

Висока наличност

Въпросът е дали да се използва HA за фаерволи или да се поставят „паралелно“ две независими кутии и в случай на падане на едната от тях да маршрутизираме трафика през втората?

На пръв поглед, отговорът изглежда очевиден – да се използва HA. Причината, поради която все пак възниква този въпрос, е, че, за съжаление, теоретичните и рекламни 99 и няколко деветки след запетаята за наличност в практиката не са така обещаващи. HA — логически доста сложна концепция, и на различно оборудване и с различни доставчици (без изключения) ние откривахме проблеми и бъгове и спиране на услугата.

При използване на HA ще имате възможност да изключвате отделни нози, да превключвате между тях без спиране на услугата, което е важно, например, при обновления, но по този начин имате далеч не нулева вероятност да се повредят и двете нози едновременно, както и да премине поредния ъпгрейд не толкова гладко, колкото обещава доставчикът (тази проблема може да се избегне, ако имате възможност да тествате ъпгрейда на лабораторно оборудване).

Ако не използвате HA, вашите рискове в контекста на двойна повреда са значително по-ниски (тъй като имате 2 независими фаервола), но тъй като сесиите не са синхронизирани, всеки път, когато настъпи превключване между тези фаерволи, ще загубите трафик. Можете, разбира се, да използвате stateless firewalling, но тогава смисълът на използването на фаервол в значителна степен се губи.

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

Удобство в управлението (managability)

В принцип HA включва също и управляемост. Вместо конфигуриране на 2 устройства поотделно и решаване на проблема със синхронизацията на конфигурациите, управлявате ги в голяма степен така, сякаш имате едно устройство.

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