Корпорацийн эсвэл хэлтсийн дотоод сүлжээний аюулгүй байдлыг хянах тухайд олон хүн үүнийг мэдээллийн алдагдлыг хянах, DLP шийдлийг хэрэгжүүлэхтэй холбодог. Хэрэв та асуултаа тодруулж, дотоод сүлжээнд халдлагыг хэрхэн илрүүлж байгааг асуувал хариулт нь дүрмээр бол халдлагыг илрүүлэх систем (IDS) -ийн тухай дурдах болно. 10-20 жилийн өмнө цорын ганц сонголт байсан нь өнөөдөр анахронизм болон хувирч байна. Дотоод сүлжээг хянах илүү үр дүнтэй бөгөөд зарим газарт цорын ганц боломжит хувилбар байдаг - урсгалын протоколууд нь сүлжээний асуудлыг хайхад зориулагдсан (алдааг олж засварлах) боловч цаг хугацааны явцад маш сонирхолтой аюулгүй байдлын хэрэгсэл болж хувирсан. Бид ямар урсгал протоколууд байдаг, аль нь сүлжээний халдлагыг илрүүлэхэд илүү дээр байдаг, урсгалын хяналтыг хаана хэрэгжүүлэх нь дээр вэ, ийм схемийг ашиглахдаа юуг анхаарах, тэр байтугай дотоодын тоног төхөөрөмж дээр хэрхэн "өргөх" талаар ярилцах болно. Энэ зүйлийн хүрээнд.
Би “Дотоод дэд бүтцийн аюулгүй байдлын мониторинг яагаад хэрэгтэй байна вэ?” гэсэн асуултад анхаарлаа хандуулахгүй. Хариулт нь тодорхой байх шиг байна. Гэсэн хэдий ч та өнөөдөр үүнгүйгээр амьдарч чадахгүй гэдгээ дахин нэг удаа батлахыг хүсч байвал, Галт ханаар хамгаалагдсан корпорацийн сүлжээнд 17 аргаар хэрхэн нэвтэрч болох тухай богино хэмжээний видео. Тиймээс бид дотоод хяналтыг зайлшгүй хийх ёстой зүйл гэдгийг ойлгож байгаа бөгөөд үүнийг хэрхэн зохион байгуулж болохыг ойлгоход л үлддэг.
Би сүлжээний түвшинд дэд бүтцийг хянах гурван үндсэн мэдээллийн эх сурвалжийг онцлон тэмдэглэх болно.
- Бидний цуглуулж, тодорхой шинжилгээний системд дүн шинжилгээ хийлгэхээр илгээдэг "түүхий" урсгал,
- траффик дамждаг сүлжээний төхөөрөмжүүдийн үйл явдлууд,
- урсгалын протоколуудын аль нэгээр дамжуулан хүлээн авсан хөдөлгөөний мэдээлэл.
Түүхий урсгалыг олж авах нь аюулгүй байдлын мэргэжилтнүүдийн дунд хамгийн түгээмэл сонголт юм, учир нь энэ нь түүхэнд гарч ирсэн бөгөөд хамгийн анхных байсан юм. Сүлжээний халдлагыг илрүүлэх уламжлалт системүүд (анхны арилжааны халдлага илрүүлэх систем нь 1998 онд Cisco-оос худалдаж авсан Wheel группын 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 протоколыг зөвхөн чиглүүлэгч, свич, түүний дотор виртуал болон үйлдвэрлэлийн төхөөрөмж дээр төдийгүй утасгүй хянагч, галт хана, тэр ч байтугай сервер дээр дэмждэг.
- Цуглуулгын урсгал. Орчин үеийн сүлжээ нь ихэвчлэн нэгээс олон сүлжээний төхөөрөмжтэй байдаг тул урсгалыг цуглуулах, нэгтгэх асуудал гарч ирдэг бөгөөд энэ нь хүлээн авсан урсгалыг боловсруулж, дүн шинжилгээ хийх зорилгоор дамжуулдаг коллектор гэж нэрлэгддэг төхөөрөмжийг ашиглан шийддэг.
- Урсгалын шинжилгээ Анализатор нь үндсэн оюуны даалгаврыг гүйцэтгэж, урсгалд янз бүрийн алгоритмуудыг ашигласнаар тодорхой дүгнэлт гаргадаг. Жишээлбэл, мэдээллийн технологийн функцын нэг хэсэг болгон ийм анализатор нь сүлжээний саад тотгорыг тодорхойлох эсвэл сүлжээг цаашид оновчтой болгохын тулд ачааллын профайлд дүн шинжилгээ хийх боломжтой. Мэдээллийн аюулгүй байдлын үүднээс ийм анализатор нь өгөгдөл алдагдсан, хортой код тархсан эсвэл DoS халдлагыг илрүүлж чаддаг.
Энэхүү гурван түвшний архитектурыг хэтэрхий төвөгтэй гэж бүү бодоорой - бусад бүх сонголтууд (SNMP ба RMON-тэй ажилладаг сүлжээний хяналтын системээс бусад) мөн үүний дагуу ажилладаг. Бидэнд дүн шинжилгээ хийх өгөгдөл үүсгэгч байдаг бөгөөд энэ нь сүлжээний төхөөрөмж эсвэл бие даасан мэдрэгч байж болно. Бид дохиолол цуглуулах систем, хяналтын бүх дэд бүтцийн удирдлагын системтэй. Сүүлийн хоёр бүрэлдэхүүн хэсгийг нэг зангилаа дотор нэгтгэж болох боловч том ба бага хэмжээний сүлжээнүүдэд өргөтгөх чадвар, найдвартай байдлыг хангах үүднээс дор хаяж хоёр төхөөрөмжид тараадаг.
Пакет бүрийн толгой, үндсэн өгөгдөл, түүний бүрдэх сессийг судлахад үндэслэсэн пакетийн шинжилгээнээс ялгаатай нь урсгалын шинжилгээ нь сүлжээний хөдөлгөөний талаархи мета өгөгдөл цуглуулахад тулгуурладаг. Хэзээ, хэр их, хаанаас, хаанаас, яаж... Эдгээр нь урсгалын янз бүрийн протоколуудыг ашиглан сүлжээний телеметрийн шинжилгээгээр хариулдаг асуултууд юм. Эхэндээ тэдгээрийг статистик мэдээлэлд дүн шинжилгээ хийх, сүлжээн дэх мэдээллийн технологийн асуудлуудыг олоход ашигладаг байсан боловч дараа нь аналитик механизмууд хөгжихийн хэрээр аюулгүй байдлын үүднээс тэдгээрийг ижил телеметрт ашиглах боломжтой болсон. Урсгалын шинжилгээ нь пакет барихыг орлохгүй эсвэл орлуулахгүй гэдгийг дахин тэмдэглэх нь зүйтэй. Эдгээр аргууд тус бүр өөрийн хэрэглээний талбартай байдаг. Гэхдээ энэ нийтлэлийн хүрээнд дотоод дэд бүтцийг хянахад хамгийн тохиромжтой нь урсгалын шинжилгээ юм. Танд сүлжээний төхөөрөмжүүд байгаа (тэдгээр нь програм хангамжаар тодорхойлсон парадигмаар эсвэл статик дүрмийн дагуу ажилладаг эсэх) халдлагыг тойрч гарах боломжгүй. Энэ нь сонгодог IDS мэдрэгчийг тойрч гарах боломжтой боловч урсгалын протоколыг дэмждэг сүлжээний төхөөрөмж боломжгүй юм. Энэ бол энэ аргын давуу тал юм.
Нөгөөтэйгүүр, хэрэв танд хууль сахиулах байгууллага эсвэл өөрийн ослын мөрдөн байцаалтын багт нотлох баримт хэрэгтэй бол багц хураахгүйгээр хийж чадахгүй - сүлжээний телеметр нь нотлох баримт цуглуулахад ашиглаж болох хөдөлгөөний хуулбар биш юм; Мэдээллийн аюулгүй байдлын чиглэлээр шуурхай илрүүлэх, шийдвэр гаргахад шаардлагатай. Нөгөөтэйгүүр, телеметрийн шинжилгээг ашигласнаар та бүх сүлжээний траффикийг биш (хэрэв ямар нэгэн зүйл бол Cisco мэдээллийн төвүүдтэй харьцдаг :-), зөвхөн халдлагад оролцож буй зүйлийг л "бичих" боломжтой. Энэ талаар телеметрийн шинжилгээний хэрэгслүүд уламжлалт пакет барих механизмыг нөхөж, сонгон авах, хадгалах командуудыг өгөх болно. Үгүй бол та асар том хадгалах дэд бүтэцтэй байх хэрэгтэй болно.
250 Мбит/сек хурдтай ажилладаг сүлжээг төсөөлье. Хэрэв та энэ бүх эзлэхүүнийг хадгалахыг хүсвэл нэг секундын траффик дамжуулахад 31 МБ, нэг минутад 1,8 ГБ, нэг цаг 108 ГБ, нэг өдрийн турш 2,6 ТБ санах ой хэрэгтэй болно. 10 Гбит/с-ийн зурвасын өргөнтэй сүлжээнээс өдөр тутмын өгөгдлийг хадгалахын тулд танд 108 TB-ийн санах ой хэрэгтэй болно. Гэхдээ зарим зохицуулагчид аюулгүй байдлын мэдээллийг олон жилийн турш хадгалахыг шаарддаг ... Урсгалын шинжилгээг хэрэгжүүлэхэд тань туслах захиалгат бичлэг нь эдгээр утгыг дарааллаар нь бууруулахад тусалдаг. Дашрамд хэлэхэд, хэрэв бид бүртгэгдсэн сүлжээний телеметрийн өгөгдлийн эзлэхүүний харьцаа болон бүрэн өгөгдөл хураах харьцааны талаар ярих юм бол энэ нь ойролцоогоор 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 талбарууд дээр үндэслэн кибер аюулгүй байдлын асуудлуудыг тодорхойлох, аюулын тагнуулын янз бүрийн эх сурвалжаас авсан стандарт өгөгдлийг гадаад мэдээллээр баяжуулах гэх мэт.
Тиймээс хэрэв танд сонголт байгаа бол Netflow эсвэл IPFIX-ийг сонго. Хэдийгээр таны тоног төхөөрөмж дотоодын үйлдвэрлэгчид шиг зөвхөн sFlow-тэй ажилладаг байсан ч энэ тохиолдолд та аюулгүй байдлын үүднээс ашиг тусаа өгөх боломжтой.
2019 оны зун би Оросын сүлжээний техник хангамж үйлдвэрлэгчдийн чадавхийг шинжилж, NSG, Polygon, Craftway-ээс бусад нь sFlow (дор хаяж Zelax, Natex, Eltex, QTech, Rusteleteh)-ийг дэмжихээ зарлав.
Таны тулгарах дараагийн асуулт бол аюулгүй байдлын үүднээс урсгалын дэмжлэгийг хаана хэрэгжүүлэх вэ? Үнэн хэрэгтээ асуулт нь бүрэн зөв тавигдаагүй байна. Орчин үеийн тоног төхөөрөмж бараг үргэлж урсгалын протоколуудыг дэмждэг. Тиймээс би асуултыг өөрөөр тайлбарлах болно - аюулгүй байдлын үүднээс телеметрийг хаана цуглуулах нь хамгийн үр дүнтэй вэ? Хариулт нь маш тодорхой байх болно - хандалтын түвшинд та бүх траффикийн 100% -ийг харж, хостуудын (MAC, VLAN, интерфэйсийн ID) нарийвчилсан мэдээлэлтэй байх бөгөөд хостуудын хоорондох P2P урсгалыг хянах боломжтой. хортой кодыг илрүүлэх, түгээх сканнер хийхэд чухал ач холбогдолтой. Үндсэн түвшинд та замын хөдөлгөөний зарим хэсгийг харахгүй байж болох ч периметрийн түвшинд та бүх сүлжээний хөдөлгөөний дөрөвний нэгийг харах болно. Гэхдээ ямар нэг шалтгаанаар таны сүлжээнд халдагчид периметрийг тойрч гарахгүйгээр "орох, гарах" боломжийг олгодог гадаад төхөөрөмж байгаа бол үүнээс телеметрийг шинжлэх нь танд юу ч өгөхгүй. Тиймээс хамгийн их хамрах хүрээг авахын тулд хандалтын түвшинд телеметрийн цуглуулгыг идэвхжүүлэхийг зөвлөж байна. Үүний зэрэгцээ, бид виртуалчлал эсвэл контейнерын талаар ярьж байгаа ч урсгалын дэмжлэгийг орчин үеийн виртуал унтраалга дээр ихэвчлэн олдог бөгөөд энэ нь танд тэндхийн урсгалыг хянах боломжийг олгодог.
Гэхдээ би энэ сэдвийг хөндсөн болохоор би асуултанд хариулах хэрэгтэй байна: хэрэв тоног төхөөрөмж, физик эсвэл виртуаль урсгалын протоколыг дэмждэггүй бол яах вэ? Эсвэл үүнийг оруулахыг хориглосон (жишээлбэл, найдвартай байдлыг хангахын тулд үйлдвэрлэлийн сегментүүдэд)? Эсвэл үүнийг асаах нь CPU-ийн ачаалал ихсэхэд хүргэдэг (энэ нь хуучин техник хангамжид тохиолддог)? Энэ асуудлыг шийдэхийн тулд тусгай виртуал мэдрэгч (урсгал мэдрэгч) байдаг бөгөөд тэдгээр нь үндсэндээ урсгалыг өөрсдөө дамжуулж, цуглуулах модуль руу урсгал хэлбэрээр дамжуулдаг энгийн задлагч юм. Үнэн, энэ тохиолдолд бид пакет барих хэрэгслүүдтэй холбоотой дээр дурдсан бүх асуудлыг олж авдаг. Өөрөөр хэлбэл, та урсгалын шинжилгээний технологийн давуу талыг төдийгүй түүний хязгаарлалтыг ойлгох хэрэгтэй.
Урсгалын шинжилгээний хэрэгслүүдийн талаар ярихдаа санаж байх ёстой өөр нэг зүйл бол. Хэрэв бид аюулгүй байдлын үйл явдлыг үүсгэх ердийн арга хэрэгсэлтэй холбоотойгоор 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-ийн хувьд та энэ бүгдийг өөрөө хийх хэрэгтэй бөгөөд энэ нь аль хэдийн бэлэн болсон програмыг ашиглахаас арай өөр ур чадвар шаардах болно. ашиглах хэрэгсэл. Энэ нь сайн ч биш, муу ч биш - энэ нь таныг юу хийхээ мэддэг гэж үздэг бараг бүх үнэгүй хэрэгслийн онцлог бөгөөд энэ нь зөвхөн танд туслах болно (арилжааны хэрэгслүүд нь хэрэглэгчдийн чадамжаас бага хамааралтай байдаг, гэхдээ тэд ч мөн адил гэж үздэг. шинжээчид сүлжээний судалгаа, мониторингийн наад зах нь үндсийг ойлгодог). Гэхдээ SiLK руу буцъя. Шинжээчдийн үүнтэй ажиллах мөчлөг дараах байдалтай байна.
- Таамаглал дэвшүүлэх. Бид сүлжээний телеметрийн дотроос юу хайж байгаагаа ойлгох ёстой, тодорхой гажиг, аюулыг тодорхойлох өвөрмөц шинж чанаруудыг мэдэх ёстой.
- Загвар бүтээх. Таамаглал дэвшүүлсний дараа бид үүнийг ижил Python, shell эсвэл SiLK-д ороогүй бусад хэрэгслийг ашиглан програмчилдаг.
- Туршилт хийх. Одоо 'rw', 'set', 'bag' гэж эхэлсэн SiLK хэрэгслүүдийг ашиглан батлагдсан эсвэл үгүйсгэгдсэн бидний таамаглалын зөв эсэхийг шалгах ээлж ирлээ.
- Бодит өгөгдөлд дүн шинжилгээ хийх. Аж үйлдвэрийн үйл ажиллагаанд SiLK нь бидэнд ямар нэг зүйлийг тодорхойлоход тусалдаг бөгөөд шинжээч нь "Бид хүлээж байсан зүйлээ олсон уу?", "Энэ нь бидний таамаглалтай нийцэж байна уу?", "Худал эерэг тоог хэрхэн бууруулах вэ?", "Хэрхэн" гэсэн асуултуудад хариулах ёстой. хүлээн зөвшөөрөх түвшинг дээшлүүлэх үү? » гэх мэт.
- Сайжруулалт. Эцсийн шатанд бид өмнө нь хийсэн зүйлийг сайжруулдаг - бид загвар үүсгэх, кодыг сайжруулж, оновчтой болгох, таамаглалыг дахин боловсруулж, тодруулах гэх мэт.
Энэ мөчлөг нь Cisco Stealthwatch-д мөн хамаарах бөгөөд зөвхөн сүүлчийнх нь эдгээр таван алхмыг хамгийн дээд хэмжээнд хүртэл автоматжуулж, шинжээчийн алдааны тоог бууруулж, осол илрүүлэх үр ашгийг нэмэгдүүлдэг. Жишээлбэл, SiLK-д та сүлжээний статистикийг гараар бичсэн скрипт ашиглан хортой IP-ийн гадаад мэдээллээр баяжуулах боломжтой бөгөөд Cisco Stealthwatch-д энэ нь сүлжээний траффик хар жагсаалтаас IP хаягуудтай харилцан үйлчлэлцсэн тохиолдолд дохиоллыг шууд харуулдаг суурилуулсан функц юм.
Хэрэв та урсгалын шинжилгээний програм хангамжийн "төлбөртэй" пирамид дээр ахивал үнэ төлбөргүй SiLK-ийн дараа Elasticsearch (индексжүүлэх, хайх, өгөгдөлд дүн шинжилгээ хийх), Logstash (өгөгдлийн оролт/гаралт) гэсэн гурван үндсэн бүрэлдэхүүн хэсгээс бүрдсэн ELK shareware программ бий болно. ) болон Кибана (дүрслэл). Бүх зүйлийг өөрөө бичих ёстой SiLK-ээс ялгаатай нь ELK-д сүлжээний телеметрийн шинжилгээг автоматжуулдаг олон бэлэн номын сан/модуль (зарим нь төлбөртэй, зарим нь биш) бий. Жишээлбэл, Logstash дахь GeoIP шүүлтүүр нь танд хяналтанд байгаа IP хаягуудыг газарзүйн байршилтай нь холбох боломжийг олгодог (Stealthwatch нь энэ суулгасан функцтэй).
ELK нь энэхүү хяналтын шийдлийн дутуу бүрэлдэхүүн хэсгүүдийг гүйцээж байгаа нэлээд том нийгэмлэгтэй. Жишээлбэл, Netflow, IPFIX, sFlow-тэй ажиллахын тулд та модулийг ашиглаж болно , хэрэв та зөвхөн Netflow дэмждэг Logstash Netflow модульд сэтгэл хангалуун бус байвал.
Урсгал цуглуулах, хайлт хийхэд илүү үр дүнтэй байхын зэрэгцээ ELK нь сүлжээний телеметрийн гажуудал, аюул заналыг илрүүлэх баялаг аналитик байхгүй байна. Өөрөөр хэлбэл, дээр дурдсан амьдралын мөчлөгийн дагуу та зөрчлийн загварыг бие даан тайлбарлаж, дараа нь байлдааны системд ашиглах хэрэгтэй болно (тэнд суурилуулсан загвар байхгүй).
Мэдээжийн хэрэг, ELK-д зориулсан илүү боловсронгуй өргөтгөлүүд байдаг бөгөөд үүнд сүлжээний телеметрийн гажигийг илрүүлэх зарим загварууд байдаг, гэхдээ ийм өргөтгөлүүд нь мөнгө шаарддаг тул тоглоом нь лааны үнэ цэнэтэй эсэх нь асуулт юм - ижил төстэй загварыг өөрөө бичиж, худалдаж аваарай. хяналтын хэрэглүүрийн хэрэгжилт эсвэл Сүлжээний хөдөлгөөний шинжилгээний ангийн бэлэн шийдлийг худалдаж аваарай.
Ерөнхийдөө би мөнгө үрж, сүлжээний телеметрийн гажиг, аюулыг хянах бэлэн шийдлийг худалдаж авах (жишээ нь Cisco Stealthwatch) эсвэл өөрөө олж мэдээд өөрчилсөн нь дээр гэсэн маргаанд орохыг хүсэхгүй байна. Шинэ аюул бүрт SiLK, ELK эсвэл nfdump эсвэл OSU урсгалын хэрэгслүүд (би тэдгээрийн сүүлийн хоёрын тухай ярьж байна. сүүлийн удаа)? Хүн бүр өөрийнхөөрөө сонгодог бөгөөд хүн бүр хоёр хувилбараас аль нэгийг нь сонгох өөрийн гэсэн сэдэлтэй байдаг. Сүлжээний телеметр бол таны дотоод дэд бүтцийн сүлжээний аюулгүй байдлыг хангах маш чухал хэрэгсэл бөгөөд хэвлэл мэдээллийн хэрэгслээр нэр нь гарсан компаниудын жагсаалтад орохгүйн тулд үүнийг үл тоомсорлож болохгүй гэдгийг харуулахыг хүссэн юм " хакердсан”, “мэдээллийн аюулгүй байдлын шаардлага хангаагүй”, “өгөгдлийн болон хэрэглэгчийн мэдээллийн аюулгүй байдлын талаар бодохгүй байна.”
Дүгнэж хэлэхэд, би дотоод дэд бүтцийнхээ мэдээллийн аюулгүй байдлын хяналтыг бий болгохдоо дагаж мөрдөх ёстой гол зөвлөмжүүдийг жагсаахыг хүсч байна.
- Зөвхөн периметрээр өөрийгөө бүү хязгаарлаарай! Сүлжээний дэд бүтцийг зөвхөн А цэгээс В цэг рүү зөөвөрлөх төдийгүй кибер аюулгүй байдлын асуудлыг шийдвэрлэхэд ашиглах (мөн сонгох).
- Сүлжээний төхөөрөмжид байгаа мэдээллийн аюулгүй байдлын хяналтын механизмуудыг судалж, ашиглах.
- Дотоод мониторингийн хувьд телеметрийн шинжилгээнд давуу эрх олгох - энэ нь сүлжээний мэдээллийн аюулгүй байдлын бүх ослын 80-90% -ийг илрүүлэх боломжийг олгодог бөгөөд сүлжээний пакетуудыг барьж авах үед боломжгүй зүйлийг хийх, мэдээллийн аюулгүй байдлын бүх үйл явдлыг хадгалах зайг хэмнэх боломжийг олгодог.
- Урсгалыг хянахын тулд Netflow v9 эсвэл IPFIX ашиглана уу - тэдгээр нь аюулгүй байдлын хүрээнд илүү их мэдээлэл өгөх бөгөөд зөвхөн IPv4 төдийгүй IPv6, MPLS гэх мэтийг хянах боломжийг танд олгоно.
- Дээжгүй урсгалын протоколыг ашигла - энэ нь аюул заналыг илрүүлэх нэмэлт мэдээллийг өгдөг. Жишээлбэл, Netflow эсвэл IPFIX.
- Сүлжээний төхөөрөмжийн ачааллыг шалгана уу - энэ нь урсгалын протоколыг зохицуулах боломжгүй байж магадгүй юм. Дараа нь виртуал мэдрэгч эсвэл Netflow Generation Appliance ашиглах талаар бодож үзээрэй.
- Хяналтыг хамгийн түрүүнд хандалтын түвшинд хэрэгжүүлээрэй - энэ нь танд бүх урсгалыг 100% харах боломжийг олгоно.
- Хэрэв танд сонголт байхгүй бөгөөд та Оросын сүлжээний тоног төхөөрөмж ашиглаж байгаа бол урсгалын протоколыг дэмждэг эсвэл SPAN/RSPAN порттойг нь сонгоорой.
- Дотоод сүлжээн дэх (үүлсийг оруулаад) дотоод сүлжээн дэх халдлага/халдлагыг илрүүлэх/урьдчилан сэргийлэх систем болон урсгалын шинжилгээний системийг хослуулах.
Сүүлийн зөвлөгөөний тухайд би өмнө нь өгсөн нэгэн жишээг хэлмээр байна. Хэрэв өмнө нь Cisco мэдээллийн аюулгүй байдлын алба мэдээллийн аюулгүй байдлын хяналтын системээ халдлагыг илрүүлэх систем, гарын үсэг зурах аргууд дээр үндэслэн бараг бүхэлд нь бүтээсэн бол одоо тохиолдлын ердөө 20% -ийг эзэлж байгааг та харж байна. Өөр 20% нь урсгалын шинжилгээний системд ногдож байгаа нь эдгээр шийдлүүд нь хүсэл эрмэлзэл биш, харин орчин үеийн аж ахуйн нэгжийн мэдээллийн аюулгүй байдлын үйлчилгээний бодит хэрэгсэл болохыг харуулж байна. Түүгээр ч зогсохгүй та тэдгээрийг хэрэгжүүлэхэд хамгийн чухал зүйл бол сүлжээний дэд бүтэц, хөрөнгө оруулалтыг сүлжээнд мэдээллийн аюулгүй байдлын хяналтын функцийг хуваарилах замаар цаашид хамгаалах боломжтой.
Сүлжээний урсгалд илэрсэн гажуудал, аюул заналхийлэлд хариу арга хэмжээ авах сэдвийг би тусгайлан хөндөөгүй ч хяналт нь зөвхөн аюулыг илрүүлэх замаар дуусах ёсгүй нь аль хэдийн тодорхой болсон гэж би бодож байна. Үүний дараа хариу өгөх ба автомат эсвэл автомат горимд байвал зохино. Гэхдээ энэ бол тусдаа нийтлэлийн сэдэв юм.
Нэмэлт мэдээлэл:
Жич. Хэрэв та дээр бичсэн бүх зүйлийг сонсоход хялбар байвал энэ тэмдэглэлийн үндэс болсон нэг цагийн илтгэлийг үзэх боломжтой.
Эх сурвалж: www.habr.com