Гэты артыкул з'яўляецца трэцім у цыкле артыкулаў "Як узяць сеткавую інфраструктуру пад свой кантроль". Змест усіх артыкулаў цыклу і спасылкі можна знайсці .
Няма сэнсу казаць аб поўным ухіленні security рызык. Мы ў прынцыпе не можам зменшыць іх да нуля. Таксама трэба разумець, што пры імкненні зрабіць сетку больш і больш бяспечнай нашы рашэнні становяцца ўсё даражэйшымі. Неабходна знайсці разумны для вашай сеткі кампраміс паміж коштам, складанасцю і бяспекай.
Вядома, дызайн бяспекі арганічна убудаваны ў агульную архітэктуру і выкарыстоўваныя security рашэнні ўплываюць на маштабаванасць, надзейнасць, кіравальнасць, … сеткавай інфраструктуры, што таксама павінна ўлічвацца.
Але, нагадаю, што зараз мы не гаворым аб стварэнні сеткі. У адпаведнасці з нашымі у нас ужо выбраны дызайн, выбрана абсталяванне, і створана інфраструктура, і на гэтым этапе мы, па магчымасці, павінны "жыць" і знаходзіць рашэнні ў кантэксце выбранага раней падыходу.
Наша задача цяпер - выявіць рызыкі, звязаныя з абароненасцю на ўзроўні сеткі і знізіць іх да разумнай велічыні.
Аўдыт сеткавай бяспекі
Калі ў вашай арганізацыі ўкаранёны працэсы ISO 27k, то аўдыт бяспекі і змены сеткі павінны быць арганічна ўпісаны ў агульныя працэсы ў рамках гэтага падыходу. Але гэтыя стандарты ўсё ж не пра канкрэтныя рашэнні, не пра канфігурацыю, не пра дызайн… Няма адназначных парад, няма стандартаў дэталёва дыктуючых якой павінна быць ваша сетка, у гэтым складанасць і прыгажосць гэтай задачы.
Я б вылучыў некалькі магчымых аўдытаў бяспекі сеткі:
- аўдыт канфігурацыі абсталявання (hardening)
- аўдыт security дызайну
- аўдыт доступаў
- аўдыт працэсаў
Аўдыт канфігурацыі абсталявання (hardening)
Здаецца, што ў большасці выпадкаў гэта лепшы стартавы пункт для аўдыту і паляпшэння бяспекі вашай сеткі. ИМХО, гэта добрая дэманстрацый закона Парэта (20% намаганняў даюць 80% выніку, а астатнія 80% намаганняў - толькі 20% выніку).
Сутнасць у тым, што звычайна ў нас ёсць рэкамендацыі ад вендараў адносна "best practices" па бяспецы пры канфігураванні абсталявання. Гэта называецца "hardening".
Таксама часта можна сустрэць апытальнік (ці скласці самім), на аснове гэтых рэкамендацый, які дапаможа вам вызначыць, наколькі канфігурацыя вашага абсталявання адпавядае гэтым «best practices» і ў адпаведнасці з вынікам зрабіць змены ў вашай сетцы. Гэта дазволіць вам даволі лёгка, фактычна без затрат, істотна знізіць security рызыкі.
Некалькі прыкладаў для некаторых аперацыйных сістэм Cisco.
На аснове гэтых дакументаў можа быць створаны спіс патрабаванняў да канфігурацыі для кожнага тыпу абсталявання. Напрыклад, для Cisco N7K VDC гэтыя патрабаванні могуць выглядаць .
Такім чынам, могуць быць створаны канфігурацыйныя файлы для розных тыпаў актыўнага абсталявання вашай сеткавай інфраструктуры. Далей, уручную ці з ужываннем аўтаматызацыі, вы можаце "заліць" гэтыя канфігурацыйныя файлы. Як аўтаматызаваць гэты працэс будзе падрабязна разгледжана ў іншай серыі артыкулаў, прысвечаных аркестрацыі і аўтаматызацыі.
Аўдыт security дызайну
Звычайна ў сетцы прадпрыемства (enterprise network) у тым ці іншым выглядзе прысутнічаюць наступныя сегменты:
- DC (Public services DMZ and Intranet data center)
- Доступ у інтэрнэт
- Remote access VPN
- WAN edge
- Філіял
- Campus (Office)
- Core
Назвы ўзяты з мадэлі, але не абавязкова, вядома, прывязвацца менавіта да гэтых назваў і да гэтай мадэлі. Усё ж такі хочацца гаварыць аб сутнасці і не ўвязаць у фармальнасцях.
Для кожнага з гэтых сегментаў патрабаванні да ўзроўню бяспекі, рызыкі і, адпаведна, рашэнні будуць адрознівацца.
Разгледзім кожны з іх паасобку на прадмет праблем, з якімі вы можаце сутыкнуцца з пункта гледжання security дызайну. Вядома, зноў паўтаруся, што ні ў якай меры дадзены артыкул не прэтэндуе на паўнату, дасягнуць якую ў гэтай сапраўды глыбокай і шматграннай тэме няпроста (калі наогул магчыма), але адлюстроўвае мой асабісты досвед.
Не існуе ідэальнага рашэння (ва ўсякім разе цяпер). Гэта заўсёды кампраміс. Але важна, каб рашэнне прымяніць той ці іншы падыход было зроблена свядома, з разуменнем як яго плюсаў, так і мінусаў.
Цэнтр апрацоўкі дадзеных
Найбольш крытычны з пункту гледжання бяспекі сегмент.
І, як звычайна, тут таксама няма ўніверсальнага рашэння. Усё моцна залежыць ад патрабаванняў да сеткі.
Патрэбен ці не фаервал?
Здавалася б, адказ відавочны, але ўсё не зусім так ужо адназначна, як можа здацца. І на ваш выбар можа паўплываць не толькі кошт.
Прыклад 1. Затрымкі.
Калі паміж нейкімі сегментамі сеткі нізкая затрымка з'яўляецца істотным патрабаваннем, што, напрыклад, справядліва ў выпадку біржы, то паміж гэтымі сегментамі мы не зможам выкарыстоўваць фаервалы. Складана знайсці даследаванні па затрымках у фаервалах, але толькі нешматлікія мадэлі камутатараў могуць даць затрымкі менш або каля 1 mksec, таму, думаю, што калі для вас істотныя мікрасекунды, то фаервалы - гэта не для вас.
Прыклад 2. Прадукцыйнасць.
Прапускная здольнасць топавых L3 камутатараў звычайна на парадак вышэй чым прапускная здольнасць самых прадукцыйных фаеролаў. Таму ў выпадку высокаінтэнсіўнага трафіку, вам таксама хутчэй за ўсё давядзецца пусціць гэты трафік у абыход фаервалаў.
Прыклад 3. Надзейнасць.
Фаервалы, асабліва сучасныя NGFW (Next-Generation FW) - складаныя прылады. Яны значна складаней чым L3/L2 камутатары. Яны падаюць вялікую колькасць сэрвісаў і магчымасцяў канфігуравання, таму нядзіўна, што іх надзейнасць значна ніжэй. Калі бесперапыннасць сэрвісу з'яўляецца крытычнай для сеткі, то, магчыма, вам давядзецца выбіраць, што прывядзе да лепшай availability — абароненасць з дапамогай фаервала ці прастата сеткі, пабудаванай на камутатарах (або рознага роду фабрыках) з выкарыстаннем звычайных ACL.
У выпадку вышэйпералічаных прыкладаў вам хутчэй за ўсё (як звычайна) давядзецца знаходзіць кампраміс. Паглядзіце ў бок наступных рашэнняў:
- калі вы вырашылі не выкарыстоўваць фаервалы ўсярэдзіне дата-цэнтра, то вам трэба прадумаць як максімальна абмежаваць доступы па перыметры. Напрыклад, вы можаце адкрыць толькі неабходныя парты з Інтэрнэту (для кліенцкага трафіку) і адміністрацыйныя доступы ў дата-цэнтр толькі з джамп хастоў. На джамп хастах вырабляць усю неабходную праверку (аўтэнтыфікацыю/аўтарызацыю, антывірус, лагіраванне, …)
- вы можаце выкарыстоўваць лагічнае разбіццё сеткі дата-цэнтра на сегменты, накшталт схемы, апісанай у PSEFABRIC . Пры гэтым маршрутызацыя павінна быць наладжана такім чынам, каб трафік, адчувальны да затрымак або высокаінтэнсіўны трафік хадзіў усярэдзіне аднаго сегмента (у выпадку p002, VRF-а) і не ішоў бы праз фаервол. Трафік жа паміж рознымі сегментамі будзе па-ранейшаму ісці праз фаервал. Таксама можна выкарыстоўваць route leaking паміж VRF-амі, каб пазбегнуць перанакіраванне трафіку праз фаервол.
- таксама можна выкарыстоўваць фаервол у transparent mode і толькі для тых VLAN-ов дзе гэтыя фактары (затрымка/прадукцыйнасць) не істотныя. Але трэба ўважліва вывучыць абмежаванні, звязаныя з выкарыстаннем гэтай моды, для кожнага вендара.
- вы можаце падумаць аб ужыванні service chain архітэктуры. Гэта дазволіць накіроўваць праз фаервал толькі неабходны трафік. Тэарэтычна выглядае прыгожа, але я ніколі не бачыў гэтага рашэння ў прадакшэне. Мы тэставалі service chain для Cisco ACI / Juniper SRX / F5 LTM каля 3-х гадоў таму, але на той момант гэтае рашэнне здалося нам "волкім"
ўзровень абароны
Цяпер трэба адказаць на пытанне, якія прылады вы хочаце прымяніць для фільтрацыі трафіку. Вось некаторыя з магчымасцяў, якія звычайна прысутнічаюць у NGFW (напрыклад, ):
- stateful firewalling (па змаўчанні)
- application firewalling
- threat prevention (antivirus, anti-spyware, and vulnerability)
- Фільтрацыя URL
- data filtering (content filtering)
- file blocking (file types blocking)
- dos protection
І таксама не ўсё адназначна. Здавалася б, чым вышэй узровень абароны, тым лепш. Але вам таксама трэба ўлічыць, што
- чым больш вышэйпералічаных функцый фаервала вы карыстаецеся, тым натуральна гэта будзе даражэй (ліцэнзіі, дадатковыя модулі)
- выкарыстанне некаторых алгарытмаў можа істотна зменшыць прапускную здольнасць фаервала, а таксама павялічыць затрымкі, гл. напрыклад
- як і любое складанае рашэнне, выкарыстанне складаных метадаў абароны можа зменшыць надзейнасць вашага рашэння, напрыклад, пры выкарыстанні application firewalling я сутыкаўся з блакаваннем некаторых суцэль стандартна якія працуюць прыкладанняў (dns, smb)
Вам, як звычайна, трэба знайсці аптымальнае для вашай сеткі рашэнне.
Немагчыма адназначна адказаць на пытанне якія функцыі абароны могуць запатрабавацца. Па-першае, таму, што гэта вядома ж залежыць ад тых дадзеных, якія вы перадаеце ці захоўваеце і спрабуеце абараніць. Па-другое, у рэчаіснасці, часта выбар сродкаў абароны - гэта пытанне веры і даверу вендару. Вы не ведаеце алгарытмы, не ведаеце, наколькі яны эфектыўныя і не можаце паўнавартасна пратэставаць іх.
Таму ў крытычных сегментах добрым рашэннем можа быць выкарыстанне прапаноў ад розных кампаній. Напрыклад, вы можаце ўключыць антывірус на фаервале, але таксама выкарыстоўваць антывірусную абарону (іншага вытворцы) лакальна на хастах.
Сегментаванне
Размова ідзе аб лагічнай сегментацыі сеткі дата-цэнтра. Напрыклад, разбіццё на VLAN-ы і падсеткі - гэта таксама лагічная сегментацыя, але мы не будзем яе разглядаць у сілу яе відавочнасці. Цікавая сегментацыя з улікам такіх сутнасцяў як FW security зоны, VRF (і іх аналагаў у дачыненні да розных вендараў), лагічных прылад (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …
Прыклад такой лагічнай сегментацыі і запатрабаванага на дадзены момант дызайну дата-цэнтра прыведзена ў .
Вызначыўшы лагічныя часткі вашай сеткі, далей вы можаце апісаць, як рухаецца трафік паміж рознымі сегментамі, на якіх прыладах будзе рабіцца фільтраванне і якімі сродкамі.
Калі ў вашай сетцы адсутнічае яснае лагічнае разбіццё і не фармалізаваны правілы ўжывання security палітык для розных струменяў дадзеных (flow), тое гэта значыць, што пры адкрыцці таго ці іншага доступу вы змушаны вырашаць гэтую задачу, і з вялікай верагоднасцю кожны раз вы будзеце вырашаць яе па рознаму.
Часта сегментацыя заснавана толькі на FW security зонах. Тады вам трэба адказаць на наступныя пытанні:
- якія security зоны вам патрэбныя
- які ўзровень абароны вы хочаце прымяніць да кожнай з гэтых зон
- ці будзе дазволены па змаўчанні intra-zone трафік
- калі не, то якія палітыкі фільтрацыі трафіку будуць прымяняцца ўнутры кожнай з зон
- якія палітыкі фільтрацыі трафіку будуць прымяняцца для кожнай пары зон (source/destination)
TCAM
Часта сустракаецца праблема недастатковага TCAM (Ternary Content Addressable Memory) як для маршрутызацыі, так і для доступаў. ИМХО, гэта адно з самых важных пытанняў пры выбары абсталявання, таму трэба паставіцца да гэтага пытання з належнай ступенню акуратнасці.
Прыклад 1. Forwarding Table TCAM.
Давайце разгледзім фаервал.
Бачым, што IPv4 forwarding table size* = 32K
Пры гэтым гэтая колькасць роўтаў агульная для ўсіх VSYS-аў.Выкажам здагадку, што ў адпаведнасці з вашым дызайнам вы вырашылі выкарыстаць 4 VSYS-а.
Кожны з гэтых VSYS-аў па BGP падлучаны да двух PE MPLS аблокі, якое вы карыстаецеся ў якасці BB. Такім чынам, 4 VSYS-а абменьваюцца ўсімі спецыфічнымі роўтамі сябар з сябрам і маюць forwarding table з прыблізна аднолькавымі наборамі маршрутаў (але рознымі 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), то пры выбары абсталявання вы павінны звярнуць увагу на ACL TCAM.
Выкажам здагадку вы жадаеце кантраляваць доступы на SVI інтэрфейсах Cisco Catalyst 4500. Тады, як відаць з , для кантролю выходнага (гэтак жа як і ўваходнага) трафіку на інтэрфейсах вы можаце выкарыстоўваць толькі 4096 радкоў TCAM. Што пры выкарыстанні TCAM3 дасць вам каля 4000 ACE (радок ACL).
У выпадку, калі вы сутыкнуліся з праблемай недастатковага TCAM, то ў першую чаргу, вядома, трэба разгледзець магчымасць аптымізацыі. Так, у выпадку праблемы з памерам Forwarding Table трэба разгледзець магчымасць агрэгавання маршрутаў. У выпадку праблемы з памерам TCAM для доступаў - аўдыт доступаў, выдаленне састарэлых і перасякальных запісаў, а таксама, магчыма, перагляд працэдуры адкрыцця доступаў (будзе падрабязна разгледжана ў раздзеле, прысвечанай аўдыту доступаў).
высокая даступнасць
Пытанне ў тым, ці выкарыстоўваць HA для фаервалаў або паставіць «паралельна» дзве незалежныя скрынкі і ў выпадку падзення адной з іх маршрутызаваць трафік праз другую?
Здавалася б, адказ відавочны выкарыстоўваць HA. Прычына, чаму гэтае пытанне ўсё ж узнікае заключаецца ў тым, што, на жаль, тэарэтычныя і рэкламныя 99 і некалькі дзявятак пасля коскі працэнтаў даступнасці на практыцы аказваюцца далёка не такімі вясёлкавымі. HA — лагічна досыць складаная штука, і на розным абсталяванні, і з рознымі вендарамі (выключэнняў не было) мы адлоўлівалі праблемы і багі і прыпынак сэрвісу.
У выпадку выкарыстання HA вы атрымаеце магчымасць выключаць асобныя ноды, перамыкацца паміж імі без прыпынку сэрвісу, што важна, напрыклад, пры апгрэйдах, але пры гэтым маеце далёка не нулявую верагоднасцю таго, што ў вас зламаюцца абедзве ноды адначасова, а таксама тое, што чарговы апгрэйд пройдзе не так гладка, як абяцае вендар (гэтую праблему можна пазбегнуць, калі ў вас ёсць магчымасць пратэставаць апгрэйд на лабараторным абсталяванні).
Калі вы не выкарыстоўваеце HA, то з пункта гледжання падвойнай паломкі вашы рыскі значна ніжэй (т.к. вы маеце 2 незалежных фаервала), але т.к. сесіі ня сінхранізаваныя, то кожны раз, калі будзе адбывацца пераключэнне паміж гэтымі фаервала вы будзе губляць трафік. Можна, вядома, выкарыстоўваць stateless firewalling, але тады сэнс выкарыстання фаервала па-многім губляецца.
Таму, калі ў выніку аўдыту вы выявілі самотна стаячыя фаервалы, і вы задумваецеся аб павелічэнні надзейнасці вашай сеткі, то HA, вядома, з'яўляецца адным з рэкамендаваных рашэнняў, але вы павінны ўлічыць і мінусы, злучаныя з гэтым падыходам і, магчыма, менавіта для вашай сеткі больш прыдатным будзе іншае рашэнне.
Выгода ў кіраванні (managability)
У прынцыпе HA гэта ў тым ліку і аб кіравальнасці. Замест канфігуравання 2-х скрынак па асобнасці і рашэнні праблемы сінхранізацыі канфігурацый, вы кіруеце імі шмат у чым так, як быццам у вас адна прылада.
Але, магчыма, у вас шмат дата-цэнтраў і шмат фаервалаў, тады гэтае пытанне ўстае на новым узроўні. І пытанне не толькі аб канфігураванні, але таксама аб
- бэкапе канфігурацый
- апдэйтах
- апгрэйдах
- маніторынгу
- лагаванні
І ўсё гэта могуць вырашыць цэнтралізаваныя сістэмы мэнэджменту.
Так, напрыклад, калі вы выкарыстоўваеце Palo Alto фаервалы, то зяўляецца такім рашэннем.
Працяг будзе.
Крыніца: habr.com