ProHoster > Blogs > Administrācija > PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Runājot par iekŔējā korporatÄ«vā vai departamenta tÄ«kla droŔības uzraudzÄ«bu, daudzi to saista ar informācijas noplÅ«des kontroli un DLP risinājumu ievieÅ”anu. Un, ja mēģināt precizēt jautājumu un jautāt, kā atklāt uzbrukumus iekŔējam tÄ«klam, tad atbilde parasti bÅ«s ielauÅ”anās atklāŔanas sistēmu (IDS) pieminÄ“Å”ana. Un tas, kas bija vienÄ«gais variants pirms 10-20 gadiem, mÅ«sdienās kļūst par anahronismu. IekŔējā tÄ«kla uzraudzÄ«bai ir efektÄ«vāka un dažviet arÄ« vienÄ«gā iespējamā iespēja ā€“ izmantojot plÅ«smas protokolus, kas sākotnēji bija paredzēti tÄ«kla problēmu meklÄ“Å”anai (problēmu novērÅ”anai), bet laika gaitā pārvērtās par ļoti interesantu droŔības rÄ«ku. Mēs runāsim par to, kādi ir plÅ«smas protokoli un kuri ir labāki tÄ«kla uzbrukumu noteikÅ”anai, kur vislabāk ir ieviest plÅ«smas uzraudzÄ«bu, ko meklēt, izvietojot Ŕādu shēmu, un pat par to, kā to visu ā€œuzceltā€ uz sadzÄ«ves iekārtām. Ŕī raksta ietvaros.

NekavÄ“Å”os pie jautājuma ā€œKāpēc nepiecieÅ”ama iekŔējās infrastruktÅ«ras droŔības uzraudzÄ«ba?ā€ Å Ä·iet, ka atbilde ir skaidra. Bet, ja tomēr vēlaties vēlreiz pārliecināties, ka Å”odien jÅ«s nevarat dzÄ«vot bez tā, izskatu Ä«ss video par to, kā 17 veidos var iekļūt korporatÄ«vajā tÄ«klā, ko aizsargā ugunsmÅ«ris. Tāpēc pieņemsim, ka saprotam, ka iekŔējā uzraudzÄ«ba ir nepiecieÅ”ama lieta un atliek tikai saprast, kā to var organizēt.

Es vēlētos izcelt trīs galvenos datu avotus infrastruktūras pārraudzībai tīkla līmenī:

  • ā€œneapstrādātaā€ datplÅ«sma, ko mēs uztveram un iesniedzam analÄ«zei noteiktām analÄ«zes sistēmām,
  • notikumi no tÄ«kla ierÄ«cēm, caur kurām Ŕķērso trafiku,
  • satiksmes informācija, kas saņemta, izmantojot vienu no plÅ«smas protokoliem.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Neapstrādātas trafika tverÅ”ana ir vispopulārākā iespēja droŔības speciālistu vidÅ«, jo tā vēsturiski parādÄ«jās un bija pati pirmā. Tradicionālās tÄ«kla ielauÅ”anās noteikÅ”anas sistēmas (pati pirmā komerciālā ielauÅ”anās atklāŔanas sistēma bija NetRanger no Wheel Group, ko 1998. gadā iegādājās Cisco) bija precÄ«zi iesaistÄ«tas pakeÅ”u (un vēlāku sesiju) uztverÅ”anā, kurās tika meklēti noteikti paraksti (ā€œizŔķiroÅ”ie noteikumiā€ FSTEC terminoloÄ£ija), signalizācijas uzbrukumi. Protams, neapstrādātu trafiku var analizēt ne tikai izmantojot IDS, bet arÄ« citus rÄ«kus (piemēram, Wireshark, tcpdum vai NBAR2 funkcionalitāti Cisco IOS sistēmā), taču tiem parasti trÅ«kst zināŔanu bāzes, kas atŔķir informācijas droŔības rÄ«ku no parastajiem. IT rÄ«ks.

Tātad, uzbrukumu noteikÅ”anas sistēmas. Vecākā un populārākā tÄ«kla uzbrukumu noteikÅ”anas metode, kas labi veic darbu perimetrā (vienalga ko ā€“ korporatÄ«vo, datu centru, segmentu utt.), bet neizdodas modernos komutētajos un programmatÅ«ras definētajos tÄ«klos. TÄ«kla gadÄ«jumā, kas veidots uz parasto slēdžu bāzes, uzbrukumu noteikÅ”anas sensoru infrastruktÅ«ra kļūst pārāk liela - jums bÅ«s jāinstalē sensors katrā savienojumā ar mezglu, kuram vēlaties uzraudzÄ«t uzbrukumus. JebkurÅ” ražotājs, protams, labprāt pārdos jums simtiem un tÅ«kstoÅ”iem sensoru, bet es domāju, ka jÅ«su budžets nevar atbalstÄ«t Ŕādus izdevumus. Es varu teikt, ka pat Cisco (un mēs esam NGIPS izstrādātāji) mēs to nevarējām izdarÄ«t, lai gan Ŕķiet, ka cenu jautājums ir mÅ«su priekŔā. Man nevajadzētu izturēt - tas ir mÅ«su paÅ”u lēmums. Turklāt rodas jautājums, kā pieslēgt sensoru Å”ajā versijā? Iekļūt spraugā? Ko darÄ«t, ja pats sensors neizdodas? Vai sensorā ir nepiecieÅ”ams apvada modulis? Vai izmantot sadalÄ«tājus (pieskarieties)? Tas viss padara risinājumu dārgāku un padara to par nepieņemamu jebkura lieluma uzņēmumam.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Varat mēģināt ā€œpiekārtā€ sensoru pie SPAN/RSPAN/ERSPAN porta un novirzÄ«t trafiku no nepiecieÅ”amajiem slēdža portiem uz to. Å Ä« opcija daļēji novērÅ” iepriekŔējā rindkopā aprakstÄ«to problēmu, bet rada vēl vienu - SPAN ports nevar pieņemt pilnÄ«gi visu trafiku, kas tam tiks nosÅ«tÄ«ts - tam nebÅ«s pietiekami daudz joslas platuma. Jums bÅ«s kaut kas jāupurē. Vai nu atstājiet dažus mezglus bez uzraudzÄ«bas (tad vispirms tiem ir jānosaka prioritātes), vai arÄ« nosÅ«tiet nevis visu datplÅ«smu no mezgla, bet tikai noteiktu veidu. Jebkurā gadÄ«jumā mēs varam palaist garām dažus uzbrukumus. Turklāt SPAN portu var izmantot citām vajadzÄ«bām. Rezultātā mums bÅ«s jāpārskata esoŔā tÄ«kla topoloÄ£ija un, iespējams, tajā jāveic korekcijas, lai maksimāli segtu jÅ«su tÄ«klu ar jÅ«su sensoru skaitu (un tas jāsaskaņo ar IT).

