🥇Flow протоколите като инструмент за мониторинг на сигурността на вътрешната мрежа

Когато става въпрос за мониторинг на безопасността на вътрешната корпоративна или ведомствена мрежа, много хора асоциират това с контрол на изтичане на информация и внедряване на DLP решения. А ако опитате да уточните въпроса и да попитате как откривате атаки във вътрешната мрежа, отговорът обикновено ще включва споменаване на системи за откриване на атаки (intrusion detection systems, IDS). И това, което преди беше единственият вариант преди 10-20 години, днес вече изглежда остаряло. Съществува по-ефективен, а понякога и единствено възможен вариант за мониторинг на вътрешната мрежа – използване на flow-протоколи, първоначално предназначени за откриване на мрежови проблеми (troubleshooting), но с течение на времето трансформирани в много интересен инструмент за безопасност. В тази статия ще говорим за различните видове flow-протоколи, които най-добре помагат за откриване на мрежови атаки, къде е най-добре да внедрите мониторинг на flow, на какво да обърнете внимание при разгръщане на такава схема и дори как всичко това да се реализира на родно оборудване.

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

Бих выделил три ключови източника на данни за мониторинг на инфраструктурата на мрежовото ниво:

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

Улавянето на суров трафик е най-популярният вариант сред специалистите по безопасност, тъй като той исторически е най-старият. Обикновените системи за откриване на атаки в мрежата (първата търговска система за откриване на атаки беше NetRanger от компанията Wheel Group, закупена през 1998 година от Cisco) се занимаваха точно с улавянето на пакети (по-късно и на сесии), в които се търсеха определени сигнатури („решаващи правила“ в терминологията на ФСТЭК), сигнализиращи за атаки. Разбира се, суровият трафик може да се анализира не само с помощта на IDS, но и с други средства (например, Wireshark, tcpdump или функционалността 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. Имайки предвид, че в съвременната мрежа обикновено има повече от едно мрежово устройство, възниква задача за събиране и консолидация на потоките, която се решава с помощта на т.нар. колектори, които обработват получените потоци и след това ги предават за анализ.
Анализ на потоци. Анализаторът поема основната интелектуална задача и, прилагайки различни алгоритми към потоките, прави съответни изводи. Например, в контекста на ИТ функцията, такъв анализатор може да открие тесни места в мрежата или да анализира профила на натоварване на трафика за последваща оптимизация на мрежата. А за информационната безопасност, такъв анализатор може да идентифицира изтичания на данни, разпространение на зловреден софтуер или атаки DoS.

Не трябва да смятате, че такава треслойна архитектура е твърде сложна — всички останали варианти (с изключение, може би, на системите за мрежово наблюдение, работещи с SNMP и RMON) също функционират на нейна база. Имаме генератор на данни за анализ, в ролята на който може да бъде мрежово устройство или самостоятелен сензор. Разполагаме с система за събиране на алармени сигнали и система за управление на цялата инфраструктура за наблюдение. Последните два компонента могат да бъдат обединени в рамките на един възел, но в по-големи мрежи те обикновено са разпределени поне на две устройства с цел осигуряване на мащабируемост и надеждност.

В отличие от анализа на пакети, който се основава на изучаване на заглавките и тялото на данните в всеки пакет и съставляващите ги сесии, анализът на потоките се опира на събиране на метаданни за мрежовия трафик. Кога, колко, откъде и накъде, как... ето въпросите, на които отговаря анализът на мрежовата телеметрия с различни протоколи flow. Първоначално те се използваха за анализ на статистиката и търсене на ИТ проблеми в мрежата, но с развитието на аналитичните механизми, стана възможно да се прилагат и за същата телеметрия и за целите на сигурността. Тук е важно отново да се подчертае, че анализът на потоките не заменя и не отменя захвата на пакети. Всеки от тези методи има своята област на приложение. Но в контекста на настоящата статия, именно анализът на потоките е най-подходящ за наблюдение на вътрешната инфраструктура. Имате мрежови устройства (независимо дали работят в софтуерно определена парадигма или според статични правила), които атаката не може да заобиколи. Сензорът на класическата IDS може да бъде заобиколен, но мрежовото устройство, поддържащо flow протокола, не може. В това се изразява предимството на този метод.

От друга страна, ако ви е нужна доказателствена база за правоохранителните органи или собствена група за разследване на инциденти, няма как да се мине без пакетно улавяне — мрежовата телеметрия не е копие на трафика, което може да се използва при събиране на доказателства; тя е необходима за оперативно откритие и вземане на решения в сферата на ИТ сигурността. От друга страна, използвайки анализа на телеметрия, можете да "записвате" не целия мрежов трафик (ако е нужно, Cisco и ЦОД-овете се занимават с това :-), а само този, който участва в атаката. Средствата за анализ на телеметрията в това отношение добре допълват традиционните механизми за пакетно улавяне, предлагайки команда за селективно улавяне и съхранение. В противен случай ще трябва да имате колосална инфраструктура за съхранение.

Представете си мрежа, работеща с скорост 250 Мбит/сек. Ако искате да съхранявате целия този обем, нуждаете се от хранилище от 31 Мб за една секунда предаване на трафик, 1,8 Гб — за една минута, 108 Гб — за един час и 2,6 Тб — за един ден. За съхранение на дневни данни от мрежа с пропускна способност 10 Гбит/сек ще ви трябва хранилище от 108 Тб. А някои регулатори изискват да се съхраняват данни по безопасност в продължение на години… Записването "по заявка", което анализът на потоките ви помага да реализирате, помага да се съкратят тези стойности с порядъци. Между другото, ако говорим за съотношението между обема на записаните данни от мрежовата телеметрия и пълното улавяне на данни, то е около 1 към 500. За същите посочени по-горе стойности, съхранението на пълната декодировка на целия дневен трафик ще е 5 и 216 Гб съответно (може дори да запишете на обикновена флашка).

Ако при анализа на сурови мрежови данни методът за захващане едва ли се различава от един производител до друг, то при анализа на потоките ситуацията е различна. Съществуват няколко варианта на потокови протоколи, за различията в които е необходимо да се знае именно в контекста на сигурността. Най-популярен е протоколът Netflow, разработен от компанията Cisco. Съществуват няколко версии на този протокол, които се различават по своите възможности и обем на записваната информация за трафика. Текущата версия е девета (Netflow v9), на базата на която беше разработен индустриалният стандарт Netflow v10, известен също така като IPFIX. Днес повечето мрежови производители поддържат именно Netflow или IPFIX в своето оборудване. Но има и различни други варианти на потокови протоколи — sFlow, jFlow, cFlow, rFlow, NetStream и т.н., от които по-популярен е sFlow. Именно той най-често се подкрепя от местните производители на мрежово оборудване поради простотата на реализацията. Какви са основните разлики между Netflow, като стандарт, станал такъв де факто, и същия sFlow? Основните, които бих отбелязал, са няколко. На първо място, Netflow има настраиваеми полета от потребителя в отличие от фиксираните полета в sFlow. На второ място, и това е най-важното в нашия случай, sFlow събира така наречената семплирана телеметрия, в отличие от несемплираната в Netflow и IPFIX. Каква е разликата между тях?

Представете си, че решихте да се запознаете с книгата “Security Operations Center: Building, Operating, and Maintaining your SOC” на моите колеги — Гари Макинтайр, Джозеф Мунитц и Надем Алфардан (по връзката можете да изтеглите част от книгата). Имате три варианта да постигнете целта — да прочетете книгата изцяло, да я прегледате, спирайки се на всяка 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), които по същество са обикновени разклонители, пропускащи трафика и трансформиращи го в поток за модула за събиране. Обаче, в този случай получаваме цял куп проблеми, за които говорихме по-горе във връзка със средствата за захващане на пакети. Тоест, трябва да разберем не само предимствата на технологията за анализ на потоците, но и нейните ограничения.

