O ran monitro diogelwch rhwydwaith corfforaethol neu adrannol mewnol, mae llawer yn ei gysylltu â rheoli gollyngiadau gwybodaeth a gweithredu datrysiadau CLLD. Ac os ceisiwch fireinio'r cwestiwn a gofyn sut rydych chi'n canfod ymosodiadau ar y rhwydwaith mewnol, yna fel arfer bydd yr ateb yn sôn am systemau canfod ymyrraeth (IDS). Ac mae'r hyn oedd yr unig opsiwn 10-20 mlynedd yn ôl yn dod yn anacroniaeth heddiw. Mae mwy effeithiol, ac mewn rhai mannau yr unig opsiwn posibl ar gyfer monitro'r rhwydwaith mewnol - i ddefnyddio protocolau llif, a gynlluniwyd yn wreiddiol i chwilio am broblemau rhwydwaith (datrys problemau), ond dros amser drawsnewid yn arf diogelwch diddorol iawn. Yma byddwn yn siarad am beth yw protocolau llif a pha rai sy'n helpu i ganfod ymosodiadau rhwydwaith yn well, lle mae'n well gweithredu monitro llif, beth i edrych amdano wrth ddefnyddio cynllun o'r fath, a hyd yn oed sut i "godi" y cyfan ar offer domestig , byddwn yn siarad o fewn cwmpas yr erthygl hon.
Ni fyddaf yn pwyso ar y cwestiwn “Pam mae angen inni fonitro diogelwch y seilwaith mewnol?” Mae'r ateb i hynny yn fath o amlwg. Ond os, serch hynny, yr hoffech wneud yn siŵr unwaith eto na allwch wneud hebddo heddiw, fideo byr gyda stori am sut y gallwch chi fynd i mewn i rwydwaith corfforaethol sydd wedi'i warchod gan wal dân mewn 17 ffordd. Felly, byddwn yn cymryd yn ganiataol ein bod yn deall bod monitro mewnol yn beth angenrheidiol ac nid yw ond yn dal i fod i ddeall sut y gellir ei drefnu.
Byddwn yn nodi tair ffynhonnell ddata allweddol ar gyfer monitro seilwaith ar lefel rhwydwaith:
- traffig “crai” yr ydym yn ei ddal a'i gyflwyno i'w ddadansoddi i rai systemau dadansoddi,
- digwyddiadau o ddyfeisiau rhwydwaith y mae traffig yn mynd trwyddynt,
- gwybodaeth traffig a dderbyniwyd drwy un o'r protocolau llif.
Dal traffig amrwd yw'r opsiwn mwyaf poblogaidd ymhlith pobl ddiogelwch, oherwydd yn hanesyddol roedd yn ymddangos a hwn oedd y cyntaf. Roedd systemau canfod ymwthiad rhwydwaith confensiynol (y system canfod ymyrraeth fasnachol gyntaf un oedd NetRanger o'r Wheel Group, a brynwyd ym 1998 gan Cisco) yn ymwneud â chasglu pecynnau (a sesiynau diweddarach) lle chwiliwyd rhai llofnodion (“rheolau pendant” yn y terminoleg y FSTEC), ymosodiadau signalau. Wrth gwrs, gallwch ddadansoddi traffig amrwd nid yn unig gydag IDS, ond hefyd gydag offer eraill (er enghraifft, Wireshark, tcpdum, neu ymarferoldeb NBAR2 yn Cisco IOS), ond fel arfer nid oes ganddynt y sylfaen wybodaeth sy'n gwahaniaethu offeryn diogelwch gwybodaeth o a offeryn TG rheolaidd.
Felly, systemau canfod ymyrraeth. Y dull hynaf a mwyaf poblogaidd ar gyfer canfod ymosodiadau rhwydwaith, sy'n gwneud gwaith da ar y perimedr (ni waeth beth - corfforaethol, canolfan ddata, segment, ac ati), ond yn methu mewn rhwydweithiau switsh modern a diffiniedig gan feddalwedd. Yn achos rhwydwaith wedi'i adeiladu ar sail switshis confensiynol, mae seilwaith synwyryddion canfod ymwthiad yn mynd yn rhy fawr - bydd yn rhaid i chi roi synhwyrydd ar bob cysylltiad â'r gwesteiwr yr ydych am fonitro ymosodiadau yn ei erbyn. Bydd unrhyw wneuthurwr, wrth gwrs, yn hapus i werthu cannoedd ar filoedd o synwyryddion i chi, ond credaf na all eich cyllideb wrthsefyll treuliau o'r fath. Gallaf ddweud, hyd yn oed yn Cisco (a ni yw datblygwyr NGIPS) na allem wneud hyn, er, mae'n ymddangos, mae mater pris ger ein bron. Ni ddylai sefyll - ein penderfyniad ein hunain yw hwn. Yn ogystal, mae'r cwestiwn yn codi, sut i gysylltu y synhwyrydd yn y fersiwn hwn? I mewn i fwlch? Beth os bydd y synhwyrydd ei hun yn methu? Angen modiwl ffordd osgoi yn y synhwyrydd? Defnyddio holltwyr (tap)? Mae hyn i gyd yn cynyddu cost yr ateb ac yn ei gwneud yn anfforddiadwy i gwmni o unrhyw faint.
Gallwch geisio “hongian” y synhwyrydd ar y porthladd SPAN / RSPAN / ERSPAN a chyfeirio traffig ato o'r porthladdoedd switsh angenrheidiol. Mae'r opsiwn hwn yn dileu'r broblem a ddisgrifiwyd yn y paragraff blaenorol yn rhannol, ond mae'n peri un arall - ni all y porthladd SPAN dderbyn yr holl draffig a anfonir ato - ni fydd ganddo ddigon o led band. Yn fodlon aberthu rhywbeth. Naill ai gadewch rai o'r nodau heb eu monitro (yna yn gyntaf mae angen i chi eu blaenoriaethu), neu anfon nid yr holl draffig o'r nod, ond dim ond math penodol. Mewn unrhyw achos, gallwn golli rhai ymosodiadau. Yn ogystal, gellir meddiannu'r porthladd SPAN ar gyfer anghenion eraill. O ganlyniad, bydd yn rhaid i ni adolygu topoleg y rhwydwaith presennol ac o bosibl gwneud addasiadau iddo er mwyn gorchuddio eich rhwydwaith i'r eithaf gyda nifer y synwyryddion sydd gennych (a chydlynu hyn gyda TG).
Beth os yw eich rhwydwaith yn defnyddio llwybrau anghymesur? Ac os ydych wedi gweithredu neu'n bwriadu gweithredu SDN? Ond beth os oes angen i chi fonitro peiriannau rhithwir neu gynwysyddion nad yw eu traffig yn cyrraedd y switsh ffisegol o gwbl? Mae'r rhain yn gwestiynau nad yw gwerthwyr IDS traddodiadol yn eu hoffi oherwydd nad ydyn nhw'n gwybod sut i'w hateb. Efallai y byddant yn eich perswadio bod yr holl dechnolegau ffasiynol hyn yn hype ac nad oes eu hangen arnoch. Efallai y byddan nhw'n siarad am yr angen i ddechrau'n fach. Neu efallai y byddant yn dweud bod angen i chi roi dyrnwr pwerus yng nghanol y rhwydwaith a chyfeirio'r holl draffig ato gan ddefnyddio cydbwyswyr llwyth. Pa bynnag opsiwn a gynigir i chi, mae angen i chi'ch hun ddeall yn glir sut mae'n addas i chi. A dim ond ar ôl hynny yn gwneud penderfyniad ar y dewis o ddull i fonitro diogelwch gwybodaeth y rhwydwaith seilwaith. Gan ddychwelyd i gipio pecynnau, rwyf am ddweud bod y dull hwn yn parhau i fod yn boblogaidd iawn ac yn bwysig, ond ei brif bwrpas yw rheoli ffiniau; y ffiniau rhwng eich sefydliad a'r Rhyngrwyd, y ffiniau rhwng y ganolfan ddata a gweddill y rhwydwaith, y ffiniau rhwng y system rheoli prosesau a'r segment corfforaethol. Yn y lleoedd hyn, mae gan IDS / IPS clasurol yr hawl o hyd i fodoli a gwneud gwaith da gyda'u tasgau.
Gadewch i ni symud ymlaen at yr ail opsiwn. Gellir defnyddio dadansoddiad o ddigwyddiadau sy'n dod o ddyfeisiau rhwydwaith hefyd at ddibenion canfod ymwthiad, ond nid fel y prif fecanwaith, gan mai dim ond dosbarth bach o ymwthiadau y mae'n eu canfod. Yn ogystal, mae rhywfaint o adweithedd yn gynhenid ynddo - rhaid i ymosodiad ddigwydd yn gyntaf, yna rhaid ei osod gan ddyfais rhwydwaith, a fydd mewn un ffordd neu'r llall yn arwydd o broblem gyda diogelwch gwybodaeth. Mae yna nifer o ddulliau o'r fath. Gall fod yn syslog, RMON neu SNMP. Defnyddir y ddau brotocol olaf ar gyfer monitro rhwydwaith yng nghyd-destun diogelwch gwybodaeth dim ond os oes angen i ni ganfod ymosodiad DoS ar yr offer rhwydwaith ei hun, oherwydd trwy ddefnyddio RMON a SNMP gallwch, er enghraifft, fonitro'r llwyth ar brosesydd canolog y ddyfais neu ei rhyngwynebau. Dyma un o'r “rhataf” (mae gan bawb syslog neu SNMP), ond hefyd y mwyaf aneffeithlon o'r holl ffyrdd o fonitro diogelwch gwybodaeth y seilwaith mewnol - mae llawer o ymosodiadau yn cael eu cuddio ohono. Wrth gwrs, ni ddylid eu hesgeuluso, ac mae'r un dadansoddiad syslog yn eich helpu i nodi newidiadau yng nghyfluniad y ddyfais ei hun mewn modd amserol, gan gyfaddawdu, ond nid yw'n addas iawn ar gyfer canfod ymosodiadau ar y rhwydwaith cyfan.
Y trydydd opsiwn yw dadansoddi gwybodaeth am draffig sy'n mynd trwy ddyfais sy'n cefnogi un o sawl protocol llif. Yn yr achos hwn, waeth beth fo'r protocol, mae'r seilwaith ffrydio o reidrwydd yn cynnwys tair cydran:
- Cynhyrchu neu lif allforio. Mae'r rôl hon fel arfer yn cael ei neilltuo i lwybrydd, switsh neu ddyfais rhwydwaith arall, sydd, wrth basio traffig rhwydwaith trwyddo'i hun, yn caniatáu ichi dynnu paramedrau allweddol ohono, sydd wedyn yn cael eu trosglwyddo i'r modiwl casglu. Er enghraifft, cefnogir protocol Netflow Cisco nid yn unig ar lwybryddion a switshis, gan gynnwys rhai rhithwir a diwydiannol, ond hefyd ar reolwyr diwifr, waliau tân, a hyd yn oed gweinyddwyr.
- Llif casglu. O ystyried bod mwy nag un ddyfais rhwydwaith fel arfer mewn rhwydwaith modern, mae'r broblem o gasglu a chydgrynhoi ffrydiau yn codi, sy'n cael ei datrys gyda chymorth casglwyr fel y'u gelwir sy'n prosesu'r ffrydiau a dderbynnir ac yna'n eu trosglwyddo i'w dadansoddi.
- dadansoddiad llif. Mae'r dadansoddwr yn ymgymryd â'r brif dasg ddeallusol a, thrwy gymhwyso algorithmau amrywiol i'r ffrydiau, yn dod i gasgliadau penodol. Er enghraifft, o fewn swyddogaeth TG, gall dadansoddwr o'r fath nodi tagfeydd rhwydwaith neu ddadansoddi'r proffil llwyth traffig i wneud y gorau o'r rhwydwaith ymhellach. Ac ar gyfer diogelwch gwybodaeth, gall dadansoddwr o'r fath ganfod gollyngiadau data, lledaeniad cod maleisus, neu ymosodiadau DoS.
Peidiwch â meddwl bod pensaernïaeth tair haen o'r fath yn rhy gymhleth - mae pob opsiwn arall (ac eithrio systemau monitro rhwydwaith sy'n gweithio gyda SNMP a RMON) hefyd yn gweithio yn unol ag ef. Mae gennym gynhyrchydd data ar gyfer dadansoddi, sef dyfais rhwydwaith neu synhwyrydd annibynnol. Mae gennym system casglu larymau ac mae gennym system reoli ar gyfer yr holl seilwaith monitro. Gellir cyfuno'r ddwy gydran olaf o fewn un nod, ond mewn rhwydweithiau mawr mwy neu lai maent fel arfer yn cael eu gwasgaru dros o leiaf ddwy ddyfais er mwyn sicrhau scalability a dibynadwyedd.
Yn wahanol i ddadansoddi pecynnau, sy'n seiliedig ar yr astudiaeth o bennawd a chorff data pob pecyn a'r sesiynau sy'n eu cynnwys, mae dadansoddiad llif yn dibynnu ar gasglu metadata am draffig rhwydwaith. Pryd, faint, o ble a ble, sut ... dyma'r cwestiynau y mae dadansoddiad telemetreg rhwydwaith yn eu hateb gan ddefnyddio protocolau llif amrywiol. I ddechrau, fe'u defnyddiwyd i ddadansoddi ystadegau a chwilio am broblemau TG yn y rhwydwaith, ond yna, wrth ddatblygu mecanweithiau dadansoddol, daeth yn bosibl eu cymhwyso i'r un telemetreg at ddibenion diogelwch. Mae'n werth ailadrodd yma nad yw dadansoddiad llif yn disodli nac yn disodli cipio pecynnau. Mae gan bob un o'r dulliau hyn ei gwmpas ei hun. Ond yng nghyd-destun yr erthygl hon, dadansoddi llif sydd fwyaf addas ar gyfer monitro seilwaith mewnol. Mae gennych ddyfeisiau rhwydwaith (p'un a ydynt yn gweithredu mewn patrwm a ddiffinnir gan feddalwedd neu yn unol â rheolau statig) na all ymosodiad eu hosgoi. Gall osgoi'r synhwyrydd IDS clasurol, ond nid dyfais rhwydwaith sy'n cefnogi'r protocol llif. Dyma fantais y dull hwn.
Ar y llaw arall, os oes angen sylfaen dystiolaeth arnoch ar gyfer gorfodi'r gyfraith neu eich tîm ymchwilio i ddigwyddiadau eich hun, ni allwch wneud heb gipio pecynnau - nid yw telemetreg rhwydwaith yn gopi o'r traffig y gellir ei ddefnyddio i gasglu tystiolaeth; mae ei angen ar gyfer canfod cyflym a gwneud penderfyniadau ym maes diogelwch gwybodaeth. Ar y llaw arall, gan ddefnyddio dadansoddiad telemetreg, gallwch “ysgrifennu” nid yw'r holl draffig rhwydwaith (os rhywbeth, mae Cisco hefyd yn ymwneud â chanolfannau data :-), ond dim ond yr un sy'n ymwneud â'r ymosodiad. Bydd offer dadansoddi telemetreg yn hyn o beth yn ategu mecanweithiau cipio pecynnau traddodiadol yn dda, gan roi gorchymyn ar gyfer dal a storio dethol. Fel arall, bydd yn rhaid i chi gael seilwaith storio anferth.
Dychmygwch rwydwaith sy'n rhedeg ar 250 Mbps. Os ydych chi am arbed yr holl gyfrol hon, yna bydd angen 31 MB o storfa arnoch am eiliad o drosglwyddo traffig, 1,8 GB am un munud, 108 GB am awr, a 2,6 TB am un diwrnod. I storio data dyddiol o rwydwaith gyda lled band o 10 Gb / s, bydd angen 108 TB o storfa arnoch. Ond mae rhai rheolyddion yn gofyn i chi storio data diogelwch am flynyddoedd ... Mae'r recordiad ar-alw o'r dadansoddiad llif yn eich helpu i leihau'r gwerthoedd hyn o orchmynion maint. Gyda llaw, os ydym yn siarad am gymhareb cyfaint y data a gofnodwyd o delemetreg rhwydwaith a dal data llawn, yna mae tua 1 i 500. Ar gyfer yr un gwerthoedd a roddwyd uchod, storio dadgryptio cyflawn o'r holl draffig dyddiol fydd 5 a 216 GB, yn y drefn honno (gallwch hyd yn oed ysgrifennu at yriant fflach rheolaidd).
Os yw'r dull o gipio data rhwydwaith crai ar gyfer offer dadansoddi bron yr un fath o'r gwerthwr i'r gwerthwr, yna yn achos dadansoddiad ffrwd, mae'r sefyllfa'n wahanol. Mae yna sawl amrywiad o brotocolau llif, y gwahaniaethau y mae angen i chi wybod amdanynt yng nghyd-destun diogelwch. Y mwyaf poblogaidd yw'r protocol Netflow a ddatblygwyd gan Cisco. Mae sawl fersiwn o'r protocol hwn sy'n amrywio o ran eu galluoedd a faint o wybodaeth a gofnodwyd am draffig. Y fersiwn gyfredol yw'r nawfed (Netflow v9), y datblygwyd safon y diwydiant Netflow v10 ohono, a elwir hefyd yn IPFIX. Heddiw, mae'r rhan fwyaf o werthwyr rhwydwaith yn cefnogi Netflow neu IPFIX yn eu hoffer. Ond mae amryw o amrywiadau eraill o brotocolau llif - sFlow, jFlow, cFlow, rFlow, NetStream, ac ati, a sFlow yw'r mwyaf poblogaidd ohonynt. Ef sy'n cael ei gefnogi amlaf gan wneuthurwyr offer rhwydwaith domestig oherwydd rhwyddineb gweithredu. Beth yw'r gwahaniaethau allweddol rhwng Netflow, fel safon de facto, a'r un sFlow? Hoffwn dynnu sylw at ychydig o rai allweddol. Yn gyntaf, mae gan Netflow feysydd y gellir eu ffurfweddu gan ddefnyddwyr yn hytrach na meysydd sefydlog yn sFlow. Ac yn ail, a dyma'r peth pwysicaf yn ein hachos ni, mae sFlow yn casglu'r hyn a elwir yn delemetreg sampl; yn wahanol i Netflow ac IPFIX heb eu samplu. Beth yw'r gwahaniaeth rhyngddynt?
Dychmygwch eich bod yn penderfynu darllen y llyfr “” fy nghydweithwyr Gary McIntyre, Joseph Munitz a Nadem Alfardan (gallwch lawrlwytho rhan o'r llyfr o'r ddolen). Mae gennych dri opsiwn i gyrraedd eich nod - darllenwch y llyfr yn ei gyfanrwydd, sgimiwch drwyddo, gan stopio ar bob 10fed neu 20fed tudalen, neu ceisiwch ddod o hyd i ailddweud cysyniadau allweddol mewn blog neu wasanaeth fel SmartReading. Felly, telemetreg heb ei samplu yw darlleniad pob “tudalen” o draffig rhwydwaith, hynny yw, dadansoddi metadata ar gyfer pob pecyn. Mae telemetreg wedi'i samplu yn astudiaeth ddethol o draffig yn y gobaith y bydd y samplau a ddewiswyd yr hyn sydd eu hangen arnoch chi. Yn dibynnu ar gyflymder y sianel, bydd y telemetreg a samplwyd yn anfon pob 64ain, 200fed, 500fed, 1000fed, 2000fed neu hyd yn oed 10000fed pecyn i'w ddadansoddi.
Yng nghyd-destun monitro diogelwch gwybodaeth, mae hyn yn golygu bod telemetreg wedi'i samplu yn addas iawn ar gyfer canfod ymosodiadau DDoS, sganio, lledaenu cod maleisus, ond gall fethu ymosodiadau atomig neu aml-becyn nad ydynt wedi'u cynnwys yn y sampl a anfonwyd i'w dadansoddi. Nid oes gan delemetreg heb ei hysgubo unrhyw ddiffygion o'r fath ychwaith. mae defnyddio'r ystod o ymosodiadau a ganfuwyd yn llawer ehangach. Dyma restr fach o ddigwyddiadau y gellir eu canfod gan ddefnyddio offer dadansoddi telemetreg rhwydwaith.
Wrth gwrs, ni fydd rhai dadansoddwr Netflow ffynhonnell agored yn caniatáu ichi wneud hyn, gan mai ei brif dasg yw casglu telemetreg a gwneud dadansoddiad sylfaenol arno o safbwynt TG. Er mwyn nodi bygythiadau IS yn seiliedig ar lif, mae angen arfogi'r dadansoddwr â pheiriannau ac algorithmau amrywiol, a fydd yn nodi problemau seiberddiogelwch yn seiliedig ar feysydd Netflow safonol neu arferol, yn cyfoethogi data safonol â data allanol o amrywiol ffynonellau Cudd-wybodaeth Bygythiad, ac ati.
Felly, os oes gennych ddewis, yna stopiwch ef ar Netflow neu IPFIX. Ond hyd yn oed os yw'ch offer ond yn gweithio gyda sFlow, fel gweithgynhyrchwyr domestig, yna hyd yn oed yn yr achos hwn gallwch chi elwa ohono mewn cyd-destun diogelwch.
Yn ystod haf 2019, dadansoddais y cyfleoedd sydd gan weithgynhyrchwyr haearn rhwydwaith Rwsiaidd, a chyhoeddodd pob un ohonynt, ac eithrio NSG, Polygon a Craftway, gefnogaeth i sFlow (o leiaf Zelaks, Natex, Eltex, QTech, Rusteletech).
Y cwestiwn nesaf a fydd yn codi ger eich bron yw ble i weithredu cymorth llif at ddibenion diogelwch? Mewn gwirionedd, nid yw'r cwestiwn yn cael ei ofyn yn hollol gywir. Ar offer modern, mae protocolau llif bron bob amser yn cael eu cefnogi. Felly, byddwn yn ailfformiwleiddio'r cwestiwn yn wahanol - ble mae'r ffordd fwyaf effeithlon o gasglu telemetreg o safbwynt diogelwch? Bydd yr ateb yn eithaf amlwg - ar y lefel mynediad, lle byddwch yn gweld 100% o'r holl draffig, lle bydd gennych wybodaeth fanwl am westeion (MAC, VLAN, ID rhyngwyneb), lle gallwch olrhain traffig P2P hyd yn oed rhwng gwesteiwyr, sy'n yn hanfodol ar gyfer sganio canfod a dosbarthu cod maleisus. Ar y lefel graidd, efallai na fyddwch yn gweld rhywfaint o'r traffig, ond ar y lefel perimedr fe welwch yn dda os yw chwarter eich traffig rhwydwaith. Ond os oes gennych chi ddyfeisiau allanol ar eich rhwydwaith am ryw reswm sy'n caniatáu i ymosodwyr “fynd i mewn ac allan” gan osgoi'r perimedr, yna ni fydd dadansoddi'r telemetreg ohono yn rhoi unrhyw beth i chi. Felly, ar gyfer y sylw mwyaf posibl, argymhellir galluogi casglu telemetreg ar y lefel mynediad. Ar yr un pryd, mae'n werth nodi, hyd yn oed os ydym yn sôn am rhithwiroli neu gynwysyddion, mae switshis rhithwir modern hefyd yn aml yn cefnogi llif, sy'n eich galluogi i reoli traffig yno hefyd.
Ond ers i mi godi'r pwnc, yna mae angen i mi ateb y cwestiwn, beth os, wedi'r cyfan, nad yw'r offer, corfforol neu rithwir, yn cefnogi protocolau llif? Neu a yw ei gynnwys wedi'i wahardd (er enghraifft, mewn segmentau diwydiannol i sicrhau dibynadwyedd)? Neu a yw ei droi ymlaen yn achosi defnydd uchel o CPU (mae hyn yn digwydd ar galedwedd hŷn)? I ddatrys y broblem hon, mae yna synwyryddion rhithwir arbenigol (synhwyrydd llif), sydd yn eu hanfod yn holltwyr cyffredin sy'n pasio traffig trwyddynt eu hunain ac yn ei ddarlledu ar ffurf llif i'r modiwl casglu. Yn wir, yn yr achos hwn rydym yn cael yr holl broblemau y buom yn siarad amdanynt uchod mewn perthynas ag offer dal pecynnau. Hynny yw, mae angen deall nid yn unig fanteision technoleg dadansoddi llif, ond hefyd ei gyfyngiadau.
Un pwynt arall sy'n bwysig i'w gofio wrth sôn am offer dadansoddi llif. Os byddwn yn cymhwyso'r metrig EPS (digwyddiad yr eiliad, digwyddiadau yr eiliad) mewn perthynas â'r dulliau arferol o gynhyrchu digwyddiadau diogelwch, yna nid yw'r dangosydd hwn yn berthnasol i ddadansoddiad telemetreg; caiff ei ddisodli gan FPS (llif yr eiliad, llif yr eiliad). Fel yn achos EPS, ni ellir ei gyfrifo ymlaen llaw, ond mae'n bosibl amcangyfrif nifer bras yr edafedd y mae dyfais benodol yn ei gynhyrchu yn dibynnu ar ei dasg. Ar y Rhyngrwyd, gallwch ddod o hyd i dablau gyda gwerthoedd bras ar gyfer gwahanol fathau o ddyfeisiau ac amodau menter, a fydd yn caniatáu ichi amcangyfrif pa fath o drwyddedau sydd eu hangen arnoch ar gyfer offer dadansoddi a beth fydd eu pensaernïaeth? Y ffaith yw bod y synhwyrydd IDS wedi'i gyfyngu i led band penodol, y bydd yn ei “dynnu allan”, ac mae gan y casglwr llif ei gyfyngiadau ei hun y mae'n rhaid eu deall. Felly, mewn rhwydweithiau mawr, wedi'u dosbarthu'n ddaearyddol, mae sawl casglwr fel arfer. Pan ddisgrifiais , Rwyf eisoes wedi rhoi nifer ein casglwyr - mae yna 21 ohonynt. Ac mae hyn ar gyfer rhwydwaith wedi'i wasgaru ar draws pum cyfandir ac yn rhifo tua hanner miliwn o ddyfeisiau gweithredol).
Rydym yn defnyddio ein datrysiad ein hunain fel system fonitro Netflow , sy'n canolbwyntio'n benodol ar ddatrys problemau diogelwch. Mae ganddo lawer o beiriannau adeiledig ar gyfer canfod gweithgaredd afreolaidd, amheus ac amlwg yn faleisus, sy'n eich galluogi i ganfod ystod eang o wahanol fygythiadau - o cryptomining i ollyngiadau gwybodaeth, o ddosbarthu cod maleisus i dwyll. Fel y rhan fwyaf o ddadansoddwyr llif, mae Stealthwatch wedi'i adeiladu ar gynllun tair lefel (generadur - casglwr - dadansoddwr), ond mae'n cael ei ategu gan nifer o nodweddion diddorol sy'n bwysig yng nghyd-destun y deunydd dan sylw. Yn gyntaf, mae'n integreiddio ag atebion cipio pecynnau (fel Cisco Security Packet Analyzer), sy'n eich galluogi i recordio sesiynau rhwydwaith dethol ar gyfer ymchwiliad a dadansoddiad manwl diweddarach. Yn ail, yn benodol i ehangu tasgau diogelwch, rydym wedi datblygu protocol nvzFlow arbennig sy'n eich galluogi i “ddarlledu” gweithgaredd cymhwysiad ar nodau diwedd (gweinyddwyr, gweithfannau, ac ati) i delemetreg a'i drosglwyddo i gasglwr i'w ddadansoddi ymhellach. Os yw Stealthwatch yn ei fersiwn wreiddiol yn gweithio gydag unrhyw brotocol llif (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) ar lefel y rhwydwaith, yna mae cefnogaeth nvzFlow yn caniatáu i ddata gael ei gydberthyn hefyd ar lefel y nod, a thrwy hynny. gwella effeithlonrwydd system gyffredinol a gweld mwy o ymosodiadau na dadansoddwyr llif rhwydwaith confensiynol.
Mae'n amlwg, wrth siarad am systemau dadansoddi Netflow o safbwynt diogelwch, nad yw'r farchnad yn gyfyngedig i un ateb gan Cisco. Gallwch ddefnyddio atebion masnachol a rhad ac am ddim neu shareware. Mae'n rhyfedd braidd os byddaf yn dyfynnu atebion cystadleuwyr ar flog Cisco, felly byddaf yn dweud ychydig eiriau am sut y gellir dadansoddi telemetreg rhwydwaith gan ddefnyddio dau offer poblogaidd, tebyg o ran enw, ond sy'n dal yn wahanol - SiLK ac ELK.
Mae SiLK yn set o offer (System ar gyfer Gwybodaeth Lefel Rhyngrwyd) ar gyfer dadansoddi traffig a ddatblygwyd gan y CERT / CC Americanaidd ac sy'n cefnogi, yng nghyd-destun erthygl heddiw, Netflow (5ed a 9fed, y fersiynau mwyaf poblogaidd), IPFIX a sLlif a defnyddio amrywiol gyfleustodau (rwfilter, rwcount, rwflowpack, ac ati) i berfformio amrywiol weithrediadau ar delemetreg rhwydwaith er mwyn canfod arwyddion o weithredoedd anawdurdodedig ynddo. Ond mae cwpl o bethau pwysig i'w nodi. Offeryn llinell orchymyn yw SiLK ac mae'n perfformio dadansoddiad ar-lein, tra'n teipio gorchymyn o'r ffurflen (canfod pecynnau ICMP sy'n fwy na 200 bytes):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ddim yn gyfforddus iawn. Gallwch ddefnyddio'r GUI iSiLK, ond ni fydd yn gwneud eich bywyd yn llawer haws trwy ddatrys y swyddogaeth ddelweddu yn unig, nid amnewid y dadansoddwr. A dyma'r ail bwynt. Yn wahanol i atebion masnachol, sydd eisoes â sylfaen ddadansoddol gadarn, algorithmau canfod anghysondebau sy'n cyfateb i lif gwaith, ac ati, yn achos SiLK, bydd yn rhaid i chi wneud hyn i gyd eich hun, a fydd yn gofyn am gymwyseddau ychydig yn wahanol i chi na defnyddio cymwyseddau parod. pecyn cymorth -i-ddefnydd. Nid yw hyn yn dda ac nid yn ddrwg - mae hon yn nodwedd o bron unrhyw offeryn rhad ac am ddim sy'n deillio o'r ffaith eich bod chi'n gwybod beth i'w wneud, a bydd ond yn eich helpu gyda hyn (mae offer masnachol yn llai dibynnol ar gymwyseddau ei ddefnyddwyr, er ei fod hefyd yn tybio bod dadansoddwyr yn deall o leiaf hanfodion cynnal ymchwiliadau rhwydwaith a monitro). Ond yn ol at SiLK. Mae cylch gwaith y dadansoddwr ag ef fel a ganlyn:
- Ffurfio rhagdybiaeth. Rhaid inni ddeall yr hyn y byddwn yn chwilio amdano y tu mewn i delemetreg rhwydwaith, gwybod y priodoleddau unigryw y byddwn yn eu defnyddio i nodi anghysondebau neu fygythiadau penodol.
- Adeiladu model. Ar ôl llunio rhagdybiaeth, rydym yn ei raglennu gan ddefnyddio'r un Python, cragen, neu offer eraill nad ydynt wedi'u cynnwys yn SiLK.
- Profi. Mae'n bryd gwirio cywirdeb ein rhagdybiaeth, sy'n cael ei chadarnhau neu ei gwrthbrofi gan ddefnyddio'r cyfleustodau SiLK gan ddechrau gyda 'rw', 'set', 'bag'.
- Dadansoddiad o ddata go iawn. Mewn gweithrediad masnachol, mae SiLK yn ein helpu i nodi rhywbeth ac mae'n rhaid i'r dadansoddwr ateb y cwestiynau "A wnaethom ddarganfod yr hyn yr oeddem yn ei ddisgwyl?", "A yw hyn yn cyfateb i'n rhagdybiaeth?", "Sut bydd yn lleihau nifer y positifau ffug?", “Sut i wella lefel y gydnabyddiaeth?” ac yn y blaen.
- Gwellhad. Yn y cam olaf, rydym yn gwella'r hyn a wnaed yn gynharach - rydym yn creu templedi, yn gwella ac yn optimeiddio'r cod, yn ailfformiwleiddio a mireinio'r rhagdybiaeth, ac ati.
Bydd y cylch hwn yn berthnasol i'r un Cisco Stealthwatch, dim ond y pum cam olaf sy'n awtomeiddio i'r eithaf, gan leihau nifer y gwallau dadansoddwr a chynyddu effeithlonrwydd canfod digwyddiadau. Er enghraifft, yn SiLK, gallwch gyfoethogi ystadegau rhwydwaith gyda data allanol ar IPs maleisus gan ddefnyddio'ch sgriptiau eich hun, ac yn Cisco Stealthwatch, mae hon yn swyddogaeth adeiledig sy'n dangos larwm i chi ar unwaith os bydd rhyngweithio â chyfeiriadau IP ar y rhestr ddu yn digwydd yn y rhwydwaith traffig.
Os ewch i fyny'r pyramid o feddalwedd dadansoddi llif “taledig”, yna bydd y SiLK hollol rhad ac am ddim yn cael ei ddilyn gan ELK shareware, sy'n cynnwys tair cydran allweddol - Elasticsearch (mynegeio, chwilio a dadansoddi data), Logstash (mewnbynnu / allbwn data) a Kibana (delweddu). Yn wahanol i SiLK, lle mae'n rhaid i chi ysgrifennu popeth eich hun, mae gan ELK lawer o lyfrgelloedd / modiwlau parod eisoes (mae rhai yn cael eu talu, nid yw rhai) sy'n awtomeiddio'r dadansoddiad o delemetreg rhwydwaith. Er enghraifft, mae'r hidlydd GeoIP yn Logstash yn caniatáu ichi rwymo'r cyfeiriadau IP a fonitrwyd i'w lleoliad daearyddol (mae gan yr un Stealthwatch y swyddogaeth adeiledig hon).
Mae gan ELK hefyd gymuned eithaf mawr sy'n ychwanegu'r cydrannau coll i'r datrysiad monitro hwn. Er enghraifft, i weithio gyda Netflow, IPFIX a sFlow gallwch ddefnyddio'r modiwl os nad ydych yn fodlon â'r Modiwl Netflow Logstash sydd ond yn cefnogi Netflow.
Gan roi mwy o effeithlonrwydd wrth gasglu llif a chwilio ynddo, ar hyn o bryd nid oes gan ELK ddadansoddeg adeiledig gyfoethog ar gyfer canfod anghysondebau a bygythiadau mewn telemetreg rhwydwaith. Hynny yw, yn dilyn y cylch bywyd a ddisgrifir uchod, bydd yn rhaid i chi ddisgrifio modelau torri yn annibynnol ac yna ei ddefnyddio yn y system ymladd (nid oes unrhyw fodelau adeiledig).
Wrth gwrs, mae yna estyniadau mwy soffistigedig ar gyfer ELK, sydd eisoes yn cynnwys rhai modelau ar gyfer canfod anghysondebau mewn telemetreg rhwydwaith, ond mae estyniadau o'r fath yn costio arian a'r cwestiwn yw a yw'r gêm yn werth y gannwyll - ysgrifennwch fodel tebyg eich hun, prynwch ei weithrediad ar gyfer eich teclyn monitro neu brynu ateb un contractwr o'r dosbarth Dadansoddiad Traffig Rhwydwaith.
Yn gyffredinol, nid wyf am fynd i ddadlau ynghylch a yw'n well gwario arian a phrynu datrysiad parod ar gyfer monitro anghysondebau a bygythiadau mewn telemetreg rhwydwaith (er enghraifft, Cisco Stealthwatch) neu ei ddarganfod ar eich pen eich hun a'i addasu. yr un SiLK, ELK neu nfdump neu Offer Llif OSU ar gyfer pob bygythiad newydd (rwy'n siarad am y ddau olaf ohonyn nhw tro diwethaf)? Mae pawb yn dewis drostynt eu hunain ac mae gan bawb eu cymhellion eu hunain dros ddewis y naill neu'r llall o'r ddau opsiwn. Roeddwn i eisiau dangos bod telemetreg rhwydwaith yn arf pwysig iawn i sicrhau diogelwch rhwydwaith eich seilwaith mewnol ac ni ddylech ei esgeuluso, er mwyn peidio ag ychwanegu at y rhestr cwmni y mae ei enw yn cael ei grybwyll yn y cyfryngau ynghyd â'r epithets. “hacio”, “ddim yn cydymffurfio â gofynion diogelwch gwybodaeth”, “ddim yn meddwl am ddiogelwch eu data a data cwsmeriaid.
I grynhoi, hoffwn restru'r awgrymiadau allweddol y dylech eu dilyn wrth adeiladu monitro diogelwch gwybodaeth o'ch seilwaith mewnol:
- Peidiwch â chyfyngu eich hun i'r perimedr yn unig! Defnyddio (a dewis) seilwaith rhwydwaith nid yn unig i drosglwyddo traffig o bwynt A i bwynt B, ond hefyd i ddatrys materion seiberddiogelwch.
- Astudiwch y mecanweithiau monitro diogelwch gwybodaeth presennol yn eich offer rhwydwaith a defnyddiwch nhw.
- Ar gyfer monitro mewnol, rhowch flaenoriaeth i ddadansoddiad telemetreg - mae'n caniatáu ichi ganfod hyd at 80-90% o'r holl ddigwyddiadau diogelwch gwybodaeth rhwydwaith, wrth wneud yr hyn sy'n amhosibl wrth ddal pecynnau rhwydwaith ac arbed lle storio ar gyfer pob digwyddiad diogelwch gwybodaeth.
- I fonitro llif, defnyddiwch Netflow v9 neu IPFIX - maen nhw'n rhoi mwy o wybodaeth yng nghyd-destun diogelwch ac yn caniatáu ichi fonitro nid yn unig IPv4, ond hefyd IPv6, MPLS, ac ati.
- Defnyddiwch brotocol llif heb ei samplu - mae'n darparu mwy o wybodaeth ar gyfer canfod bygythiadau. Er enghraifft, Netflow neu IPFIX.
- Gwiriwch lwyth eich offer rhwydwaith - efallai na fydd yn gallu trin prosesu'r protocol llif hefyd. Yna ystyriwch ddefnyddio synwyryddion rhithwir neu Declyn Cynhyrchu Netflow.
- Gweithredu rheolaeth yn y lle cyntaf ar y lefel mynediad - bydd hyn yn rhoi cyfle i chi weld 100% o'r holl draffig.
- Os nad oes gennych unrhyw ddewis a'ch bod yn defnyddio offer rhwydwaith Rwsiaidd, yna dewiswch un sy'n cefnogi protocolau llif neu sydd â phorthladdoedd SPAN / RSPAN.
- Cyfuno ymyrraeth / canfod ymosodiadau / atal ar y ffiniau a systemau dadansoddi llif yn y rhwydwaith mewnol (gan gynnwys yn y cymylau).
O ran y tip olaf, hoffwn roi enghraifft yr wyf eisoes wedi'i roi o'r blaen. Gallwch weld pe bai gwasanaeth Cisco IS bron yn gyfan gwbl wedi adeiladu ei system fonitro GG yn seiliedig ar systemau canfod ymyrraeth a dulliau llofnod, erbyn hyn maent yn cyfrif am 20% yn unig o ddigwyddiadau. Mae systemau dadansoddi llif yn cyfrif am 20% arall, sy'n awgrymu nad mympwy yw'r atebion hyn, ond offeryn go iawn yng ngweithgareddau gwasanaethau diogelwch gwybodaeth menter fodern. Ar ben hynny, mae gennych y peth pwysicaf ar gyfer eu gweithredu - y seilwaith rhwydwaith, buddsoddiadau y gellir eu hamddiffyn yn ychwanegol trwy neilltuo swyddogaethau monitro diogelwch gwybodaeth i'r rhwydwaith.
Ni chyffyrddais yn fwriadol â’r pwnc o ymateb i anghysondebau neu fygythiadau a ganfuwyd mewn llifoedd rhwydwaith, ond credaf ei bod yn amlwg na ddylai monitro ddod i ben gyda chanfod bygythiad yn unig. Dylai gael ei ddilyn gan ymateb ac yn ddelfrydol mewn modd awtomatig neu awtomataidd. Ond mae hwn yn bwnc ar gyfer erthygl ar wahân.
Gwybodaeth Ychwanegol:
PS. Os yw'n haws i chi wrando ar bopeth a ysgrifennwyd uchod, yna gallwch wylio'r cyflwyniad awr o hyd a oedd yn sail i'r nodyn hwn.
Ffynhonnell: hab.com