Ko darÄ«t, ja jÅ«su tÄ«kls izmanto asimetriskus marÅ”rutus? Ko darÄ«t, ja esat ieviesis vai plānojat ieviest SDN? Ko darÄ«t, ja jums ir jāuzrauga virtualizētās maŔīnas vai konteineri, kuru satiksme vispār nesasniedz fizisko slēdzi? Å ie ir jautājumi, kas tradicionālajiem IDS pārdevējiem nepatÄ«k, jo viņi nezina, kā uz tiem atbildēt. VarbÅ«t viņi jÅ«s pārliecinās, ka visas Ŕīs modernās tehnoloÄ£ijas ir ažiotāža un jums tās nav vajadzÄ«gas. VarbÅ«t viņi runās par nepiecieÅ”amÄ«bu sākt ar mazumiņu. Vai varbÅ«t viņi teiks, ka tÄ«kla centrā ir jāievieto jaudÄ«gs kuļmaŔīnas un jānovirza visa trafika uz to, izmantojot balansētājus. NeatkarÄ«gi no tā, kāda iespēja jums tiek piedāvāta, jums ir skaidri jāsaprot, kā tas jums ir piemērots. Un tikai pēc tam pieņemiet lēmumu par pieejas izvēli tÄ«kla infrastruktÅ«ras informācijas droŔības uzraudzÄ«bai. Atgriežoties pie pakeÅ”u uztverÅ”anas, gribu teikt, ka Ŕī metode joprojām ir ļoti populāra un svarÄ«ga, taču tās galvenais mērÄ·is ir robežkontrole; robežas starp jÅ«su organizāciju un internetu, robežas starp datu centru un pārējo tÄ«klu, robežas starp procesu vadÄ«bas sistēmu un korporatÄ«vo segmentu. Å ajās vietās klasiskajiem IDS/IPS joprojām ir tiesÄ«bas pastāvēt un labi tikt galā ar saviem uzdevumiem.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Pāriesim pie otrā varianta. No tÄ«kla ierÄ«cēm nākoÅ”o notikumu analÄ«zi var izmantot arÄ« uzbrukumu noteikÅ”anas nolÅ«kos, taču ne kā galveno mehānismu, jo tā ļauj atklāt tikai nelielu ielauÅ”anās gadÄ«jumu grupu. Turklāt tas ir raksturÄ«gs zināmai reaktivitātei - vispirms jānotiek uzbrukumam, pēc tam tas jāreÄ£istrē tÄ«kla ierÄ«cei, kas vienā vai otrā veidā signalizēs par informācijas droŔības problēmu. Ir vairāki Ŕādi veidi. Tas varētu bÅ«t syslog, RMON vai SNMP. Pēdējie divi tÄ«kla uzraudzÄ«bas protokoli informācijas droŔības kontekstā tiek izmantoti tikai tad, ja mums ir nepiecieÅ”ams atklāt DoS uzbrukumu paÅ”am tÄ«kla aprÄ«kojumam, jo, izmantojot RMON un SNMP, ir iespējams, piemēram, uzraudzÄ«t ierÄ«ces centrālās ierÄ«ces slodzi. procesors vai tā saskarnes. Å Ä« ir viena no ā€œlētākajāmā€ (visiem ir syslog vai SNMP), bet arÄ« visneefektÄ«vākā no visām iekŔējās infrastruktÅ«ras informācijas droŔības uzraudzÄ«bas metodēm - daudzi uzbrukumi no tā vienkārÅ”i tiek paslēpti. Protams, tos nevajadzētu atstāt novārtā, un tā pati syslog analÄ«ze palÄ«dz savlaicÄ«gi identificēt paÅ”as ierÄ«ces konfigurācijas izmaiņas, tās apdraudējumu, taču tā nav Ä«paÅ”i piemērota, lai atklātu uzbrukumus visam tÄ«klam.