Още един момент, който е важно да се има предвид, когато става въпрос за анализаторите на потоци. Ако за обикновените средства за генериране на събития за безопасност използваме метриката EPS (събития на секунда), то за анализа на телеметрията този показател не е приложим; той се заменя с FPS (поток на секунда). Както при EPS, не може да се изчисли предварително, но може да се оцени примерното количество потоци, които генерира дадено устройство в зависимост от задачата му. В интернет можете да намерите таблици с приблизителни стойности за различни типове корпоративни устройства и условия, които ще ви помогнат да прецените какви лицензи са ви необходими за средствата за анализ и каква ще бъде тяхната архитектура. Факт е, че IDS сензорът е ограничен с определена пропускателна способност, която може да издържи, вече посочих броя на нашите колектори — те са 21. И това е на мрежа, разпръсната по пет континента и включваща около половин милион активни устройства).

Като система за мониторинг на Netflow използваме собственото си решение Cisco Stealthwatch, който е специално насочен към решаване на проблеми със сигурността. Има много вградени механизми за откриване на аномална, подозрителна и явно вредоносна активност, което позволява откритие на широк спектър от различни заплахи – от криптомайнинг до изтичане на информация, от разпространение на злонамерен код до измама. Както повечето анализатори на потоци, Stealthwatch е построен по триредова схема (генератор – колектор – анализатор), но е допълнен с редица интересни функции, които са важни в контекста на разглеждания материал. Първо, интегрира се с решения за улавяне на пакети (например, Cisco Security Packet Analyzer), което позволява записване на избрани мрежови сесии за последващо дълбочинно разследване и анализ. Второ, специално за разширяване на задачите по сигурността, разработихме специален протокол nvzFlow, който позволява “транслиране” на активността на приложенията на крайни възли (сервери, работни станции и др.) в телеметрия и предаване на нея на колектора за по-нататъшен анализ. Ако в оригиналния си вариант Stealthwatch работи с всеки flow-протокол (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) на ниво мрежа, то поддръжката на nvzFlow позволява извършване на корелация на данните и на ниво възел, като по този начин повишава ефективността на цялата система и позволява откритие на повече атаки, отколкото обикновените мрежови анализатори на потоци.

