Kiam temas pri monitorado de la sekureco de interna kompania aŭ departementa reto, multaj asocias ĝin kun kontrolado de informaj likoj kaj efektivigado de DLP-solvoj. Kaj se vi provas klarigi la demandon kaj demandi kiel vi detektas atakojn sur la interna reto, tiam la respondo estos, kiel regulo, mencio de entrudiĝaj detektaj sistemoj (IDS). Kaj kio estis la sola opcio antaŭ 10-20 jaroj, hodiaŭ fariĝas anakronismo. Estas pli efika, kaj kelkloke, la sola ebla opcio por monitori internan reton - uzante fluajn protokolojn, kiuj origine estis desegnitaj por serĉi retajn problemojn (solvado de problemoj), sed kun la tempo transformitaj en tre interesan sekurecan ilon. Ni parolos pri kiaj fluaj protokoloj ekzistas kaj kiuj estas pli bonaj por detekti retajn atakojn, kie estas plej bone efektivigi fluan monitoradon, kion serĉi dum deplojado de tia skemo, kaj eĉ kiel "levi" ĉion ĉi sur hejmaj ekipaĵoj. en la amplekso de ĉi tiu artikolo.
Mi ne traktos la demandon "Kial necesas monitorado pri interna infrastruktura sekureco?" La respondo ŝajnas esti klara. Sed se vi tamen ŝatus certigi denove, ke hodiaŭ vi ne povas vivi sen ĝi, mallonga video pri kiel vi povas penetri kompanian reton protektitan de fajroŝirmilo en 17 manieroj. Tial ni supozos, ke ni komprenas, ke interna monitorado estas necesa afero kaj restas nur kompreni kiel ĝi povas esti organizita.
Mi reliefigus tri ŝlosilajn datumfontojn por monitorado de infrastrukturo ĉe la retonivelo:
- "kruda" trafiko, kiun ni kaptas kaj sendas por analizo al certaj analizsistemoj,
- eventoj de retaj aparatoj tra kiuj trafiko pasas,
- trafikinformoj ricevitaj per unu el la fluprotokoloj.
Kapti krudan trafikon estas la plej populara opcio inter sekurecaj specialistoj, ĉar ĝi historie aperis kaj estis la unua. Konvenciaj retaj entrudiĝdetektosistemoj (la plej unua komerca entrudiĝdetektosistemo estis NetRanger de la Rado-Grupo, aĉetita en 1998 fare de Cisco) estis ĝuste engaĝitaj pri kaptado de pakaĵetoj (kaj pli postaj sesioj) en kiuj certaj signaturoj estis serĉitaj ("decidaj reguloj" en FSTEC-terminologio), signalado de atakoj. Kompreneble, vi povas analizi krudan trafikon ne nur uzante IDS, sed ankaŭ uzante aliajn ilojn (ekzemple, Wireshark, tcpdum aŭ la NBAR2-funkcio en Cisco IOS), sed al ili kutime mankas la sciobazo, kiu distingas informan sekurecan ilon de kutima. IT-ilo.
Do, atakaj detektsistemoj. La plej malnova kaj plej populara metodo por detekti retajn atakojn, kiu faras bonan laboron ĉe la perimetro (ne gravas kio - kompania, datumcentro, segmento, ktp.), sed malsukcesas en modernaj ŝaltitaj kaj softvaraj retoj. En la kazo de reto konstruita surbaze de konvenciaj ŝaltiloj, la infrastrukturo de atakaj detektaj sensiloj fariĝas tro granda - vi devos instali sensilon sur ĉiu konekto al la nodo, sur kiu vi volas kontroli atakojn. Ajna fabrikanto, kompreneble, volonte vendos al vi centojn kaj milojn da sensiloj, sed mi pensas, ke via buĝeto ne povas subteni tiajn elspezojn. Mi povas diri, ke eĉ ĉe Cisco (kaj ni estas la programistoj de NGIPS) ni ne povus fari ĉi tion, kvankam ŝajnus, ke la temo de prezo estas antaŭ ni. Mi ne devus stari - estas nia propra decido. Krome, ŝprucas la demando, kiel konekti la sensilon en ĉi tiu versio? En la breĉon? Kio se la sensilo mem malsukcesas? Ĉu vi bezonas pretervojon en la sensilo? Ĉu uzi splitiloj (frapeto)? Ĉio ĉi faras la solvon pli multekosta kaj faras ĝin neatingebla por kompanio de ajna grandeco.
Vi povas provi "pendigi" la sensilon sur SPAN/RSPAN/ERSPAN-haveno kaj direkti trafikon de la bezonataj ŝaltilhavenoj al ĝi. Ĉi tiu opcio parte forigas la problemon priskribitan en la antaŭa alineo, sed prezentas alian - la SPAN-haveno ne povas akcepti absolute la tutan trafikon, kiu estos sendita al ĝi - ĝi ne havos sufiĉe da bendolarĝo. Vi devos oferi ion. Aŭ lasu kelkajn el la nodoj sen monitorado (tiam vi devas unue prioritatigi ilin), aŭ sendi ne la tutan trafikon de la nodo, sed nur certan tipon. Ĉiukaze, ni povas maltrafi iujn atakojn. Krome, la haveno SPAN povas esti uzata por aliaj bezonoj. Kiel rezulto, ni devos revizii la ekzistantan retan topologion kaj eble fari alĝustigojn al ĝi por kovri vian reton al la maksimumo per la nombro da sensiloj, kiujn vi havas (kaj kunordigi ĉi tion kun IT).
Kio se via reto uzas nesimetriajn itinerojn? Kio se vi efektivigis aŭ planas efektivigi SDN? Kio se vi bezonas monitori virtualigitajn maŝinojn aŭ ujojn, kies trafiko tute ne atingas la fizikan ŝaltilon? Ĉi tiuj estas demandoj, kiujn tradiciaj IDS-vendistoj ne ŝatas, ĉar ili ne scias kiel respondi ilin. Eble ili persvados vin, ke ĉiuj ĉi tiuj modaj teknologioj estas hype kaj vi ne bezonas ĝin. Eble ili parolos pri la bezono komenci malgrandan. Aŭ eble ili diros, ke vi devas meti potencan draŝilon en la centron de la reto kaj direkti la tutan trafikon al ĝi uzante balancilojn. Kia ajn elekto estas proponita al vi, vi devas klare kompreni kiel ĝi konvenas al vi. Kaj nur post tio prenu decidon pri elekto de aliro al monitorado de la informa sekureco de la reto-infrastrukturo. Revenante al paka kaptado, mi volas diri, ke ĉi tiu metodo daŭre estas tre populara kaj grava, sed ĝia ĉefa celo estas landlima kontrolo; limoj inter via organizo kaj la Interreto, limoj inter la datumcentro kaj la resto de la reto, limoj inter la proceza kontrolsistemo kaj la kompania segmento. En ĉi tiuj lokoj, klasikaj IDS/IPS ankoraŭ rajtas ekzisti kaj bone trakti siajn taskojn.
Ni transiru al la dua opcio. Analizo de eventoj venantaj de retaj aparatoj ankaŭ povas esti uzata por ataka detekto, sed ne kiel la ĉefa mekanismo, ĉar ĝi permesas detekti nur malgrandan klason de entrudiĝoj. Krome, ĝi estas propra al iu reagemo - la atako unue devas okazi, tiam ĝi devas esti registrita per reto-aparato, kiu laŭ unu maniero aŭ alia signalos problemon pri informa sekureco. Estas pluraj tiaj manieroj. Ĉi tio povus esti syslog, RMON aŭ SNMP. La lastaj du protokoloj por reta monitorado en la kunteksto de informa sekureco estas uzataj nur se ni bezonas detekti DoS-atakon sur la reto-ekipaĵo mem, ĉar uzante RMON kaj SNMP eblas, ekzemple, kontroli la ŝarĝon sur la centra aparato de la aparato. procesoro aŭ ĝiaj interfacoj. Ĉi tiu estas unu el la "plej malmultekostaj" (ĉiu havas syslog aŭ SNMP), sed ankaŭ la plej neefika el ĉiuj metodoj por kontroli la informan sekurecon de interna infrastrukturo - multaj atakoj estas simple kaŝitaj de ĝi. Kompreneble, ili ne devas esti neglektitaj, kaj la sama sislog-analizo helpas vin ĝustatempe identigi ŝanĝojn en la agordo de la aparato mem, la kompromison de ĝi, sed ĝi ne tre taŭgas por detekti atakojn sur la tuta reto.
La tria opcio estas analizi informojn pri trafiko pasanta tra aparato kiu subtenas unu el pluraj fluaj protokoloj. En ĉi tiu kazo, sendepende de la protokolo, la surfadena infrastrukturo nepre konsistas el tri komponentoj:
- Generacio aŭ eksportado de fluo. Ĉi tiu rolo kutime estas asignita al enkursigilo, ŝaltilo aŭ alia reto-aparato, kiu, pasante retan trafikon tra si, ebligas al vi ĉerpi de ĝi ŝlosilajn parametrojn, kiuj poste estas transdonitaj al la kolektomodulo. Ekzemple, Cisco subtenas la Netflow-protokolon ne nur sur enkursigiloj kaj ŝaltiloj, inkluzive de virtualaj kaj industriaj, sed ankaŭ sur sendrataj regiloj, fajroŝirmiloj kaj eĉ serviloj.
- Kolekta fluo. Konsiderante, ke moderna reto kutime havas pli ol unu retan aparaton, ekestas la problemo pri kolektado kaj solidigo de fluoj, kiu estas solvita per tiel nomataj kolektantoj, kiuj prilaboras la ricevitajn fluojn kaj poste transdonas ilin por analizo.
- Flua analizo La analizilo prenas la ĉefan intelektan taskon kaj, aplikante diversajn algoritmojn al fluoj, eltiras certajn konkludojn. Ekzemple, kiel parto de IT-funkcio, tia analizilo povas identigi retajn proplempunktojn aŭ analizi la trafikŝarĝan profilon por plia retoptimumigo. Kaj por informa sekureco, tia analizilo povas detekti datumfluojn, disvastiĝon de malica kodo aŭ DoS-atakojn.
Ne pensu, ke ĉi tiu trinivela arkitekturo estas tro komplika - ĉiuj aliaj opcioj (krom, eble, retaj monitoraj sistemoj laborantaj kun SNMP kaj RMON) ankaŭ funkcias laŭ ĝi. Ni havas datumgeneratoron por analizo, kiu povas esti reto-aparato aŭ memstara sensilo. Ni havas alarm-kolektan sistemon kaj administran sistemon por la tuta monitora infrastrukturo. La lastaj du komponentoj povas esti kombinitaj ene de ununura nodo, sed en pli-malpli grandaj retoj ili estas kutime disvastigitaj tra almenaŭ du aparatoj por certigi skaleblon kaj fidindecon.
Male al pakaĵanalizo, kiu baziĝas sur studado de la kap- kaj korpdatenoj de ĉiu pako kaj la sesioj el kiuj ĝi konsistas, fluanalizo dependas de kolektado de metadatenoj pri rettrafiko. Kiam, kiom, de kie kaj kie, kiel... ĉi tiuj estas la demandoj responditaj de la analizo de rettelemetrio uzante diversajn fluprotokolojn. Komence, ili estis uzataj por analizi statistikojn kaj trovi IT-problemojn en la reto, sed tiam, kiam analizaj mekanismoj disvolviĝis, eblis apliki ilin al la sama telemetrio por sekurecaj celoj. Indas noti denove, ke fluanalizo ne anstataŭas aŭ anstataŭigas pakaĵetkapton. Ĉiu el ĉi tiuj metodoj havas sian propran kampon de apliko. Sed en la kunteksto de ĉi tiu artikolo, estas fluo-analizo, kiu plej taŭgas por monitorado de interna infrastrukturo. Vi havas retajn aparatojn (ĉu ili funkcias en programaro difinita paradigmo aŭ laŭ statikaj reguloj), kiujn atako ne povas preteriri. Ĝi povas preteriri klasikan IDS-sensilon, sed reta aparato, kiu subtenas la fluo-protokolon, ne povas. Ĉi tiu estas la avantaĝo de ĉi tiu metodo.
Aliflanke, se vi bezonas pruvojn por policoj aŭ vian propran okazaĵan enketteamon, vi ne povas malhavi pakaĵkapton - rettelemetrio ne estas kopio de trafiko, kiu povas esti uzata por kolekti pruvojn; ĝi estas bezonata por rapida detektado kaj decidiĝo en la kampo de informa sekureco. Aliflanke, uzante telemetrian analizon, vi povas "skribi" ne la tutan retan trafikon (se io, Cisco traktas datumcentrojn :-), sed nur tion, kio estas implikita en la atako. Telemetriaj analiziloj ĉi-rilate bone kompletigos tradiciajn pakaĵajn kaptajn mekanismojn, donante komandojn por selektema kaptado kaj stokado. Alie, vi devos havi kolosan stokan infrastrukturon.
Ni imagu reton funkciantan kun rapideco de 250 Mbit/sec. Se vi volas stoki ĉi tiun tutan volumon, tiam vi bezonos 31 MB da stokado por unu sekundo de trafika transdono, 1,8 GB por unu minuto, 108 GB por unu horo, kaj 2,6 TB por unu tago. Por stoki ĉiutagajn datumojn de reto kun bendolarĝo de 10 Gbit/s, vi bezonos 108 TB da stokado. Sed iuj reguligistoj postulas stoki sekurecajn datumojn dum jaroj... Laŭpeta registrado, kiun fluanalizo helpas vin efektivigi, helpas redukti ĉi tiujn valorojn laŭ grand-ordoj. Cetere, se ni parolas pri la proporcio de la volumo de registritaj rettelemetriaj datumoj kaj kompleta datuma kapto, tiam ĝi estas proksimume 1 ĝis 500. Por la samaj valoroj donitaj supre, konservante plenan transskribon de la tuta ĉiutaga trafiko. estos 5 kaj 216 GB respektive (vi eĉ povas registri ĝin sur regula poŝmemoro).
Se por iloj por analizi krudajn retajn datumojn, la metodo de kapti ĝin estas preskaŭ la sama de vendisto al vendisto, tiam en la kazo de fluo-analizo la situacio estas malsama. Estas pluraj ebloj por fluaj protokoloj, pri la diferencoj pri kiuj vi devas scii en la kunteksto de sekureco. La plej populara estas la Netflow-protokolo evoluigita de Cisco. Estas pluraj versioj de ĉi tiu protokolo, diferencantaj en siaj kapabloj kaj la kvanto de trafikaj informoj registritaj. La nuna versio estas la naŭa (Netflow v9), surbaze de kiu la industrinormo Netflow v10, ankaŭ konata kiel IPFIX, estis evoluigita. Hodiaŭ, plej multaj retaj vendistoj subtenas Netflow aŭ IPFIX en sia ekipaĵo. Sed ekzistas diversaj aliaj opcioj por fluaj protokoloj - sFlow, jFlow, cFlow, rFlow, NetStream, ktp., el kiuj sFlow estas la plej populara. Estas ĉi tiu tipo, kiu plej ofte estas subtenata de hejmaj fabrikantoj de retaj ekipaĵoj pro sia facileco de efektivigo. Kio estas la ŝlosilaj diferencoj inter Netflow, kiu fariĝis fakta normo, kaj sFlow? Mi reliefigus plurajn ŝlosilajn. Unue, Netflow havas uzantajn agordeblajn kampojn kontraste al la fiksaj kampoj en sFlow. Kaj due, kaj ĉi tio estas la plej grava afero en nia kazo, sFlow kolektas tiel nomatan samplitan telemetrion; kontraste al la nespecimedita por Netflow kaj IPFIX. Kio estas la diferenco inter ili?
Imagu, ke vi decidas legi la libron "” de miaj kolegoj - Gary McIntyre, Joseph Munitz kaj Nadem Alfardan (vi povas elŝuti parton de la libro de la ligilo). Vi havas tri eblojn por atingi vian celon - legu la tutan libron, trarigardu ĝin, haltu ĉe ĉiu 10-a aŭ 20-a paĝo, aŭ provu trovi rerakonton de ŝlosilaj konceptoj en blogo aŭ servo kiel SmartReading. Do, nespecimenita telemetrio legas ĉiun "paĝon" de rettrafiko, tio estas, analizas metadatenojn por ĉiu pako. Sampledita telemetrio estas la selektema studo de trafiko kun la espero, ke la elektitaj specimenoj enhavos tion, kion vi bezonas. Depende de la kanalrapideco, specimena telemetrio estos sendita por analizo ĉiun 64-an, 200-an, 500-an, 1000-an, 2000-an aŭ eĉ 10000-an pakaĵon.
En la kunteksto de informa sekurecmonitorado, tio signifas, ke provita telemetrio estas bone taŭga por detektado de DDoS-atakoj, skanado kaj disvastigado de malica kodo, sed povas maltrafi atomajn aŭ plurpakajn atakojn, kiuj ne estis inkluditaj en la specimeno sendita por analizo. Neprovanta telemetrio ne havas tiajn malavantaĝojn. Kun ĉi tio, la gamo de detektitaj atakoj estas multe pli larĝa. Jen mallonga listo de eventoj detekteblaj per retaj telemetriaj analiziloj.
Kompreneble, iu malfermfonta Netflow-analizilo ne permesos vin fari tion, ĉar ĝia ĉefa tasko estas kolekti telemetrion kaj fari bazan analizon pri ĝi el IT-perspektivo. Por identigi informajn sekurecajn minacojn bazitajn sur fluo, necesas ekipi la analizilon per diversaj motoroj kaj algoritmoj, kiuj identigos cibersekurecajn problemojn bazitajn sur normaj aŭ kutimaj Netflow-kampoj, riĉigos normajn datumojn per eksteraj datumoj de diversaj Threat Intelligence-fontoj, ktp.
Tial, se vi havas elekton, tiam elektu Netflow aŭ IPFIX. Sed eĉ se via ekipaĵo funkcias nur kun sFlow, kiel hejmaj fabrikistoj, tiam eĉ ĉi-kaze vi povas profiti de ĝi en sekureca kunteksto.
En la somero de 2019, mi analizis la kapablojn kiujn havas rusaj retaj aparataro-fabrikistoj kaj ĉiuj ili, ekskludante NSG, Polygon kaj Craftway, anoncis subtenon por sFlow (almenaŭ Zelax, Natex, Eltex, QTech, Rusteleteh).
La sekva demando, kiun vi alfrontos, estas kie efektivigi fluan subtenon por sekurecaj celoj? Fakte, la demando ne estas starigita tute ĝuste. Modernaj ekipaĵoj preskaŭ ĉiam subtenas fluprotokolojn. Tial mi reformulus la demandon alimaniere - kie estas plej efika kolekti telemetrion el sekureca vidpunkto? La respondo estos sufiĉe evidenta - ĉe la alirnivelo, kie vi vidos 100% de la tuta trafiko, kie vi havos detalajn informojn pri gastigantoj (MAC, VLAN, interfaco ID), kie vi eĉ povas kontroli P2P-trafikon inter gastigantoj, kio estas kritika por skanado de detekto kaj distribuado de malica kodo. Ĉe la kernnivelo, vi eble simple ne vidas iom da trafiko, sed ĉe la perimetra nivelo, vi vidos kvaronon de via tuta rettrafiko. Sed se ial vi havas fremdajn aparatojn en via reto, kiuj permesas atakantojn "eniri kaj eliri" sen preteriri la perimetron, tiam analizi la telemetrion de ĝi nenion donos al vi. Tial, por maksimuma kovrado, rekomendas ebligi telemetrian kolekton ĉe la alirnivelo. Samtempe, indas noti, ke eĉ se ni parolas pri virtualigo aŭ ujoj, flusubteno ankaŭ troviĝas ofte en modernaj virtualaj ŝaltiloj, kio ebligas al vi kontroli trafikon ankaŭ tie.
Sed ĉar mi levis la temon, mi devas respondi la demandon: kio se la ekipaĵo, fizika aŭ virtuala, ne subtenas fluajn protokolojn? Aŭ ĉu ĝia inkludo estas malpermesita (ekzemple en industriaj segmentoj por certigi fidindecon)? Aŭ ĉu ŝalti ĝin kondukas al alta CPU-ŝarĝo (ĉi tio okazas ĉe pli malnova aparataro)? Por solvi ĉi tiun problemon, ekzistas specialigitaj virtualaj sensiloj (fluosensiloj), kiuj estas esence ordinaraj splitiloj, kiuj trapasas trafikon tra si kaj elsendas ĝin en formo de fluo al la kolektomodulo. Vere, en ĉi tiu kazo ni ricevas ĉiujn problemojn, pri kiuj ni parolis supre, rilate al pakaj kaptado-iloj. Tio estas, vi devas kompreni ne nur la avantaĝojn de fluo-analiza teknologio, sed ankaŭ ĝiajn limojn.
Alia punkto, kiun gravas memori, kiam oni parolas pri fluaj analiziloj. Se rilate al konvenciaj rimedoj por generi sekurecajn eventojn ni uzas la EPS-metrikon (okazaĵo por sekundo), tiam ĉi tiu indikilo ne aplikeblas al telemetria analizo; ĝi estas anstataŭigita per FPS (fluo por sekundo). Kiel en la kazo de EPS, ĝi ne povas esti kalkulita anticipe, sed vi povas taksi la proksimuman nombron da fadenoj, kiujn specifa aparato generas depende de sia tasko. Vi povas trovi tabelojn en la Interreto kun proksimumaj valoroj por malsamaj specoj de entreprenaj aparatoj kaj kondiĉoj, kiuj permesos al vi taksi kiajn licencojn vi bezonas por analizaj iloj kaj kia estos ilia arkitekturo? La fakto estas, ke la IDS-sensilo estas limigita de certa bendolarĝo, kiun ĝi povas "tiri", kaj la fluokolektilo havas siajn proprajn limigojn, kiujn oni devas kompreni. Tial, en grandaj, geografie distribuitaj retoj estas kutime pluraj kolektantoj. Kiam mi priskribis , Mi jam donis la nombron de niaj kolektantoj - estas 21. Kaj ĉi tio estas por reto disigita tra kvin kontinentoj kaj nombranta ĉirkaŭ duonmilionon da aktivaj aparatoj).
Ni uzas nian propran solvon kiel Netflow monitora sistemo , kiu estas specife fokusita al solvado de sekurecaj problemoj. Ĝi havas multajn enkonstruitajn motorojn por detekti anomalian, suspektindan kaj klare malican agadon, permesante al ĝi detekti larĝan gamon de malsamaj minacoj - de kripta minado ĝis informfuĝoj, de disvastiĝo de malica kodo ĝis fraŭdo. Kiel la plej multaj fluanaliziloj, Stealthwatch estas konstruita laŭ trinivela skemo (generatoro - kolektanto - analizilo), sed ĝi estas kompletigita per kelkaj interesaj trajtoj, kiuj estas gravaj en la kunteksto de la materialo konsiderata. Unue, ĝi integriĝas kun pakaj kaptaj solvoj (kiel Cisco Security Packet Analyzer), kiu ebligas al vi registri elektitajn retajn sesiojn por pli posta profunda esploro kaj analizo. Due, specife por pligrandigi sekurecajn taskojn, ni evoluigis specialan nvzFlow-protokolon, kiu ebligas al vi "dissendi" la agadon de aplikaĵoj sur finaj nodoj (serviloj, laborstacioj, ktp.) en telemetrion kaj transdoni ĝin al la kolektanto por plia analizo. Se en ĝia originala versio Stealthwatch funkcias kun iu ajn fluprotokolo (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) ĉe la retonivelo, tiam la subteno de nvzFlow permesas datuman korelacion ankaŭ ĉe la noda nivelo, tiel. pliigante la efikecon de la tuta sistemo kaj vidante pli da atakoj ol konvenciaj retfluaj analiziloj.
Estas klare, ke kiam oni parolas pri analizsistemoj de Netflow de sekureca vidpunkto, la merkato ne limiĝas al ununura solvo de Cisco. Vi povas uzi kaj komercajn kaj senpagajn aŭ akciajn solvojn. Estas sufiĉe strange, se mi citas solvojn de konkurantoj kiel ekzemplojn en la Cisco-blogo, do mi diros kelkajn vortojn pri kiel rettelemetrio povas esti analizita per du popularaj, similaj laŭnomaj, sed ankoraŭ malsamaj iloj - SiLK kaj ELK.
SiLK estas aro da iloj (la Sistemo por Interreta-nivela Scio) por analizo de trafiko, evoluigita de la usona CERT/CC kaj kiu subtenas, en la kunteksto de la hodiaŭa artikolo, Netflow (5-a kaj 9-a, la plej popularaj versioj), IPFIX. kaj sFlow kaj uzante diversajn ilojn (rwfilter, rwcount, rwflowpack, ktp.) por fari diversajn operaciojn pri rettelemetrio por detekti signojn de neaŭtorizitaj agoj en ĝi. Sed estas kelkaj gravaj punktoj por noti. SiLK estas komandlinia ilo kiu elfaras interretan analizon enmetante komandojn kiel ĉi tio (detekto de ICMP-pakoj pli grandaj ol 200 bajtoj):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ne tre komforta. Vi povas uzi la iSiLK GUI, sed ĝi ne multe plifaciligos vian vivon, nur solvante la bildigan funkcion kaj ne anstataŭigante la analiziston. Kaj ĉi tiu estas la dua punkto. Male al komercaj solvoj, kiuj jam havas solidan analizan bazon, algoritmojn de detektado de anomalioj, respondan laborfluon ktp., en la kazo de SiLK vi devos fari ĉion ĉi mem, kio postulos de vi iomete malsamajn kompetentecojn ol de uzado de jam preta- uzeblaj iloj. Ĉi tio estas nek bona nek malbona - ĉi tio estas trajto de preskaŭ ajna libera ilo, kiu supozas, ke vi scias kion fari, kaj ĝi nur helpos vin pri tio (komercaj iloj malpli dependas de la kompetentecoj de ĝiaj uzantoj, kvankam ili ankaŭ supozas. ke analizistoj komprenas almenaŭ bazojn de retaj esploroj kaj monitorado). Sed ni revenu al SiLK. La laborciklo de la analizisto kun ĝi aspektas jene:
- Formulante hipotezon. Ni devas kompreni, kion ni serĉos en la reto de telemetrio, scii la unikajn atributojn per kiuj ni identigos certajn anomaliojn aŭ minacojn.
- Konstruante modelon. Formulinte hipotezon, ni programas ĝin uzante la saman Python, ŝelon aŭ aliajn ilojn ne inkluzivitajn en SiLK.
- Testado. Nun venas la vico kontroli la ĝustecon de nia hipotezo, kiu estas konfirmita aŭ refutita per SiLK-utiloj komencante per 'rw', 'set', 'bag'.
- Analizo de realaj datumoj. En industria operacio, SiLK helpas nin identigi ion kaj la analizisto devas respondi la demandojn "Ĉu ni trovis tion, kion ni atendis?", "Ĉu ĉi tio respondas al nia hipotezo?", "Kiel redukti la nombron da falsaj pozitivoj?", "Kiel". plibonigi la nivelon de rekono? » kaj tiel plu.
- Pliboniĝo. En la fina etapo, ni plibonigas tion, kio estis farita pli frue - ni kreas ŝablonojn, plibonigas kaj optimumigas la kodon, reformulas kaj klarigas la hipotezon ktp.
Ĉi tiu ciklo ankaŭ estos aplikebla al Cisco Stealthwatch, nur la lasta aŭtomatigas ĉi tiujn kvin paŝojn al la maksimumo, reduktante la nombron da analizaj eraroj kaj pliigante la efikecon de okazaĵdetekto. Ekzemple, en SiLK vi povas riĉigi retajn statistikojn per eksteraj datumoj pri malicaj IP-oj uzante manskribitajn skriptojn, kaj en Cisco Stealthwatch ĝi estas enkonstruita funkcio, kiu tuj montras alarmon se rettrafiko enhavas interagojn kun IP-adresoj el la nigra listo.
Se vi iros pli alte en la "pagita" piramido por flua analiza programaro, tiam post la absolute senpaga SiLK estos shareware ELK, konsistanta el tri ŝlosilaj komponantoj - Elasticsearch (indeksado, serĉado kaj datuma analizo), Logstash (datuma enigo/eligo). ) kaj Kibana ( bildigo). Male al SiLK, kie oni devas mem skribi ĉion, ELK jam havas multajn pretajn bibliotekojn/modulojn (kelkaj pagitaj, iuj ne), kiuj aŭtomatigas la analizon de rettelemetrio. Ekzemple, la GeoIP-filtrilo en Logstash permesas vin asocii monitoritajn IP-adresojn kun ilia geografia loko (Stealthwatch havas ĉi tiun enkonstruitan funkcion).
ELK ankaŭ havas sufiĉe grandan komunumon, kiu kompletigas la mankantajn komponantojn por ĉi tiu monitora solvo. Ekzemple, por labori kun Netflow, IPFIX kaj sFlow vi povas uzi la modulon , se vi ne estas kontenta pri la Logstash Netflow Modulo, kiu nur subtenas Netflow.
Donante pli da efikeco en kolektado de fluo kaj serĉado en ĝi, al ELK nuntempe mankas riĉa enkonstruita analizo por detekti anomaliojn kaj minacojn en rettelemetrio. Tio estas, sekvante la vivociklon priskribitan supre, vi devos sendepende priskribi malobservajn modelojn kaj poste uzi ĝin en la batalsistemo (tie ne ekzistas enkonstruitaj modeloj).
Estas, kompreneble, pli kompleksaj etendaĵoj por ELK, kiuj jam enhavas kelkajn modelojn por detekti anomaliojn en rettelemetrio, sed tiaj etendaĵoj kostas monon kaj ĉi tie la demando estas ĉu la ludo valoras la kandelon - skribu similan modelon mem, aĉetu ĝin. efektivigo por via monitora ilo, aŭ aĉetu pretan solvon de la klaso Reto-Trafika Analizo.
Ĝenerale, mi ne volas eniri en la debaton, ke estas pli bone elspezi monon kaj aĉeti pretan solvon por monitorado de anomalioj kaj minacoj en rettelemetrio (ekzemple, Cisco Stealthwatch) aŭ mem eltrovi kaj personecigi la saman. SiLK, ELK aŭ nfdump aŭ OSU Flow Tools por ĉiu nova minaco (mi parolas pri la lastaj du el ili lastfoje)? Ĉiu elektas por si kaj ĉiu havas siajn proprajn motivojn por elekti iun el la du opcioj. Mi nur volis montri, ke rettelemetrio estas tre grava ilo por certigi la retan sekurecon de via interna infrastrukturo kaj vi ne devas neglekti ĝin, por ne aliĝi al la listo de kompanioj, kies nomo estas menciita en la amaskomunikilaro kune kun la epitetoj " hakita", "nekonforma kun informsekurecaj postuloj" ", "ne pensante pri la sekureco de iliaj datumoj kaj klientdatenoj."
Por resumi, mi ŝatus listigi la ŝlosilajn konsiletojn, kiujn vi devus sekvi dum konstruado de informasekureca monitorado de via interna infrastrukturo:
- Ne limigu vin nur al la perimetro! Uzu (kaj elektu) retan infrastrukturon ne nur por movi trafikon de punkto A al punkto B, sed ankaŭ por trakti problemojn pri cibersekureco.
- Studu la ekzistantajn informsekurecajn monitorajn mekanismojn en via reto-ekipaĵo kaj uzu ilin.
- Por interna monitorado, donu preferon al telemetria analizo - ĝi permesas vin detekti ĝis 80-90% de ĉiuj retaj informaj sekurecaj okazaĵoj, dum vi faras tion, kio estas neebla, kiam vi kaptas retajn pakaĵojn kaj ŝparas spacon por konservi ĉiujn eventojn pri informa sekureco.
- Por monitori fluojn, uzu Netflow v9 aŭ IPFIX - ili provizas pli da informoj en sekureca kunteksto kaj permesas vin kontroli ne nur IPv4, sed ankaŭ IPv6, MPLS, ktp.
- Uzu neprovizitan fluan protokolon - ĝi provizas pli da informoj por detekti minacojn. Ekzemple, Netflow aŭ IPFIX.
- Kontrolu la ŝarĝon sur via reto-ekipaĵo - eble ĝi ankaŭ ne povos trakti la fluo-protokolon. Tiam konsideru uzi virtualajn sensilojn aŭ Netflow Generation Appliance.
- Efektivigu kontrolon antaŭ ĉio ĉe la alirnivelo - ĉi tio donos al vi la ŝancon vidi 100% de la tuta trafiko.
- Se vi ne havas elekton kaj vi uzas rusan retan ekipaĵon, tiam elektu unu kiu subtenas fluajn protokolojn aŭ havas SPAN/RSPAN-havenojn.
- Kombinu sistemojn de entrudiĝo/ataka detektado/preventado ĉe la randoj kaj fluaj analizsistemoj en la interna reto (inkluzive en la nuboj).
Pri la lasta konsileto, mi ŝatus doni ilustraĵon, kiun mi jam donis antaŭe. Vi vidas, ke se antaŭe la informsekureca servo de Cisco preskaŭ tute konstruis sian informan sekurecmonitoran sistemon surbaze de entrudiĝaj detektaj sistemoj kaj subskribaj metodoj, nun ili okupas nur 20% de incidentoj. Alia 20% falas sur fluo-analizaj sistemoj, kio sugestas, ke ĉi tiuj solvoj ne estas kaprico, sed vera ilo en la agadoj de informaj sekurecaj servoj de moderna entrepreno. Krome, vi havas la plej gravan aferon por ilia efektivigo - retan infrastrukturon, investojn en kiuj povas esti plue protektitaj atribuante informajn sekurecajn monitorajn funkciojn al la reto.
Mi specife ne tuŝis la temon respondi al anomalioj aŭ minacoj identigitaj en retaj fluoj, sed mi pensas, ke jam estas klare, ke monitorado ne devas finiĝi nur per la detekto de minaco. Ĝi estu sekvata de respondo kaj prefere en aŭtomata aŭ aŭtomatigita reĝimo. Sed ĉi tio estas temo por aparta artikolo.
Pliaj informoj:
PS. Se estas pli facile por vi aŭdi ĉion, kio estis skribita supre, tiam vi povas spekti la unuhoran prezenton, kiu formis la bazon de ĉi tiu noto.
fonto: www.habr.com