TreŔā iespēja ir analizēt informāciju par trafiku, kas Ŕķērso ierÄ«ci, kas atbalsta vienu no vairākiem plÅ«smas protokoliem. Å ajā gadÄ«jumā, neatkarÄ«gi no protokola, vÄ«tņu infrastruktÅ«ra noteikti sastāv no trim komponentiem:

  • PlÅ«smas Ä£enerÄ“Å”ana vai eksportÄ“Å”ana. Å Ä« loma parasti tiek pieŔķirta marÅ”rutētājam, slēdžam vai citai tÄ«kla ierÄ«cei, kas, nododot tÄ«kla trafiku caur sevi, ļauj iegÅ«t no tā galvenos parametrus, kas pēc tam tiek pārsÅ«tÄ«ti uz savākÅ”anas moduli. Piemēram, Cisco atbalsta Netflow protokolu ne tikai marÅ”rutētājos un slēdžos, tostarp virtuālajos un rÅ«pnieciskajos, bet arÄ« bezvadu kontrolleros, ugunsmÅ«ros un pat serveros.
  • Kolekcijas plÅ«sma. Ņemot vērā, ka mÅ«sdienu tÄ«klā parasti ir vairāk nekā viena tÄ«kla ierÄ«ce, rodas plÅ«smu savākÅ”anas un konsolidācijas problēma, kas tiek atrisināta, izmantojot tā sauktos kolektorus, kas apstrādā saņemtās plÅ«smas un pēc tam nosÅ«ta tās analÄ«zei.
  • PlÅ«smas analÄ«ze Analizators uzņemas galveno intelektuālo uzdevumu un, izmantojot dažādus algoritmus plÅ«smām, izdara noteiktus secinājumus. Piemēram, IT funkcijas ietvaros Ŕāds analizators var identificēt tÄ«kla vājās vietas vai analizēt trafika slodzes profilu turpmākai tÄ«kla optimizācijai. Un informācijas droŔībai Ŕāds analizators var atklāt datu noplÅ«des, ļaunprātÄ«ga koda izplatÄ«bu vai DoS uzbrukumus.

Nedomājiet, ka Ŕī trÄ«s lÄ«meņu arhitektÅ«ra ir pārāk sarežģīta - visas pārējās iespējas (izņemot, iespējams, tÄ«kla uzraudzÄ«bas sistēmas, kas darbojas ar SNMP un RMON) arÄ« darbojas saskaņā ar to. Mums ir datu Ä£enerators analÄ«zei, kas var bÅ«t tÄ«kla ierÄ«ce vai atseviŔķs sensors. Mums ir trauksmes savākÅ”anas sistēma un vadÄ«bas sistēma visai uzraudzÄ«bas infrastruktÅ«rai. Pēdējos divus komponentus var apvienot vienā mezglā, bet vairāk vai mazāk lielos tÄ«klos tie parasti tiek izkliedēti vismaz divās ierÄ«cēs, lai nodroÅ”inātu mērogojamÄ«bu un uzticamÄ«bu.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

AtŔķirÄ«bā no pakeÅ”u analÄ«zes, kas balstās uz katras paketes un sesiju, no kurām tā sastāv, galvenes un pamatdatu izpēti, plÅ«smas analÄ«ze balstās uz metadatu vākÅ”anu par tÄ«kla trafiku. Kad, cik, no kurienes un kur, kā... uz Å”iem jautājumiem atbild tÄ«kla telemetrijas analÄ«ze, izmantojot dažādus plÅ«smas protokolus. Sākotnēji tos izmantoja statistikas analÄ«zei un IT problēmu atraÅ”anai tÄ«klā, bet pēc tam, attÄ«stoties analÄ«tiskajiem mehānismiem, kļuva iespējams droŔības nolÅ«kos tos piemērot tai paÅ”ai telemetrijai. Vēlreiz ir vērts atzÄ«mēt, ka plÅ«smas analÄ«ze neaizstāj vai neaizstāj pakeÅ”u uztverÅ”anu. Katrai no Ŕīm metodēm ir sava pielietojuma joma. Bet Ŕī raksta kontekstā tieÅ”i plÅ«smas analÄ«ze ir vispiemērotākā iekŔējās infrastruktÅ«ras uzraudzÄ«bai. Jums ir tÄ«kla ierÄ«ces (neatkarÄ«gi no tā, vai tās darbojas programmatÅ«ras definētā paradigmā vai saskaņā ar statiskiem noteikumiem), kuras uzbrukums nevar apiet. Tas var apiet klasisko IDS sensoru, bet tÄ«kla ierÄ«ce, kas atbalsta plÅ«smas protokolu, nevar. Tā ir Ŕīs metodes priekÅ”rocÄ«ba.

Savukārt, ja nepiecieÅ”ami pierādÄ«jumi tiesÄ«bsargājoÅ”ajām iestādēm vai savai incidentu izmeklÄ“Å”anas grupai, neiztikt bez pakeÅ”u uztverÅ”anas ā€“ tÄ«kla telemetrija nav trafika kopija, ko var izmantot pierādÄ«jumu vākÅ”anai; tas ir nepiecieÅ”ams ātrai atklāŔanai un lēmumu pieņemÅ”anai informācijas droŔības jomā. No otras puses, izmantojot telemetrijas analÄ«zi, jÅ«s varat ā€œrakstÄ«tā€ ne visu tÄ«kla trafiku (ja kas, Cisco nodarbojas ar datu centriem :-), bet tikai to, kas ir iesaistÄ«ts uzbrukumā. Telemetrijas analÄ«zes rÄ«ki Å”ajā ziņā labi papildinās tradicionālos pakeÅ”u uztverÅ”anas mehānismus, dodot komandas selektÄ«vai uztverÅ”anai un uzglabāŔanai. Pretējā gadÄ«jumā jums bÅ«s jābÅ«t kolosālai uzglabāŔanas infrastruktÅ«rai.

