Оваа статија е трета од серијата написи „Како да ја преземете контролата врз вашата мрежна инфраструктура“. Содржината на сите написи во серијата и линковите може да се најдат .
Нема смисла да се зборува за целосно елиминирање на безбедносните ризици. Во принцип, не можеме да ги сведеме на нула. Исто така, треба да разбереме дека додека се стремиме да ја направиме мрежата сè побезбедна, нашите решенија стануваат сè поскапи. Треба да најдете компромис помеѓу трошоците, сложеноста и безбедноста што има смисла за вашата мрежа.
Се разбира, безбедносниот дизајн е органски интегриран во целокупната архитектура и безбедносните решенија што се користат влијаат на приспособливоста, доверливоста, управливоста, ... на мрежната инфраструктура, што исто така мора да се земе предвид.
Но, да ве потсетам дека сега не зборуваме за создавање мрежа. Според нашите веќе го избравме дизајнот, ја избравме опремата и ја создадовме инфраструктурата и во оваа фаза, ако е можно, треба да „живееме“ и да најдеме решенија во контекст на претходно избраниот пристап.
Наша задача сега е да ги идентификуваме ризиците поврзани со безбедноста на ниво на мрежа и да ги намалиме на разумно ниво.
Ревизија на безбедноста на мрежата
Ако вашата организација има имплементирано ISO 27k процеси, тогаш безбедносните ревизии и мрежните промени треба беспрекорно да се вклопат во севкупните процеси во рамките на овој пристап. Но, овие стандарди сè уште не се за конкретни решенија, не за конфигурација, не за дизајн... Нема јасни совети, нема стандарди кои детално диктираат каква треба да биде вашата мрежа, ова е сложеноста и убавината на оваа задача.
Јас би истакнал неколку можни контроли за безбедност на мрежата:
- ревизија на конфигурација на опремата (стврднување)
- ревизија на безбедносниот дизајн
- ревизија на пристап
- ревизија на процесот
Ревизија на конфигурација на опремата (стврднување)
Се чини дека во повеќето случаи ова е најдобрата почетна точка за ревизија и подобрување на безбедноста на вашата мрежа. IMHO, ова е добра демонстрација на законот на Парето (20% од напорот произведува 80% од резултатот, а останатите 80% од напор произведува само 20% од резултатот).
Заклучокот е дека ние обично имаме препораки од продавачите во врска со „најдобрите практики“ за безбедност при конфигурирање на опремата. Ова се нарекува „стврднување“.
Исто така, често можете да најдете прашалник (или сами да креирате) врз основа на овие препораки, што ќе ви помогне да одредите колку добро конфигурацијата на вашата опрема е во согласност со овие „најдобри практики“ и, во согласност со резултатот, да направите промени во вашата мрежа . Ова ќе ви овозможи значително да ги намалите безбедносните ризици прилично лесно, практично без трошоци.
Неколку примери за некои Cisco оперативни системи.
Врз основа на овие документи, може да се креира листа на барања за конфигурација за секој тип на опрема. На пример, за Cisco N7K VDC овие барања може да изгледаат вака .
На овој начин, конфигурациските датотеки може да се креираат за различни типови на активна опрема во вашата мрежна инфраструктура. Следно, рачно или користејќи автоматизација, можете да ги „подигнете“ овие конфигурациски датотеки. Како да се автоматизира овој процес ќе се дискутира во детали во друга серија написи за оркестрација и автоматизација.
Ревизија на безбедносен дизајн
Вообичаено, претпријатието мрежа ги содржи следните сегменти во една или друга форма:
- DC (Јавни услуги DMZ и Интранет центар за податоци)
- Интернет пристап
- Далечински пристап VPN
- WAN раб
- Гранка
- Кампус (канцеларија)
- Основни
Наслови преземени од модел, но не е неопходно, се разбира, да се прикачи токму на овие имиња и на овој модел. Сепак, сакам да зборувам за суштината и да не се заглавувам во формалности.
За секој од овие сегменти, безбедносните барања, ризиците и, соодветно, решенијата ќе бидат различни.
Ајде да го разгледаме секој од нив посебно за проблемите со кои може да се сретнете од безбедносен дизајн. Се разбира, повторно повторувам дека во никој случај овој напис не се преправа дека е комплетен, што не е лесно (ако не и невозможно) да се постигне во оваа навистина длабока и повеќеслојна тема, но го одразува моето лично искуство.
Не постои совршено решение (барем не се уште). Секогаш е компромис. Но, важно е одлуката да се користи еден или друг пристап да биде донесена свесно, со разбирање и на неговите добрите и лошите страни.
На Центарот за податоци
Најкритичниот сегмент од безбедносна гледна точка.
И, како и обично, и овде нема универзално решение. Сето тоа во голема мера зависи од барањата на мрежата.
Дали е потребен заштитен ѕид или не?
Се чини дека одговорот е очигледен, но сè не е толку јасно како што може да изгледа. И вашиот избор може да биде под влијание не само цена.
Пример 1. Одложувања.
Ако ниската латентност е суштински услов помеѓу некои мрежни сегменти, што е, на пример, точно во случај на размена, тогаш нема да можеме да користиме заштитни ѕидови помеѓу овие сегменти. Тешко е да се најдат студии за латентност во заштитните ѕидови, но неколку модели на прекинувачи можат да обезбедат латентност помала или од редот на 1 mksec, така што мислам дека ако микросекундите се важни за вас, тогаш заштитните ѕидови не се за вас.
Пример 2. Изведба.
Пропусната моќ на горните L3 прекинувачи е обично по ред на големина поголема од пропусната моќ на најмоќните заштитни ѕидови. Затоа, во случај на сообраќај со висок интензитет, најверојатно ќе треба да дозволите овој сообраќај да ги заобиколува заштитните ѕидови.
Пример 3. Сигурност.
Заштитните ѕидови, особено модерните NGFW (Next-Generation FW) се сложени уреди. Тие се многу посложени од прекинувачите L3/L2. Тие обезбедуваат голем број услуги и опции за конфигурација, па затоа не е чудно што нивната сигурност е многу помала. Ако континуитетот на услугата е критичен за мрежата, тогаш можеби ќе треба да изберете што ќе доведе до подобра достапност - безбедност со заштитен ѕид или едноставноста на мрежата изградена на прекинувачи (или разни видови ткаенини) користејќи редовни ACL.
Во случајот со горенаведените примери, најверојатно (како и обично) ќе треба да најдете компромис. Погледнете кон следните решенија:
- ако одлучите да не користите заштитни ѕидови во центарот за податоци, тогаш треба да размислите како да го ограничите пристапот околу периметарот колку што е можно повеќе. На пример, можете да ги отворите само потребните порти од Интернет (за сообраќај на клиенти) и административен пристап до центарот за податоци само од скокачки хостови. На jump hosts, извршете ги сите потребни проверки (автентикација/овластување, антивирус, логирање, ...)
- можете да користите логичка партиција на мрежата на центарот за податоци во сегменти, слична на шемата опишана во PSEFABRIC . Во овој случај, рутирањето мора да биде конфигурирано на таков начин што сообраќајот чувствителен на доцнење или со висок интензитет оди „во рамките на“ еден сегмент (во случајот p002, VRF) и не поминува низ заштитниот ѕид. Сообраќајот меѓу различните сегменти ќе продолжи да се одвива преку заштитниот ѕид. Можете исто така да користите протекување на маршрутата помеѓу VRF за да избегнете пренасочување на сообраќајот низ заштитниот ѕид
- Можете исто така да користите заштитен ѕид во транспарентен режим и само за оние VLAN каде што овие фактори (латентност/перформанси) не се значајни. Но, треба внимателно да ги проучите ограничувањата поврзани со употребата на овој мод за секој продавач
- можеби ќе сакате да размислите за користење на архитектура на синџир на услуги. Ова ќе овозможи само потребниот сообраќај да поминува низ заштитниот ѕид. Изгледа убаво во теорија, но никогаш не сум го видел ова решение во производство. Го тестиравме синџирот на услуги за Cisco ACI/Juniper SRX/F5 LTM пред околу 3 години, но во тоа време ова решение ни изгледаше „сурово“.
Ниво на заштита
Сега треба да одговорите на прашањето кои алатки сакате да ги користите за филтрирање на сообраќајот. Еве некои од карактеристиките кои обично се присутни во NGFW (на пример, ):
- државен заштитен ѕид (стандардно)
- огнен ѕид на апликацијата
- спречување закани (антивирус, анти-шпионски софтвер и ранливост)
- Филтрирање URL
- филтрирање податоци (филтрирање содржина)
- блокирање на датотеки (блокирање на типови датотеки)
- dos заштита
И не е сè јасно. Се чини дека колку е повисоко нивото на заштита, толку подобро. Но, исто така треба да го земете предвид тоа
- Колку повеќе од горенаведените функции на заштитен ѕид користите, толку поскапо ќе биде природно (лиценци, дополнителни модули)
- употребата на некои алгоритми може значително да ја намали пропусната моќ на заштитен ѕид и исто така да ги зголеми доцнењата, видете на пример
- како и секое сложено решение, употребата на сложени методи за заштита може да ја намали веродостојноста на вашето решение, на пример, кога користев заштитник на апликацијата, наидов на блокирање на некои сосема стандардни работни апликации (dns, smb)
Како и секогаш, треба да го пронајдете најдоброто решение за вашата мрежа.
Невозможно е дефинитивно да се одговори на прашањето какви заштитни функции може да се бараат. Прво, затоа што секако зависи од податоците што ги пренесувате или складирате и се обидувате да ги заштитите. Второ, во реалноста, честопати изборот на безбедносни алатки е прашање на вера и доверба во продавачот. Не ги знаете алгоритмите, не знаете колку се ефективни и не можете целосно да ги тестирате.
Затоа, во критичните сегменти, добро решение може да биде користењето понуди од различни компании. На пример, можете да овозможите антивирус на заштитниот ѕид, но исто така да користите антивирусна заштита (од друг производител) локално на хостовите.
Сегментација
Станува збор за логичка сегментација на мрежата на центарот за податоци. На пример, поделбата во VLAN и подмрежи е исто така логична сегментација, но нема да ја разгледаме поради неговата очигледност. Интересна сегментација земајќи ги предвид ентитетите како FW безбедносни зони, VRFs (и нивните аналози во однос на различни продавачи), логички уреди (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Даден е пример за таква логичка сегментација и тековно бараниот дизајн на центарот за податоци .
Откако ќе ги дефинирате логичките делови на вашата мрежа, потоа можете да опишете како сообраќајот се движи помеѓу различни сегменти, на кои уреди ќе се врши филтрирање и на кои средства.
Ако вашата мрежа нема јасна логичка партиција и правилата за примена на безбедносни политики за различни текови на податоци не се формализирани, тоа значи дека кога ќе го отворите овој или оној пристап, вие сте принудени да го решите овој проблем и со голема веројатност ќе го решава секој пат поинаку.
Често, сегментацијата се заснова само на безбедносните зони на FW. Потоа треба да одговорите на следниве прашања:
- кои безбедносни зони ви се потребни
- кое ниво на заштита сакате да го примените за секоја од овие зони
- ќе биде стандардно дозволен сообраќај во зоната?
- ако не, какви политики за филтрирање сообраќај ќе се применуваат во секоја зона
- кои политики за филтрирање сообраќај ќе се применуваат за секој пар зони (извор/дестинација)
TCAM
Чест проблем е недоволната TCAM (Ternary Content Addressable Memory), и за рутирање и за пристапи. IMHO, ова е едно од најважните прашања при изборот на опрема, па затоа треба да го третирате ова прашање со соодветен степен на грижа.
Пример 1. Табела за препраќање TCAM.
ајде да размислиме заштитен ѕид
Гледаме дека големината на табелата за препраќање IPv4* = 32K
Покрај тоа, овој број на правци е заеднички за сите VSYS.Да претпоставиме дека според вашиот дизајн одлучивте да користите 4 VSYS.
Секој од овие VSYS е поврзан преку BGP со две MPLS PE на облакот што ги користите како BB. Така, 4 VSYS ги разменуваат сите специфични правци едни со други и имаат табела за препраќање со приближно исти групи на правци (но различни NHs). Бидејќи секој VSYS има 2 BGP сесии (со исти поставки), потоа секоја рута добиена преку MPLS има 2 NH и, соодветно, 2 FIB записи во Табелата за препраќање. Ако претпоставиме дека ова е единствениот заштитен ѕид во центарот за податоци и мора да знае за сите правци, тогаш тоа ќе значи дека вкупниот број на рути во нашиот центар за податоци не може да биде повеќе од 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