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

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

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

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

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

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

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

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

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

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

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

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

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

Няколко примера за някои операционни системи на Cisco.

Втвърдяване на конфигурацията на Cisco IOS
Втвърдяване на конфигурацията на Cisco IOS-XR
Подсилване на конфигурацията на Cisco NX-OS
Списък за проверка на базовата сигурност на Cisco

Въз основа на тези документи може да се създаде списък с изисквания за конфигурация за всеки тип оборудване. Например за Cisco N7K VDC тези изисквания може да изглеждат така така.

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

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

Обикновено корпоративната мрежа съдържа следните сегменти под една или друга форма:

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

Заглавията са взети от Cisco БЕЗОПАСЕН модел, но не е необходимо, разбира се, да се привързва точно към тези имена и към този модел. Все пак искам да говоря по същество и да не се затъвам във формалности.

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

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

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

Център за данни

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

Необходима ли е защитна стена или не?

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

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

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

Пример 2. Производителност.

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

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

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

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

• ако решите да не използвате защитни стени вътре в центъра за данни, тогава трябва да помислите как да ограничите достъпа около периметъра възможно най-много. Например, можете да отворите само необходимите портове от Интернет (за клиентски трафик) и административен достъп до центъра за данни само от хостове за прескачане. На хостовете за прескачане извършете всички необходими проверки (удостоверяване/упълномощаване, антивирусна програма, регистриране, ...)
• можете да използвате логическо разделяне на мрежата на центъра за данни на сегменти, подобно на схемата, описана в PSEFABRIC пример p002. В този случай маршрутизирането трябва да бъде конфигурирано по такъв начин, че чувствителният към забавяне или трафик с висока интензивност да преминава „в рамките“ на един сегмент (в случай на p002, VRF) и да не преминава през защитната стена. Трафикът между различните сегменти ще продължи да преминава през защитната стена. Можете също така да използвате изтичане на маршрут между VRF, за да избегнете пренасочване на трафика през защитната стена
• Можете също да използвате защитна стена в прозрачен режим и само за онези VLAN мрежи, където тези фактори (закъснение/производителност) не са значими. Но трябва внимателно да проучите ограниченията, свързани с използването на този мод за всеки доставчик
• може да искате да обмислите използването на архитектура на верига за услуги. Това ще позволи само необходимия трафик да премине през защитната стена. Изглежда добре на теория, но никога не съм виждал това решение в производство. Тествахме сервизната верига за Cisco ACI/Juniper SRX/F5 LTM преди около 3 години, но тогава това решение ни се стори „сурово“.

Ниво на защита

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

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

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

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

Както винаги, трябва да намерите най-доброто решение за вашата мрежа.

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

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

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

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

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

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

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

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

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

КОСНПТ

Често срещан проблем е недостатъчната TCAM (адресируема памет с троично съдържание), както за маршрутизиране, така и за достъп. IMHO, това е един от най-важните въпроси при избора на оборудване, така че трябва да се отнасяте към този проблем с подходяща степен на внимание.

Пример 1. Препращаща таблица TCAM.

Нека разгледаме Пало Алто 7к защитна стена
Виждаме, че размерът на таблицата за препращане на IPv4* е 32K
Освен това този брой маршрути е общ за всички VSYS.

Да приемем, че според вашия дизайн решите да използвате 4 VSYS.
Всеки от тези VSYS е свързан чрез BGP към две MPLS PE от облака, които използвате като BB. По този начин 4 VSYS обменят всички специфични маршрути един с друг и имат таблица за препращане с приблизително еднакви набори от маршрути (но различни NH). защото всеки VSYS има 2 BGP сесии (с еднакви настройки), тогава всеки маршрут, получен през MPLS, има 2 NH и съответно 2 FIB записа в Forwarding Table. Ако приемем, че това е единствената защитна стена в центъра за данни и тя трябва да знае за всички маршрути, тогава това ще означава, че общият брой маршрути в нашия център за данни не може да бъде повече от 32K/(4 * 2) = 4K.

Сега, ако приемем, че имаме 2 центъра за данни (с еднакъв дизайн) и искаме да използваме VLAN, „разпънати“ между центрове за данни (например за vMotion), тогава, за да разрешим проблема с маршрутизирането, трябва да използваме хост маршрути . Но това означава, че за 2 центъра за данни ще имаме не повече от 4096 възможни хоста и, разбира се, това може да не е достатъчно.

Пример 2. ACL TCAM.

Ако планирате да филтрирате трафика на комутатори L3 (или други решения, които използват комутатори L3, например Cisco ACI), тогава при избора на оборудване трябва да обърнете внимание на TCAM ACL.

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

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

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

Въпросът е: трябва ли да използвам HA за защитни стени или да инсталирам две независими кутии "паралелно" и ако едната от тях не успее, да маршрутизирам трафика през втората?

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

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

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

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

Управляемост

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

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

• резервни конфигурации
• актуализации
• надстройки
• наблюдение
• дърводобив

И всичко това може да бъде решено чрез централизирани системи за управление.

Така че, например, ако използвате защитни стени на Пало Алто, тогава панорама е такова решение.

Да продължи.

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