Iedomāsimies tÄ«klu, kas darbojas ar ātrumu 250 Mbit/sek. Ja vēlaties saglabāt visu Å”o apjomu, jums bÅ«s nepiecieÅ”ams 31 MB krātuve vienai trafika pārraides sekundei, 1,8 GB vienai minÅ«tei, 108 GB vienai stundai un 2,6 TB vienai dienai. Lai saglabātu ikdienas datus no tÄ«kla ar joslas platumu 10 Gbit/s, jums bÅ«s nepiecieÅ”ama 108 TB krātuve. Taču daži regulatori pieprasa droŔības datu glabāŔanu gadiem ilgi... IerakstÄ«Å”ana pēc pieprasÄ«juma, kuru plÅ«smas analÄ«ze palÄ«dz ieviest, palÄ«dz samazināt Ŕīs vērtÄ«bas par lielumu kārtām. Starp citu, ja mēs runājam par reÄ£istrēto tÄ«kla telemetrijas datu apjoma un pilnÄ«gas datu tverÅ”anas attiecÄ«bu, tad tas ir aptuveni 1 pret 500. Tādām paŔām vērtÄ«bām, kas norādÄ«tas iepriekÅ”, tiek saglabāts visas dienas trafika pilns atÅ”ifrējums. bÅ«s attiecÄ«gi 5 un 216 GB (varat pat ierakstÄ«t parastajā zibatmiņas diskā).

Ja tÄ«kla neapstrādātu datu analÄ«zes rÄ«kiem to iegÅ«Å”anas metode ir gandrÄ«z vienāda no piegādātāja lÄ«dz pārdevējam, tad plÅ«smas analÄ«zes gadÄ«jumā situācija ir atŔķirÄ«ga. PlÅ«smas protokoliem ir vairākas iespējas, atŔķirÄ«bas, par kurām jums jāzina droŔības kontekstā. Vispopulārākais ir Cisco izstrādātais Netflow protokols. Å im protokolam ir vairākas versijas, kas atŔķiras pēc iespējām un ierakstÄ«tās satiksmes informācijas apjoma. PaÅ”reizējā versija ir devÄ«tā (Netflow v9), uz kuras pamata tika izstrādāts nozares standarts Netflow v10, kas pazÄ«stams arÄ« kā IPFIX. MÅ«sdienās lielākā daļa tÄ«kla pārdevēju savā aprÄ«kojumā atbalsta Netflow vai IPFIX. Bet ir vēl dažādas plÅ«smas protokolu iespējas - sFlow, jFlow, cFlow, rFlow, NetStream utt., no kuriem sFlow ir vispopulārākais. TieÅ”i Å”o veidu vietējie tÄ«kla iekārtu ražotāji visbiežāk atbalsta tā ievieÅ”anas vienkārŔības dēļ. Kādas ir galvenās atŔķirÄ«bas starp Netflow, kas ir kļuvis par de facto standartu, un sFlow? Es izcelÅ”u vairākus galvenos. Pirmkārt, Netflow ir lietotāja pielāgojami lauki pretstatā fiksētajiem sFlow laukiem. Un, otrkārt, un tas ir vissvarÄ«gākais mÅ«su gadÄ«jumā, sFlow apkopo tā saukto izlases telemetriju; atŔķirÄ«bā no neatlasÄ«tā Netflow un IPFIX. Kāda ir atŔķirÄ«ba starp tām?

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Iedomājieties, ka jÅ«s nolemjat izlasÄ«t grāmatu "DroŔības operāciju centrs: SOC izveide, darbÄ«ba un uzturÄ“Å”anaā€ manu kolēģu - Gerija Makintara, Džozefa Munica un Nadema Alfardana (daļu grāmatas varat lejupielādēt no saites). Lai sasniegtu savu mērÄ·i, jums ir trÄ«s iespējas ā€” izlasÄ«t visu grāmatu, pārlÅ«kot to, apstājoties pie katras 10. vai 20. lappuses, vai mēģināt atrast galveno jēdzienu pārstāstu emuārā vai pakalpojumā, piemēram, SmartReading. Tātad neatlasÄ«tā telemetrija nolasa katru tÄ«kla trafika ā€œlapuā€, tas ir, analizē katras paketes metadatus. Izlases telemetrija ir selektÄ«va trafika izpēte, cerot, ka atlasÄ«tajos paraugos bÅ«s tas, kas jums nepiecieÅ”ams. AtkarÄ«bā no kanāla ātruma parauga telemetrija tiks nosÅ«tÄ«ta analÄ«zei katru 64., 200., 500., 1000., 2000. vai pat 10000. paketi.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Informācijas droŔības uzraudzÄ«bas kontekstā tas nozÄ«mē, ka izlases telemetrija ir labi piemērota DDoS uzbrukumu noteikÅ”anai, skenÄ“Å”anai un ļaunprātÄ«ga koda izplatÄ«Å”anai, taču var palaist garām atomu vai vairāku pakeÅ”u uzbrukumus, kas nebija iekļauti analÄ«zei nosÅ«tÄ«tajā paraugā. NeatlasÄ«tai telemetrijai Ŕādu trÅ«kumu nav. Tādējādi atklāto uzbrukumu klāsts ir daudz plaŔāks. Å eit ir Ä«ss notikumu saraksts, kurus var noteikt, izmantojot tÄ«kla telemetrijas analÄ«zes rÄ«kus.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Protams, daži atvērtā pirmkoda Netflow analizatori to neļaus izdarÄ«t, jo tā galvenais uzdevums ir apkopot telemetriju un veikt tā pamata analÄ«zi no IT viedokļa. Lai identificētu informācijas droŔības draudus, pamatojoties uz plÅ«smu, nepiecieÅ”ams aprÄ«kot analizatoru ar dažādiem dzinējiem un algoritmiem, kas identificēs kiberdroŔības problēmas, pamatojoties uz standarta vai pielāgotiem Netflow laukiem, bagātinās standarta datus ar ārējiem datiem no dažādiem Threat Intelligence avotiem utt.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Tāpēc, ja jums ir izvēle, izvēlieties Netflow vai IPFIX. Bet pat tad, ja jÅ«su aprÄ«kojums darbojas tikai ar sFlow, piemēram, vietējie ražotāji, pat Å”ajā gadÄ«jumā jÅ«s varat gÅ«t labumu no tā droŔības kontekstā.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

