Протоколите на проток како алатка за следење на безбедноста на внатрешната мрежа

Кога станува збор за следење на безбедноста на внатрешна корпоративна или одделенска мрежа, многумина го поврзуваат со контролирање на протекување информации и имплементација на решенија за DLP. И ако се обидете да го разјасните прашањето и прашате како откривате напади на внатрешната мрежа, тогаш одговорот, по правило, ќе биде спомнување на системи за откривање на упад (IDS). А она што беше единствената опција пред 10-20 години, денес станува анахронизам. Постои поефикасна, а на некои места и единствена можна опција за следење на внатрешната мрежа - користење протоколи за проток, кои првично беа дизајнирани да бараат мрежни проблеми (решавање проблеми), но со текот на времето се трансформираа во многу интересна безбедносна алатка. Ќе разговараме за тоа какви протоколи има и кои се подобри во откривањето мрежни напади, каде е најдобро да се спроведе следење на протокот, што да барате при распоредување на таква шема, па дури и како да се „подигне“ сето ова на домашна опрема во рамките на овој член.

Нема да се задржам на прашањето „Зошто е потребен мониторинг на внатрешната безбедност на инфраструктурата? Се чини дека одговорот е јасен. Но, ако, сепак, сакате уште еднаш да се уверите дека денес не можете да живеете без него, погледнете кратко видео за тоа како можете да навлезете во корпоративна мрежа заштитена со заштитен ѕид на 17 начини. Затоа, ќе претпоставиме дека разбираме дека внатрешниот мониторинг е неопходна работа и останува само да се разбере како може да се организира.

Би истакнал три клучни извори на податоци за следење на инфраструктурата на мрежно ниво:

• „суров“ сообраќај што го фаќаме и го доставуваме на анализа до одредени системи за анализа,
• настани од мрежни уреди низ кои минува сообраќајот,
• информации за сообраќајот добиени преку еден од протоколите за проток.

Снимањето необработен сообраќај е најпопуларната опција меѓу специјалистите за безбедност, бидејќи историски се појави и беше прва. Конвенционалните мрежни системи за откривање на упад (првиот комерцијален систем за откривање на упад беше NetRanger од Wheel Group, купен во 1998 година од Cisco) беа прецизно ангажирани во фаќање пакети (и подоцнежни сесии) во кои се бараа одредени потписи („одлучувачки правила“ во FSTEC терминологија), сигнални напади. Се разбира, можете да го анализирате необработениот сообраќај не само со помош на IDS, туку и со користење на други алатки (на пример, Wireshark, tcpdum или функционалноста NBAR2 во Cisco IOS), но тие обично немаат база на знаење што ја разликува алатката за безбедност на информации од обична ИТ алатка.

Значи, системи за откривање напади. Најстариот и најпопуларниот метод за откривање мрежни напади, кој добро ја врши работата на периметарот (без разлика што - корпоративен, центар за податоци, сегмент итн.), но не успева во современите комутирани и софтверски дефинирани мрежи. Во случај на мрежа изградена врз основа на конвенционални прекинувачи, инфраструктурата на сензорите за откривање напади станува преголема - ќе мора да инсталирате сензор на секоја врска со јазолот на кој сакате да ги следите нападите. Секој производител, се разбира, со задоволство ќе ви продаде стотици и илјадници сензори, но мислам дека вашиот буџет не може да издржи такви трошоци. Можам да кажам дека дури и во Cisco (а ние сме развивачи на NGIPS) не можевме да го направиме ова, иако се чини дека прашањето за цената е пред нас. Не треба да стојам - тоа е наша сопствена одлука. Покрај тоа, се поставува прашањето, како да го поврзете сензорот во оваа верзија? Во јазот? Што ако самиот сензор не успее? Дали ви треба бајпас модул во сензорот? Користете разделувачи (допрете)? Сето ова го прави решението поскапо и го прави недостапно за компанија од која било големина.

