As it giet om it tafersjoch op de feiligens fan in ynterne bedriuws- as ôfdielingsnetwurk, assosjearje in protte it mei it kontrolearjen fan ynformaasjelekken en it ymplementearjen fan DLP-oplossingen. En as jo besykje de fraach te ferdúdlikjen en te freegjen hoe't jo oanfallen op it ynterne netwurk ûntdekke, dan sil it antwurd, as regel, in fermelding wêze fan systemen foar ynbraakdeteksje (IDS). En wat 10-20 jier lyn de ienige opsje wie, wurdt hjoed in anachronisme. D'r is in effektiver, en op guon plakken, de ienige mooglike opsje foar it kontrolearjen fan in ynterne netwurk - mei help fan streamprotokollen, dy't oarspronklik waarden ûntworpen om te sykjen nei netwurkproblemen (troubleshooting), mar yn 'e rin fan' e tiid omfoarme ta in heul ynteressant befeiligingsark. Wy sille prate oer hokker streamprotokollen d'r binne en hokker better binne by it opspoaren fan netwurkoanfallen, wêr't it it bêste is om streammonitoring te ymplementearjen, wat te sykjen by it ynsetten fan sa'n skema, en sels hoe't jo dit alles kinne "heffe" op húshâldlike apparatuer binnen it berik fan dit artikel.
Ik sil net stilhâlde by de fraach "Wêrom is tafersjoch op ynterne ynfrastruktuer feiligens nedich?" It antwurd liket dúdlik te wêzen. Mar as jo dochs noch ien kear soargje wolle dat jo hjoed net sûnder kinne, in koarte fideo oer hoe't jo op 17 manieren kinne penetrearje yn in bedriuwsnetwurk beskerme troch in firewall. Dêrom sille wy oannimme dat wy begripe dat ynterne tafersjoch in needsaaklik ding is en alles wat oerbliuwt is te begripen hoe't it kin wurde organisearre.
Ik soe trije wichtige gegevensboarnen markearje foar it kontrolearjen fan ynfrastruktuer op netwurknivo:
- "Raw" ferkear dat wy fange en yntsjinje foar analyse oan bepaalde analysesystemen,
- eveneminten fan netwurkapparaten dêr't ferkear trochhinne giet,
- ferkearsynformaasje ûntfongen fia ien fan 'e streamprotokollen.
It fêstlizzen fan rau ferkear is de populêrste opsje ûnder feiligensspesjalisten, om't it histoarysk ferskynde en wie de alderearste. Konvinsjonele netwurk-ynbraakdeteksjesystemen (it earste kommersjele systeem foar ynbraakdeteksje wie NetRanger fan 'e Wheel Group, kocht yn 1998 troch Cisco) wiene krekt dwaande mei it fangen fan pakketten (en letter sesjes) wêryn't nei bepaalde hantekeningen socht waard ("beslissende regels" yn FSTEC-terminology), sinjalearjen fan oanfallen. Fansels kinne jo analysearje rau ferkear net allinnich mei help fan IDS, mar ek mei help fan oare ark (Bygelyks, Wireshark, tcpdum of de NBAR2 funksjonaliteit yn Cisco IOS), mar se meastal misse de kennis basis dy't ûnderskiedt in ynformaasje feiligens ark fan in gewoane IT tool.
Dat, systemen foar oanfaldeteksje. De âldste en populêrste metoade foar it opspoaren fan netwurkoanfallen, dy't in goede baan docht oan 'e perimeter (maklik wat - bedriuw, datasintrum, segment, ensfh.), mar mislearret yn moderne skeakele en software-definieare netwurken. Yn it gefal fan in netwurk boud op basis fan konvinsjonele skeakels, wurdt de ynfrastruktuer fan oanfallendeteksjesensors te grut - jo moatte in sensor ynstallearje op elke ferbining mei it knooppunt wêrop jo oanfallen kontrolearje wolle. Elke fabrikant sil fansels bliid wêze om jo hûnderten en tûzenen sensoren te ferkeapjen, mar ik tink dat jo budzjet sokke útjeften net stypje kin. Ik kin sizze dat sels by Cisco (en wy binne de ûntwikkelders fan NGIPS) kinne wy dit net dwaan, hoewol it liket dat it probleem fan priis foar ús is. Ik soe net stean moatte - it is ús eigen beslút. Boppedat, de fraach ûntstiet, hoe te ferbinen de sensor yn dizze ferzje? Yn it gat? Wat as de sensor sels mislearret? Fereaskje in bypass module yn de sensor? Splitters brûke (kraan)? Dit alles makket de oplossing djoerder en makket it ûnbetelber foar in bedriuw fan elke grutte.
Jo kinne besykje te "hingje" de sensor op in SPAN / RSPAN / ERSPAN haven en direkte ferkear fan de fereaske switch havens nei it. Dizze opsje ferwideret foar in part it probleem beskreaun yn 'e foarige paragraaf, mar stelt in oar - de SPAN-poarte kin net perfoarst al it ferkear akseptearje dat dernei sil wurde stjoerd - it sil net genôch bânbreedte hawwe. Jo sille wat opofferje moatte. Lit guon fan 'e knopen sûnder tafersjoch litte (dan moatte jo se earst prioritearje), of stjoer net alle ferkear fan' e node, mar allinich in bepaald type. Yn alle gefallen kinne wy wat oanfallen misse. Derneist kin de SPAN-poarte brûkt wurde foar oare behoeften. As gefolch dêrfan moatte wy de besteande netwurktopology besjen en mooglik oanpassingen meitsje om jo netwurk maksimaal te dekken mei it oantal sensoren dat jo hawwe (en dit koördinearje mei IT).
Wat as jo netwurk asymmetryske rûtes brûkt? Wat as jo SDN hawwe ymplementearre of fan plan binne te ymplementearjen? Wat as jo virtualisearre masines of konteners moatte kontrolearje wêrfan it ferkear de fysike skeakel hielendal net berikt? Dit binne fragen dy't tradisjonele IDS-ferkeapers net leuk fine, om't se net witte hoe't se se moatte beantwurdzje. Miskien sille se jo oertsjûgje dat al dizze modieuze technologyen hype binne en jo it net nedich hawwe. Miskien sille se prate oer de needsaak om lyts te begjinnen. Of miskien sille se sizze dat jo in krêftige thresher yn it sintrum fan it netwurk moatte pleatse en alle ferkear dernei rjochtsje mei help fan balancers. Hokker opsje wurdt oanbean oan jo, jo moatte dúdlik begripe hoe't it by jo past. En pas dêrnei meitsje in beslút oer it kiezen fan in oanpak foar it kontrolearjen fan de ynformaasjefeiligens fan 'e netwurkynfrastruktuer. Werom nei pakketfangen, wol ik sizze dat dizze metoade tige populêr en wichtich bliuwt, mar har haaddoel is grinskontrôle; grinzen tusken jo organisaasje en it ynternet, grinzen tusken it datasintrum en de rest fan it netwurk, grinzen tusken it proses kontrôle systeem en it bedriuwssegment. Op dizze plakken hawwe klassike IDS/IPS noch altyd besteansrjocht en goed omgean mei har taken.
Litte wy nei de twadde opsje gean. Analyse fan eveneminten dy't komme fan netwurkapparaten kinne ek brûkt wurde foar doelen foar oanfaldeteksje, mar net as it haadmeganisme, om't it allinich in lytse klasse fan ynbraken kin opspoare. Derneist is it inherent oan guon reaktiviteit - de oanfal moat earst foarkomme, dan moat it opnommen wurde troch in netwurkapparaat, dat op ien of oare manier in probleem mei ynformaasjefeiligens sil sinjalearje. D'r binne ferskate sokke manieren. Dit kin syslog, RMON of SNMP wêze. De lêste twa protokollen foar netwurkmonitoring yn 'e kontekst fan ynformaasjefeiligens wurde allinich brûkt as wy in DoS-oanfal op' e netwurkapparatuer sels moatte ûntdekke, om't it brûken fan RMON en SNMP bygelyks mooglik is om de lading op 'e sintrale apparaat te kontrolearjen. prosessor of syn ynterfaces. Dit is ien fan 'e "goedkeapste" (elkenien hat syslog as SNMP), mar ek de meast yneffektive fan alle metoaden om de ynformaasjefeiligens fan ynterne ynfrastruktuer te kontrolearjen - in protte oanfallen binne der gewoan ferburgen fan. Fansels moatte se net ferwaarleazge wurde, en deselde syslog-analyse helpt jo wizigingen yn 'e konfiguraasje fan it apparaat sels te identifisearjen, it kompromis dêrfan, mar it is net heul geskikt foar it opspoaren fan oanfallen op it heule netwurk.
De tredde opsje is om ynformaasje te analysearjen oer ferkear dat troch in apparaat giet dat ien fan ferskate streamprotokollen stipet. Yn dit gefal, nettsjinsteande it protokol, bestiet de threading-ynfrastruktuer needsaaklik út trije komponinten:
- Generaasje of eksport fan stream. Dizze rol wurdt meastentiids tawiisd oan in router, switch of in oar netwurkapparaat, dat, troch it trochjaan fan netwurkferkear troch himsels, jo wichtige parameters derút kinne ekstrahearje, dy't dan nei de kolleksjemodule wurde oerdroegen. Bygelyks, Cisco stipet it Netflow-protokol net allinich op routers en skeakels, ynklusyf firtuele en yndustriële, mar ek op draadloze controllers, firewalls en sels servers.
- Samling flow. Yn betinken nommen dat in moderne netwurk meastentiids mear as ien netwurkapparaat hat, ûntstiet it probleem fan it sammeljen en konsolidearjen fan streamen, dat wurdt oplost mei saneamde samlers, dy't de ûntfongen streamen ferwurkje en dan foar analyse oerjaan.
- Flow analyze De analysator nimt de wichtichste yntellektuele taak op en, mei it tapassen fan ferskate algoritmen op streamen, lûkt bepaalde konklúzjes. Bygelyks, as ûnderdiel fan in IT-funksje, kin sa'n analysator netwurkknelpunten identifisearje of it ferkearsloadprofyl analysearje foar fierdere netwurkoptimalisaasje. En foar ynformaasjefeiligens kin sa'n analysator gegevenslekken, de fersprieding fan kweade koade of DoS-oanfallen detektearje.
Tink net dat dizze trije-tier-arsjitektuer te yngewikkeld is - alle oare opsjes (útsein, miskien, netwurkmonitorsystemen dy't wurkje mei SNMP en RMON) wurkje der ek neffens. Wy hawwe in gegevensgenerator foar analyse, dat kin in netwurkapparaat as in standalone sensor wêze. Wy hawwe in alarmopfangsysteem en in behearsysteem foar de hiele tafersjochynfrastruktuer. De lêste twa komponinten kinne wurde kombinearre binnen ien knooppunt, mar yn min of mear grutte netwurken binne se meastal ferspraat oer op syn minst twa apparaten om te soargjen scalability en betrouberens.
Oars as pakketanalyse, dy't basearre is op it bestudearjen fan de koptekst en lichemsgegevens fan elk pakket en de sesjes dêr't it út bestiet, is streamanalyse basearre op it sammeljen fan metadata oer netwurkferkear. Wannear, hoefolle, fan wêr en wêr, hoe ... dit binne de fragen beantwurde troch de analyze fan netwurktelemetry mei ferskate streamprotokollen. Yn it earstoan waarden se brûkt om statistiken te analysearjen en IT-problemen op it netwurk te finen, mar doe, as analytyske meganismen ûntwikkele, waard it mooglik om se op deselde telemetry foar feiligensdoelen te brûken. It is opnij de muoite wurdich op te merken dat streamanalyse gjin pakketfangen ferfangt of ferfangt. Elk fan dizze metoaden hat in eigen gebiet fan tapassing. Mar yn 'e kontekst fan dit artikel is it streamanalyse dy't it bêste geskikt is foar it kontrolearjen fan ynterne ynfrastruktuer. Jo hawwe netwurk apparaten (oft se wurkje yn in software-definiearre paradigma of neffens statyske regels) dat in oanfal kin net omgean. It kin in klassike IDS-sensor omgean, mar in netwurkapparaat dat it streamprotokol stipet kin net. Dit is it foardiel fan dizze metoade.
Oan 'e oare kant, as jo bewiis nedich hawwe foar wet hanthavenjen of jo eigen ynsidintûndersyksteam, kinne jo net sûnder pakket capture - netwurktelemetry is gjin kopy fan ferkear dat kin brûkt wurde om bewiis te sammeljen; it is nedich foar rappe detectie en beslútfoarming op it mêd fan ynformaasjefeiligens. Oan 'e oare kant, mei help fan telemetry-analyze, kinne jo net alle netwurkferkear "skriuwe" (as der wat, Cisco docht mei datasintra :-), mar allinich dat wat belutsen is by de oanfal. Telemetry-analyze-ark yn dit ferbân sille tradisjonele pakketfangmeganismen goed oanfolje, en jouwe kommando's foar selektyf fangen en opslach. Oars moatte jo in kolossale opslachynfrastruktuer hawwe.
Litte wy ús in netwurk foarstelle dat wurket mei in snelheid fan 250 Mbit / sek. As jo al dit folume wolle opslaan, dan sille jo 31 MB opslach nedich hawwe foar ien sekonde fan ferkearstransmission, 1,8 GB foar ien minút, 108 GB foar ien oere, en 2,6 TB foar ien dei. Om deistige gegevens op te slaan fan in netwurk mei in bânbreedte fan 10 Gbit / s, sille jo 108 TB opslach nedich hawwe. Mar guon tafersjochhâlders fereaskje it opslaan fan befeiligingsgegevens jierrenlang ... Opname op oanfraach, dy't streamanalyse jo helpt te ymplementearjen, helpt dizze wearden te ferminderjen troch oarders fan grutte. Trouwens, as wy prate oer de ferhâlding fan it folume fan opnommen netwurktelemetrygegevens en folsleine gegevensopfang, dan is it sawat 1 oant 500. Foar deselde wearden dy't hjirboppe jûn wurde, it opslaan fan in folslein transkripsje fan alle deistige ferkear sil respektivelik 5 en 216 GB wêze (jo kinne it sels opnimme op in gewoane flash drive).
As foar ark foar it analysearjen fan rau netwurkgegevens, de metoade foar it fêstlizzen is hast itselde fan ferkeaper nei ferkeaper, dan is yn it gefal fan streamanalyse de situaasje oars. D'r binne ferskate opsjes foar streamprotokollen, de ferskillen wêryn jo moatte witte oer yn 'e kontekst fan feiligens. It populêrste is it Netflow-protokol ûntwikkele troch Cisco. D'r binne ferskate ferzjes fan dit protokol, ferskillend yn har mooglikheden en it bedrach fan opnommen ferkearynformaasje. De hjoeddeistige ferzje is de njoggende (Netflow v9), op basis wêrfan de yndustrystandert Netflow v10, ek bekend as IPFIX, waard ûntwikkele. Tsjintwurdich stypje de measte netwurkferkeapers Netflow as IPFIX yn har apparatuer. Mar d'r binne ferskate oare opsjes foar streamprotokollen - sFlow, jFlow, cFlow, rFlow, NetStream, ensfh., wêrfan sFlow de populêrste is. It is dit type dat wurdt meast faak stipe troch ynlânske fabrikanten fan netwurk apparatuer fanwege it gemak fan útfiering. Wat binne de wichtichste ferskillen tusken Netflow, dy't in de facto standert wurden is, en sFlow? Ik soe ferskate kaaien markearje. Earst hat Netflow brûker-oanpasbere fjilden yn tsjinstelling ta de fêste fjilden yn sFlow. En twadde, en dit is it wichtichste ding yn ús gefal, sammelet sFlow saneamde sampled telemetry; yn tsjinstelling ta de unsamplede foar Netflow en IPFIX. Wat is it ferskil tusken harren?
Stel jo foar dat jo beslute om it boek te lêzen "” fan myn kollega's - Gary McIntyre, Joseph Munitz en Nadem Alfardan (jo kinne in diel fan it boek downloade fan 'e keppeling). Jo hawwe trije opsjes om jo doel te berikken - lês it heule boek, blêdzje der troch, stopje op elke 10e of 20e side, of besykje in werhelling fan wichtige begripen te finen op in blog of tsjinst lykas SmartReading. Dat, unsamplede telemetry is it lêzen fan elke "pagina" fan netwurkferkear, dat is it analysearjen fan metadata foar elk pakket. Sampled telemetry is de selektive stúdzje fan ferkear yn 'e hope dat de selekteare samples sille befetsje wat jo nedich binne. Ofhinklik fan 'e kanaalsnelheid sil samplede telemetry elk 64e, 200e, 500e, 1000e, 2000e of sels 10000e pakket stjoerd wurde foar analyse.
Yn 'e kontekst fan monitoaring fan ynformaasjefeiligens betsjut dit dat sampled telemetry goed geskikt is foar it opspoaren fan DDoS-oanfallen, scannen en fersprieden fan kweade koade, mar kinne atomyske of multi-pakket oanfallen misse dy't net opnommen binne yn' e stekproef dy't stjoerd is foar analyse. Unsample telemetry hat gjin sokke neidielen. Hjirmei is it berik fan ûntdutsen oanfallen folle breder. Hjir is in koarte list mei eveneminten dy't kinne wurde ûntdutsen mei helpmiddels foar analyse fan netwurktelemetry.
Fansels sil guon iepen boarne Netflow-analyzer jo dit net tastean, om't har haadtaak is om telemetry te sammeljen en basisanalyse derop út te fieren út in IT-perspektyf. Om ynformaasjefeiligensbedrigingen te identifisearjen basearre op stream, is it nedich om de analysator út te rusten mei ferskate motoren en algoritmen, dy't cyberfeiligensproblemen sille identifisearje op basis fan standert as oanpaste Netflow-fjilden, standertgegevens ferrykje mei eksterne gegevens fan ferskate Threat Intelligence-boarnen, ensfh.
Dêrom, as jo in kar hawwe, kies dan Netflow of IPFIX. Mar sels as jo apparatuer allinnich wurket mei sFlow, lykas ynlânske fabrikanten, dan sels yn dit gefal kinne jo profitearje fan it yn in feiligens kontekst.
Yn 'e simmer fan 2019 analysearre ik de mooglikheden dy't Russyske fabrikanten fan netwurkhardware hawwe en allegear, útsein NSG, Polygon en Craftway, kundige stipe oan foar sFlow (op syn minst Zelax, Natex, Eltex, QTech, Rusteleteh).
De folgjende fraach dy't jo sille tsjinkomme is wêr't jo streamstipe kinne ymplementearje foar feiligensdoelen? Yn feite is de fraach net hielendal korrekt steld. Moderne apparatuer stipet hast altyd streamprotokollen. Dêrom soe ik de fraach oars formulearje - wêr is it it meast effektyf om telemetry te sammeljen út in feiligenspunt? It antwurd sil frij dúdlik wêze - op it tagongsnivo, wêr't jo 100% fan alle ferkear sille sjen, wêr't jo detaillearre ynformaasje hawwe oer hosts (MAC, VLAN, ynterface-ID), wêr't jo sels P2P-ferkear kinne kontrolearje tusken hosts, wat is kritysk foar skennen detectie en distribúsje fan kweade koade. Op it kearnnivo kinne jo gewoan wat fan it ferkear net sjen, mar op it perimeternivo sille jo in kwart fan al jo netwurkferkear sjen. Mar as jo om ien of oare reden bûtenlânske apparaten op jo netwurk hawwe dy't oanfallers tastean om "yn te gean en út te gean" sûnder de perimeter te omgean, dan sil it analysearjen fan de telemetry derfan jo neat jaan. Dêrom, foar maksimale dekking, wurdt it oanrikkemandearre om telemetry-kolleksje yn te skeakeljen op it tagongsnivo. Tagelyk is it de muoite wurdich op te merken dat sels as wy it hawwe oer virtualisaasje as konteners, wurdt streamstipe ek faak fûn yn moderne firtuele skeakels, wêrtroch jo it ferkear dêr ek kinne kontrolearje.
Mar om't ik it ûnderwerp opbrocht, moat ik de fraach beäntwurdzje: wat as de apparatuer, fysyk as firtueel, gjin streamprotokollen stipet? Of is it opnimmen ferbean (bygelyks yn yndustriële segminten om betrouberens te garandearjen)? Of liedt it ynskeakeljen ta hege CPU-load (dit bart op âldere hardware)? Om dit probleem op te lossen binne d'r spesjalisearre firtuele sensoren (flowsensors), dy't yn wêzen gewoane splitters binne dy't ferkear troch harsels passe en it yn 'e foarm fan stream útstjoere nei de kolleksjemodule. Wier, yn dit gefal krije wy alle problemen wêr't wy hjirboppe oer praat hawwe yn ferbân mei ark foar pakketfanger. Dat is, jo moatte net allinich de foardielen fan streamanalysetechnology begripe, mar ek har beheiningen.
In oar punt dat wichtich is om te ûnthâlden as jo prate oer ark foar flowanalyse. As yn relaasje ta konvinsjonele middels foar it generearjen fan befeiligingseveneminten wy de EPS-metrik brûke (evenemint per sekonde), dan is dizze yndikator net fan tapassing foar telemetry-analyze; it wurdt ferfongen troch FPS (flow per sekonde). Lykas yn it gefal fan EPS, kin it net fan tefoaren berekkene wurde, mar jo kinne it ûngefear oantal triedden skatte dat in bepaald apparaat generearret ôfhinklik fan syn taak. Jo kinne tabellen op it ynternet fine mei sawat wearden foar ferskate soarten ûndernimmingsapparaten en betingsten, wêrtroch jo kinne skatte hokker lisinsjes jo nedich binne foar analyse-ark en wat har arsjitektuer sil wêze? It feit is dat de IDS sensor wurdt beheind troch in bepaalde bânbreedte dat it kin "lûke", en de flow samler hat syn eigen beheinings dy't moatte wurde begrepen. Dêrom binne yn grutte, geografysk ferspraat netwurken meastentiids ferskate samlers. Doe't ik beskreaun , Ik haw it oantal fan ús samlers al jûn - d'r binne 21. En dit is foar in netwurk ferspraat oer fiif kontininten en nûmere sawat in heal miljoen aktive apparaten).
Wy brûke ús eigen oplossing as Netflow-monitorsysteem , dy't spesifyk rjochte is op it oplossen fan feiligensproblemen. It hat in protte ynboude motoren foar it opspoaren fan abnormale, fertochte en dúdlik kweade aktiviteit, wêrtroch jo in breed oanbod fan ferskate bedrigingen kinne ûntdekke - fan kryptominearjen oant ynformaasjelekken, fan 'e fersprieding fan kweade koade oant fraude. Lykas de measte flow analyzers, Stealthwatch is boud neffens in trije-nivo skema (generator - samler - analysator), mar it wurdt oanfolle mei in oantal nijsgjirrige funksjes dy't wichtich binne yn 'e kontekst fan it materiaal ûnder behanneling. Earst, it yntegrearret mei pakket capture oplossings (lykas Cisco Security Packet Analyzer), wêrmei jo te nimmen selektearre netwurk sesjes foar letter yngeande ûndersyk en analyze. As twadde, spesifyk om feiligenstaken út te wreidzjen, hawwe wy in spesjale nvzFlow-protokol ûntwikkele, wêrtroch jo de aktiviteit fan tapassingen op einknooppunten (tsjinners, wurkstasjons, ensfh.) kinne "útstjoere" yn telemetry en stjoere it nei de samler foar fierdere analyze. As yn syn oarspronklike ferzje Stealthwatch wurket mei elk streamprotokol (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) op it netwurknivo, dan lit nvzFlow-stipe gegevenskorrelaasje ek op it knooppuntnivo, dêrmei. it fergrutsjen fan de effisjinsje fan it hiele systeem en sjogge mear oanfallen as konvinsjonele netwurk flow analysatoren.
It is dúdlik dat as it praat oer Netflow-analysesystemen út in feiligenspunt, de merk net beheind is ta ien oplossing fan Cisco. Jo kinne sawol kommersjele as fergese as shareware-oplossingen brûke. It is heul nuver as ik oplossings fan konkurrinten as foarbylden neame op it Cisco-blog, dus ik sil in pear wurden sizze oer hoe't netwurktelemetry kin wurde analysearre mei twa populêre, ferlykbere nammen, mar dochs ferskillende ark - SiLK en ELK.
SiLK is in set ark (it systeem foar kennis op ynternetnivo) foar ferkearsanalyse, ûntwikkele troch de Amerikaanske CERT/CC en dy't stipet, yn 'e kontekst fan it hjoeddeiske artikel, Netflow (5e en 9e, de populêrste ferzjes), IPFIX en sFlow en it brûken fan ferskate nutsbedriuwen (rwfilter, rwcount, rwflowpack, ensfh.) Mar d'r binne in pear wichtige punten om te notearjen. SiLK is in kommandorigelark dat online analyse útfiert troch kommando's lykas dit yn te fieren (deteksje fan ICMP-pakketten grutter dan 200 bytes):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
net hiel noflik. Jo kinne de iSiLK GUI brûke, mar it sil jo libben net folle makliker meitsje, allinich de fisualisaasjefunksje oplosse en de analist net ferfange. En dit is it twadde punt. Oars as kommersjele oplossingen, dy't al in solide analytyske basis hawwe, anomalydeteksjealgoritmen, oerienkommende workflow, ensfh., Yn it gefal fan SiLK sille jo dit alles sels moatte dwaan, wat fan jo wat oare kompetinsjes sil fereaskje as fan it brûken fan al klear- ark te brûken. Dit is net goed noch min - dit is in eigenskip fan hast alle fergese ark dat derfan útgiet dat jo witte wat te dwaan, en it sil jo allinich helpe mei dit (kommersjele ark binne minder ôfhinklik fan 'e kompetinsjes fan har brûkers, hoewol se ek oannimme dat analysten op syn minst de basis fan netwurkûndersiken en tafersjoch begripe). Mar litte wy weromgean nei SiLK. De wurksyklus fan de analist dêrmei sjocht der sa út:
- Formulearjen fan in hypoteze. Wy moatte begripe wat wy sille sykje binnen netwurk telemetry, kenne de unike attributen wêrmei wy sille identifisearje bepaalde anomalies of bedrigings.
- Bouwe in model. Nei't wy in hypoteze hawwe formulearre, programmearje wy it mei deselde Python, shell of oare ark net opnommen yn SiLK.
- Testen. No komt de beurt om de krektens fan ús hypoteze te kontrolearjen, dy't wurdt befêstige of wjerlein mei help fan SiLK-hulpprogramma's begjinnend mei 'rw', 'set', 'bag'.
- Analyse fan echte gegevens. Yn yndustriële operaasje helpt SiLK ús wat te identifisearjen en de analist moat de fragen beantwurdzje "Hawwe wy fûn wat wy ferwachte?", "Komt dit oerien mei ús hypoteze?", "Hoe kinne jo it oantal falske positiven ferminderje?", "Hoe it nivo fan erkenning ferbetterje? » ensafuorthinne.
- Ferbettering. Yn it lêste stadium ferbetterje wy wat earder dien is - wy meitsje sjabloanen, ferbetterje en optimalisearje de koade, herformulearje en ferdúdlikje de hypoteze, ensfh.
Dizze syklus sil ek fan tapassing wêze op Cisco Stealthwatch, allinich de lêste automatisearret dizze fiif stappen nei it maksimum, it ferminderjen fan it oantal analystflaters en it fergrutsjen fan de effisjinsje fan ynsidintdeteksje. Bygelyks, yn SiLK kinne jo netwurkstatistiken ferrykje mei eksterne gegevens oer kweade IP's mei help fan hânskreaune skripts, en yn Cisco Stealthwatch is it in ynboude funksje dy't fuortendaliks in alaarm toant as netwurkferkear ynteraksjes mei IP-adressen fan 'e swarte list befettet.
As jo heger geane yn 'e "betelle" piramide foar software foar streamanalyse, dan sil d'r nei de absolút fergese SiLK in shareware ELK wêze, besteande út trije wichtige komponinten - Elasticsearch (yndeksearje, sykjen en gegevensanalyse), Logstash (gegevensynfier / útfier ) en Kibana (fisualisaasje). Oars as SiLK, wêr't jo alles sels skriuwe moatte, hat ELK al in protte klearmakke biblioteken / modules (guon betelle, guon net) dy't de analyze fan netwurktelemetry automatisearje. Bygelyks, it GeoIP-filter yn Logstash lit jo kontrolearre IP-adressen assosjearje mei har geografyske lokaasje (Stealthwatch hat dizze ynboude funksje).
ELK hat ek in frij grutte mienskip dy't de ûntbrekkende komponinten foltôget foar dizze tafersjochoplossing. Om bygelyks te wurkjen mei Netflow, IPFIX en sFlow kinne jo de module brûke , as jo net tefreden binne mei de Logstash Netflow Module, dy't allinich Netflow stipet.
Wylst it mear effisjinsje jout by it sammeljen fan stream en it sykjen dêryn, mist ELK op it stuit rike ynboude analytiken foar it opspoaren fan anomalies en bedrigingen yn netwurktelemetry. Dat is, nei de hjirboppe beskreaune libbenssyklus, moatte jo selsstannich oertredingsmodellen beskriuwe en it dan brûke yn it fjochtsysteem (d'r binne gjin ynboude modellen).
D'r binne fansels mear ferfine tafoegings foar ELK, dy't al inkele modellen befetsje foar it opspoaren fan anomalies yn netwurktelemetry, mar sokke tafoegings kostje jild en hjir is de fraach oft it spultsje de kears wurdich is - skriuw sels in ferlykber model, keapje har ymplemintaasje foar jo monitoring ark, of keapje klearebare oplossing fan de Network Traffic Analysis klasse.
Yn 't algemien wol ik net yn it debat komme dat it better is om jild te besteegjen en in klearmakke oplossing te keapjen foar it kontrolearjen fan anomalies en bedrigingen yn netwurktelemetry (bygelyks Cisco Stealthwatch) of sels útfine en itselde oanpasse SiLK, ELK of nfdump of OSU Flow Tools foar elke nije bedriging (ik ha it oer de lêste twa fan har lêste kear)? Elkenien kiest foar harsels en elkenien hat har eigen motiven om ien fan 'e twa opsjes te kiezen. Ik woe gewoan sjen litte dat netwurktelemetry in heul wichtich ark is om de netwurkfeiligens fan jo ynterne ynfrastruktuer te garandearjen en jo moatte it net ferwaarleazje, om net mei te dwaan oan 'e list fan bedriuwen waans namme wurdt neamd yn' e media tegearre mei de epithets " hacked", "net yn oerienstimming mei easken foar ynformaasjefeiligens" ", "net tinke oer de feiligens fan har gegevens en klantgegevens."
Om gearfetsje, wol ik de kaai tips listje dy't jo moatte folgje by it bouwen fan tafersjoch op ynformaasjefeiligens fan jo ynterne ynfrastruktuer:
- Beheine josels net allinich ta de perimeter! Brûk (en kies) netwurkynfrastruktuer net allinich om ferkear fan punt A nei punt B te ferpleatsen, mar ek om problemen mei cyberfeiligens oan te pakken.
- Studearje de besteande meganismen foar monitoaring fan ynformaasjefeiligens yn jo netwurkapparatuer en brûk se.
- Foar ynterne tafersjoch, jouwe foarkar oan telemetry-analyze - it lit jo maksimaal 80-90% fan alle ynsidinten foar feiligens fan netwurkynformaasje detektearje, wylst jo dwaan wat ûnmooglik is by it fêstlizzen fan netwurkpakketten en romte besparje foar it bewarjen fan alle eveneminten foar ynformaasjefeiligens.
- Om streamen te kontrolearjen, brûk Netflow v9 as IPFIX - se jouwe mear ynformaasje yn in feiligenskontekst en kinne jo net allinich IPv4, mar ek IPv6, MPLS, ensfh.
- Brûk in unsampled streamprotokol - it leveret mear ynformaasje foar it opspoaren fan bedrigingen. Bygelyks, Netflow of IPFIX.
- Kontrolearje de lading op jo netwurkapparatuer - it kin miskien it streamprotokol ek net behannelje. Beskôgje dan it brûken fan firtuele sensoren as Netflow Generation Appliance.
- Implementearje kontrôle earst fan alles op it tagongsnivo - dit sil jo de kâns jaan om 100% fan alle ferkear te sjen.
- As jo gjin kar hawwe en jo brûke Russyske netwurkapparatuer, kies dan ien dy't streamprotokollen stipet of SPAN/RSPAN-poarten hat.
- Kombinearje ynbraak- / oanfaldeteksje- / previnsjesystemen oan 'e rânen en streamanalysesystemen yn it ynterne netwurk (ynklusyf yn' e wolken).
Oangeande de lêste tip wol ik in yllustraasje jaan dy't ik al earder jûn haw. Jo sjogge dat as earder de Cisco-ynformaasjebefeiligingstsjinst hast folslein har kontrôlesysteem foar ynformaasjefeiligens boude op basis fan systemen foar ynbraakdeteksje en hantekeningmetoaden, no binne se mar 20% fan ynsidinten. In oare 20% falt op streamanalysesystemen, wat suggerearret dat dizze oplossingen gjin wille binne, mar in echte ark yn 'e aktiviteiten fan tsjinsten foar ynformaasjefeiligens fan in moderne ûndernimming. Boppedat hawwe jo it wichtichste ding foar har ymplemintaasje - netwurkynfrastruktuer, ynvestearrings wêryn't fierder kinne wurde beskerme troch it tawizen fan funksjes foar tafersjoch fan ynformaasjefeiligens oan it netwurk.
Ik spesifyk net oanreitsje op it ûnderwerp fan reagearjen op anomalies of bedrigingen identifisearre yn netwurk streamen, mar ik tink dat it is al dúdlik dat tafersjoch moat net einigje allinnich mei de detectie fan in bedriging. It moat wurde folge troch in antwurd en leafst yn in automatyske of automatyske modus. Mar dit is in ûnderwerp foar in apart artikel.
Oanfoljende ynformaasje:
PS. As it foar jo makliker is om alles te hearren dat hjirboppe skreaun is, dan kinne jo de oerenlange presintaasje besjen dy't de basis fan dizze notysje foarme.
Boarne: www.habr.com