2019. gada vasarā es analizēju iespējas, kādas ir Krievijas tÄ«kla aparatÅ«ras ražotājiem, un tās visas, izņemot NSG, Polygon un Craftway, paziņoja par atbalstu sFlow (vismaz Zelax, Natex, Eltex, QTech, Rusteleteh).

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Nākamais jautājums, ar kuru jÅ«s saskarsities, ir tas, kur ieviest plÅ«smas atbalstu droŔības nolÅ«kos? PatiesÄ«bā jautājums nav uzdots pilnÄ«gi pareizi. MÅ«sdienu aprÄ«kojums gandrÄ«z vienmēr atbalsta plÅ«smas protokolus. Tāpēc es jautājumu pārformulētu savādāk - kur ir visefektÄ«vāk apkopot telemetriju no droŔības viedokļa? Atbilde bÅ«s diezgan acÄ«mredzama - piekļuves lÄ«menÄ«, kur jÅ«s redzēsiet 100% no visas trafika, kur jums bÅ«s detalizēta informācija par hostiem (MAC, VLAN, interfeisa ID), kur jÅ«s pat varat uzraudzÄ«t P2P trafiku starp hostiem, kas ir ļoti svarÄ«ga, lai skenētu ļaunprātÄ«ga koda atklāŔanu un izplatÄ«Å”anu. PamatlÄ«menÄ« jÅ«s varat vienkārÅ”i neredzēt daļu trafika, bet perimetra lÄ«menÄ« jÅ«s redzēsit ceturto daļu no visas tÄ«kla trafika. Bet, ja kāda iemesla dēļ jÅ«su tÄ«klā ir sveÅ”as ierÄ«ces, kas ļauj uzbrucējiem ā€œiekļūt un izietā€, neapejot perimetru, tad telemetrijas analÄ«ze no tā jums neko nedos. Tāpēc, lai nodroÅ”inātu maksimālu pārklājumu, ir ieteicams piekļuves lÄ«menÄ« iespējot telemetrijas datu apkopoÅ”anu. Tajā paŔā laikā ir vērts atzÄ«mēt, ka pat tad, ja mēs runājam par virtualizāciju vai konteineriem, plÅ«smas atbalsts bieži ir atrodams arÄ« mÅ«sdienu virtuālajos slēdžos, kas ļauj kontrolēt trafiku arÄ« tur.

Bet, tā kā es izvirzÄ«ju tēmu, man ir jāatbild uz jautājumu: ko darÄ«t, ja aprÄ«kojums, fiziskais vai virtuālais, neatbalsta plÅ«smas protokolus? Vai arÄ« tā iekļauÅ”ana ir aizliegta (piemēram, rÅ«pnieciskajos segmentos, lai nodroÅ”inātu uzticamÄ«bu)? Vai arÄ« tā ieslēgÅ”ana noved pie lielas CPU slodzes (tas notiek ar vecāku aparatÅ«ru)? Lai atrisinātu Å”o problēmu, ir specializēti virtuālie sensori (plÅ«smas sensori), kas bÅ«tÄ«bā ir parastie sadalÄ«tāji, kas laiž cauri satiksmi un pārraida to plÅ«smas veidā uz savākÅ”anas moduli. Tiesa, Å”ajā gadÄ«jumā mēs iegÅ«stam visas problēmas, par kurām mēs runājām iepriekÅ” saistÄ«bā ar pakeÅ”u uztverÅ”anas rÄ«kiem. Tas ir, jums ir jāsaprot ne tikai plÅ«smas analÄ«zes tehnoloÄ£ijas priekÅ”rocÄ«bas, bet arÄ« tās ierobežojumi.