Може да се обидете да го „закачите“ сензорот на порта SPAN/RSPAN/ERSPAN и да го насочите сообраќајот од потребните порти за прекинувач до него. Оваа опција делумно го отстранува проблемот опишан во претходниот пасус, но поставува уште еден - пристаништето SPAN не може да го прифати апсолутно целиот сообраќај што ќе биде испратен до него - нема да има доволно пропусен опсег. Ќе мора да жртвувате нешто. Или оставете некои од јазлите без следење (тогаш треба прво да им дадете приоритет), или да го испратите не целиот сообраќај од јазолот, туку само одреден тип. Во секој случај, може да пропуштиме некои напади. Покрај тоа, пристаништето SPAN може да се користи и за други потреби. Како резултат на тоа, ќе треба да ја прегледаме постоечката мрежна топологија и евентуално да направиме прилагодувања за да ја покриеме вашата мрежа до максимум со бројот на сензори што ги имате (и да го координираме ова со ИТ).

Што ако вашата мрежа користи асиметрични правци? Што ако сте имплементирале или планирате да го имплементирате SDN? Што ако треба да ги следите виртуелизираните машини или контејнери чиј сообраќај воопшто не допира до физичкиот прекинувач? Ова се прашања кои традиционалните продавачи на IDS не ги сакаат бидејќи не знаат како да одговорат на нив. Можеби ќе ве убедат дека сите овие модерни технологии се возбуда и дека тоа не ви е потребно. Можеби тие ќе зборуваат за потребата да се започне малку. Или можеби ќе речат дека треба да ставите моќен млаз во центарот на мрежата и да го насочите целиот сообраќај кон него користејќи балансери. Без оглед на опцијата што ви се нуди, треба јасно да разберете како ви одговара. И само после тоа донесете одлука за избор на пристап за следење на информациската безбедност на мрежната инфраструктура. Враќајќи се на фаќањето пакети, сакам да кажам дека овој метод продолжува да биде многу популарен и важен, но неговата главна цел е граничната контрола; границите помеѓу вашата организација и Интернетот, границите помеѓу центарот за податоци и остатокот од мрежата, границите помеѓу системот за контрола на процесите и корпоративниот сегмент. На овие места, класичните IDS/IPS сè уште имаат право да постојат и добро да се справат со своите задачи.

Да преминеме на втората опција. Анализата на настаните кои доаѓаат од мрежните уреди може да се користи и за откривање напади, но не како главен механизам, бидејќи овозможува откривање само на мала класа на упади. Дополнително, тоа е вродено во одредена реактивност - прво мора да се случи нападот, а потоа мора да биде снимен од мрежен уред, кој на еден или друг начин ќе сигнализира проблем со безбедноста на информациите. Постојат неколку такви начини. Ова може да биде syslog, RMON или SNMP. Последните два протоколи за следење на мрежата во контекст на безбедноста на информациите се користат само ако треба да откриеме DoS напад на самата мрежна опрема, бидејќи со користење на RMON и SNMP е можно, на пример, да се следи оптоварувањето на централната опрема на уредот. процесор или неговите интерфејси. Ова е еден од „најевтините“ (секој има syslog или SNMP), но исто така и најнеефективниот од сите методи за следење на безбедноста на информациите на внатрешната инфраструктура - многу напади едноставно се скриени од него. Се разбира, тие не треба да се занемарат, а истата анализа на системите ви помага навремено да ги идентификувате промените во конфигурацијата на самиот уред, компромисот за него, но не е многу погоден за откривање напади на целата мрежа.

Третата опција е да се анализираат информациите за сообраќајот што минува низ уред кој поддржува еден од неколкуте протоколи за проток. Во овој случај, без оглед на протоколот, инфраструктурата за нишки нужно се состои од три компоненти:

• Генерирање или извоз на проток. Оваа улога обично се доделува на рутер, прекинувач или друг мрежен уред, кој, со поминување на мрежниот сообраќај низ себе, ви овозможува да ги извлечете клучните параметри од него, кои потоа се пренесуваат до модулот за собирање. На пример, Cisco го поддржува протоколот Netflow не само на рутери и прекинувачи, вклучително и виртуелни и индустриски, туку и на безжични контролери, заштитни ѕидови, па дури и сервери.
• Тек на собирање. Имајќи предвид дека модерната мрежа обично има повеќе од еден мрежен уред, се јавува проблемот на собирање и консолидирање на тековите, што се решава со помош на таканаречените колектори, кои ги обработуваат примените текови и потоа ги пренесуваат на анализа.
• Анализа на проток Анализаторот ја презема главната интелектуална задача и, применувајќи различни алгоритми на потоци, донесува одредени заклучоци. На пример, како дел од ИТ функција, таков анализатор може да ги идентификува тесните грла на мрежата или да го анализира профилот на оптоварување на сообраќајот за понатамошна оптимизација на мрежата. И за безбедност на информациите, таков анализатор може да открие протекување податоци, ширење на малициозен код или DoS напади.

