Ички корпоративдик же ведомстволук тармактын коопсуздугун көзөмөлдөөгө келгенде, көптөр аны маалыматтын агып кетишин көзөмөлдөө жана DLP чечимдерин ишке ашыруу менен байланыштырышат. Эгерде сиз суроону тактоого аракет кылсаңыз жана ички тармакка чабуулдарды кантип аныктайсыз деп сурасаңыз, анда жооп, эреже катары, интрузияларды аныктоо системалары (IDS) жөнүндө сөз болот. Ал эми мындан 10-20 жыл мурун бир гана вариант болгон нерсе бүгүн анахронизмге айланып баратат. Ички тармакты көзөмөлдөөнүн кыйла эффективдүү, кээ бир жерлерде бирден-бир мүмкүн болгон варианты бар - агым протоколдорун колдонуу, алар алгач тармак көйгөйлөрүн издөө үчүн иштелип чыккан (проблемаларды чечүү), бирок убакыттын өтүшү менен абдан кызыктуу коопсуздук куралына айланган. Биз кандай агым протоколдору бар жана кайсылары тармактык чабуулдарды аныктоодо жакшыраак, агымга мониторинг жүргүзүү кайсы жерде жакшыраак, мындай схеманы колдонууда эмнеге көңүл буруу керек жана мунун баарын ата мекендик жабдууларда кантип "көтөрүү" керектиги жөнүндө сүйлөшөбүз. ушул берененин алкагында.
“Эмне үчүн ички инфраструктуранын коопсуздугуна мониторинг жүргүзүү керек?” деген суроого токтолбой эле коёюн. Жооп айкын көрүнөт. Бирок, ошентсе да, сиз бүгүн ансыз жашай албасыңызга дагы бир жолу ынангыңыз келсе, брандмауэр менен корголгон корпоративдик тармакка 17 жол менен кантип кире аласыз деген кыска видео. Ошондуктан, биз ички мониторинг зарыл нерсе экенин түшүнөбүз деп ойлойбуз жана аны кантип уюштурууга болорун түшүнүү гана калды.
Мен тармак деңгээлинде инфраструктурага мониторинг жүргүзүү үчүн үч негизги маалымат булактарын бөлүп көрсөтөм:
- Биз кармаган жана белгилүү бир анализ системаларына талдоо үчүн тапшырган "чийки" трафик,
- трафик өтүүчү тармактык түзүлүштөрдөгү окуялар,
- агым протоколдорунун бири аркылуу алынган трафик маалыматы.
Чийки трафикти басып алуу - коопсуздук адистеринин эң популярдуу варианты, анткени ал тарыхый жактан пайда болгон жана эң биринчи болгон. Тармактык интрузияны аныктоонун кадимки системалары (биринчи коммерциялык интрузияны аныктоо системасы 1998-жылы Cisco тарабынан сатылып алынган Wheel Group компаниясынан NetRanger болгон) так белгилүү бир кол тамгалар изделген пакеттерди (жана кийинки сессияларды) басып алуу менен алектенген ("чечүүчү эрежелер"). FSTEC терминологиясы), сигналдык чабуулдар. Албетте, чийки трафикти IDS аркылуу гана эмес, башка инструменттердин жардамы менен да талдай аласыз (мисалы, Wireshark, tcpdum же Cisco IOSдогу NBAR2 функционалы), бирок аларда адатта маалымат коопсуздугу куралын кадимки программадан айырмалай турган билим базасы жетишсиз. IT куралы.
Ошентип, чабуулдарды аныктоо системалары. Тармактык чабуулдарды аныктоонун эң эски жана эң популярдуу ыкмасы, ал периметрде жакшы иштейт (кандай болбосун - корпоративдик, маалымат борбору, сегмент ж. Кадимки өчүргүчтөрдүн негизинде курулган тармак учурда, чабуулду аныктоо сенсорлорунун инфраструктурасы өтө чоң болуп калат - сиз чабуулдарды көзөмөлдөгүңүз келген түйүнгө ар бир туташуу боюнча сенсорду орнотууга туура келет. Ар бир өндүрүүчү, албетте, жүздөгөн жана миңдеген сенсорлорду сатууга кубанычта болот, бирок менимче, сиздин бюджетиңиз мындай чыгымдарды көтөрө албайт. Мен Ciscoдо да (жана биз NGIPSти иштеп чыгуучуларбыз) биз муну жасай албадык деп айта алам, бирок баа маселеси биздин алдыбызда тургандай сезилет. Мен турбашым керек - бул өзүбүздүн чечимибиз. Мындан тышкары, суроо туулат, бул версияда сенсорду кантип туташтыруу керек? боштукка? Сенсор өзү иштебей калсачы? Сенсордо айланып өтүү модулу керекпи? Бөлгүчтөр колдонулабы (таптоо)? Мунун баары чечимди кымбаттатат жана аны каалаган өлчөмдөгү компания үчүн жеткиликтүү эмес кылат.
Сиз сенсорду SPAN/RSPAN/ERSPAN портуна “илип” коюуга жана ага керектүү коммутаторлордон трафикти түз кылууга аракет кылсаңыз болот. Бул параметр мурунку абзацта сүрөттөлгөн көйгөйдү жарым-жартылай жок кылат, бирок башкасын жаратат - SPAN порту ага жөнөтүлө турган бардык трафикти таптакыр кабыл ала албайт - анын өткөрүү жөндөмдүүлүгү жетишсиз болот. Сиз бир нерсени курмандыкка чалууга туура келет. Же кээ бир түйүндөрдү мониторингсиз калтырыңыз (андан кийин аларга биринчи кезекте артыкчылык беришиңиз керек), же түйүндөн бардык трафикти эмес, белгилүү бир түрүн гана жөнөтүңүз. Кандай болгон күндө да кээ бир чабуулдарды өткөрүп жиберишибиз мүмкүн. Мындан тышкары, SPAN портун башка муктаждыктар үчүн колдонсо болот. Натыйжада, сизде болгон сенсорлордун саны менен тармагыңызды максималдуу түрдө камтуу үчүн (жана муну IT менен координациялоо үчүн) болгон тармактын топологиясын карап чыгып, ага оңдоолорду киргизишибиз керек болот.
Тармагыңыз асимметриялык маршруттарды колдонсочу? Эгер сиз SDNди ишке ашырган болсоңуз же ишке ашырууну пландап жатсаңызчы? Эгер сизге виртуалдаштырылган машиналарды же трафики физикалык которгучка такыр жетпеген контейнерлерди көзөмөлдөө керек болсочы? Бул салттуу IDS сатуучуларга жакпаган суроолор, анткени аларга кантип жооп берүү керектигин билишпейт. Балким, алар сизди бул модалуу технологиялардын баары хайп экенине жана сизге кереги жок экенине ынандырат. Балким, алар кичинеден баштоо керектиги жөнүндө сүйлөшөт. Же, балким, алар тармактын борборуна кубаттуу кырманды коюп, ага бардык трафикти баланстоочулар аркылуу багыттоо керек деп айтышат. Кандай вариант сизге сунушталбасын, ал сизге кандай ылайыктуу экенин так түшүнүшүңүз керек. Ошондон кийин гана тармактык инфраструктуранын маалыматтык коопсуздугуна мониторинг жүргүзүү ыкмасын тандоо жөнүндө чечим кабыл алынат. Пакетти басып алууга кайрылып, мен бул ыкма абдан популярдуу жана маанилүү бойдон кала берээрин айткым келет, бирок анын негизги максаты чек араны көзөмөлдөө; Сиздин уюмуңуз менен Интернеттин ортосундагы чек аралар, маалымат борбору менен тармактын калган бөлүгүнүн ортосундагы чек аралар, процессти башкаруу системасы менен корпоративдик сегменттин ортосундагы чек аралар. Бул жерлерде классикалык IDS/IPS дагы эле бар болууга жана өз милдеттерин жакшы аткарууга укуктуу.
Экинчи вариантка өтөбүз. Тармактык түзүлүштөрдөн келген окуялардын анализи чабуулдарды аныктоо максатында да колдонулушу мүмкүн, бирок негизги механизм катары эмес, анткени ал интрузиялардын аз гана классын аныктоого мүмкүндүк берет. Кошумчалай кетсек, ал кандайдыр бир реактивдүүлүккө мүнөздүү - адегенде чабуул болушу керек, андан кийин ал тигил же бул жол менен маалыматтык коопсуздуктун көйгөйүн билдире турган тармактык түзүлүш тарабынан жазылууга тийиш. Мындай жолдор бир нече. Бул syslog, RMON же SNMP болушу мүмкүн. Маалыматтык коопсуздук контекстинде тармактык мониторингдин акыркы эки протоколу тармактык жабдыктын өзүнө DoS чабуулун аныктоо керек болгондо гана колдонулат, анткени RMON жана SNMP колдонуу менен, мисалы, аппараттын борбордук түйүнүндөгү жүктөмдү көзөмөлдөөгө болот. процессор же анын интерфейстери. Бул "эң арзандардын" бири (ар кимде syslog же SNMP бар), бирок ошондой эле ички инфраструктуранын маалыматтык коопсуздугун көзөмөлдөөнүн бардык ыкмаларынын эң натыйжасызы - көптөгөн чабуулдар андан жашырылган. Албетте, аларга көңүл бурбай коюуга болбойт жана ошол эле системалык анализ аппараттын конфигурациясындагы өзгөрүүлөрдү, анын компромиссин өз убагында аныктоого жардам берет, бирок ал бүт тармакка чабуулдарды аныктоо үчүн анча ылайыктуу эмес.
Үчүнчү вариант - бир нече агым протоколдорунун бирин колдогон түзүлүш аркылуу өткөн трафик жөнүндө маалыматты талдоо. Бул учурда, протоколго карабастан, жип инфраструктурасы сөзсүз түрдө үч компоненттен турат:
- Агымды түзүү же экспорттоо. Бул роль адатта роутерге, коммутаторго же башка тармактык түзүлүшкө ыйгарылат, ал тармак трафигин өзү аркылуу өткөрүү менен андан негизги параметрлерди чыгарууга мүмкүндүк берет, алар андан кийин чогултуу модулуна өткөрүлүп берилет. Мисалы, Cisco Netflow протоколун роутерлерде жана коммутаторлордо, анын ичинде виртуалдык жана өнөр жайда гана эмес, ошондой эле зымсыз контроллерлерде, брандмауэрлерде жана ал тургай серверлерде да колдойт.
- Коллекциянын агымы. Заманбап тармак адатта бирден ашык тармактык түзүлүшкө ээ экендигин эске алсак, агымдарды чогултуу жана консолидациялоо маселеси келип чыгат, ал кабыл алынган агымдарды иштетип, анан анализге өткөрүп берүүчү коллекторлор деп аталгандарды колдонуу менен чечилет.
- Агымды анализдөө Анализатор негизги интеллектуалдык милдетти өзүнө алат жана агымдарга ар кандай алгоритмдерди колдонуу менен белгилүү бир жыйынтыктарды чыгарат. Мисалы, IT-функциянын бир бөлүгү катары, мындай анализатор тармактын тоскоолдуктарын аныктай алат же тармакты андан ары оптималдаштыруу үчүн трафик жүктөө профилин талдай алат. Ал эми маалыматтык коопсуздук үчүн мындай анализатор маалыматтардын агып кетишин, зыяндуу коддун жайылышын же DoS чабуулдарын аныктай алат.
Бул үч баскычтуу архитектура өтө татаал деп ойлобоңуз - башка бардык варианттар (балким, SNMP жана RMON менен иштеген тармактык мониторинг тутумдарынан тышкары) дагы ага ылайык иштейт. Бизде талдоо үчүн маалымат генератору бар, ал тармактык түзүлүш же өзүнчө сенсор болушу мүмкүн. Бизде сигналдарды чогултуу системасы жана мониторингдин бардык инфраструктурасын башкаруу системасы бар. Акыркы эки компонентти бир түйүн ичинде бириктирсе болот, бирок аздыр-көптүр чоң тармактарда масштабдуулугун жана ишенимдүүлүгүн камсыз кылуу үчүн алар, адатта, жок дегенде эки түзмөккө жайылтылат.
Ар бир пакеттин башын жана негизги маалыматтарын жана ал турган сессияларды изилдөөгө негизделген пакеттик анализден айырмаланып, агым анализи тармак трафиги жөнүндө метаберилиштерди чогултууга таянат. Качан, канча, кайдан жана кайдан, кантип... бул суроолорго ар кандай агым протоколдорун колдонуу менен тармактык телеметриянын анализи жооп берет. Башында, алар статистиканы талдоо жана тармактагы IT көйгөйлөрүн табуу үчүн колдонулган, бирок андан кийин аналитикалык механизмдер өнүккөн сайын, аларды коопсуздук максатында ошол эле телеметрияга колдонууга мүмкүн болду. Дагы бир жолу белгилей кетүү керек, агым анализи пакетти басып алууну алмаштырбайт же алмаштырбайт. Бул ыкмалардын ар бири өзүнүн колдонуу чөйрөсүнө ээ. Бирок бул макаланын контекстинде ички инфраструктурага мониторинг жүргүзүү үчүн эң ылайыктуу агымдын анализи. Сизде тармактык түзүлүштөр бар (алар программалык камсыздоо менен аныкталган парадигмада иштейби же статикалык эрежелерге ылайыкпы), чабуулду айланып өтүүгө болбойт. Ал классикалык 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 анализатору муну кылууга жол бербейт, анткени анын негизги милдети телеметрияны чогултуу жана ага IT көз карашынан негизги анализ жүргүзүү. Агымдын негизинде маалыматтык коопсуздук коркунучтарын аныктоо үчүн анализаторду ар кандай кыймылдаткычтар жана алгоритмдер менен жабдуу зарыл, алар стандарттуу же ыңгайлаштырылган 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 сенсору "тартып" ала турган белгилүү бир өткөрүү жөндөмдүүлүгү менен чектелген жана агым коллекторунун түшүнүү керек болгон өзүнүн чектөөлөрү бар. Ошондуктан, чоң, географиялык бөлүштүрүлгөн тармактарда, адатта, бир нече коллекторлор бар. Мен сүрөттөп жатканда , Мен буга чейин биздин коллекционерлерибиздин санын айттым - алардын саны 21. Ал эми бул беш континентке чачырап кеткен жана жарым миллионго жакын активдүү түзмөктөрдү камтыган тармак үчүн).
Биз Netflow мониторинг системасы катары өзүбүздүн чечимди колдонобуз коопсуздук маселелерин чечүүгө өзгөчө багытталган. Анда аномалдык, шектүү жана ачык зыяндуу аракеттерди аныктоо үчүн көптөгөн орнотулган кыймылдаткычтар бар, бул ар кандай коркунучтардын кеңири спектрин аныктоого мүмкүндүк берет - криптоминингден маалыматтын агып кетишине чейин, зыяндуу коддун жайылышынан алдамчылыкка чейин. Көпчүлүк агым анализаторлор сыяктуу эле, Stealthwatch үч деңгээлдүү схема боюнча курулган (генератор - коллектор - анализатор), бирок ал каралып жаткан материалдын контекстинде маанилүү болгон бир катар кызыктуу функциялар менен толукталган. Биринчиден, ал пакетти басып алуу чечимдери (мисалы, Cisco Security Packet Analyzer) менен интеграцияланат, бул кийинчерээк терең иликтөө жана талдоо үчүн тандалган тармак сессияларын жаздырууга мүмкүндүк берет. Экинчиден, атайын коопсуздук тапшырмаларын кеңейтүү үчүн биз атайын nvzFlow протоколун иштеп чыктык, ал сизге акыркы түйүндөрдөгү (серверлер, жумушчу станциялар ж. Эгерде Stealthwatch өзүнүн баштапкы версиясында тармак деңгээлинде каалаган агым протоколу (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) менен иштесе, nvzFlow колдоосу түйүн деңгээлинде да маалыматтарды корреляциялоого мүмкүндүк берет. бүт системанын натыйжалуулугун жогорулатуу жана кадимки тармак агымы анализаторлор караганда көбүрөөк чабуулдарды көрүү.
Коопсуздук көз карашынан алганда Netflow талдоо системалары жөнүндө сөз болгондо, рынок Cisco бир эле чечими менен эле чектелбей турганы түшүнүктүү. Сиз коммерциялык жана акысыз же Shareware чечимдерди колдоно аласыз. Эгер мен 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ке кайрылып көрөлү. Аналитиктин аны менен иштөө цикли төмөнкүдөй көрүнөт:
- Гипотезаны түзүү. Биз тармактык телеметриядан эмнени издей турганыбызды түшүнүшүбүз керек, айрым аномалияларды же коркунучтарды аныктай турган уникалдуу атрибуттарды билишибиз керек.
- Модель куруу. Гипотезаны түзүп, биз аны ошол эле Python, shell же SiLKге кирбеген башка куралдарды колдонуп программалайбыз.
- Сыноо. 'rw', 'set', 'cash' менен башталган SiLK утилиталары аркылуу тастыкталган же жокко чыгарылган гипотезабыздын тууралыгын текшерүүгө убакыт жетти.
- Чыныгы маалыматтарды талдоо. Өнөр жай ишинде SiLK бизге бир нерсени аныктоого жардам берет жана аналитик “Биз күткөн нерсени таптыкпы?”, “Бул биздин гипотезабызга дал келеби?”, “Жалган позитивдердин санын кантип азайтуу керек?”, “Кантип суроолорго жооп бериши керек. таануу деңгээлин жогорулатуу үчүн? » жана башка.
- жакшыртуу. Акыркы этапта биз мурда жасалган иштерди жакшыртабыз - шаблондорду түзөбүз, кодду жакшыртабыз жана оптималдаштырабыз, гипотезаны кайра формулировкалайбыз жана тактайбыз ж.б.
Бул цикл Cisco Stealthwatch үчүн да колдонулат, акыркысы гана бул беш кадамды максималдуу автоматташтырат, аналитиктин каталарынын санын азайтат жана инциденттерди аныктоонун натыйжалуулугун жогорулатат. Мисалы, SiLKте тармак статистикасын кол менен жазылган скрипттердин жардамы менен зыяндуу IP-дар боюнча тышкы маалыматтар менен байыта аласыз, ал эми Cisco Stealthwatch-те бул тармактык трафикте кара тизмедеги IP даректер менен өз ара аракеттешүүлөрдү камтыган болсо, дароо сигналды көрсөтүүчү орнотулган функция.
Эгерде сиз агымды талдоо үчүн программалык камсыздоонун “акы төлөнүүчү” пирамидасында жогору чыксаңыз, анда таптакыр бекер SiLKден кийин үч негизги компоненттен турган ELK shareware программасы пайда болот - Elasticsearch (индекстөө, издөө жана маалыматтарды талдоо), Logstash (маалыматтарды киргизүү/чыгаруу). ) жана Кибана (визуализация). Баарын өзүңүз жазышыңыз керек болгон SiLKтен айырмаланып, ELK тармактык телеметриянын анализин автоматташтырган көптөгөн даяр китепканаларга/модульдерге ээ (айрымдары акы төлөнөт, кээ бирлери жок). Мисалы, Logstash ичиндеги GeoIP чыпкасы көзөмөлдөнгөн IP даректерди алардын географиялык жайгашкан жери менен байланыштырууга мүмкүндүк берет (Stealthwatch бул камтылган өзгөчөлүккө ээ).
ELK ошондой эле бул мониторинг чечими үчүн жетишпеген компоненттерди аяктап жаткан кыйла чоң коомчулукка ээ. Мисалы, Netflow, IPFIX жана sFlow менен иштөө үчүн сиз модулду колдонсоңуз болот , сиз Netflow'ту гана колдогон Logstash Netflow модулу менен канааттанбасаңыз.
Агымды чогултууда жана аны издөөдө көбүрөөк эффективдүүлүктү берип жатканда, ELK учурда тармактык телеметриядагы аномалияларды жана коркунучтарды аныктоо үчүн бай камтылган аналитикага ээ эмес. Башкача айтканда, жогоруда сүрөттөлгөн жашоо циклинен кийин, сиз бузуу моделдерин өз алдынча сүрөттөп, андан кийин аны согуштук тутумда колдонууга туура келет (ал жерде орнотулган моделдер жок).
Албетте, ELK үчүн татаалыраак кеңейтүүлөр бар, алар буга чейин тармактык телеметриядагы аномалияларды аныктоо үчүн кээ бир моделдерди камтыйт, бирок мындай кеңейтүүлөр акча талап кылат жана оюн шамга татыктуубу деген суроо туулат - окшош моделди өзүңүз жазыңыз, аны ишке ашырууну сатып алыңыз Сиздин мониторинг куралы үчүн, же Network Traffic Analysis классынын даяр чечимин сатып алыңыз.
Жалпысынан, мен акча коротуп, тармактык телеметриядагы аномалияларды жана коркунучтарды (мисалы, 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. Эгер сизге жогоруда жазылгандардын баарын угуу оңой болсо, анда бул жазууга негиз болгон бир сааттык презентацияны көрө аласыз.
Source: www.habr.com