Vēl viens punkts, kas ir svarÄ«gi atcerēties, runājot par plÅ«smas analÄ«zes rÄ«kiem. Ja saistÄ«bā ar tradicionālajiem droŔības notikumu Ä£enerÄ“Å”anas lÄ«dzekļiem mēs izmantojam EPS metriku (notikums sekundē), tad Å”is rādÄ«tājs nav piemērojams telemetrijas analÄ«zei; to aizstāj ar FPS (plÅ«sma sekundē). Tāpat kā EPS gadÄ«jumā, to nevar aprēķināt iepriekÅ”, bet jÅ«s varat novērtēt aptuveno pavedienu skaitu, ko konkrētā ierÄ«ce Ä£enerē atkarÄ«bā no tās uzdevuma. Internetā varat atrast tabulas ar aptuvenām vērtÄ«bām dažāda veida uzņēmuma ierÄ«cēm un apstākļiem, kas ļaus novērtēt, kādas licences ir nepiecieÅ”amas analÄ«zes rÄ«kiem un kāda bÅ«s to arhitektÅ«ra? Fakts ir tāds, ka IDS sensoru ierobežo noteikts joslas platums, ko tas var ā€œvilktā€, un plÅ«smas kolektoram ir savi ierobežojumi, kas ir jāsaprot. Tāpēc lielos, Ä£eogrāfiski sadalÄ«tos tÄ«klos parasti ir vairāki kolektori. Kad es aprakstÄ«ju kā tÄ«kls tiek uzraudzÄ«ts iekÅ” Cisco, es jau norādÄ«ju mÅ«su kolekcionāru skaitu - to ir 21. Un tas ir tÄ«klam, kas izkaisÄ«ts piecos kontinentos un kurā ir aptuveni pusmiljons aktÄ«vo ierīču).

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Mēs izmantojam savu risinājumu kā Netflow uzraudzÄ«bas sistēmu Cisco Stealthwatch, kas ir Ä«paÅ”i vērsta uz droŔības problēmu risināŔanu. Tajā ir iebÅ«vēti daudzi dzinēji anomālu, aizdomÄ«gu un nepārprotami ļaunprātÄ«gu darbÄ«bu noteikÅ”anai, kas ļauj atklāt visdažādākos draudus ā€“ no Å”ifrÄ“Å”anas lÄ«dz informācijas noplÅ«dei, no kaitÄ«ga koda izplatÄ«bas lÄ«dz krāpÅ”anai. Tāpat kā lielākā daļa plÅ«smas analizatoru, arÄ« Stealthwatch ir veidots pēc trÄ«s lÄ«meņu shēmas (Ä£enerators - kolektors - analizators), taču tas ir papildināts ar vairākām interesantām funkcijām, kas ir svarÄ«gas aplÅ«kojamā materiāla kontekstā. Pirmkārt, tas ir integrēts ar pakeÅ”u uztverÅ”anas risinājumiem (piemēram, Cisco Security Packet Analyzer), kas ļauj ierakstÄ«t atlasÄ«tās tÄ«kla sesijas vēlākai padziļinātai izmeklÄ“Å”anai un analÄ«zei. Otrkārt, Ä«paÅ”i droŔības uzdevumu paplaÅ”ināŔanai esam izstrādājuÅ”i Ä«paÅ”u nvzFlow protokolu, kas ļauj gala mezglos (serveros, darbstacijās u.c.) esoÅ”o lietojumprogrammu darbÄ«bu ā€œpārraidÄ«tā€ telemetrijā un pārsÅ«tÄ«t uz kolektoru tālākai analÄ«zei. Ja sākotnējā versijā Stealthwatch darbojas ar jebkuru plÅ«smas protokolu (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) tÄ«kla lÄ«menÄ«, tad nvzFlow atbalsts ļauj veikt datu korelāciju arÄ« mezgla lÄ«menÄ«, tādējādi. palielinot visas sistēmas efektivitāti un redzot vairāk uzbrukumu nekā parastie tÄ«kla plÅ«smas analizatori.

Ir skaidrs, ka, runājot par Netflow analÄ«zes sistēmām no droŔības viedokļa, tirgus neaprobežojas tikai ar vienu Cisco risinājumu. Varat izmantot gan komerciālus, gan bezmaksas vai shareware risinājumus. Ir diezgan dÄ«vaini, ja Cisco emuārā kā piemērus minu konkurentu risinājumus, tāpēc teikÅ”u dažus vārdus par to, kā tÄ«kla telemetriju var analizēt, izmantojot divus populārus, pēc nosaukuma lÄ«dzÄ«gus, bet tomēr atŔķirÄ«gus rÄ«kus - SiLK un ELK.

SiLK ir rÄ«ku komplekts (Internet-Level Knowledge sistēma) trafika analÄ«zei, ko izstrādājis amerikāņu CERT/CC un kas Å”odienas raksta kontekstā atbalsta Netflow (5. un 9., populārākās versijas), IPFIX. un sFlow un izmantojot dažādas utilÄ«tas (rwfilter, rwcount, rwflowpack u.c.), lai veiktu dažādas darbÄ«bas tÄ«kla telemetrijā, lai atklātu tajā nesankcionētu darbÄ«bu pazÄ«mes. Bet ir jāņem vērā pāris svarÄ«gi punkti. SiLK ir komandrindas rÄ«ks, kas veic tieÅ”saistes analÄ«zi, ievadot Ŕādas komandas (ICMP pakeÅ”u noteikÅ”ana, kas lielākas par 200 baitiem):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

