Barne korporazio edo saileko sare baten segurtasuna monitorizatzeko orduan, askok informazio ihesak kontrolatzearekin eta DLP irtenbideak ezartzearekin lotzen dute. Eta galdera argitzen saiatzen bazara eta barne-sarean erasoak nola detektatzen dituzun galdetzen baduzu, erantzuna, normalean, intrusioak detektatzeko sistemen (IDS) aipamena izango da. Eta duela 10-20 urte aukera bakarra zena anakronismo bihurtzen ari da gaur. Barne sare bat monitorizatzeko aukera eraginkorragoa, eta leku batzuetan, posible bakarra dago - fluxu-protokoloak erabiltzea, jatorriz sareko arazoak bilatzeko diseinatuta zeudenak (arazoak konpontzeko), baina denborarekin segurtasun-tresna oso interesgarri bihurtuz. Zer fluxu-protokolo dauden eta sareko erasoak detektatzeko hobeak zein diren hitz egingo dugu, non hobe den fluxuen monitorizazioa ezartzea, zer bilatu behar den eskema hori zabaltzean eta baita hori guztia etxeko ekipoetan nola "altxatu" ere. artikulu honen esparruan.
Ez naiz luzatuko "Zergatik beharrezkoa da barne azpiegituren segurtasunaren monitorizazioa?" Erantzuna argia dela dirudi. Baina, hala ere, berriro ziurtatu nahi baduzu gaur ezin zarela hura gabe bizi, Suebaki batek babestutako sare korporatibo batean 17 modutan sar zaitezkeen bideo laburra. Horregatik, ulertuko dugu barne-jarraipena beharrezkoa dela eta nola antola daitekeen ulertzea besterik ez dela geratzen.
Hiru datu-iturri nagusi nabarmenduko nituzke sare mailan azpiegiturak monitorizatzeko:
- Trafiko "gordina" harrapatzen eta analisi-sistema jakin batzuetara aztertzeko bidaltzen duguna,
- trafikoa igarotzen den sareko gailuetako gertaerak,
- fluxu-protokoloetako baten bidez jasotako trafiko-informazioa.
Trafiko gordina harrapatzea segurtasun espezialisten artean aukerarik ezagunena da, historikoki agertu zelako eta lehenengoa izan zelako. Sare-sarrerak detektatzeko ohiko sistemak (lehenengo merkataritza-sarrerak detektatzeko sistema izan zen Wheel Group-eko NetRanger, Cisco-k 1998an erosi zuena), hain zuzen ere sinadura batzuk bilatzen zituzten paketeetan (eta ondorengo saioetan) harrapatzen ari ziren ("arau erabakigarriak" FSTEC terminologia), erasoak seinaleztatzeko. Noski, trafiko gordina azter dezakezu IDS erabiliz ez ezik, beste tresna batzuk ere erabiliz (adibidez, Wireshark, tcpdum edo Cisco IOS-en NBAR2 funtzionaltasuna), baina normalean ez dute informazio-segurtasun tresna arrunt batetik bereizten duen ezagutza-baserik. informatika tresna.
Beraz, erasoak detektatzeko sistemak. Sare-erasoak detektatzeko metodorik zaharrena eta ezagunena, perimetroan lan ona egiten duena (ez dio axola - korporatiboa, datu-zentroa, segmentua, etab.), baina huts egiten duen sare kommutazio modernoetan eta softwarez definitutako sareetan. Ohiko etengailuetan oinarrituta eraikitako sare baten kasuan, erasoak detektatzeko sentsoreen azpiegitura handiegia bihurtzen da - erasoak kontrolatu nahi dituzun nodoko konexio bakoitzean sentsore bat instalatu beharko duzu. Edozein fabrikatzaileak, noski, pozik salduko ditu ehunka eta milaka sentsore, baina uste dut zure aurrekontuak ezin dituela horrelako gastuak onartu. Esan dezaket Cisco-n ere (eta NGIPSen garatzaileak gara) ezin genuela hori egin, nahiz eta badirudi prezioaren gaia gure aurrean dagoela. Ez nuke jasan behar - gure erabakia da. Horrez gain, galdera sortzen da, nola konektatu sentsorea bertsio honetan? Hutsunean sartu? Zer gertatzen da sentsoreak berak huts egiten badu? Saihesbide-modulu bat behar al duzu sentsorean? Zatitzaileak erabili (sakatu)? Horrek guztiak konponbidea garestitzen du eta edozein tamainatako enpresarentzat erosezin bihurtzen da.
Saia zaitezke sentsorea SPAN/RSPAN/ERSPAN ataka batean "zintzilikatzen" eta trafikoa behar diren etengailu ataketatik bertara bideratzen. Aukera honek partzialki kentzen du aurreko paragrafoan deskribatutako arazoa, baina beste bat planteatzen du - SPAN atakak ezin du berari bidaliko zaion trafiko guztia onartu - ez du banda zabalera nahikorik izango. Zerbait sakrifikatu beharko duzu. Edo utzi nodo batzuk monitorizaziorik gabe (orduan lehentasuna eman behar diezu lehenik), edo ez bidali nodotik trafiko guztia, mota jakin bat baizik. Edonola ere, eraso batzuk galduko ditugu. Gainera, SPAN ataka beste beharretarako erabil daiteke. Ondorioz, lehendik dagoen sarearen topologia berrikusi beharko dugu eta, beharbada, egokitzapenak egin beharko ditugu zure sarea daukazun sentsore kopuruarekin (eta hori ITrekin koordinatu) ahalik eta gehien estaltzeko.
Zer gertatzen da zure sareak ibilbide asimetrikoak erabiltzen baditu? Zer gertatzen da SDN inplementatu baduzu edo ezartzeko asmoa baduzu? Zer gertatzen da birtualizatutako makinak edo edukiontziak kontrolatu behar badituzu, zeinen trafikoa etengailu fisikora batere iristen ez den? IDS saltzaile tradizionalei gustatzen ez zaizkien galderak dira, ez dakitelako nola erantzun. Agian konbentzituko zaituzte modan dauden teknologia horiek guztiak hype direla eta ez duzula behar. Agian txikitan hasi beharraz hitz egingo dute. Edo agian esango dute sarearen erdigunean thresher indartsu bat jarri behar duzula eta bertara bideratu trafiko guztia orekatzaileak erabiliz. Eskaintzen zaizun aukera edozein dela ere, argi ulertu behar duzu nola egokitzen zaizun. Eta horren ondoren soilik hartu sarearen azpiegituraren informazioaren segurtasuna kontrolatzeko ikuspegi bat aukeratzeko erabakia. Pakete harrapaketara itzuliz, esan nahi dut metodo honek oso ezaguna eta garrantzitsua izaten jarraitzen duela, baina bere helburu nagusia mugen kontrola dela; Zure erakundearen eta Interneten arteko mugak, datu-zentroaren eta gainerako sarearen arteko mugak, prozesuen kontrol sistemaren eta segmentu korporatiboaren arteko mugak. Leku horietan, IDS/IPS klasikoek oraindik ere existitzeko eta beren zereginei ondo aurre egiteko eskubidea dute.
Goazen bigarren aukerara. Sareko gailuetatik datozen gertaeren analisia erasoak hautemateko helburuetarako ere erabil daiteke, baina ez mekanismo nagusi gisa, intrusio-klase txiki bat baino ez detektatzeko aukera ematen baitu. Horrez gain, erreaktibotasun baten berezkoa da - erasoa gertatu behar da lehenik, gero sareko gailu batek grabatu behar du, eta horrek modu batean edo bestean informazioaren segurtasunarekin arazo bat adieraziko du. Horrelako hainbat modu daude. Hau syslog, RMON edo SNMP izan daiteke. Informazioaren segurtasunaren testuinguruan sare monitorizatzeko azken bi protokoloak sareko ekipoen aurkako DoS eraso bat detektatu behar badugu soilik erabiltzen dira, RMON eta SNMP erabiliz posible baita, adibidez, gailuaren zentralaren karga kontrolatzea. prozesadorea edo bere interfazeak. Hau "merkeenetakoa" da (denek dute syslog edo SNMP), baina baita barne azpiegituren informazioaren segurtasuna kontrolatzeko metodo guztien artean eraginkorrena ere - eraso asko ezkutatzen dira. Jakina, ez dira alde batera utzi behar, eta syslog-aren azterketa bera gailuaren konfigurazioan aldaketak garaiz identifikatzen laguntzen dizu, horren konpromezua, baina ez da oso egokia sare osoan erasoak detektatzeko.
Hirugarren aukera fluxu-protokoloetako bat onartzen duen gailu batetik igarotzen den trafikoari buruzko informazioa aztertzea da. Kasu honetan, protokoloa edozein dela ere, hari-azpiegiturak hiru osagai ditu nahitaez:
- Fluxua sortzea edo esportatzea. Rol hori bideratzaile, switch edo sareko beste gailu bati esleitzen zaio normalean, eta horrek, sareko trafikoa bertatik pasatuz, bertatik funtsezko parametroak ateratzeko aukera ematen du, eta ondoren bilketa-modulura igortzen dira. Esate baterako, Cisco-k Netflow protokoloa onartzen du bideratzaile eta kommutadoreetan ez ezik, birtualetan eta industrialetan barne, baita haririk gabeko kontrolagailuetan, suebakietan eta baita zerbitzarietan ere.
- Bilketa-fluxua. Sare moderno batek normalean sareko gailu bat baino gehiago izan ohi duela kontuan hartuta, fluxuak biltzeko eta finkatzeko arazoa sortzen da, kolektore deiturikoak erabiliz konpontzen dena, jasotako fluxuak prozesatzen dituztenak eta gero aztertzeko transmititzen dituztenak.
- Fluxuaren analisia Analizatzaileak bere gain hartzen du zeregin intelektual nagusia eta, korronteei hainbat algoritmo aplikatuz, zenbait ondorio ateratzen ditu. Esate baterako, IT funtzio baten zati gisa, analizatzaile batek sareko botilak identifikatu ditzake edo trafiko-kargaren profila aztertu dezake sarearen optimizazio gehiago lortzeko. Eta informazioaren segurtasunerako, analizatzaile horrek datuen ihesak, kode gaiztoen hedapena edo DoS erasoak detektatu ditzake.
Ez pentsa hiru mailatako arkitektura hori konplikatuegia denik - beste aukera guztiek (salbu, beharbada, SNMP eta RMONekin lan egiten duten sareko monitorizazio-sistemek) horren arabera funtzionatzen dute. Analisirako datu-sorgailu bat dugu, sareko gailu bat edo sentsore autonomo bat izan daitekeena. Alarmak biltzeko sistema eta monitorizazio azpiegitura osoaren kudeaketa sistema bat ditugu. Azken bi osagaiak nodo bakarrean konbina daitezke, baina sare gutxi-asko handietan gutxienez bi gailutan banatu ohi dira, eskalagarritasuna eta fidagarritasuna bermatzeko.
Paketeen analisia ez bezala, hau da, pakete bakoitzaren goiburuko eta gorputzeko datuak eta osatzen duten saioen azterketan oinarritzen dena, fluxuaren azterketa sareko trafikoari buruzko metadatuak biltzean oinarritzen da. Noiz, zenbat, nondik eta nondik, nola... hainbat fluxu-protokolo erabiliz sareko telemetriaren analisiak erantzun dituen galderak dira. Hasieran, estatistikak aztertzeko eta sarean informatika-arazoak aurkitzeko erabiltzen ziren, baina gero, mekanismo analitikoak garatu ahala, telemetria berean aplikatzea posible izan zen segurtasun helburuetarako. Aipatzekoa da berriro fluxuaren analisiak ez duela paketeen harrapaketa ordezkatzen edo ordezkatzen. Metodo horietako bakoitzak bere aplikazio eremua du. Baina artikulu honen testuinguruan, fluxu-analisia da barne-azpiegiturak kontrolatzeko egokiena dena. Sareko gailuak dituzu (softwareak definitutako paradigman edo arau estatikoen arabera funtzionatzen duten) eraso batek saihestu ezin dituenak. IDS sentsore klasiko bat saihestu dezake, baina fluxu-protokoloa onartzen duen sareko gailu batek ezin du. Hau da metodo honen abantaila.
Bestalde, legea betearazteko edo zure gertakariak ikertzeko talderako frogak behar badituzu, ezin duzu paketeen atzematerik gabe egin - sareko telemetria ez da frogak biltzeko erabil daitekeen trafikoaren kopia bat; beharrezkoa da informazio-segurtasunaren arloan azkar detektatzeko eta erabakiak hartzeko. Bestalde, telemetria-analisia erabiliz, sareko trafiko guztia ez "idatzi" dezakezu (baldin bada, Ciscok datu-zentroekin jorratzen du :-), erasoan parte hartzen duena baizik. Zentzu honetan telemetria aztertzeko tresnek paketeen harrapatzeko mekanismo tradizionalak ondo osatuko dituzte, harrapaketa eta biltegiratze selektiborako aginduak emanez. Bestela, biltegiratze azpiegitura izugarria izan beharko duzu.
Imajina dezagun sare bat 250 Mbit/seg-ko abiaduran funtzionatzen. Bolumen hori guztia gorde nahi baduzu, 31 MB biltegiratze beharko dituzu trafikoaren transmisioko segundo baterako, 1,8 GB minutu baterako, 108 GB ordubetez eta 2,6 TB egun baterako. 10 Gbit/s-ko banda-zabalera duen sare bateko eguneroko datuak gordetzeko, 108 TB-ko biltegiratzea beharko duzu. Baina erregulatzaile batzuek segurtasun-datuak urtez gordetzea eskatzen dute... Eskariaren araberako grabaketak, fluxu-analisiak ezartzen laguntzen dizunak, balio horiek magnitude-ordenaren arabera murrizten laguntzen du. Bide batez, grabatutako sareko telemetria-datuen bolumenaren eta datuen harrapaketa osoaren proportzioaz hitz egiten badugu, gutxi gorabehera 1etik 500era bitartekoa da. Goian emandako balio berdinetarako, eguneroko trafiko guztiaren transkripzio osoa gordetzea. 5 eta 216 GB izango dira, hurrenez hurren (flash drive arrunt batean ere graba dezakezu).
Sareko datu gordinak aztertzeko tresnetarako, harrapatzeko metodoa ia berdina bada saltzaile batetik bestera, orduan fluxuaren analisiaren kasuan egoera ezberdina da. Fluxu-protokoloetarako hainbat aukera daude, segurtasunaren testuinguruan ezagutu behar dituzun desberdintasunak. Ezagunena Ciscok garatutako Netflow protokoloa da. Protokolo honen hainbat bertsio daude, haien gaitasun eta erregistratutako trafiko-informazio kopurua desberdinak. Egungo bertsioa bederatzigarrena da (Netflow v9), eta horren arabera garatu zen industriako Netflow v10 estandarra, IPFIX izenez ere ezaguna. Gaur egun, sareko saltzaile gehienek Netflow edo IPFIX onartzen dute euren ekipoetan. Baina fluxu-protokoloetarako beste hainbat aukera daude: sFlow, jFlow, cFlow, rFlow, NetStream, etab., eta horietako sFlow da ezagunena. Sare-ekipoen etxeko fabrikatzaileek gehien onartzen duten mota hau da, inplementatzeko erraztasunagatik. Zeintzuk dira de facto estandar bihurtu den Netflow eta sFlow-en arteko desberdintasun nagusiak? Hainbat gako nabarmenduko nituzke. Lehenik eta behin, Netflow-ek erabiltzaileak pertsonaliza daitezkeen eremuak ditu sFlow-en finkatutako eremuen aldean. Eta bigarrenik, eta hori da gure kasuan garrantzitsuena, sFlow-ek lagintutako telemetria deritzona biltzen du; Netflow eta IPFIX-en lagintu gabekoaren aldean. Zein da haien arteko aldea?
Imajinatu liburua irakurtzea erabakitzen duzulaββ nire lankideen - Gary McIntyre, Joseph Munitz eta Nadem Alfardan (liburuaren zati bat deskarga dezakezu estekatik). Hiru aukera dituzu zure helburua lortzeko: irakurri liburu osoa, arakatu, 10. edo 20. orrialde guztietan gelditu, edo SmartReading bezalako blog edo zerbitzu batean funtsezko kontzeptuen berri ematen saiatu. Beraz, lagin gabeko telemetria sareko trafikoaren "orrialde" bakoitza irakurtzen ari da, hau da, pakete bakoitzaren metadatuak aztertzen. Sampled telemetria trafikoaren azterketa selektiboa da, hautatutako laginek behar duzuna edukiko dutelakoan. Kanalaren abiaduraren arabera, lagintutako telemetria bidaliko da analisirako 64., 200., 500., 1000., 2000. edo baita 10000. pakete bakoitzean.
Informazioaren segurtasunaren monitorizazioaren testuinguruan, horrek esan nahi du lagindako telemetria egokia dela DDoS erasoak detektatzeko, eskaneatzeko eta kode gaiztoa zabaltzeko, baina analisirako bidalitako laginean sartu ez ziren atomo edo pakete anitzeko erasoak galdu ditzakeela. Lagintu gabeko telemetriak ez du halako desabantailarik. Horrekin, detektatutako erasoen sorta askoz ere zabalagoa da. Hona hemen sareko telemetria aztertzeko tresnak erabiliz detekta daitezkeen gertaeren zerrenda laburra.
Jakina, kode irekiko Netflow analizatzaile batzuek ez dizute hori egiten utziko, bere zeregin nagusia telemetria biltzea eta oinarrizko analisiak egitea IT ikuspegitik. Fluxuan oinarritutako informazioaren segurtasun-mehatxuak identifikatzeko, beharrezkoa da analizatzailea hainbat motor eta algoritmoz hornitzea, eta horiek Netflow eremu estandar edo pertsonalizatuetan oinarrituta zibersegurtasun arazoak identifikatuko dituzte, datu estandarrak aberastuko dituzte Threat Intelligence iturri ezberdinetako kanpoko datuekin, etab.
Hori dela eta, aukera baduzu, aukeratu Netflow edo IPFIX. Baina zure ekipoak sFlow-ekin soilik funtzionatzen badu ere, etxeko fabrikatzaileek bezala, kasu honetan ere etekina atera dezakezu segurtasun testuinguruan.
2019ko udan, Errusiako sareko hardware fabrikatzaileek dituzten gaitasunak aztertu nituen eta horiek guztiek, NSG, Polygon eta Craftway izan ezik, sFlow-rako laguntza iragarri zuten (gutxienez Zelax, Natex, Eltex, QTech, Rusteleteh).
Aurrerago duzun hurrengo galdera hau da: non ezarri fluxu-laguntza segurtasun-helburuetarako? Izan ere, galdera ez da guztiz zuzen planteatzen. Ekipamendu modernoak ia beti fluxu-protokoloak onartzen ditu. Hori dela eta, galdera ezberdin birformulatuko nuke: non da eraginkorrena telemetria biltzea segurtasunaren ikuspuntutik? Erantzuna nahiko begi-bistakoa izango da: sarbide mailan, non trafiko guztiaren % 100 ikusiko duzu, non ostalariei buruzko informazio zehatza izango duzu (MAC, VLAN, interfazearen IDa), non ostalarien arteko P2P trafikoa kontrolatu dezakezun. funtsezkoa da kode gaiztoak detektatzeko eta banatzeko eskaneatzeko. Oinarrizko mailan, agian ez duzu trafikoaren zati bat ikusiko, baina perimetro mailan, zure sareko trafiko osoaren laurdena ikusiko duzu. Baina arrazoiren batengatik zure sarean erasotzaileei "sartu eta irteteko" aukera ematen dieten atzerriko gailuak badituzu perimetroa saihestu gabe, hortik telemetria aztertzeak ez dizu ezer emango. Hori dela eta, estaldurarik handiena lortzeko, sarbide mailan telemetria-bilketa gaitzea gomendatzen da. Aldi berean, azpimarratzekoa da birtualizazioaz edo edukiontziez ari bagara ere, fluxuaren euskarria ere askotan aurkitzen dela etengailu birtual modernoetan, eta horrek trafikoa bertan ere kontrolatzeko aukera ematen du.
Baina gaia planteatu dudanez, galderari erantzun behar diot: zer gertatzen da ekipamenduak, fisikoak edo birtualak, fluxu-protokoloak onartzen ez baditu? Edo debekatuta al dago sartzea (adibidez, industria-segmentuetan fidagarritasuna bermatzeko)? Edo aktibatzea PUZaren karga handia dakar (hau hardware zaharragoetan gertatzen da)? Arazo hori konpontzeko, sentsore birtual espezializatuak (fluxu-sentsoreak) daude, funtsean, trafikoa beraiek igarotzen duten eta bilketa-modulura fluxu moduan igortzen duten banatzaile arruntak dira. Egia da, kasu honetan paketeak harrapatzeko tresnei dagokienez goian aipatu ditugun arazo guztiak jasotzen ditugu. Hau da, fluxua aztertzeko teknologiaren abantailak ez ezik, bere mugak ere ulertu behar dituzu.
Fluxua aztertzeko tresnei buruz hitz egitean gogoratu beharreko beste puntu bat. Segurtasun-gertaerak sortzeko ohiko bitartekoei dagokienez, EPS metrika erabiltzen badugu (gertaera segundoko), orduan adierazle hau ez da aplikagarria telemetria-analisirako; FPS-rekin (segundoko fluxua) ordezkatzen da. EPS-ren kasuan bezala, ezin da aldez aurretik kalkulatu, baina gailu jakin batek bere zereginaren arabera sortzen duen gutxi gorabeherako hari kopurua kalkula dezakezu. Interneten aurki ditzakezu enpresa gailu eta baldintza desberdinetarako gutxi gorabeherako balioak dituzten taulak, analisi tresnetarako zein lizentzia behar dituzun eta zein izango den haien arkitektura kalkulatzeko aukera emango dizutenak? Izan ere, IDS sentsoreak "erara dezakeen" banda-zabalera jakin batek mugatzen duela eta fluxu-kolektoreak ulertu beharreko mugak ditu. Horregatik, geografikoki banatutako sare handietan hainbat biltzaile egon ohi dira. Deskribatu nuenean , Dagoeneko eman dut gure bildumagileen kopurua - 21 dira. Eta hau bost kontinenteetan barreiatuta eta milioi erdi gailu aktibo inguru dituen sare batentzat da).
Gure irtenbide propioa erabiltzen dugu Netflow monitorizazio sistema gisa , bereziki segurtasun arazoak konpontzera bideratuta dagoena. Jarduera anomaloak, susmagarriak eta argi eta garbi gaiztoak detektatzeko motor asko ditu barneratuta, eta horri esker, askotariko mehatxuak detektatzeko aukera ematen dizu: kriptominatzetik informazio-filtrazioetara, kode gaiztoen hedapenetik iruzurreraino. Fluxu analizatzaile gehienak bezala, Stealthwatch hiru mailatako eskema baten arabera eraikitzen da (sorgailua - kolektorea - analizatzailea), baina kontuan hartzen den materialaren testuinguruan garrantzitsuak diren hainbat ezaugarri interesgarrirekin osatzen da. Lehenik eta behin, paketeen harrapatzeko soluzioekin integratzen da (adibidez, Cisco Security Packet Analyzer), hautatutako sareko saioak grabatzeko aukera emanez gero ikerketa eta azterketa sakonak egiteko. Bigarrenik, bereziki segurtasun-zereginak zabaltzeko, nvzFlow protokolo berezi bat garatu dugu, azken nodoetan (zerbitzariak, lan-estazioak, etab.) aplikazioen jarduera "igortzeko" telemetrian eta biltzaileari igortzeko aukera ematen duena, azterketa gehiago egin dezan. Jatorrizko bertsioan Stealthwatch-ek edozein fluxu-protokolorekin (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) funtzionatzen badu sare mailan, orduan nvzFlow laguntzak datu-korrelazioa ahalbidetzen du nodo mailan ere. sistema osoaren eraginkortasuna areagotuz eta ohiko sare-fluxuen analizagailuek baino eraso gehiago ikustea.
Argi dago segurtasunaren ikuspegitik Netflow analisi-sistemei buruz hitz egitean, merkatua ez dela Ciscoren soluzio bakarrera mugatzen. Irtenbide komertzialak zein doakoak edo partekatzaileak erabil ditzakezu. Nahiko arraroa da Cisco blogean lehiakideen soluzioak adibide gisa aipatzea, beraz, sareko telemetria nola aztertu daitekeen bi tresna ezagun, izenez antzeko baina oraindik desberdinak erabiliz: SiLK eta ELK, hitz batzuk esango ditut.
SiLK trafikoa aztertzeko tresna multzo bat da (Internet-Level Knowledge Sistema), CERT/CC estatubatuarrak garatua eta, gaurko artikuluaren testuinguruan, Netflow (5. eta 9., bertsio ezagunenak), IPFIX onartzen duena. eta sFlow eta hainbat utilitate erabiliz (rwfilter, rwcount, rwflowpack, etab.) sareko telemetriari buruzko hainbat eragiketa egiteko, bertan baimenik gabeko ekintzen zantzuak detektatzeko. Baina kontuan hartu beharreko pare bat puntu garrantzitsu daude. SiLK komando lerroko tresna bat da, lineako analisia egiten duena, honelako komandoak sartuz (200 byte baino handiagoak diren ICMP paketeen detekzioa):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ez oso erosoa. iSiLK GUI erabil dezakezu, baina ez dizu bizitza askoz erraztuko, bistaratzeko funtzioa konponduz eta analista ordezkatuz. Eta hau da bigarren puntua. Soluzio komertzialak ez bezala, dagoeneko oinarri analitiko sendoa dutenak, anomaliak detektatzeko algoritmoak, dagozkion lan-fluxua, etab., SiLK-en kasuan zuk zeuk egin beharko duzu hori guztia, eta horrek konpetentzia apur bat desberdinak eskatuko dizkizu lehendik prest erabiltzeko baino. tresnak erabiltzeko. Hau ez da ez ona ez txarra - zer egin behar den badakizula suposatzen duen doako tresnaren ezaugarri bat da, eta horretan bakarrik lagunduko dizu (tresn komertzialak erabiltzaileen gaitasunen menpe gutxiago daude, nahiz eta bere gain hartzen duten). analistek gutxienez sarearen ikerketen eta monitorizazioaren oinarriak ulertzen dituztela). Baina itzul gaitezen SiLKera. Hona hemen analistaren lan-zikloa:
- Hipotesi bat formulatzea. Sareko telemetriaren barruan zer bilatuko dugun ulertu behar dugu, zenbait anomalia edo mehatxu identifikatuko ditugun ezaugarri bereziak ezagutu.
- Eredu bat eraikitzea. Hipotesi bat formulatu ondoren, SiLK-n sartzen ez diren Python, shell edo beste tresna bera erabiliz programatzen dugu.
- Probak. Orain gure hipotesiaren zuzentasuna egiaztatzeko txanda dator, eta SiLK utilitateak erabiliz baieztatzen edo ezeztatzen da 'rw', 'set', 'bag'-ekin hasita.
- Datu errealen analisia. Eragiketa industrialean, SiLK-k zerbait identifikatzen laguntzen digu eta analistak galderei erantzun behar die: βEspero genuena aurkitu dugu?β, βBa al dago gure hipotesiarekin?β, βNola murriztu positibo faltsuen kopurua?β, βNolaβ. aitorpen maila hobetzeko?Β» eta abar.
- Hobekuntza. Azken fasean, lehen egindakoa hobetzen dugu: txantiloiak sortzen ditugu, kodea hobetu eta optimizatzen dugu, hipotesia birformulatu eta argitzen dugu, etab.
Ziklo hau Cisco Stealthwatch-i ere aplikagarria izango da, azkenak soilik bost urrats hauek automatizatzen ditu gehienez, analista-akatsen kopurua murriztuz eta gertakariak detektatzeko eraginkortasuna areagotuz. Esaterako, SiLK-n sare-estatistikak aberastu ditzakezu IP gaiztoen kanpoko datuekin eskuz idatzitako script-ak erabiliz, eta Cisco Stealthwatch-en alarma bat berehala bistaratzen duen funtzio integratua da, sareko trafikoak zerrenda beltzeko IP helbideekin interakzioak baditu.
Fluxuen analisirako softwarerako "ordainpeko" piramidean gorago joaten bazara, orduan erabat doako SiLKren ondoren shareware ELK bat egongo da, hiru osagai nagusiz osatua: Elasticsearch (indexatzea, bilaketa eta datuen analisia), Logstash (datuen sarrera/irteera). ) eta Kibana (bisualizazioa). SiLK-k ez bezala, non dena zuk zeuk idatzi behar duzun, ELK-k dagoeneko baditu prest egindako liburutegi/modulu asko (batzuk ordainduta, beste batzuk ez) sareko telemetriaren analisia automatizatzen dutenak. Esaterako, Logstash-eko GeoIP iragazkiak kontrolatutako IP helbideak beren kokapen geografikoarekin lotzeko aukera ematen du (Stealthwatch-ek funtzio integratua du).
ELK-k ere komunitate handi samarra du monitorizazio irtenbide honetarako falta diren osagaiak osatzen ari dena. Adibidez, Netflow, IPFIX eta sFlow-ekin lan egiteko modulua erabil dezakezu , Netflow soilik onartzen duen Logstash Netflow moduluarekin konforme ez bazaude.
Fluxua biltzeko eta bertan bilatzeko eraginkortasun handiagoa ematen badu ere, gaur egun ELK-k sareko telemetrian anomaliak eta mehatxuak detektatzeko analisi integratu aberatsak falta ditu. Hau da, goian deskribatutako bizi-zikloari jarraituz, modu independentean deskribatu beharko dituzu urraketa-ereduak eta, ondoren, borroka-sisteman erabili (ez dago integratutako eredurik bertan).
Badaude, noski, ELKrako luzapen sofistikatuagoak, sareko telemetrian anomaliak detektatzeko eredu batzuk dagoeneko dituztenak, baina luzapen horiek dirua balio dute eta hemen galdera da jokoak kandela merezi duen ala ez - idatzi antzeko eredu bat zuk zeuk, erosi bere zure monitorizazio tresnarako inplementazioa, edo erosi Sareko Trafikoaren Analisi klaseko irtenbide prest.
Orokorrean, ez dut eztabaidan sartu nahi hobe dela dirua gastatzea eta sareko telemetrian anomaliak eta mehatxuak monitorizatzeko prest dagoen irtenbide bat erostea (adibidez, Cisco Stealthwatch) edo zuk zeuk asmatu eta gauza bera pertsonalizatzea. SiLK, ELK edo nfdump edo OSU Flow Tools mehatxu berri bakoitzeko (azken biei buruz ari naiz Azken aldiz)? Bakoitzak bere kabuz aukeratzen du eta bakoitzak bere motiboak ditu bi aukeretako edozein aukeratzeko. Erakutsi nahi nuen sareko telemetria tresna oso garrantzitsua dela zure barne-azpiegituraren sareko segurtasuna bermatzeko eta ez duzula alde batera utzi behar, komunikabideetan izenak epitetoekin batera aipatzen diren enpresen zerrendan ez sartzeko ". pirateatu", "informazioaren segurtasun-baldintzak ez ditu betetzen" ", "ez dute beren datuen eta bezeroen datuen segurtasunean pentsatzen".
Laburbilduz, zure barne azpiegituraren informazioaren segurtasunaren monitorizazioa eraikitzean jarraitu behar dituzun aholku nagusiak zerrendatu nahiko nituzke:
- Ez zaitez bakarrik perimetrora mugatu! Erabili (eta aukeratu) sare-azpiegiturak trafikoa A puntutik B puntura eramateko ez ezik, zibersegurtasun arazoak konpontzeko ere.
- Aztertu zure sareko ekipoetan dauden informazioaren segurtasuna kontrolatzeko mekanismoak eta erabili.
- Barne monitorizaziorako, eman lehentasuna telemetria-analisiari - sareko informazioaren segurtasun-intzidentzia guztien % 80-90 arte detektatzeko aukera ematen du, sare-paketeak harrapatzen dituzunean ezinezkoa dena eginez eta informazio-segurtasun-gertaera guztiak gordetzeko tokia aurrezten duzun bitartean.
- Fluxuak kontrolatzeko, erabili Netflow v9 edo IPFIX - informazio gehiago ematen dute segurtasun testuinguruan eta IPv4 ez ezik, IPv6, MPLS eta abar kontrolatzeko aukera ematen dute.
- Erabili laginketarik gabeko fluxu-protokolo bat - mehatxuak detektatzeko informazio gehiago ematen du. Adibidez, Netflow edo IPFIX.
- Egiaztatu sareko ekipoaren karga - baliteke fluxu-protokoloa ere ezin izango duela kudeatu. Ondoren, kontuan hartu sentsore birtualak edo Netflow Generation Appliance erabiltzea.
- Ezarri kontrola lehenik sarbide mailan - honek trafiko guztiaren %100 ikusteko aukera emango dizu.
- Aukerarik ez baduzu eta Errusiako sareko ekipoak erabiltzen ari bazara, aukeratu fluxu-protokoloak onartzen dituen edo SPAN/RSPAN atakak dituen bat.
- Konbinatu intrusioa/erasoa detektatzeko/prebentzio-sistemak ertzetan eta fluxuen analisi-sistemak barne sarean (hodeietan barne).
Azken aholkuari dagokionez, aurretik eman dudan ilustrazio bat eman nahiko nuke. Ikusten duzu lehen Cisco informazio-segurtasun zerbitzuak ia osorik bere informazioaren segurtasuna kontrolatzeko sistema intrusioak detektatzeko sistemetan eta sinadura-metodoetan oinarrituta eraiki bazuen, orain intzidentziaren % 20 baino ez dutela hartzen. Beste % 20 fluxuen analisi sistemetan erortzen da, eta horrek iradokitzen du soluzio horiek ez direla kapritxo bat, baizik eta benetako tresna bat enpresa moderno baten informazio-segurtasun zerbitzuen jardueretan. Gainera, horiek ezartzeko gauzarik garrantzitsuena duzu - sareko azpiegiturak, inbertsioak gehiago babestu daitezkeen informazioaren segurtasuna kontrolatzeko funtzioak sareari esleituta.
Zehazki ez nuen sareko fluxuetan identifikatutako anomaliei edo mehatxuei erantzuteko gaia ukitu, baina uste dut dagoeneko argi dagoela monitorizazioa ez dela mehatxu bat detektatzean bakarrik amaitu behar. Erantzun bat izan behar du ondoren, eta ahal dela modu automatikoan edo automatizatuan. Baina hau aparteko artikulu baterako gaia da.
Informazio gehigarria:
PS. Goian idatzitako guztia entzutea errazagoa bazaizu, ohar honen oinarria izan den ordubeteko aurkezpena ikus dezakezu.
Iturria: www.habr.com