Немојте да мислите дека оваа архитектура со три нивоа е премногу комплицирана - сите други опции (освен, можеби, мрежните системи за следење кои работат со SNMP и RMON) исто така работат според неа. Имаме генератор на податоци за анализа, кој може да биде мрежен уред или самостоен сензор. Имаме систем за собирање аларм и систем за управување со целата инфраструктура за мониторинг. Последните две компоненти може да се комбинираат во еден јазол, но во повеќе или помалку големи мрежи тие обично се распоредени на најмалку два уреди со цел да се обезбеди приспособливост и доверливост.

За разлика од анализата на пакети, која се заснова на проучување на податоците за заглавието и телото на секој пакет и сесиите од кои се состои, анализата на протокот се потпира на собирање метаподатоци за мрежниот сообраќај. Кога, колку, од каде и каде, како... ова се прашањата на кои одговара анализата на мрежната телеметрија со помош на различни протоколи на проток. Првично, тие беа користени за анализа на статистика и наоѓање на ИТ проблеми на мрежата, но потоа, како што се развиваа аналитичките механизми, стана можно да се применат на истата телеметрија за безбедносни цели. Вреди да се напомене повторно дека анализата на протокот не го заменува или заменува фаќањето пакети. Секој од овие методи има своја област на примена. Но, во контекст на овој напис, анализата на протокот е најдобро одговара за следење на внатрешната инфраструктура. Имате мрежни уреди (без разлика дали работат во софтверски дефинирана парадигма или според статични правила) кои нападот не може да ги заобиколи. Може да заобиколи класичен IDS сензор, но мрежен уред што го поддржува протоколот за проток не може. Ова е предноста на овој метод.

Од друга страна, ако ви требаат докази за спроведување на законот или ваш сопствен тим за истрага на инциденти, не можете без фаќање пакети - мрежната телеметрија не е копија од сообраќајот што може да се користи за собирање докази; тоа е потребно за брзо откривање и одлучување во областа на информациската безбедност. Од друга страна, користејќи телеметриска анализа, можете да го „напишете“ не целиот мрежен сообраќај (ако нешто, Cisco се занимава со центри за податоци :-), туку само оној што е вклучен во нападот. Алатките за анализа на телеметрија во овој поглед добро ќе ги надополнат традиционалните механизми за фаќање пакети, давајќи команди за селективно снимање и складирање. Во спротивно, ќе мора да имате колосална инфраструктура за складирање.

Да замислиме мрежа која работи со брзина од 250 Mbit/sec. Ако сакате да го зачувате целиот овој волумен, тогаш ќе ви требаат 31 MB простор за една секунда пренос на сообраќај, 1,8 GB за една минута, 108 GB за еден час и 2,6 TB за еден ден. За да складирате дневни податоци од мрежа со пропусен опсег од 10 Gbit/s, ќе ви треба простор за складирање од 108 TB. Но, некои регулатори бараат складирање на безбедносни податоци со години... Снимањето на барање, кое анализата на протокот ви помага да го спроведете, помага да се намалат овие вредности по редови на големина. Патем, ако зборуваме за односот на обемот на снимените мрежни телеметриски податоци и целосното снимање на податоци, тогаш тоа е приближно 1 до 500. За истите вредности дадени погоре, складирање целосен препис од целиот дневен сообраќај ќе биде 5 и 216 GB, соодветно (можете дури и да го снимате на обичен флеш драјв ).