ne pārāk ērti. JÅ«s varat izmantot iSiLK GUI, taču tas jÅ«su dzÄ«vi Ä«paÅ”i nepadarÄ«s vieglāku, atrisinot tikai vizualizācijas funkciju, nevis nomainot analÄ«tiÄ·i. Un tas ir otrais punkts. AtŔķirÄ«bā no komerciālajiem risinājumiem, kuriem jau ir stabila analÄ«tiskā bāze, anomāliju noteikÅ”anas algoritmi, atbilstoÅ”a darbplÅ«sma utt., SiLK gadÄ«jumā tas viss bÅ«s jādara paÅ”am, kas prasÄ«s no jums nedaudz atŔķirÄ«gas kompetences nekā no jau gatavas lietojami instrumenti. Tas nav ne labi, ne slikti ā€” Ŕī ir gandrÄ«z jebkura bezmaksas rÄ«ka iezÄ«me, kas paredz, ka jÅ«s zināt, kas jādara, un tas jums tikai palÄ«dzēs (komerciālie rÄ«ki ir mazāk atkarÄ«gi no lietotāju kompetences, lai gan viņi arÄ« pieņem ka analÄ«tiÄ·i saprot vismaz tÄ«kla izmeklÄ“Å”anas un uzraudzÄ«bas pamatus). Bet atgriezÄ«simies pie SiLK. AnalÄ«tiÄ·a darba cikls ar to izskatās Ŕādi:

  • Hipotēzes formulÄ“Å”ana. Mums ir jāsaprot, ko mēs meklēsim tÄ«kla telemetrijā, jāzina unikālie atribÅ«ti, pēc kuriem mēs identificēsim noteiktas anomālijas vai draudus.
  • Modeļa veidoÅ”ana. Pēc hipotēzes formulÄ“Å”anas mēs to programmējam, izmantojot to paÅ”u Python, apvalku vai citus rÄ«kus, kas nav iekļauti SiLK.
  • TestÄ“Å”ana. Tagad pienāk kārta pārbaudÄ«t mÅ«su hipotēzes pareizÄ«bu, kas tiek apstiprināta vai atspēkota, izmantojot SiLK utilÄ«tus, kas sākas ar 'rw', 'set', 'bag'.
  • Reālu datu analÄ«ze. RÅ«pnieciskajā darbÄ«bā SiLK palÄ«dz mums kaut ko identificēt un analÄ«tiÄ·im ir jāatbild uz jautājumiem ā€œVai atradām to, ko gaidÄ«jām?ā€, ā€œVai tas atbilst mÅ«su hipotēzei?ā€, ā€œKā samazināt viltus pozitÄ«vo rezultātu skaitu?ā€, ā€œKā lai uzlabotu atpazÄ«stamÄ«bas lÄ«meni? Ā» un tā tālāk.
  • UzlaboÅ”ana. Pēdējā posmā mēs uzlabojam iepriekÅ” paveikto - veidojam veidnes, uzlabojam un optimizējam kodu, pārformulējam un precizējam hipotēzi utt.

Å is cikls bÅ«s piemērojams arÄ« Cisco Stealthwatch, tikai pēdējais maksimāli automatizē Ŕīs piecas darbÄ«bas, samazinot analÄ«tiÄ·u kļūdu skaitu un palielinot incidentu noteikÅ”anas efektivitāti. Piemēram, SiLK var bagātināt tÄ«kla statistiku ar ārējiem datiem par ļaunprātÄ«giem IP, izmantojot ar roku rakstÄ«tus skriptus, savukārt programmā Cisco Stealthwatch tā ir iebÅ«vēta funkcija, kas nekavējoties parāda trauksmi, ja tÄ«kla trafiks satur mijiedarbÄ«bu ar IP adresēm no melnā saraksta.

Ja pakāpsies augstāk ā€œapmaksātajāā€ plÅ«smas analÄ«zes programmatÅ«ras piramÄ«dā, tad pēc absolÅ«ti bezmaksas SiLK bÅ«s shareware ELK, kas sastāv no trim galvenajām sastāvdaļām - Elasticsearch (indeksÄ“Å”ana, meklÄ“Å”ana un datu analÄ«ze), Logstash (datu ievade/izvade). ) un Kibana (vizualizācija). AtŔķirÄ«bā no SiLK, kur viss jāraksta paÅ”am, ELK jau ir daudz gatavu bibliotēku/moduļu (daži maksas, daži ne), kas automatizē tÄ«kla telemetrijas analÄ«zi. Piemēram, GeoIP filtrs Logstash ļauj saistÄ«t uzraudzÄ«tās IP adreses ar to Ä£eogrāfisko atraÅ”anās vietu (Stealthwatch ir Ŕī iebÅ«vētā funkcija).

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

ELK ir arÄ« diezgan liela kopiena, kas papildina Å”im uzraudzÄ«bas risinājumam trÅ«kstoŔās sastāvdaļas. Piemēram, lai strādātu ar Netflow, IPFIX un sFlow, varat izmantot moduli elastÄ«ba, ja neesat apmierināts ar Logstash Netflow moduli, kas atbalsta tikai Netflow.

Lai gan ELK nodroÅ”ina lielāku efektivitāti plÅ«smas savākÅ”anā un meklÄ“Å”anā tajā, ELK paÅ”laik trÅ«kst bagātÄ«gas iebÅ«vētas analÄ«zes, lai noteiktu anomālijas un draudus tÄ«kla telemetrijā. Tas ir, ievērojot iepriekÅ” aprakstÄ«to dzÄ«ves ciklu, jums bÅ«s patstāvÄ«gi jāapraksta pārkāpumu modeļi un pēc tam jāizmanto kaujas sistēmā (tur nav iebÅ«vētu modeļu).

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