Ясно е, че говоря за системи за анализ на Netflow от гледна точка на сигурността, пазарът не се ограничава само с решението на Cisco. Можете да използвате както търговски, така и безплатни или условно безплатни решения. Достатъчно странно е, ако в блога на Cisco давам примери с решения на конкуренти, затова ще кажа няколко думи за това как мрежовата телеметрия може да бъде анализирана с помощта на два популярни, схожи по име, но все пак различни инструмента – SiLK и ELK.

SiLK е набор от инструменти (Системата за интернет ниво знания) за анализ на трафика, разработен от американския 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, но той няма да ви облекчи значително, решавайки само функциите на визуализация, а не заместването на аналитика. И това е вторият момент. За разлика от търговските решения, които вече имат солидна аналитична база, алгоритми за откриване на аномалии, съответстващи на работния поток и т.н., в случая с SiLK вие всичко това трябва да направите сами, което ще изисква от вас малко по-различни компетенции, отколкото при използването на вече готов инструментариум. Това не е нито добре, нито зле — това е особеност на почти всяко безплатно средство, което предполага, че знаете какво да правите, а то просто ще ви помогне в това (търговският инструментариум е по-малко зависим от компетенциите на потребителите си, макар и да предполага, че аналитиците поне разбират основите на провеждането на мрежови разследвания и мониторинг). Но да се върнем на SiLK. Цикълът на работа на аналитика с него изглежда по следния начин:

Формулиране на хипотеза. Трябва да разберем какво ще търсим в мрежовата телеметрия, да знаем уникалните атрибути, по които ще откриваме определени аномалии или заплахи.
Създаване на модел. След като формулираме хипотезата, програмираме я с помощта на същия Python, shell или други инструменти, които не са включени в 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 можете да се възползвате от модула elastiflow, ако 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 портове.
Комбинирайте системи за откриване/предотвратяване на intrusion/атаки на границите и системи за анализ на потоците в вътрешната мрежа (включително и в облака).

Що се отнася до последния съвет, бих искал да представя илюстрация, която вече споменах преди. Виждате, че ако преди службата за информационна безопасност на Cisco почти изцяло изграждаше своята система за мониторинг на ИБ на базата на системи за откриване на нарушители и сигнатурни методи, то сега на тях се дължат само 20% от инцидентите. Още 20% идват от системи за анализ на потоците, което показва, че тези решения не са каприз, а реален инструмент в работата на службите за информационна сигурност на съвременната компания. Тем повече, че за внедряването им имате най-важното – мрежовата инфраструктура, инвестициите в която можете допълнително да защитите, натоварвайки мрежата и с функции за мониторинг на ИБ.

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

Допълнителна информация:

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

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

Flow-протоколи като инструмент за мониторинг на безопасността на вътрешната мрежа