Ако за алатките за анализа на необработени мрежни податоци, начинот на нивно снимање е речиси ист од продавач до продавач, тогаш во случај на анализа на проток ситуацијата е поинаква. Постојат неколку опции за протоколи за проток, разликите во кои треба да знаете во контекст на безбедноста. Најпопуларниот е протоколот Netflow развиен од Cisco. Постојат неколку верзии на овој протокол, кои се разликуваат во нивните способности и количината на информации за сообраќајот снимени. Тековната верзија е деветта (Netflow v9), врз основа на која е развиен индустрискиот стандард Netflow v10, познат и како IPFIX. Денес, повеќето мрежни продавачи поддржуваат Netflow или IPFIX во нивната опрема. Но, постојат разни други опции за протоколи за проток - sFlow, jFlow, cFlow, rFlow, NetStream итн., од кои sFlow е најпопуларен. Токму овој тип е најчесто поддржан од домашните производители на мрежна опрема поради неговата леснотија на имплементација. Кои се клучните разлики помеѓу Netflow, кој стана де факто стандард, и sFlow? Би истакнал неколку клучни. Прво, Netflow има полиња приспособливи од корисникот наспроти фиксните полиња во sFlow. И второ, и ова е најважното нешто во нашиот случај, sFlow собира таканаречена телеметрија на примерок; за разлика од непримерокот за Netflow и IPFIX. Која е разликата меѓу нив?

Замислете дека одлучивте да ја прочитате книгата“Безбедносен оперативен центар: градење, работење и одржување на вашиот SOC” на моите колеги - Гери Мекинтајр, Џозеф Муниц и Надем Алфардан (дел од книгата можете да преземете од линкот). Имате три опции за да ја постигнете целта - прочитајте ја целата книга, прелистајте ја, застанувајќи на секоја 10-та или 20-та страница или обидете се да најдете прераскажување на клучните концепти на блог или услуга како SmartReading. Значи, телеметрија без примероци ја чита секоја „страница“ од мрежниот сообраќај, односно анализира метаподатоци за секој пакет. Телеметрија на примерок е селективно проучување на сообраќајот со надеж дека избраните примероци ќе го содржат она што ви треба. Во зависност од брзината на каналот, земената телеметрија ќе се испраќа на анализа секој 64-ти, 200-ти, 500-ти, 1000-ти, 2000-ти или дури 10000-ти пакети.

Во контекст на следењето на безбедноста на информациите, тоа значи дека телеметријата од примерокот е добро прилагодена за откривање DDoS напади, скенирање и ширење на злонамерен код, но може да пропушти атомски или напади со повеќе пакети кои не биле вклучени во примерокот испратен за анализа. Телеметријата без примероци нема такви недостатоци. Со ова, опсегот на откриени напади е многу поширок. Еве краток список на настани што може да се откријат со помош на алатки за анализа на мрежна телеметрија.

Се разбира, некој Netflow анализатор со отворен код нема да ви дозволи да го направите ова, бидејќи неговата главна задача е да собере телеметрија и да спроведе основна анализа на неа од гледна точка на ИТ. За да се идентификуваат заканите за безбедноста на информациите врз основа на проток, неопходно е да се опреми анализаторот со различни мотори и алгоритми, кои ќе ги идентификуваат проблемите со сајбер безбедност врз основа на стандардни или прилагодени полиња на Netflow, ќе ги збогатат стандардните податоци со надворешни податоци од различни извори на Threat Intelligence итн.

Затоа, ако имате избор, тогаш изберете Netflow или IPFIX. Но, дури и ако вашата опрема работи само со sFlow, како домашните производители, тогаш дури и во овој случај можете да имате корист од тоа во безбедносен контекст.

Во летото 2019 година, ги анализирав можностите што ги имаат руските производители на мрежен хардвер и сите, со исклучок на NSG, Polygon и Craftway, објавија поддршка за sFlow (барем Zelax, Natex, Eltex, QTech, Rusteleteh).

Следното прашање со кое ќе се соочите е каде да се имплементира поддршката за проток за безбедносни цели? Всушност, прашањето не е целосно поставено. Модерната опрема речиси секогаш поддржува протоколи за проток. Затоа, поинаку би го преформулирал прашањето - каде е најефикасно да се собере телеметрија од безбедносен аспект? Одговорот ќе биде сосема очигледен - на ниво на пристап, каде што ќе видите 100% од целиот сообраќај, каде што ќе имате детални информации за хостовите (MAC, VLAN, ID на интерфејс), каде што можете дури и да го следите сообраќајот P2P помеѓу хостовите, што е од клучно значење за скенирање на откривање и дистрибуција на малициозен код. На ниво на јадро, можеби едноставно нема да видите дел од сообраќајот, но на ниво на периметар, ќе видите четвртина од целиот мрежен сообраќај. Но, ако поради некоја причина имате странски уреди на вашата мрежа кои им дозволуваат на напаѓачите да „влегуваат и излегуваат“ без да го заобиколат периметарот, тогаш анализата на телеметријата од неа нема да ви даде ништо. Затоа, за максимална покриеност, се препорачува да се овозможи телеметриско собирање на ниво на пристап. Во исто време, вреди да се напомене дека дури и ако зборуваме за виртуелизација или контејнери, поддршката за проток често се наоѓа и во современите виртуелни прекинувачи, што ви овозможува да го контролирате сообраќајот и таму.

