Калі гаворка заходзіць аб маніторынгу бяспекі ўнутранай карпаратыўнай або ведамаснай сеткі, то ў многіх узнікае асацыяцыя з кантролем уцечак інфармацыі і ўкараненнем DLP-рашэнняў. А калі паспрабаваць удакладніць пытанне і спытаць, як вы выяўляеце напады ва ўнутранай сетцы, то адказам будзе, як правіла, згадванне сістэм выяўлення нападаў (intrusion detection systems, IDS). І тое, што было адзіным варыянтам яшчэ гадоў 10-20 таму, тое сёння становіцца анахранізмам. Існуе больш эфектыўны, а месцамі і адзіна магчымы варыянт маніторынгу ўнутранай сеткі – выкарыстоўваць flow-пратаколаў, першапачаткова прызначаных для пошуку сеткавых праблем (troubleshooting), але з часам якія трансфармаваліся ў вельмі цікавая прылада бяспекі. Вось пра тое, якія flow-пратаколы бываюць і якія з іх лепш дапамагаюць выяўляць сеткавыя напады, дзе лепш за ўсё ўкараняць маніторынг flow, на што звярнуць увагу пры разгортванні такой схемы, і нават як гэта ўсё "падняць" на айчынным абсталяванні, мы і пагаворым у рамках дадзенага артыкула.
Я не буду спыняцца на пытанні "Навошта патрэбен маніторынг бяспекі ўнутранай інфраструктуры?" Адказ на яго быццам і так зразумелы. Але калі ўсё ж такі вы хацелі б яшчэ раз пераканацца, што сёння без гэтага нікуды, невялікае відэа з аповедам пра тое, як можна 17-цю спосабамі пракрасціся ў карпаратыўную сетку, абароненую міжсеткавым экранам. Таму будзем лічыць, што мы разумеем, што ўнутраны маніторынг - штука патрэбная і засталося толькі зразумець, як яго можна арганізаваць.
Я б вылучыў тры ключавыя крыніцы дадзеных для маніторынгу інфраструктуры на сеткавым узроўні:
- "волкі" трафік, які мы захопліваем і падаем на разбор нейкім сістэмам аналізу,
- падзеі з сеткавых прылад, праз якія праходзіць трафік,
- інфармацыя аб трафіку, якая атрымліваецца па адным з flow-пратаколаў.
Захоп сырога трафіку - самы папулярны ў бяспечнікаў варыянт, таму што ён гістарычна з'явіўся і самым першым. Звычайныя сеткавыя сістэмы выяўлення нападаў (самай першай камерцыйнай сістэмай выяўлення нападаў была NetRanger ад кампаніі Wheel Group, набытая ў 1998-м годзе Cisco) як раз і займаліся захопам пакетаў (а пазней і сесій), у якіх шукаліся вызначаныя сігнатуры ("вырашальныя правілы" у тэрміналогіі (ФСТЭК), якія сігналізуюць аб нападах. Зразумела, аналізаваць волкі трафік можна не толькі з дапамогай IDS, але і з дапамогай іншых сродкаў (напрыклад, Wireshark, tcpdum ці функцыянал NBAR2 у Cisco IOS), але ім звычайна бракуе базы ведаў, якая адрознівае сродак ИБ ад звычайнага ІТ-прылады.
Такім чынам, сістэмы выяўлення нападаў. Самы стары і самы папулярны метад выяўлення сеткавых нападаў, які нядрэнна спраўляецца са сваёй задачай на перыметры (усё роўна якім – карпаратыўным, ЦАДа, сегмента і да т.п.), але пасуе ў сучасных камуціруемых і праграмна-вызначаных сетках. У выпадку з сеткай, пабудаванай на базе звычайных камутатараў, інфраструктура сэнсараў выяўлення нападаў становіцца занадта вялікай - вам прыйдзецца ставіць па сэнсары на кожны злучэнне з вузлом, напады на які вы жадаеце маніторыць. Любы вытворца, вядома, будзе рады прадаць вам сотні і тысячы сэнсараў, але думаю ваш бюджэт не вытрымаць такіх выдаткаў. Магу сказаць, што нават у Cisco (а мы з'яўляемся распрацоўшчыкамі NGIPS) мы не змаглі гэта зрабіць, хоць, здавалася б, пытанне кошту перад намі. стаяць не павінен - гэта ж наша ўласнае рашэнне. Акрамя таго, узнікае пытанне, а як падключаць сэнсар у такім варыянце? У разрыў? А калі сам сэнсар будзе выведзены са строю? Патрабаваць наяўнасці bypass-модуля ў сэнсары? Выкарыстоўваць разветвители (tap)? Усё гэта падаражае рашэнне і робіць яго непад'ёмным для кампаніі любога маштабу.
Можна паспрабаваць "павесіць" сэнсар на SPAN/RSPAN/ERSPAN-порт і накіраваць на яго трафік з неабходных партоў камутатара. Гэты варыянт часткова здымае праблему, апісаную ў папярэднім абзацы, але ставіць іншую - SPAN-порт не можа прыняць абсалютна ўвесь трафік, які ў яго будзе накіроўвацца - яму не хопіць прапускной здольнасці. Прыйдзецца чымсьці ахвяраваць. Або частку вузлоў пакінуць без маніторынгу (тады папярэдне вам трэба правесці іх прыярытэзацыю), ці накіроўваць не ўвесь трафік з вузла, а толькі вызначанага тыпу. У любым выпадку мы можам прапусціць нейкія напады. Акрамя таго, SPAN-порт можа быць заняты пад іншыя патрэбы. У выніку, нам прыйдзецца перагледзець існуючую тапалогію сеткі і ўнесці, магчыма, у яе карэктывы, каб ахапіць па максімуме вашу сетку наяўным у вас лікам сэнсараў (і ўзгадніць гэта з ІТ).
А калі ў вас сетка выкарыстоўвае асіметрычныя маршруты? А калі ў вас укаранёны ці плануецца да ўкаранення SDN? А калі вам трэба маніторыць віртуалізаваныя машыны ці кантэйнеры, трафік якіх наогул не даходзіць да фізічнага камутатара? Гэтыя пытанні не любяць вытворцы традыцыйных IDS, таму што не ведаюць, як адказаць на іх. Магчыма, яны будуць схіляць вас да таго, што ўсе гэтыя модныя тэхналогіі - хайп і вам ён не патрэбен. Магчыма, яны будуць казаць аб неабходнасці пачаць з малога. А можа быць яны скажуць, што вам трэба паставіць магутную малатарню ў цэнтр сеткі і накіраваць увесь трафік у яе з дапамогай балансавальнікаў. Які б варыянт вам не прапаноўвалі, вам трэба самім дакладна зразумець, наколькі ён вам падыходзіць. І толькі пасля гэтага прымаць рашэнне аб выбары падыходу да маніторынгу ИБ сеткавай інфраструктуры. Вяртаючыся ж да захопу пакетаў, хачу сказаць, што гэты метад працягвае заставацца вельмі папулярным і важным, але яго асноўнае прызначэнне - кантроль меж; межаў паміж вашай арганізацыяй і Інтэрнэт, межаў паміж ЦАД і астатняй сеткай, межаў паміж АСК ТП і карпаратыўным сегментам. У гэтых месцах класічныя IDS/IPS па-ранейшаму маюць права на існаванне і добра спраўляюцца з пастаўленымі задачамі.
Пяройдзем да другога варыянту. Аналіз падзей, якія паступаюць з сеткавых прылад, таксама можа быць скарыстаны для мэт выяўлення нападаў, але не як асноўны механізм, бо ён дазваляе дэтэктаваць толькі невялікі клас уварванняў. Да таго ж яму ўласцівая некаторая рэактыўнасць – атака спачатку павінна адбыцца, потым яна павінна быць зафіксаваная сеткавай прыладай, якое тым ці іншым спосабам будзе сігналізаваць аб праблеме з ИБ. Спосабаў такіх некалькі. Гэта можа быць syslog, RMON ці SNMP. Апошнія два пратаколы для сеткавага маніторынгу ў кантэксце ИБ ужываюцца толькі калі нам неабходна выявіць DoS-напад на само сеткавае абсталяванне, бо з дапамогай RMON і SNMP можна, напрыклад, адсочваць загрузку цэнтральнага працэсара прылады або яго інтэрфейсаў. Гэта адзін з самых "танных" (syslog або SNMP ёсць ва ўсіх), але і самы неэфектыўны з усіх спосабаў маніторынгу ИБ ўнутранай інфраструктуры – многія атакі проста схаваныя ад яго. Зразумела ім не трэба грэбаваць і той жа аналіз syslog дапамагае вам своечасова ідэнтыфікаваць змены ў канфігурацыі самай прылады, кампраметацыю менавіта яго, але выяўляць напады на ўсю сетку ён не вельмі падыходзіць.
Трэці варыянт - гэта аналіз інфармацыі аб трафіку, які праходзіць праз прыладу, якое падтрымлівае адзін з некалькіх flow-пратаколаў. У дадзеным выпадку, незалежна ад пратаколу, інфраструктура працы са струменямі абавязкова складаецца з трох кампанентаў:
- Генерацыя ці экспарт flow. Гэтая роля звычайна ўскладаецца на маршрутызатар, камутатар ці іншая сеткавая прылада, якое, прапускаючы праз сябе сеткавы трафік, дазваляе вылучаць з яго ключавыя параметры, якія затым перадаюцца на модуль збору. Напрыклад, у Cisco пратакол Netflow падтрымліваецца не толькі на маршрутызатарах і камутатарах, у тым ліку і віртуальныя і прамысловыя, але і на бесправадных кантралёрах, міжсеткавых экранах і нават серверах.
- Збор flow. Улічваючы, што ў сучаснай сетцы звычайна больш адной сеткавай прылады, узнікае задача збору і кансалідацыі струменяў, якая вырашаецца з дапамогай так званых калектараў, якія праводзяць апрацоўку атрыманых струменяў і затым перадаюць іх для аналізу.
- Аналіз flow. Аналізатар бярэ на сябе асноўную інтэлектуальную задачу і, ужываючы да струменяў розныя алгарытмы, робіць тыя ці іншыя высновы. Напрыклад, у рамках ІТ-функцыі такі аналізатар можа выяўляць вузкія месцы сеткі ці аналізаваць профіль загрузкі трафіку для далейшай аптымізацыі сеткі. А для ИБ такі аналізатар можа выяўляць уцечкі дадзеных, распаўсюджванне шкоднаснага кода ці DoS-напады.
Не варта думаць, што такая трехзвенная архітэктура занадта складаная – усе астатнія варыянты (выключаючы, быць можа, сістэмы сеткавага маніторынгу, якія працуюць з SNMP і RMON) таксама працуе паводле яе. У нас ёсць генератар дадзеных для аналізу, у якасці якога выступае сеткавая прылада або асобна стаіць сэнсар. У нас ёсць сістэма збору сігналаў трывогі і ёсць сістэма кіравання ўсёй інфраструктурай маніторынгу. Апошнія два кампаненты могуць быць аб'яднаны ў рамках аднаго вузла, але ў больш-менш буйных сетках яны звычайна разнесены па двух, прынамсі, прыладам з мэтах забеспячэння маштабавання і надзейнасці.
У адрозненне ад аналізу пакетаў, які базуецца на вывучэнні загалоўка і целы дадзеных кожнага пакета і якія складаюцца з іх сесій, аналіз струменяў абапіраецца на збор метададзеных аб сеткавым трафіку. Калі, колькі, адкуль і куды, як… вось пытанні, на якія адказвае аналіз сеткавай тэлеметрыі пры дапамозе розных пратаколаў flow. Першапачаткова яны выкарыстоўваліся для аналізу статыстыкі і пошуку ІТ-праблем у сетцы, але потым, па меры развіцця аналітычных механізмаў, іх стала магчымым ужываць да той жа тэлеметрыі і для мэт бяспекі. Тут варта яшчэ раз адзначыць, што аналіз плыняў не замяняе і не адмяняе захопу пакетаў. Кожны з гэтых метадаў маюць сваю вобласць ужывання. Але ў кантэксце гэтага артыкула, менавіта аналіз патокаў лепш за ўсё падыходзіць для маніторынгу ўнутранай інфраструктуры. У вас ёсць сеткавыя прылады (і не важна, працуюць яны ў праграмна-вызначанай парадыгме або паводле статычных правілаў), якія напад абмінуць не можа. Сэнсар класічнай IDS яна абыйсці можа, а сеткавая прылада, якое падтрымлівае flow-пратакол, не. У гэтым перавага гэтага метаду.
З іншага боку, калі вам патрэбная доказная база для праваахоўных органаў ці ўласнай групы расследавання інцыдэнтаў, без захопу пакетаў вам не абысціся — сеткавая тэлеметрыя не з'яўляецца копіяй трафіку, які можна выкарыстоўваць пры зборы доказаў; яна патрэбна для аператыўнага выяўлення і прыняцці рашэнняў у вобласці ИБ. З іншага боку, выкарыстоўваючы аналіз тэлеметрыі, вы можаце "пісаць" не ўвесь сеткавы трафік (калі што, то Cisco і ЦАД займаецца :-), а толькі той, які ўдзельнічае ў атацы. Сродкі аналізу тэлеметрыі ў гэтым плане добра дапоўняць традыцыйныя механізмы захопу пакетаў, даючы каманду на выбарачны захоп і захоўванне. У адваротным выпадку вам давядзецца мець каласальную інфраструктуру захоўвання.
Прадстаўляльны сетка, якая працуе на хуткасці 250 Мбіт/сек. Калі вы захочаце захоўваць увесь гэты аб'ём, то вам спатрэбіцца сховішча на 31 Мб для адной секунды перадачы трафіку, 1,8 Гб – для адной хвіліны, 108 Гб – для адной гадзіны, і 2,6 Тб – для адных сутак. Для захоўвання сутачных дадзеных з сеткі з прапускной здольнасцю ў 10 Гбіт/сек вам спатрэбіцца сховішча на 108 Тб. А бо некаторыя рэгулятары патрабуюць захоўваць дадзеныя па бяспецы гадамі ... Запіс "па патрабаванні", якую вам дапамагае рэалізаваць аналіз патокаў, дапамагае скараціць гэтыя значэння на парадкі. Дарэчы, калі казаць аб суадносінах аб'ёму якія запісваюцца дадзеных сеткавай тэлеметрыі і поўнага захопу дадзеных, то яно складае прыкладна 1 да 500. Для тых жа прыведзеных вышэй значэнняў, захоўванне поўнай расшыфроўкі ўсяго дзённага трафіку складзе 5 і 216 Гб адпаведна (можна нават на звычайную флешку запісаць ).
Калі ў сродкаў аналізу волкіх сеткавых дадзеных метад іх захопу амаль не адрозніваецца ад вендара да вендару, то ў выпадку з аналізам струменяў сітуацыя іншая. Існуе некалькі варыянтаў flow-пратаколаў, аб адрозненнях у якіх неабходна ведаць менавіта ў кантэксце бяспекі. Самым папулярным з'яўляецца пратакол Netflow, распрацаваны кампаніяй Cisco. Існуе некалькі версій гэтага пратакола, якія адрозніваюцца па сваіх магчымасцях і аб'ёме запісванай аб трафіку інфармацыі. Бягучая версія – дзевятая (Netflow v9), на базе якой быў распрацаваны прамысловы стандарт Netflow v10, таксама вядомы як IPFIX. Сёння большасць сеткавых вендараў падтрымлівае менавіта Netflow ці IPFIX у сваім абсталяванні. Але ёсць і розныя іншыя варыянты flow-пратаколаў - sFlow, jFlow, cFlow, rFlow, NetStream і да т.п., з якіх папулярнейшым з'яўляецца sFlow. Менавіта ён часцей за ўсё падтрымліваецца айчыннымі вытворцамі сеткавага абсталявання з прычыны прастаты рэалізацыі. У чым ключавыя адрозненні паміж Netflow, як стандарту сталым такім дэ-факта, і тым жа sFlow? Ключавых я б вылучыў некалькі. Па-першае, Netflow мае наладжвальныя карыстачом поля ў адрозненне ад фіксаваных палёў у sFlow. А па-другое, і гэта самае галоўнае ў нашым выпадку, sFlow збірае так званую сэмпляваную тэлеметрыю; у адрозненне ад несемпляванай у Netflow і IPFIX. У чым жа паміж імі розніца?
Уявіце, што вы вырашылі азнаёміцца з кнігай” маіх калег — Гары Макінтайра, Джозэфа Муніца і Надзема Альфардана (па спасылцы вы можаце спампаваць частку кнігі). У вас ёсць тры варыянты дасягнуць пастаўленай мэты - прачытаць кнігу цалкам, прабегчы яе вачыма, спыняючыся на кожнай 10-й або 20-й старонцы, або паспрабаваць знайсці пераказ ключавых канцэпцый у якім-небудзь блогу або сэрвісе тыпу SmartReading. Дык вось несемпляваная тэлеметрыя - гэта чытанне кожнай "старонкі" сеткавага трафіку, гэта значыць аналіз метададзеных па кожным пакеце. Сэмпляваная тэлеметрыя - гэта выбарачнае вывучэнне трафіку ў надзеі, што ў абраных сэмплах апынецца тое, што вам трэба. У залежнасці ад хуткасці канала сэмпляваная тэлеметрыя будзе аддаваць для аналізу кожны 64-ы, 200-ы, 500-ы, 1000-ы, 2000-ы ці нават 10000-ы пакет.
У кантэксце маніторынгу ИБ гэта азначае, што сэмпляваная тэлеметрыя добра падыходзіць для выяўлення DDoS-нападаў, сканавання, распаўсюджванні шкоднаснага кода, але можа прапусціць атамарныя ці шматпакетныя напады, не якія патрапілі ў сэмпл, адпраўлены для аналізу. У несмепляванай тэлеметрыі такіх недахопаў няма і з яе. дапамогай спектр выяўляных нападаў значна шырэй. Вось невялікі пералік падзей, якія можна выяўляць з дапамогай сродкаў аналізу сеткавай тэлеметрыі.
Зразумела, які-небудзь open source аналізатар Netflow вам гэтага не дазволіць, бо яго асноўная задача – сабраць тэлеметрыю і правесці над ёй базавы аналіз з пункта гледжання ІТ. Для выяўлення на базе flow пагроз ИБ неабходна абсталяваць аналізатар рознымі рухавічкамі і алгарытмамі, якія і будуць на базе стандартных ці карыстацкіх палёў Netflow выяўляць праблемы кібербяспекі, узбагачаць стандартныя дадзеныя вонкавымі дадзенымі ад розных крыніц Threat Intelligence і да т.п.
Таму калі ў вас ёсць выбар, то спыняйце яго на Netflow ці IPFIX. Але нават калі ваша абсталяванне працуе толькі з sFlow, як у айчынных вытворцаў, то нават у гэтым выпадку вы можаце атрымаць з яго карысць у кантэксце бяспекі.
Улетку 2019-га года я праводзіў аналіз магчымасцяў, якія ёсць у расійскіх вытворцаў сеткавага жалеза і ўсе яны, выключаючы NSG, Палігона і Крафтвея, заяўлялі аб падтрымцы sFlow (як мінімум, Зелакс, Натэкс, Элтэкс, QTech, Рустэлетэх).
Наступнае пытанне, якое перад вамі паўстане, - дзе ўкараняць падтрымку flow для мэт бяспекі? Насамрэч, пытанне пастаўлена не зусім карэктна. На сучасным абсталяванні падтрымка flow-пратаколаў ёсць амаль заўсёды. Таму пытанне я б перафармуляваў інакш - дзе больш эфектыўна за ўсё збіраць тэлеметрыю з пункту гледжання бяспекі? Адказ будзе дастаткова відавочным – на ўзроўні доступу, дзе вы ўбачыце 100% усяго трафіку, дзе ў вас будзе дэталёвая інфармацыя па хастах (MAC, VLAN, ID інтэрфейсу), дзе вы зможаце адсочваць нават P2P-трафік паміж хастамі, што крытычна для выяўлення сканавання і і распаўсюджванні шкоднаснага кода. На ўзроўні ядра частка трафіку вы можаце проста не ўбачыць, а на ўзроўні перыметра вы ўбачыце добра, калі чвэрць усяго вашага сеткавага трафіку. Але калі па нейкіх прычынах у вас у сетцы завяліся староннія прылады, якія дазваляюць зламыснікам "уваходзіць і выходзіць", абыходзячы перыметр, то аналіз тэлеметрыі з яго вам нічога не дасць. Таму для максімальнага ахопу рэкамендуецца ўключаць збор тэлеметрыі менавіта на ўзроўні доступа. Пры гэтым, варта адзначыць, што нават калі мы гаворым аб віртуалізацыі або кантэйнерах, то ў сучасных віртуальных камутатарах таксама часта сустракаецца падтрымка flow, што дазваляе кантраляваць трафік і там.
Але раз ужо я падняў тэму, то трэба адказаць на пытанне, а што калі ўсёткі абсталяванне, фізічнае ці віртуальнае, не падтрымлівае flow-пратаколы? Ці яго ўключэнне забаронена (напрыклад, у прамысловых сегментах для забеспячэння надзейнасці)? Ці яго ўключэнне прыводзіць да высокай загрузкі цэнтральнага працэсара (такое бывае на састарэлым абсталяванні)? Для рашэння гэтай задачы існуюць спецыялізаваныя віртуальныя сэнсары (flow sensor), якія ў сутнасці з'яўляюцца звычайнымі разгаліноўшчыкамі, якія прапускаюць праз сябе трафік і транслявалыя яго ў выглядзе flow на модуль збору. Праўда, у гэтым выпадку мы атрымліваем увесь куча праблем, аб якіх мы казалі вышэй у дачыненні да сродкаў захопу пакетаў. Гэта значыць, трэба разумець не толькі перавагі тэхналогіі аналізу патокаў, але і яе абмежаванні.
Яшчэ адзін момант, які важна памятаць, гаворачы аб сродках аналізу патокаў. Калі ў дачыненні да звычайных сродкаў генерацыі падзей бяспекі мы ўжываем метрыку EPS (event per second, падзей у секунду), то да аналізу тэлеметрыі гэты паказчык непрымяняльны; ён замяняецца на FPS (flow per second, струмень у секунду). Як і ў выпадку з EPS, вылічыць загадзя яго нельга, але можна ацаніць прыкладную колькасць струменяў, якое генерыць тое ці іншае прылада ў залежнасці ад яго задачы. У Інтэрнэт вы можаце знайсці табліцы з прыкладнымі значэннямі для розных тыпаў карпаратыўных прылад і ўмоў, што дазволіць вам прыкінуць, якія ліцэнзіі вам патрэбны для сродкаў аналізу і якая будзе іх архітэктура? Справа ў тым, што сэнсар IDS абмежаваны вызначанай прапускной здольнасцю, якую ён "выцягне", так і калектар струменяў мае свае абмежаванні, якія трэба разумець. Таму ў буйных, тэрытарыяльна-размеркаваных сетках калектараў звычайна некалькі. Калі я апісваў, , я ўжо прыводзіў лік нашых калектараў – іх 21. І гэта на сетку, раскіданую па пяці мацерыкам і якая налічвае каля паўмільёна актыўных прылад).
У якасці сістэмы маніторынгу Netflow мы выкарыстоўваем нашае ўласнае рашэнне , якое спецыяльна арыентавана на вырашэнне задач бяспекі. У яго шмат убудаваных рухавікоў выяўлення анамальнай, падазронай і відавочна шкоднаснай актыўнасці, якая дазваляе дэтэктаваць шырокі спектр розных пагроз – ад криптомайнинга да ўцечак інфармацыі, ад распаўсюджвання шкоднаснага кода да махлярства. Як і большасць аналізатараў патокаў Stealthwatch пабудаваны па трохузроўневай схеме (генератар – калектар – аналізатар), але ён дапоўнены побач цікавых асаблівасцяў, якія важныя ў кантэксце разгляданага матэрыялу. Па-першае, ён інтэгруецца з рашэннямі па захопе пакетаў (напрыклад, Cisco Security Packet Analyzer), што дазваляе запісваць абраныя сеткавыя сесіі для наступнага глыбокага расследавання і аналізу. Па-другое, спецыяльна для пашырэння задач бяспекі мы распрацавалі спецыяльны пратакол nvzFlow, які дазваляе "трансляваць" актыўнасць прыкладанняў на канцавых вузлах (серверах, працоўных станцыях і да т.п.) у тэлеметрыю і перадаваць яе на калектар для далейшага аналізу. Калі ў сваім спрадвечным варыянце Stealthwatch працуе з любым flow-пратаколам (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) на ўзроўні сеткі, то падтрымка nvzFlow дазваляе праводзіць карэляцыю дадзеных яшчэ і на ўзроўні вузла, тым самым. падвышаючы эфектыўнасці ўсёй сістэмы і бачачы больш нападаў, чым звычайныя сеткавыя аналізатары струменяў.
Зразумела, што кажучы аб сістэмах аналізу Netflow з пункта гледжання бяспекі, рынак не абмежаваны адзіным рашэннем ад Cisco. Вы можаце выкарыстоўваць як камерцыйныя, так і бясплатныя ці ўмоўна бясплатныя рашэнні. Досыць дзіўна, калі я ў блогу Cisco буду прыводзіць у прыклад рашэнні канкурэнтаў, таму скажу пару слоў пра тое, як сеткавая тэлеметрыя можа быць прааналізаваная з дапамогай двух папулярных, падобных па назове, але ўсёткі розных прылад – SiLK і ELK.
SiLK - гэта набор інструментаў (the System for Internet-Level Knowledge) для аналізу трафіку, распрацаваны амерыканскім CERT / CC і які падтрымлівае, у кантэксце сённяшняга артыкула, Netflow (5-й і 9-й, самых папулярных версій), IPFIX і sFlow і з дапамогай розных утыліт (rwfilter, rwcount, rwflowpack і інш.) вырабляць розныя аперацыі над сеткавай тэлеметрыяй з мэтай выяўлення ў ёй прыкмет несанкцыянаваных дзеянняў. Але трэба адзначыць пару важных момантаў. SiLK - гэта інструмент каманднага радка і праводзіць аператыўны аналіз, увесь час уводу каманды віду (выяўленне ICMP-пакетаў памерам больш за 200 байт):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
не вельмі зручна. Вы можаце выкарыстоўваць графічны інтэрфейс iSiLK, але ён не моцна аблегчыць ваша жыццё, вырашаючы толькі функцыю візуалізацыі, а не замены аналітыка. І гэта другі момант. У адрозненне ад камерцыйных рашэнняў, у якія ўжо закладзена самавітая аналітычная база, алгарытмы выяўлення анамалій, якія адпавядаюць workflow і да т.п., у выпадку з SiLK вы ўсё гэта павінны будзеце прарабіць самастойна, што запатрабуе ад вас трохі іншых кампетэнцый, чым ад выкарыстання ўжо гатовага да працы інструментара. Гэта нядобра і нядрэнна - гэта асаблівасць амаль любога бясплатнага інструмента, які зыходзіць з таго, што вы ведаеце, што рабіць, а ён вам толькі дапаможа ў гэтым (камерцыйны інструментарый менш залежым ад кампетэнцый яго карыстальнікаў, хоць таксама мяркуе, што аналітыкі разумеюць хаця б асновы правядзення сеткавых расследаванняў і маніторынгу). Але вернемся да SiLK. Цыкл працы аналітыка з ім выглядае наступным чынам:
- Фармуляванне гіпотэзы. Мы павінны разумець, што мы будзем шукаць унутры сеткавай тэлеметрыі, ведаць унікальныя атрыбуты, па якіх будзем выяўляць тыя ці іншыя анамаліі ці пагрозы.
- Пабудова мадэлі. Сфармуляваўшы гіпотэзу, мы праграмуем яе з дапамогай таго ж Python, шелла ці іншых прылад, якія не ўваходзяць у SiLK.
- Тэсціраванне. Надыходзіць чарга праверкі правільнасці нашай гіпотэзы, якая пацвярджаецца або абвяргаецца з дапамогай утыліт SiLK, якія пачынаюцца з 'rw', 'set', 'bag'.
- Аналіз рэальных даных. У прамысловай эксплуатацыі SiLK нам дапамагае нам выяўляць нешта і аналітык павінен адказаць на пытанні "Ці знайшлі мы тое, што меркавалі?", "Ці адпавядае гэта нашай гіпотэзе?", "Як знізіць колькасць ілжывых спрацоўванняў?", "Як палепшыць узровень распазнання? » і да т.п.
- Паляпшэнне. На фінальным этапе мы паляпшаем зробленае раней - ствараем шаблоны, паляпшаем і аптымізуем код, перафармулюем і ўдакладняем гіпотэзу і інш.
Гэты цыкл будзе дастасавальны і да таго ж Cisco Stealthwatch, толькі апошні гэтыя пяць крокаў аўтаматызуе па максімуме, зніжаючы колькасць памылак аналітыка і падвышаючы аператыўнасць выяўлення інцыдэнтаў. Напрыклад, у SiLK сеткавую статыстыку вы можаце ўзбагаціць вонкавымі дадзенымі па шкоднасным IP з дапамогай уласнаручна напісаных скрыптоў, а ў Cisco Stealthwatch – гэта ўбудаваная функцыя, якая адразу вам адлюстроўвае сігнал трывогі, калі ў сеткавым трафіку сустракаецца ўзаемадзеянне з IP-адрасамі з чорнага спісу.
Калі пайсці вышэй па пірамідзе «платнасці» ПЗ па аналізе flow, то за абсалютна бясплатным SiLK будзе ісці ўмоўна бясплатны ELK, які складаецца з трох ключавых кампанентаў – Elasticsearch (індэксацыя, пошук і аналіз дадзеных), Logstash (увод / вывад дадзеных) і Kibana ( візуалізацыя). У адрозненне ад SiLK, дзе ўсё даводзіцца пісаць самому, у ELK ужо ёсць шмат гатовых бібліятэк/модуляў (частка платныя, частка няма), якія аўтаматызуюць аналіз сеткавай тэлеметрыі. Напрыклад, фільтр GeoIP у Logstash дазваляе прывязаць назіраныя IP-адрасы да іх геаграфічнага месцазнаходжання (у таго ж Stealthwatch гэта ўбудаваная функцыя).
У ELK таксама досыць вялікае кам'юніці, якое дапісвае адсутнічаюць кампаненты для гэтага рашэння па маніторынгу. Напрыклад, каб працаваць з Netflow, IPFIX і sFlow вы можаце скарыстацца модулем , калі вас не задавальняе Logstash Netflow Module, які падтрымлівае толькі Netflow.
Даючы больш аператыўнасці па зборы flow і пошуку ў ім, у ELK на бягучы момант адсутнічае багатая ўбудаваная аналітыка па выяўленні анамалій і пагроз у сеткавай тэлеметрыі. Гэта значыць, вынікаючы вышэй апісанаму жыццёваму цыклу, вам давядзецца самастойна апісваць мадэлі парушэнняў і потым ужо карыстацца ім у баявой сістэме (убудаваных мадэляў там няма).
Ёсць вядома і больш наварочаныя пашырэнні для ELK, у якіх ужо закладзены некаторыя мадэлі выяўлення анамалій у сеткавай тэлеметрыі, але такія пашырэнні каштуюць грошай і тут ужо пытанне, ці варта аўчынка выраба – пісаць аналагічную мадэль самому, купляць яе рэалізацыю для свайго сродку маніторынгу ці купіць гатовае рашэнне класа Network Traffic Analysis.
Наогул не жадаю ўдавацца ў палеміку, што лепш выдаткаваць грошы і купіць гатовае рашэнне для маніторынгу анамалій і пагроз у сеткавай тэлеметрыі (напрыклад, Cisco Stealthwatch) ці разабрацца самастойна і дакручваць пад кожную новую пагрозу той жа SiLK, ELK ці nfdump ці OSU Flow Tools ( я пра апошнія два з іх мінулым разам)? Кожны выбірае для сябе і ў кожнага ёсць свае матывы абраць любы з двух варыянтаў. Я ж жадаў проста паказаць, што сеткавая тэлеметрыя - гэта вельмі важны інструмент у забеспячэнні сеткавай бяспекі сваёй унутранай інфраструктуры і грэбаваць ім не варта, каб не папоўніць спіс кампанія, чыё імя згадваецца ў СМІ разам з эпітэтамі «ўзламаная», «якая не выконвала патрабаванні па ИБ », «якая не задумваецца аб бяспецы сваіх дадзеных і дадзеных кліентаў».
Падводзячы вынікі, я б жадаў пералічыць ключавыя рады, якім варта вынікаць пры выбудоўванні маніторынгу ИБ сваёй унутранай інфраструктуры:
- Не абмяжоўвайцеся толькі перыметрам! Выкарыстоўвайце (і выбірайце) сеткавую інфраструктуру не толькі для перадачы трафіку з кропкі А ў кропку Б, але і для вырашэння пытанняў кібербяспекі.
- Вывучыце існуючыя механізмы маніторынгу ИБ ў вашым сеткавым абсталяванні і задзейнічайце іх.
- Для ўнутранага маніторынгу аддавайце перавагу аналізу тэлеметрыі – ён дазваляе выяўляць да 80-90% усіх сеткавых інцыдэнтаў ИБ, робячы пры гэтым тое, што немагчыма пры захопе сеткавых пакетаў і эканомячы прастору для захоўвання ўсіх падзей ИБ.
- Для маніторынгу патокаў выкарыстоўвайце Netflow v9 або IPFIX - яны даюць больш інфармацыі ў кантэксце бяспекі і дазваляюць маніторыць не толькі IPv4, але і IPv6, MPLS і г.д.
- Выкарыстоўвайце несемпляваны flow-пратакол - ён дае больш інфармацыі для выяўлення пагроз. Напрыклад, Netflow ці IPFIX.
- Праверце загрузку вашага сеткавага абсталявання - магчыма яно не зладзіцца з апрацоўкай яшчэ і flow-пратакола. Тады прадумайце ўжыванне віртуальных сэнсараў ці Netflow Generation Appliance.
- Рэалізуйце кантроль у першую чаргу на ўзроўні доступу - гэта дасць вам магчымасць бачыць 100% усяго трафіку.
- Калі вы ў вас не выбару і вы карыстаецеся расійскае сеткавае абсталяванне, то выбірайце тое, якое падтрымлівае flow-пратаколы ці мае SPAN/RSPAN-парты.
- Камбінуйце сістэмы выяўлення/ прадухіленні ўварвання/нападаў на межах і сістэмы аналізу струменяў ва ўнутранай сетцы (у тым ліку і ў аблоках).
Што да апошняй рады, то я бы жадаў прывесці ілюстрацыю, якую ўжо прыводзіў раней. Вы бачыце, што калі раней служба ИБ Cisco амаль цалкам выбудоўвала сваю сістэму маніторынгу ИБ на базе сістэм выяўлення ўварванняў і сігнатурных метадаў, то зараз на іх дзель даводзіцца ўсяго 20% інцыдэнтаў. Яшчэ 20% прыпадае на сістэмы аналізу патокаў, што кажа аб тым, што гэтыя рашэнні – не блазнота, а рэальны інструмент у дзейнасці службаў ИБ сучаснага прадпрыемства. Тым больш, што ў вас для іх укаранення ёсць самае галоўнае – сеткавая інфраструктура, інвестыцыі ў якую можна дадаткова абараніць, усклаўшы на сетку яшчэ і функцыі маніторынгу ИБ.
Я спецыяльна не стаў дакранацца тэмы рэагавання на выяўленыя ў сеткавых плынях анамаліі ці пагрозы, але думаю, што і так зразумела, што маніторынг не павінен завяршацца толькі выяўленнем пагрозы. За ім павінна прытрымлівацца рэагавання і пажадана ў аўтаматычным ці аўтаматызаваным рэжыме. Але гэта ўжо тэма асобнага матэрыялу.
Дадатковая інфармацыя:
ЗЫ. Калі вам прасцей успрымаць на слых усё, што было напісана вышэй, тыя вы можаце паглядзець гадзіннікавую прэзентацыю, якая легла ў аснову дадзенай нататкі.
Крыніца: habr.com