🥇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) също работят според нея. Имаме генератор на данни за анализ, за който се използва мрежово устройство или самостоятелен сензор. Имаме система за събиране на алармени сигнали и система за управление на цялата инфраструктура за мониторинг. Последните два компонента могат да бъдат обединени в рамките на един възел, но в по-малки мрежи обикновено се разпределят на две, поне, устройства с цел осигуряване на мащабируемост и надеждност.

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

От друга страна, ако ви е нужна доказателствена база за правоохранителните органи или собствена група за разследване на инциденти, няма да можете да се справите без улавяне на пакети — мрежовата телеметрия не е копие на трафика, който може да се използва при събиране на доказателства; тя е необходима за оперативно откритие и вземане на решения в сферата на ИБ. От друга страна, използвайки анализа на телеметрията, можете да „записвате“ не целия мрежов трафик (ако се интересувате, 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. Каква е разликата между тях?

Представете си, че сте решили да се запознаете с книгата “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), които по същество са обикновени разклонители, пропускащи трафик и предаващи го под формата на flow на модула за събиране. Истината е, че в този случай получаваме целия пакет от проблеми, за които говорихме по-горе по отношение на средствата за захващане на пакети. Тоест, трябва да разберем не само предимствата на технологията за анализ на поток, но и нейните ограничения.

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

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

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

SiLK — това е набор от инструменти (Системата за знания на интернет ниво) за анализ на трафика, разработен от американския CERT\/CC, който поддържа, в контекста на днешната статия, Netflow (петата и деветата, най-популярни версии), 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, шел или други инструменти, които не са включени в 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, ако не сте доволни от модула за Netflow на Logstash, който поддържа само 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

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