Но, бидејќи ја покренав темата, треба да одговорам на прашањето: што ако опремата, физичка или виртуелна, не поддржува протоколи за проток? Или е забрането неговото вклучување (на пример, во индустриски сегменти за да се обезбеди сигурност)? Или неговото вклучување доведува до големо оптоварување на процесорот (ова се случува на постар хардвер)? За да се реши овој проблем, постојат специјализирани виртуелни сензори (сензори за проток), кои во суштина се обични сплитери кои го минуваат сообраќајот низ себе и го емитуваат во форма на проток до модулот за собирање. Точно, во овој случај ги добиваме сите проблеми за кои зборувавме погоре во врска со алатките за фаќање пакети. Тоа е, треба да ги разберете не само предностите на технологијата за анализа на проток, туку и нејзините ограничувања.

Друга точка што е важно да се запамети кога се зборува за алатки за анализа на проток. Ако во однос на конвенционалните средства за генерирање безбедносни настани ја користиме метриката EPS (настан во секунда), тогаш овој индикатор не е применлив за телеметриска анализа; се заменува со FPS (проток во секунда). Како и во случајот со EPS, не може да се пресмета однапред, но можете да го процените приближниот број на нишки што ги генерира одреден уред во зависност од неговата задача. Можете да најдете табели на Интернет со приближни вредности за различни типови на претпријатија и услови, што ќе ви овозможат да процените какви лиценци ви се потребни за алатки за анализа и каква ќе биде нивната архитектура? Факт е дека сензорот IDS е ограничен со одредена пропусност што може да ја „влече“, а колекторот на проток има свои ограничувања што мора да се разберат. Затоа, во големите, географски дистрибуирани мрежи обично има неколку собирачи. Кога опишав како мрежата се следи внатре во Cisco, веќе го дадов бројот на нашите колекционери - ги има 21. А ова е за мрежа расфрлана на пет континенти и брои околу половина милион активни уреди).