ELK, protams, ir arÄ« sarežģītāki paplaÅ”inājumi, kuros jau ir daži modeļi tÄ«kla telemetrijas anomāliju noteikÅ”anai, taču Ŕādi paplaÅ”inājumi maksā naudu un jautājums ir, vai spēle ir sveces vērta - uzraksti pats lÄ«dzÄ«gu modeli, iegādājies tā realizāciju. savam uzraudzÄ«bas rÄ«kam vai iegādājieties gatavu TÄ«kla trafika analÄ«zes klases risinājumu.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Vispār nevēlos iedziļināties debatēs par to, ka labāk ir tērēt naudu un nopirkt gatavu risinājumu tÄ«kla telemetrijas anomāliju un draudu uzraudzÄ«bai (piemēram, Cisco Stealthwatch) vai izdomāt pats un pielāgot to paÅ”u. SiLK, ELK vai nfdump vai OSU plÅ«smas rÄ«ki katram jaunam apdraudējumam (es runāju par pēdējiem diviem no tiem stāstÄ«ja pēdējo reizi)? Katrs izvēlas pats un katram ir savs motÄ«vs izvēlēties kādu no divām iespējām. Vēlējos tikai parādÄ«t, ka tÄ«kla telemetrija ir ļoti svarÄ«gs instruments JÅ«su iekŔējās infrastruktÅ«ras tÄ«kla droŔības nodroÅ”ināŔanā un nevajag to atstāt novārtā, lai neiekļūtu to uzņēmumu sarakstā, kuru vārds medijos tiek minēts lÄ«dz ar epitetiem ā€œ uzlauztsā€, ā€œinformācijas droŔības prasÄ«bām neatbilstoÅ”sā€, ā€œnedomā par savu un klientu datu droŔībuā€.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Apkopojot, es vēlos uzskaitÄ«t galvenos padomus, kas jums jāievēro, veidojot savas iekŔējās infrastruktÅ«ras informācijas droŔības uzraudzÄ«bu:

  1. Neierobežojiet sevi tikai ar perimetru! Izmantojiet (un izvēlieties) tÄ«kla infrastruktÅ«ru ne tikai, lai pārvietotu trafiku no punkta A uz punktu B, bet arÄ« lai risinātu kiberdroŔības problēmas.
  2. Izpētiet esoÅ”os informācijas droŔības uzraudzÄ«bas mehānismus savā tÄ«kla aprÄ«kojumā un izmantojiet tos.
  3. IekŔējai uzraudzÄ«bai dodiet priekÅ”roku telemetrijas analÄ«zei - tā ļauj atklāt lÄ«dz 80-90% no visiem tÄ«kla informācijas droŔības incidentiem, vienlaikus darot to, kas nav iespējams, tverot tÄ«kla paketes un ietaupot vietu visu informācijas droŔības notikumu glabāŔanai.
  4. PlÅ«smu uzraudzÄ«bai izmantojiet Netflow v9 vai IPFIX ā€“ tie sniedz vairāk informācijas droŔības kontekstā un ļauj pārraudzÄ«t ne tikai IPv4, bet arÄ« IPv6, MPLS u.c.
  5. Izmantojiet neatlasÄ«tu plÅ«smas protokolu ā€” tas sniedz vairāk informācijas draudu noteikÅ”anai. Piemēram, Netflow vai IPFIX.
  6. Pārbaudiet tÄ«kla aprÄ«kojuma noslogojumu ā€” tas var arÄ« nespēs apstrādāt plÅ«smas protokolu. Pēc tam apsveriet iespēju izmantot virtuālos sensorus vai Netflow Generation Appliance.
  7. Ieviesiet kontroli, pirmkārt, piekļuves līmenī - tas dos jums iespēju redzēt 100% no visas trafika.
  8. Ja jums nav izvēles un izmantojat krievu tīkla aprīkojumu, izvēlieties tādu, kas atbalsta plūsmas protokolus vai kam ir SPAN/RSPAN porti.
  9. Apvienojiet ielauÅ”anās/uzbrukuma noteikÅ”anas/novērÅ”anas sistēmas malās un plÅ«smas analÄ«zes sistēmas iekŔējā tÄ«klā (tostarp mākoņos).

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

AttiecÄ«bā uz pēdējo padomu es vēlos sniegt ilustrāciju, ko jau esmu sniedzis iepriekÅ”. Redziet, ja iepriekÅ” Cisco informācijas droŔības dienests gandrÄ«z pilnÄ«bā veidoja savu informācijas droŔības uzraudzÄ«bas sistēmu, pamatojoties uz ielauÅ”anās atklāŔanas sistēmām un parakstu metodēm, tad tagad tās veido tikai 20% incidentu. Vēl 20% attiecas uz plÅ«smas analÄ«zes sistēmām, kas liecina, ka Å”ie risinājumi nav kaprÄ«ze, bet gan reāls instruments mÅ«sdienu uzņēmuma informācijas droŔības dienestu darbÄ«bā. Turklāt jums ir vissvarÄ«gākais to ievieÅ”anai - tÄ«kla infrastruktÅ«ra, kurā investÄ«cijas var vēl vairāk aizsargāt, pieŔķirot tÄ«klam informācijas droŔības uzraudzÄ«bas funkcijas.

PlÅ«smas protokoli kā instruments iekŔējā tÄ«kla droŔības uzraudzÄ«bai

Speciāli nepieskāros tēmai par reaģēŔanu uz tÄ«kla plÅ«smās konstatētajām anomālijām vai draudiem, bet domāju, ka jau tagad ir skaidrs, ka monitoringam nevajadzētu beigties tikai ar apdraudējuma konstatÄ“Å”anu. Tam vajadzētu sekot atbildei un vēlams automātiskā vai automatizētā režīmā. Bet Ŕī ir atseviŔķa raksta tēma.

Papildus informācija:

PS. Ja jums ir vieglāk dzirdēt visu iepriekÅ” rakstÄ«to, varat noskatÄ«ties stundu garo prezentāciju, kas bija Ŕīs piezÄ«mes pamatā.



Avots: www.habr.com

Pievieno komentāru