Ішкі корпоративтік немесе ведомстволық желінің қауіпсіздігін бақылауға келгенде, көпшілігі оны ақпараттың ағып кетуін бақылаумен және DLP шешімдерін енгізумен байланыстырады. Егер сіз сұрақты нақтылауға тырыссаңыз және ішкі желідегі шабуылдарды қалай анықтайсыз деп сұрасаңыз, онда жауап, әдетте, кіруді анықтау жүйелері (IDS) туралы сөз болады. Ал 10-20 жыл бұрын жалғыз нұсқа болған нәрсе бүгінде анахронизмге айналуда. Ішкі желіні бақылаудың тиімдірек және кейбір жерлерде жалғыз мүмкін нұсқасы бар - бастапқыда желі мәселелерін (ақауларды жою) іздеуге арналған, бірақ уақыт өте қызықты қауіпсіздік құралына айналдырылған ағындық протоколдарды пайдалану. Біз қандай ағын хаттамалары бар және олардың қайсысы желілік шабуылдарды анықтауда жақсырақ, ағынды бақылауды қай жерде жүзеге асырған дұрыс, мұндай схеманы орналастыру кезінде нені іздеу керек және тіпті мұның бәрін отандық жабдықта қалай «көтеру» керектігі туралы сөйлесеміз. осы баптың аясында.
Мен «Ішкі инфрақұрылымдық қауіпсіздік мониторингі не үшін қажет?» Деген сұраққа тоқталмаймын. Жауап түсінікті сияқты. Бірақ, соған қарамастан, сіз бүгін онсыз өмір сүре алмайтыныңызға тағы бір рет көз жеткізгіңіз келсе, брандмауэрмен қорғалған корпоративтік желіге 17 жолмен қалай енуге болатыны туралы қысқаша бейне. Сондықтан біз ішкі мониторингтің қажетті нәрсе екенін түсінеміз және оны қалай ұйымдастыруға болатынын түсіну ғана қалады.
Мен желі деңгейінде инфрақұрылымды бақылау үшін үш негізгі деректер көзін атап өткім келеді:
- біз түсіретін және белгілі бір талдау жүйелеріне талдауға жіберетін «шикі» трафик,
- трафик өтетін желілік құрылғылардағы оқиғалар,
- ағын хаттамаларының бірі арқылы алынған трафик туралы ақпарат.
Шикі трафикті түсіру - қауіпсіздік мамандары арасында ең танымал нұсқа, өйткені ол тарихи түрде пайда болды және ең бірінші болды. Желіге кіруді анықтаудың кәдімгі жүйелері (алғашқы коммерциялық шабуылды анықтау жүйесі 1998 жылы Cisco сатып алған Wheel тобынан NetRanger болды) нақты қолтаңбалар ізделетін пакеттерді (және кейінгі сеанстарды) түсірумен айналысты («шешуші ережелер»). FSTEC терминологиясы), сигналдық шабуылдар. Әрине, шикі трафикті IDS көмегімен ғана емес, сонымен қатар басқа құралдарды (мысалы, Wireshark, tcpdum немесе Cisco IOS жүйесіндегі NBAR2 функционалдығы) пайдалана отырып талдауға болады, бірақ оларда әдетте ақпараттық қауіпсіздік құралын кәдімгі құралдан ажырататын білім базасы жетіспейді. IT құралы.
Сонымен, шабуылдарды анықтау жүйелері. Желілік шабуылдарды анықтаудың ең көне және ең танымал әдісі, ол периметрде жақсы жұмыс істейді (қандай болса да - корпоративтік, деректер орталығы, сегмент және т.б.), бірақ заманауи коммутацияланған және бағдарламалық қамтамасыз етумен анықталған желілерде сәтсіздікке ұшырайды. Кәдімгі қосқыштар негізінде құрылған желі жағдайында шабуылдарды анықтау сенсорларының инфрақұрылымы тым үлкен болады - шабуылдарды бақылайтын түйінге әрбір қосылымға сенсорды орнату керек болады. Кез келген өндіруші, әрине, сізге жүздеген және мыңдаған сенсорларды сатуға қуанышты болады, бірақ менің ойымша, сіздің бюджетіңіз мұндай шығындарды көтере алмайды. Мен тіпті 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 Мбит/сек жылдамдықпен жұмыс істейтін желіні елестетейік. Егер сіз осы көлемнің барлығын сақтағыңыз келсе, трафикті тасымалдаудың бір секундына 31 Мбайт, бір минутқа 1,8 ГБ, бір сағатқа 108 ГБ және бір күн үшін 2,6 ТБ жад қажет болады. Өткізу қабілеті 10 Гбит/с болатын желіден күнделікті деректерді сақтау үшін сізге 108 ТБ жады қажет болады. Бірақ кейбір реттеушілер қауіпсіздік деректерін жылдар бойы сақтауды талап етеді... Ағын талдауы іске асыруға көмектесетін сұраныс бойынша жазу бұл мәндерді шама бойынша азайтуға көмектеседі. Айтпақшы, егер жазылған желілік телеметрия деректері мен толық деректерді түсіру көлемінің арақатынасы туралы айтатын болсақ, онда ол шамамен 1-ден 500-ге дейін болады. Жоғарыда келтірілген мәндер үшін барлық күнделікті трафиктің толық транскрипциясы сақталады. тиісінше 5 және 216 ГБ болады (тіпті оны кәдімгі флэш-дискке жазуға болады ).
Егер бастапқы желі деректерін талдау құралдары үшін оны түсіру әдісі жеткізушіден жеткізушіге бірдей дерлік болса, онда ағынды талдау жағдайында жағдай басқаша болады. Ағын хаттамаларының бірнеше нұсқалары бар, оларда қауіпсіздік контекстінде білу қажет айырмашылықтар. Ең танымалы Cisco әзірлеген Netflow протоколы. Бұл хаттаманың мүмкіндіктері мен жазылған трафик ақпаратының көлемімен ерекшеленетін бірнеше нұсқалары бар. Ағымдағы нұсқасы тоғызыншы (Netflow v9), оның негізінде IPFIX ретінде белгілі Netflow v10 салалық стандарты әзірленді. Бүгінгі күні көптеген желі жеткізушілері өз жабдықтарында Netflow немесе IPFIX-ті қолдайды. Бірақ ағын протоколдарының басқа да нұсқалары бар - sFlow, jFlow, cFlow, rFlow, NetStream және т.б., олардың ішінде sFlow ең танымал. Дәл осы түрді іске асырудың қарапайымдылығына байланысты отандық желілік жабдықтар өндірушілері жиі қолдайды. Іс жүзінде стандартқа айналған Netflow мен sFlow арасындағы негізгі айырмашылықтар қандай? Мен бірнеше негізгілерін атап өткім келеді. Біріншіден, Netflow бағдарламасында sFlow ішіндегі тіркелген өрістерге қарағанда пайдаланушы реттейтін өрістер бар. Екіншіден, бұл біздің жағдайда ең маңыздысы, sFlow таңдамалы телеметрия деп аталатындарды жинайды; Netflow және IPFIX үшін үлгіленбегеннен айырмашылығы. Олардың арасындағы айырмашылық неде?
Сіз кітапты оқуға шешім қабылдадыңыз деп елестетіңіз.” менің әріптестерім – Гари МакИнтайр, Джозеф Муниц және Надем Альфардан (кітаптың бір бөлігін сілтемеден жүктеп алуға болады). Мақсатыңызға жету үшін сізде үш нұсқа бар - кітапты толығымен оқып шығыңыз, оны қарап шығыңыз, әрбір 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, интерфейс идентификаторы), онда сіз тіпті хосттар арасындағы P2P трафигін бақылай аласыз. зиянды кодты анықтау және тарату сканерлеу үшін өте маңызды. Негізгі деңгейде сіз трафиктің бір бөлігін көрмеуіңіз мүмкін, бірақ периметр деңгейінде сіз барлық желілік трафиктің төрттен бірін көресіз. Бірақ егер қандай да бір себептермен сіздің желіңізде шабуылдаушыларға периметрді айналып өтпей «кіруге және шығуға» мүмкіндік беретін шетелдік құрылғылар болса, одан телеметрияны талдау сізге ештеңе бермейді. Сондықтан максималды қамту үшін қол жеткізу деңгейінде телеметрия жинауды қосу ұсынылады. Сонымен қатар, виртуалдандыру немесе контейнерлер туралы айтатын болсақ, ағынды қолдау қазіргі заманғы виртуалды қосқыштарда жиі кездесетінін атап өткен жөн, бұл сізге трафикті басқаруға мүмкіндік береді.
Бірақ мен тақырыпты көтергендіктен, мен сұраққа жауап беруім керек: егер жабдық физикалық немесе виртуалды ағын хаттамаларын қолдамаса ше? Немесе оны қосуға тыйым салынған ба (мысалы, сенімділікті қамтамасыз ету үшін өнеркәсіптік сегменттерде)? Немесе оны қосу процессордың жоғары жүктемесіне әкеледі (бұл ескі жабдықта орын алады)? Бұл мәселені шешу үшін мамандандырылған виртуалды сенсорлар (ағындық сенсорлар) бар, олар негізінен трафикті өздері арқылы өткізетін және оны жинау модуліне ағын түрінде тарататын қарапайым бөлгіштер. Рас, бұл жағдайда біз пакетті түсіру құралдарына қатысты жоғарыда айтқан барлық мәселелерді аламыз. Яғни, сіз ағынды талдау технологиясының артықшылықтарын ғана емес, сонымен қатар оның шектеулерін де түсінуіңіз керек.
Ағынды талдау құралдары туралы айтқан кезде есте сақтау маңызды тағы бір мәселе. Егер қауіпсіздік оқиғаларын генерациялаудың әдеттегі құралдарына қатысты біз EPS метрикасын (секундтағы оқиға) қолданатын болсақ, онда бұл көрсеткіш телеметриялық талдауға қолданылмайды; ол FPS (секундына ағын) ауыстырылады. EPS жағдайындағыдай, оны алдын ала есептеу мүмкін емес, бірақ оның тапсырмасына байланысты белгілі бір құрылғы жасайтын ағындардың шамамен санын бағалауға болады. Сіз Интернетте әртүрлі типтегі кәсіпорын құрылғылары мен шарттары үшін шамаланған мәндері бар кестелерді таба аласыз, бұл сізге талдау құралдары үшін қандай лицензиялар қажет екенін және олардың архитектурасы қандай болатынын бағалауға мүмкіндік береді? Шындығында, IDS сенсоры белгілі бір өткізу қабілеттілігімен шектеледі, ол «тартылады» және ағын коллекторында түсіну керек өз шектеулері бар. Сондықтан үлкен, географиялық таралған желілерде әдетте бірнеше коллекторлар болады. Мен сипаттаған кезде , Мен қазірдің өзінде коллекторларымыздың санын келтірдім - олардың саны 21. Бұл бес континентте шашыраңқы және жарты миллионға жуық белсенді құрылғыларды қамтитын желіге арналған).
Біз Netflow мониторинг жүйесі ретінде өз шешімімізді қолданамыз , ол қауіпсіздік мәселелерін шешуге арнайы бағытталған. Онда аномальды, күдікті және анық зиянды әрекетті анықтауға арналған көптеген кіріктірілген қозғалтқыштар бар, бұл әртүрлі қауіптердің кең ауқымын анықтауға мүмкіндік береді - криптоминдеуден ақпараттың ағып кетуіне дейін, зиянды кодтың таралуынан алаяқтыққа дейін. Көптеген ағын анализаторлары сияқты, 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 мына сияқты пәрмендерді енгізу арқылы желіде талдауды жүзеге асыратын пәрмен жолы құралы болып табылады (200 байттан үлкен ICMP пакеттерін анықтау):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
өте ыңғайлы емес. Сіз iSiLK GUI пайдалана аласыз, бірақ ол сіздің өміріңізді айтарлықтай жеңілдетпейді, тек визуализация функциясын шешеді және талдаушыны ауыстырмайды. Және бұл екінші нүкте. Қатты аналитикалық базасы, аномалияларды анықтау алгоритмдері, сәйкес жұмыс процесі және т.б. бар коммерциялық шешімдерден айырмашылығы, SiLK жағдайында мұның бәрін өзіңіз орындауға тура келеді, бұл сізден қазірдің өзінде дайын өнімді пайдаланудан сәл басқа құзыреттерді талап етеді. құралдарды қолдануға. Бұл жақсы да, жаман да емес - бұл не істеу керектігін білетін кез келген дерлік тегін құралдың мүмкіндігі және ол сізге тек осыған көмектеседі (коммерциялық құралдар пайдаланушылардың құзыреттеріне аз тәуелді, бірақ олар да болжайды талдаушылар кем дегенде желілік зерттеулер мен мониторинг негіздерін түсінеді). Бірақ SiLK-ке оралайық. Онымен талдаушының жұмыс циклі келесідей болады:
- Гипотезаны тұжырымдау. Біз желілік телеметриядан не іздейтінімізді түсінуіміз керек, белгілі бір ауытқуларды немесе қауіптерді анықтайтын бірегей атрибуттарды білуіміз керек.
- Модель құрастыру. Гипотезаны құрастыра отырып, біз оны бірдей Python, shell немесе SiLK құрамына кірмейтін басқа құралдар арқылы бағдарламалаймыз.
- Тестілеу. Енді 'rw', 'set', 'bag' деп басталатын SiLK утилиталары арқылы расталған немесе жоққа шығарылатын гипотезамыздың дұрыстығын тексеру кезегі келеді.
- Нақты деректерді талдау. Өнеркәсіптік жұмыста SiLK бізге бір нәрсені анықтауға көмектеседі және талдаушы «Біз күткен нәрсені таптық па?», «Бұл біздің гипотезаға сәйкес келе ме?», «Жалған позитивтердің санын қалай азайтуға болады?», «Қалайша?» деген сұрақтарға жауап беруі керек. тану деңгейін жақсарту үшін бе?» және т.б.
- Жақсарту. Соңғы кезеңде біз бұрын жасалған нәрсені жетілдіреміз - үлгілерді жасаймыз, кодты жақсартамыз және оңтайландырамыз, гипотезаны қайта тұжырымдаймыз және нақтылаймыз және т.б.
Бұл цикл Cisco Stealthwatch үшін де қолданылады, тек соңғысы осы бес қадамды барынша автоматтандырады, аналитик қателерінің санын азайтады және оқиғаны анықтау тиімділігін арттырады. Мысалы, SiLK жүйесінде желілік статистиканы қолмен жазылған сценарийлерді пайдаланып зиянды IP мекенжайлары бойынша сыртқы деректермен байытуға болады, ал Cisco Stealthwatch бағдарламасында желілік трафикте қара тізімдегі IP мекенжайларымен өзара әрекеттесулер болса, дереу дабылды көрсететін кірістірілген функция.
Егер сіз ағынды талдау бағдарламалық жасақтамасы үшін «ақылы» пирамидада жоғары көтерілсеңіз, онда мүлдем тегін SiLK-тен кейін үш негізгі компоненттен тұратын ELK ортақ бағдарламалық құралы болады - Elasticsearch (индекстеу, іздеу және деректерді талдау), Logstash (деректерді енгізу/шығару). ) және Кибана (визуализация). Барлығын өзіңіз жазуға тура келетін SiLK-тен айырмашылығы, ELK желілік телеметрияны талдауды автоматтандыратын көптеген дайын кітапханалар/модульдер (кейбіреулері ақылы, кейбіреулері жоқ) бар. Мысалы, Logstash жүйесіндегі GeoIP сүзгісі бақыланатын IP мекенжайларын олардың географиялық орналасуымен байланыстыруға мүмкіндік береді (Stealthwatch-та бұл кірістірілген мүмкіндік бар).
ELK сонымен қатар осы бақылау шешімі үшін жетіспейтін құрамдастарды аяқтайтын жеткілікті үлкен қауымдастыққа ие. Мысалы, Netflow, IPFIX және sFlow бағдарламаларымен жұмыс істеу үшін модульді пайдалануға болады , тек Netflow қолдайтын Logstash Netflow модуліне қанағаттанбасаңыз.
Ағынды жинау және оны іздеуде тиімдірек бола тұра, ELK қазіргі уақытта желілік телеметриядағы ауытқулар мен қауіптерді анықтауға арналған бай кірістірілген аналитикаға ие емес. Яғни, жоғарыда сипатталған өмірлік циклден кейін сіз бұзу үлгілерін өз бетінше сипаттап, содан кейін оны жауынгерлік жүйеде қолдануға тура келеді (онда кіріктірілген модельдер жоқ).
Әрине, ELK үшін анағұрлым күрделі кеңейтімдер бар, олар желілік телеметриядағы ауытқуларды анықтауға арналған кейбір үлгілерді қамтиды, бірақ мұндай кеңейтімдер ақшаны талап етеді және бұл жерде ойынның шамға тұрарлық екендігі туралы сұрақ туындайды - ұқсас модельді өзіңіз жазыңыз, оны сатып алыңыз. бақылау құралы үшін іске асыру немесе желілік трафикті талдау сыныбының дайын шешімін сатып алыңыз.
Жалпы, мен ақша жұмсап, желілік телеметриядағы аномалиялар мен қауіптерді (мысалы, Cisco Stealthwatch) бақылауға арналған дайын шешімді сатып алған дұрыс немесе оны өзіңіз анықтап, сол сияқты теңшеу туралы пікірталасқа түскім келмейді. Әрбір жаңа қауіп үшін SiLK, ELK немесе nfdump немесе OSU Flow құралдары (мен олардың соңғы екеуі туралы айтып отырмын. өткен жолы)? Әркім өзі таңдайды және екі нұсқаның кез келгенін таңдауға әркімнің өз мотиві бар. Мен жай ғана желілік телеметрия сіздің ішкі инфрақұрылымыңыздың желілік қауіпсіздігін қамтамасыз етудің өте маңызды құралы екенін және БАҚ-та эпитеттермен бірге аты аталған компаниялардың тізіміне қосылмау үшін оны назардан тыс қалдырмау керектігін көрсеткім келді. бұзылған», «ақпараттық қауіпсіздік талаптарына сәйкес емес», «өз деректерінің және тұтынушы деректерінің қауіпсіздігі туралы ойламау.»
Қорытындылай келе, мен сіздің ішкі инфрақұрылымыңыздың ақпараттық қауіпсіздік мониторингін құру кезінде ұстануға тиіс негізгі кеңестерді тізімдеймін:
- Өзіңізді тек периметрмен шектемеңіз! Трафикті А нүктесінен В нүктесіне жылжыту үшін ғана емес, сонымен қатар киберқауіпсіздік мәселелерін шешу үшін желілік инфрақұрылымды пайдаланыңыз (және таңдаңыз).
- Желілік жабдықтағы ақпараттық қауіпсіздікті бақылау механизмдерін зерттеп, оларды пайдаланыңыз.
- Ішкі бақылау үшін телеметриялық талдауға артықшылық беріңіз - ол желілік пакеттерді түсіру кезінде мүмкін емес нәрсені жасай отырып және ақпараттық қауіпсіздіктің барлық оқиғаларын сақтау үшін орынды үнемдей отырып, барлық желілік ақпараттық қауіпсіздік инциденттерінің 80-90% дейін анықтауға мүмкіндік береді.
- Ағындарды бақылау үшін Netflow v9 немесе IPFIX пайдаланыңыз - олар қауіпсіздік контекстінде қосымша ақпарат береді және IPv4 ғана емес, сонымен қатар IPv6, MPLS және т.б. бақылауға мүмкіндік береді.
- Үлгіленбеген ағын протоколын пайдаланыңыз - ол қауіптерді анықтау үшін қосымша ақпарат береді. Мысалы, Netflow немесе IPFIX.
- Желілік жабдықтың жүктемесін тексеріңіз - ол ағын протоколын да өңдей алмауы мүмкін. Содан кейін виртуалды сенсорларды немесе Netflow Generation Appliance пайдалануды қарастырыңыз.
- Бақылауды ең алдымен қол жеткізу деңгейінде жүзеге асырыңыз - бұл сізге барлық трафиктің 100% көру мүмкіндігін береді.
- Егер таңдауыңыз болмаса және ресейлік желі жабдығын пайдаланып жатсаңыз, ағындық протоколдарды қолдайтын немесе SPAN/RSPAN порттары бар біреуін таңдаңыз.
- Ішкі желідегі (оның ішінде бұлттарда) ағынды талдау жүйелерін шеттерде басып кіру/шабуылдарды анықтау/алдын алу жүйелерін біріктіріңіз.
Соңғы кеңеске қатысты мен бұрыннан келтірген мысал келтіргім келеді. Көріп отырсыздар, егер бұрын Cisco ақпараттық қауіпсіздік қызметі өзінің ақпараттық қауіпсіздікті бақылау жүйесін толығымен дерлік шабуылдарды анықтау жүйелері мен қолтаңба әдістері негізінде құрса, қазір олар оқиғалардың 20% ғана құрайды. Тағы 20% ағынды талдау жүйелеріне келеді, бұл бұл шешімдердің қыңырлық емес, заманауи кәсіпорынның ақпараттық қауіпсіздік қызметтерінің қызметіндегі нақты құрал екенін көрсетеді. Сонымен қатар, сізде оларды іске асыру үшін ең маңызды нәрсе бар - желілік инфрақұрылым, желіге ақпараттық қауіпсіздікті бақылау функцияларын тағайындау арқылы одан әрі қорғалатын инвестициялар.
Мен желілік ағындарда анықталған аномалияларға немесе қауіптерге жауап беру тақырыбына арнайы тоқталған жоқпын, бірақ менің ойымша, мониторинг тек қауіпті анықтаумен ғана аяқталмауы керек екендігі қазірдің өзінде анық. Одан кейін жауап және жақсырақ автоматты немесе автоматтандырылған режимде болуы керек. Бірақ бұл бөлек мақаланың тақырыбы.
Қосымша ақпарат:
PS. Егер сізге жоғарыда жазылғандардың барлығын есту оңай болса, онда сіз осы жазбаның негізін құраған сағаттық презентацияны көре аласыз.
Ақпарат көзі: www.habr.com