Ние користиме сопствено решение како систем за следење на Netflow Cisco Stealthwatch, кој е конкретно фокусиран на решавање на безбедносните проблеми. Има многу вградени мотори за откривање аномални, сомнителни и јасно злонамерни активности, што му овозможуваат да открие широк спектар на различни закани - од криптомајнирање до протекување информации, од ширење на малициозен код до измама. Како и повеќето анализатори на проток, Stealthwatch е изграден според шема на три нивоа (генератор - колектор - анализатор), но е дополнет со голем број интересни карактеристики кои се важни во контекст на материјалот што се разгледува. Прво, се интегрира со решенија за фаќање пакети (како што е Cisco Security Packet Analyzer), што ви овозможува да снимате избрани мрежни сесии за подоцнежна длабинска истрага и анализа. Второ, конкретно за проширување на безбедносните задачи, развивме специјален протокол nvzFlow, кој ви овозможува да ја „емитувате“ активноста на апликациите на крајните јазли (сервери, работни станици итн.) во телеметрија и да ја пренесете до колекторот за понатамошна анализа. Ако во неговата оригинална верзија Stealthwatch работи со кој било протокол за проток (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 е алатка за командна линија која врши on-line анализа со внесување на команди како оваа (откривање на ICMP пакети поголеми од 200 бајти):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

не многу удобно. Можете да го користите iSiLK GUI, но нема да ви го олесни животот многу, туку само да ја решите функцијата за визуелизација, а не да го замените аналитичарот. И ова е втората точка. За разлика од комерцијалните решенија, кои веќе имаат солидна аналитичка основа, алгоритми за откривање аномалии, соодветниот тек на работа итн., во случајот на SiLK ќе мора сето ова да го направите сами, што ќе бара малку поинакви компетенции од вас отколку од користење на веќе подготвени алатки за употреба. Ова не е ниту добро ниту лошо - ова е карактеристика на речиси секоја бесплатна алатка која претпоставува дека знаете што да правите и само ќе ви помогне во тоа (комерцијалните алатки се помалку зависни од компетенциите на нејзините корисници, иако тие исто така претпоставуваат дека аналитичарите ги разбираат барем основите на мрежните истраги и мониторинг). Но, да се вратиме на СиЛК. Работниот циклус на аналитичарот со него изгледа вака:

• Формулирање на хипотеза. Мора да разбереме што ќе бараме внатре во мрежната телеметрија, да ги знаеме уникатните атрибути со кои ќе идентификуваме одредени аномалии или закани.
• Изградба на модел. Откако формулиравме хипотеза, ја програмираме користејќи го истиот Python, школка или други алатки кои не се вклучени во SiLK.
• Тестирање. Сега доаѓа редот да ја провериме точноста на нашата хипотеза, која е потврдена или побиена со користење на алатките на SiLK кои започнуваат со 'rw', 'set', 'bag'.
• Анализа на реални податоци. Во индустриското работење, SiLK ни помага да идентификуваме нешто и аналитичарот мора да одговори на прашањата „Дали го најдовме она што го очекувавме?“, „Дали ова одговара на нашата хипотеза?“, „Како да се намали бројот на лажни позитиви?“, „Како да се подобри нивото на препознавање? » и така натаму.
• Подобрување. Во последната фаза, го подобруваме она што беше направено порано - создаваме шаблони, го подобруваме и оптимизираме кодот, ја преформулираме и разјаснуваме хипотезата итн.

Овој циклус ќе биде применлив и за Cisco Stealthwatch, само последниот ги автоматизира овие пет чекори до максимум, намалувајќи го бројот на грешки на аналитичарот и зголемувајќи ја ефикасноста на откривањето инциденти. На пример, во SiLK можете да ја збогатите мрежната статистика со надворешни податоци за малициозни IP адреси користејќи рачно напишани скрипти, а во Cisco Stealthwatch тоа е вградена функција која веднаш прикажува аларм доколку мрежниот сообраќај содржи интеракции со IP адреси од црната листа.

Ако одите повисоко во „платената“ пирамида за софтверот за анализа на проток, тогаш по апсолутно бесплатната SiLK ќе има shareware ELK, составен од три клучни компоненти - Elasticsearch (индексирање, пребарување и анализа на податоци), Logstash (влез/излез на податоци ) и Кибана (визуелизација). За разлика од SiLK, каде што треба да напишете сè сам, ELK веќе има многу готови библиотеки/модули (некои платени, некои не) кои ја автоматизираат анализата на мрежната телеметрија. На пример, филтерот GeoIP во Logstash ви овозможува да ги поврзете набљудуваните IP адреси со нивната географска локација (Stealthwatch ја има оваа вградена функција).

ELK, исто така, има прилично голема заедница која ги комплетира компонентите што недостасуваат за ова решение за следење. На пример, за работа со Netflow, IPFIX и sFlow, можете да го користите модулот еластична проток, ако не сте задоволни со Logstash Netflow Module, кој поддржува само Netflow.

И покрај тоа што дава поголема ефикасност во собирањето проток и пребарувањето во него, на ELK моментално му недостасува богата вградена аналитика за откривање аномалии и закани во мрежната телеметрија. Тоа е, следејќи го животниот циклус опишан погоре, ќе мора самостојно да ги опишувате моделите за прекршување и потоа да го користите во борбениот систем (таму нема вградени модели).

Има секако пософистицирани екстензии за ELK, кои веќе содржат некои модели за откривање аномалии во мрежната телеметрија, но таквите екстензии чинат и прашање е дали играта вреди за свеќата - напишете сличен модел сами, купете ја неговата имплементација за вашата алатка за следење или купи готово решение од класата Network Traffic Analysis.

Во принцип, не сакам да навлегувам во дебата дека е подобро да потрошите пари и да купите готово решение за следење аномалии и закани во мрежната телеметрија (на пример, Cisco Stealthwatch) или сами да го сфатите и да го приспособите истото SiLK, ELK или nfdump или OSU Flow Tools за секоја нова закана ( зборувам за последните две од нив изјави последен пат)? Секој избира за себе и секој има свои мотиви за избор на која било од двете опции. Само сакав да покажам дека мрежната телеметрија е многу важна алатка за обезбедување на мрежната безбедност на вашата внатрешна инфраструктура и не треба да ја занемарите, за да не се приклучите на листата на компании чие име се споменува во медиумите заедно со епитетите “ хакирани“, „не се во согласност со барањата за безбедност на информациите“, „не размислувајќи за безбедноста на нивните податоци и податоците за клиентите“.

Да резимираме, би сакал да ги наведам клучните совети што треба да ги следите при градење на следење на безбедноста на информациите на вашата внатрешна инфраструктура:

1. Не се ограничувајте само на периметарот! Користете (и изберете) мрежна инфраструктура не само за да го преместите сообраќајот од точката А до точката Б, туку и за да ги решите проблемите со сајбер безбедноста.
2. Проучете ги постоечките механизми за следење на безбедноста на информациите во вашата мрежна опрема и користете ги.
3. За внатрешен мониторинг, дајте предност на телеметриската анализа - ви овозможува да откриете до 80-90% од сите инциденти за безбедност на мрежни информации, притоа правејќи го она што е невозможно кога фаќате мрежни пакети и заштедувате простор за складирање на сите настани за безбедност на информациите.
4. За следење на тековите, користете Netflow v9 или IPFIX - тие обезбедуваат повеќе информации во безбедносен контекст и ви дозволуваат да го следите не само IPv4, туку и IPv6, MPLS итн.
5. Користете протокол за проток без примероци - тој обезбедува повеќе информации за откривање закани. На пример, Netflow или IPFIX.
6. Проверете го оптоварувањето на вашата мрежна опрема - можеби нема да може да се справи и со протоколот за проток. Потоа размислете за користење виртуелни сензори или Netflow Generation Appliance.
7. Спроведете контрола пред сè на ниво на пристап - ова ќе ви даде можност да видите 100% од целиот сообраќај.
8. Ако немате избор и користите руска мрежна опрема, тогаш изберете ја онаа што поддржува протоколи за проток или има порти SPAN/RSPAN.
9. Комбинирајте системи за откривање/спречување на упад/напад на рабовите и системи за анализа на проток во внатрешната мрежа (вклучително и во облаците).

Во врска со последниот совет, би сакал да дадам илустрација што веќе ја дадов претходно. Гледате дека ако претходно службата за информациска безбедност на Cisco речиси целосно го изгради својот систем за следење на безбедноста на информациите врз основа на системи за откривање на упад и методи на потпис, сега тие претставуваат само 20% од инцидентите. Други 20% паѓаат на системите за анализа на проток, што сугерира дека овие решенија не се каприц, туку вистинска алатка во активностите на службите за безбедност на информации на модерно претпријатие. Згора на тоа, го имате најважното нешто за нивна имплементација - мрежна инфраструктура, инвестиции во кои може дополнително да се заштитат со доделување функции за следење на безбедноста на информациите на мрежата.

Конкретно не ја допрев темата за одговор на аномалии или закани идентификувани во мрежните текови, но мислам дека веќе е јасно дека следењето не треба да заврши само со откривање на закана. Треба да биде проследено со одговор и по можност во автоматски или автоматизиран режим. Но, ова е тема за посебна статија.

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

• Опис на Cisco IOS Netflow
• Матрица за поддршка на Netflow во различни решенија на Cisco
• Водич за конфигурирање на Netflow на различни платформи на Cisco
• sFlow заедница
• Лабораторија користејќи Stealtjwatch, SiLK и ELK за анализа на Netflow од безбедносна перспектива
• Веб-страница на SiLK
• Водич од триста страници за користење на SiLK со тони примери
• Logstash Netflow модул
• Cisco чекор-по-чекор водич за анализа на Netflow во ELK
• Анализа на NetFlow v.9 Cisco ASA користејќи Logstash (ELK)
• Cisco Stealthwatch решение

П.С. Ако ви е полесно да слушнете сè што е напишано погоре, тогаш можете да ја погледнете едночасовната презентација што ја формираше основата на оваа белешка.

Извор: www.habr.com