{"id":37437,"date":"2019-10-31T22:17:38","date_gmt":"2019-10-31T19:17:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\/"},"modified":"2019-10-31T22:17:38","modified_gmt":"2019-10-31T19:17:38","slug":"flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Quando si parla di monitoraggio della sicurezza di una rete aziendale interna o di un ente, molti associano questo termine al controllo delle perdite di informazioni e all'implementazione di soluzioni DLP. Ma se proviamo a chiarire la questione e chiediamo come si rilevano gli attacchi all'interno della rete, la risposta sar\u00e0, di solito, un riferimento ai sistemi di rilevamento delle intrusioni (intrusion detection systems, IDS). Ci\u00f2 che era l'unica opzione circa 10-20 anni fa, oggi diventa un anacronismo. Esiste un'opzione pi\u00f9 efficace, e in alcuni casi anche l'unica possibile, per il monitoraggio della rete interna: utilizzare i protocolli di flow, inizialmente concepiti per la risoluzione dei problemi di rete (troubleshooting), ma che nel tempo si sono trasformati in uno strumento di sicurezza molto interessante. In questo articolo parleremo dei diversi protocolli di flow, di quali siano pi\u00f9 utili per rilevare attacchi di rete, di dove sia meglio implementare il monitoraggio del flow, di cosa prestare attenzione durante la realizzazione di questa architettura e persino di come \u201calzarla\u201d su hardware domestico.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Non mi fermer\u00f2 sulla questione \u201cPerch\u00e9 \u00e8 necessario il monitoraggio della sicurezza delle infrastrutture interne?\u201d. La risposta sembra piuttosto ovvia. Ma se comunque desiderate confermare ancora una volta che oggi non si pu\u00f2 fare a meno di questo, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">guarda<\/a><\/noindex> un breve video che spiega 17 modi in cui si pu\u00f2 penetrare in una rete aziendale protetta da un firewall. Quindi consideriamo che comprendiamo che il monitoraggio interno \u00e8 necessario e rimane solo da capire come organizzarlo.<\/p>\n<p>Indicherei tre fonti chiave di dati per il monitoraggio dell'infrastruttura a livello di rete:<\/p>\n<ul>\n<li>il traffico \u201cgrezzo\u201d, che catturiamo e inviamo per l'analisi a un certo sistema di analisi,<\/li>\n<li>eventi provenienti dai dispositivi di rete attraverso i quali passa il traffico,<\/li>\n<li>informazioni sul traffico ottenute tramite uno dei protocolli di flow.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCatturare il traffico grezzo \u00e8 l'opzione pi\u00f9 popolare tra gli specialisti della sicurezza, poich\u00e9 \u00e8 storicamente la pi\u00f9 antica. I normali sistemi di rilevamento intrusioni (il primo sistema commerciale di rilevamento delle intrusioni \u00e8 stato NetRanger dell'azienda Wheel Group, acquisito da Cisco nel 1998) si occupavano appunto della cattura dei pacchetti (e successivamente delle sessioni), nei quali si cercavano specifiche firme (\u201cregole decisive\u201d nella terminologia del FSTEK), che segnalavano attacchi. Naturalmente, \u00e8 possibile analizzare il traffico grezzo non solo tramite IDS, ma anche attraverso altri strumenti (ad esempio, Wireshark, tcpdump o la funzionalit\u00e0 NBAR2 in Cisco IOS), ma di solito mancano di una base di conoscenze che differenzia uno strumento di sicurezza informatica da un normale strumento IT.<\/p>\n<p>Quindi, i sistemi di rilevamento delle intrusioni. Il metodo pi\u00f9 antico e popolare per rilevare le intrusioni di rete, che svolge adeguatamente il suo compito al perimetro (indipendentemente che sia aziendale, di un centro dati, di un segmento, ecc.), ma che si trova in difficolt\u00e0 nelle reti moderne commutate e definite via software. Nel caso di una rete basata su normali switch, l'infrastruttura dei sensori di rilevamento delle intrusioni diventa troppo grande: dovrai installare un sensore per ciascuna connessione a un nodo, per cui vuoi monitorare gli attacchi. Ogni produttore sar\u00e0 felice di venderti centinaia e migliaia di sensori, ma penso che il tuo budget non reggerebbe tali spese. Posso dire che anche in Cisco (dove sviluppiamo NGIPS) non siamo riusciti a fare questo, anche se, apparentemente, il problema del prezzo non dovrebbe esistere \u2014 si tratta infatti della nostra soluzione. Inoltre, sorge la questione di come collegare il sensore in questo caso? In interruzione? E se il sensore stesso si guasta? Richiedere un modulo di bypass nel sensore? Utilizzare i tap? Tutto ci\u00f2 aumenta il costo della soluzione e la rende insostenibile per aziende di qualsiasi dimensione.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 possibile provare a \"installare\" un sensore su una porta SPAN\/RSPAN\/ERSPAN e indirizzare su di essa il traffico dalle porte necessarie dello switch. Questa opzione allevia parzialmente il problema descritto nel paragrafo precedente, ma ne solleva un altro: la porta SPAN non pu\u00f2 ricevere tutto il traffico che verr\u00e0 indirizzato verso di essa, poich\u00e9 non ha sufficiente capacit\u00e0 di banda. Sar\u00e0 necessario sacrificare qualcosa. O mantenere alcune nodi sotto monitoraggio (in tal caso sar\u00e0 necessario prima effettuare una loro priorizzazione), oppure inviare non tutto il traffico da un nodo, ma solo un determinato tipo. In ogni caso, potremmo perdere alcuni attacchi. Inoltre, la porta SPAN potrebbe essere occupata per altre esigenze. Alla fine, dovremo rivedere la topologia di rete esistente e apportare, forse, delle correzioni per coprire al massimo la vostra rete con il numero di sensori a vostra disposizione (e concordare ci\u00f2 con IT).<\/p>\n<p>E se la vostra rete utilizza percorsi asimmetrici? E se avete implementato o state pianificando di implementare SDN? E se dovete monitorare macchine virtuali o container, il cui traffico non raggiunge affatto lo switch fisico? Queste domande non piacciono ai produttori di IDS tradizionali, perch\u00e9 non sanno come rispondere. Potrebbero tentarvi a pensare che tutte queste tecnologie di moda siano solo un hype e che non ne abbiate bisogno. Potrebbero parlare dell'esigenza di iniziare in piccolo. O forse diranno che dovete installare un potente dispositivo al centro della rete e indirizzare tutto il traffico verso di esso tramite bilanciatori. Qualunque opzione vi venga proposta, \u00e8 necessario capire chiaramente quanto sia adatta a voi. E solo dopo prendere una decisione sul tipo di approccio da utilizzare per il monitoraggio della sicurezza della rete. Tornando alla cattura dei pacchetti, voglio sottolineare che questo metodo rimane molto popolare e importante, ma il suo scopo principale \u00e8 il controllo dei confini; i confini tra la vostra organizzazione e Internet, i confini tra il data center e il restante della rete, i confini tra l'automazione dei sistemi e il segmento aziendale. In questi punti, gli IDS\/IPS classici hanno ancora diritto a esistere e svolgono bene i compiti assegnati.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPassiamo alla seconda opzione. L'analisi degli eventi provenienti dai dispositivi di rete pu\u00f2 essere utilizzata anche per scopi di rilevamento delle intrusioni, ma non come meccanismo principale, poich\u00e9 consente di rilevare solo una piccola classe di intrusioni. Inoltre, presenta una certa reattivit\u00e0: un attacco deve prima verificarsi, poi deve essere registrato dal dispositivo di rete, il quale, in un modo o nell'altro, segnaler\u00e0 il problema con la sicurezza informatica. Ci sono diversi modi per farlo. Pu\u00f2 essere syslog, RMON o SNMP. Gli ultimi due protocolli per il monitoraggio di rete nel contesto della sicurezza informatica vengono utilizzati solo se \u00e8 necessario rilevare un attacco DoS sull'hardware di rete stesso, poich\u00e9 con RMON e SNMP \u00e8 possibile, ad esempio, monitorare il carico della CPU del dispositivo o delle sue interfacce. Questo \u00e8 uno dei metodi pi\u00f9 'economici' (syslog o SNMP sono disponibili per tutti), ma anche il meno efficace per il monitoraggio della sicurezza informatica dell'infrastruttura interna: molte intrusioni gli sfuggono. \u00c8 ovvio che non devono essere trascurati, e lo stesso analisi di syslog aiuta a identificare tempestivamente le modifiche nella configurazione del dispositivo, la compromissione di esso, ma non \u00e8 molto adatto per rilevare attacchi all'intera rete.<\/p>\n<p>La terza opzione \u00e8 l'analisi delle informazioni sul traffico che passa attraverso un dispositivo che supporta uno dei vari protocolli di flusso. In questo caso, indipendentemente dal protocollo, l'infrastruttura di lavoro con i flussi consiste necessariamente di tre componenti:<\/p>\n<ul>\n<li>Generazione o esportazione del flusso. Questo compito \u00e8 solitamente affidato a un router, uno switch o un altro dispositivo di rete che, passando attraverso di esso, permette di estrarre dal traffico di rete parametri chiave che poi vengono inviati al modulo di raccolta. Ad esempio, nel caso di Cisco, il protocollo Netflow \u00e8 supportato non solo su router e switch, inclusi quelli virtuali e industriali, ma anche su controller wireless, firewall e persino server.<\/li>\n<li>Raccolta del flusso. Tenendo presente che in una rete moderna ci sono di solito pi\u00f9 di un dispositivo di rete, sorge la necessit\u00e0 di raccogliere e consolidare i flussi, che viene risolta tramite i cosiddetti collezionisti, che elaborano i flussi ricevuti e poi li trasmettono per l'analisi.<\/li>\n<li>Analisi del flow. L'analizzatore assume il compito intellettuale principale e, applicando algoritmi diversi ai flussi, trae varie conclusioni. Ad esempio, nell'ambito della funzione IT, tale analizzatore pu\u00f2 identificare colli di bottiglia nella rete o analizzare il profilo di carico del traffico per ulteriori ottimizzazioni della rete. Per la sicurezza informatica, tale analizzatore pu\u00f2 rilevare perdite di dati, diffusione di malware o attacchi DoS. <\/li>\n<\/ul>\n<p>Non bisogna pensare che un'architettura a tre livelli sia troppo complessa: tutte le altre varianti (escludendo, forse, i sistemi di monitoraggio della rete che operano con SNMP e RMON) funzionano ugualmente secondo questa logica. Abbiamo un generatore di dati per l'analisi, il quale pu\u00f2 essere un dispositivo di rete o un sensore autonomo. Abbiamo un sistema di raccolta degli allarmi e un sistema di gestione dell'intera infrastruttura di monitoraggio. Questi ultimi due componenti possono essere combinati all'interno di un unico nodo, ma in reti di dimensioni pi\u00f9 o meno grandi sono generalmente distribuiti su almeno due dispositivi per garantire scalabilit\u00e0 e affidabilit\u00e0.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA differenza dell'analisi dei pacchetti, che si basa sullo studio dell'intestazione e del corpo di ogni pacchetto, e delle sessioni che ne derivano, l'analisi dei flussi si basa sulla raccolta di metadati sul traffico di rete. Quando, quanto, da dove e dove, come... queste sono le domande a cui risponde l'analisi della telemetria di rete tramite vari protocolli di flow. Inizialmente, erano utilizzati per analizzare statistiche e rilevare problemi IT nella rete, ma successivamente, con l'evoluzione dei meccanismi analitici, \u00e8 stato possibile applicarli alla stessa telemetria anche per scopi di sicurezza. \u00c8 importante sottolineare che l'analisi dei flussi non sostituisce n\u00e9 annulla la cattura dei pacchetti. Ognuno di questi metodi ha la sua area di applicazione. Tuttavia, nel contesto di questo articolo, l'analisi dei flussi \u00e8 la pi\u00f9 adatta per il monitoraggio dell'infrastruttura interna. Hai dispositivi di rete (e non importa se funzionano nella logica della programmazione definita dal software o secondo regole statiche) che non possono essere aggirati dall'attacco. Un sensore classico IDS pu\u00f2 essere bypassato, mentre un dispositivo di rete che supporta il protocollo flow no. Questo \u00e8 il vantaggio di questo metodo. <\/p>\n<p>D'altra parte, se hai bisogno di una base di prove per le forze dell'ordine o per il tuo gruppo di investigazione sugli incidenti, non puoi fare a meno della cattura dei pacchetti: la telemetria di rete non \u00e8 una copia del traffico che pu\u00f2 essere utilizzata per raccogliere prove; \u00e8 necessaria per la rilevazione operativa e la presa di decisioni in ambito di sicurezza informatica. D'altra parte, utilizzando l'analisi della telemetria, puoi \"scrivere\" non tutto il traffico di rete (per chi non lo sapesse, Cisco si occupa di data center :-), ma solo quello che partecipa all'attacco. Gli strumenti di analisi della telemetria in questo senso completano bene i tradizionali meccanismi di cattura dei pacchetti, fornendo un comando per la cattura e la conservazione selettiva. Altrimenti, dovrai avere un'infrastruttura di archiviazione colossale.<\/p>\n<p>Immagina una rete che funziona a una velocit\u00e0 di 250 Mbit\/s. Se desideri conservare tutto questo volume, avrai bisogno di uno spazio di archiviazione di 31 MB per un secondo di trasmissione dei dati, 1,8 GB per un minuto, 108 GB per un'ora e 2,6 TB per un giorno. Per archiviare i dati giornalieri di una rete con una larghezza di banda di 10 Gbit\/s, avrai bisogno di uno spazio di archiviazione di 108 TB. E alcune normative richiedono di conservare i dati sulla sicurezza per anni... La registrazione \"su richiesta\" che l'analisi del flusso ti aiuta a realizzare permette di ridurre questi valori di ordini di grandezza. A proposito, parlando del rapporto tra il volume di dati registrati dalla telemetria di rete e la cattura completa dei dati, \u00e8 di circa 1 a 500. Per i valori menzionati sopra, la memorizzazione della decodifica completa dell'intero traffico giornaliero sar\u00e0 di 5 e 216 GB rispettivamente (puoi anche registrarlo su una normale chiavetta USB).<\/p>\n<p>Se per gli strumenti di analisi dei dati di rete grezzi il metodo di acquisizione non differisce molto da fornitore a fornitore, nel caso dell'analisi dei flussi la situazione \u00e8 diversa. Esistono diversi protocolli flow, delle differenze dei quali \u00e8 necessario essere a conoscenza, soprattutto nel contesto della sicurezza. Il protocollo pi\u00f9 popolare \u00e8 Netflow, sviluppato da Cisco. Ci sono diverse versioni di questo protocollo, che differiscono per capacit\u00e0 e volume di informazioni sul traffico registrato. La versione attuale \u00e8 la nona (Netflow v9), su cui \u00e8 stato sviluppato lo standard industriale Netflow v10, noto anche come IPFIX. Oggi la maggior parte dei fornitori di rete supporta proprio Netflow o IPFIX nel proprio hardware. Ma ci sono anche altri tipi di protocolli flow: sFlow, jFlow, cFlow, rFlow, NetStream e cos\u00ec via, tra i quali sFlow \u00e8 il pi\u00f9 popolare. Questo \u00e8 spesso supportato dai produttori nazionali di apparecchiature di rete a causa della sua semplicit\u00e0 di implementazione. Quali sono le principali differenze tra Netflow, che \u00e8 diventato uno standard de facto, e lo stesso sFlow? Ne evidenzierei alcune. In primo luogo, Netflow ha campi personalizzabili dall'utente, a differenza dei campi fissi in sFlow. In secondo luogo, e questo \u00e8 il punto pi\u00f9 importante nel nostro caso, sFlow raccoglie quella che viene definita telemetria campionata; a differenza della telemetria non campionata di Netflow e IPFIX. Qual \u00e8, quindi, la differenza tra di loro?<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nImmaginate di aver deciso di conoscere il libro \u201c<noindex><a rel=\"nofollow\" href=\"http:\/\/www.ciscopress.com\/store\/security-operations-center-building-operating-and-maintaining-9780134052014\">Security Operations Center: Building, Operating, and Maintaining your SOC<\/a><\/noindex>\u201d dei miei colleghi \u2014 Gary McIntyre, Joseph Muniz e Nadeem AlFardan (al link potete scaricare una parte del libro). Avete tre opzioni per raggiungere l'obiettivo: leggere il libro per intero, scorgerne il contenuto fermandovi ogni 10\u00b0 o 20\u00b0 pagina, oppure cercare un riassunto dei concetti chiave in qualche blog o servizio tipo SmartReading. La telemetria non campionata equivale a leggere ogni \u201cpagina\u201d del traffico di rete, cio\u00e8 analizzare i metadati di ogni pacchetto. La telemetria campionata \u00e8 uno studio selettivo del traffico nella speranza di trovare quello che serve all'interno dei campioni scelti. A seconda della velocit\u00e0 della connessione, la telemetria campionata analizzer\u00e0 ogni 64\u00b0, 200\u00b0, 500\u00b0, 1000\u00b0, 2000\u00b0 o anche 10000\u00b0 pacchetto.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNel contesto del monitoraggio della sicurezza informatica, questo significa che la telemetria campionata \u00e8 ben adatta per rilevare attacchi DDoS, scansioni, diffusione di malware, ma pu\u00f2 trascurare attacchi atomici o multi-packet che non rientrano nel campione inviato per l'analisi. La telemetria non campionata non ha questi svantaggi e, grazie a essa, lo spettro degli attacchi rilevabili \u00e8 notevolmente pi\u00f9 ampio. Ecco un breve elenco di eventi che possono essere rilevati con strumenti di analisi della telemetria di rete.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNaturalmente, un'analizzatore Netflow open source non vi permetter\u00e0 di farlo, poich\u00e9 il suo compito principale \u00e8 raccogliere la telemetria e condurre un'analisi di base dal punto di vista IT. Per rilevare minacce informatiche basate su flow, \u00e8 necessario equipaggiare l'analizzatore con vari motori e algoritmi, che identificheranno i problemi di cybersecurity sulla base di campi Netflow standard o personalizzati, arricchendo i dati standard con informazioni esterne provenienti da diverse fonti di Threat Intelligence, e cos\u00ec via.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuindi, se avete la possibilit\u00e0, scegliete Netflow o IPFIX. Ma anche se il vostro hardware supporta solo sFlow, come nel caso dei produttori nazionali, potete comunque trarne vantaggio in termini di sicurezza. <\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNell'estate del 2019, ho effettuato un'analisi delle capacit\u00e0 disponibili presso i produttori russi di hardware di rete, e tutti loro, ad eccezione di NSG, Poligono e Kraftway, hanno dichiarato di supportare sFlow (almeno, Zelax, Natex, Eltex, QTech, Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa domanda successiva che vi porrete \u00e8: dove implementare il supporto flow per obiettivi di sicurezza? In realt\u00e0, la domanda \u00e8 posta in modo non del tutto corretto. Sull\u2019hardware moderno, il supporto ai protocolli flow \u00e8 quasi sempre presente. Pertanto, riformulerei la domanda in questo modo: dove \u00e8 pi\u00f9 efficace raccogliere la telemetria dal punto di vista della sicurezza? La risposta sar\u00e0 piuttosto ovvia: a livello di accesso, dove vedrete il 100% di tutto il traffico, dove avrete informazioni dettagliate sugli host (MAC, VLAN, ID interfaccia), dove potrete monitorare anche il traffico P2P tra gli host, il che \u00e8 cruciale per rilevare scansioni e la diffusione di malware. A livello del kernel, parte del traffico potrebbe non essere visibile, mentre a livello di perimetro vedrete a malapena un quarto di tutto il vostro traffico di rete. Ma se per qualche motivo nella vostra rete ci sono dispositivi estranei che consentono agli aggressori di 'entrare e uscire', bypassando il perimetro, l'analisi della telemetria non vi servir\u00e0 a nulla. Pertanto, per una copertura massima, si raccomanda di abilitare la raccolta della telemetria proprio a livello di accesso. Vale la pena notare che, anche parlando di virtualizzazione o contenitori, nei moderni switch virtuali il supporto flow \u00e8 spesso presente, permettendo di controllare il traffico anche l\u00ec.<\/p>\n<p>Ma dato che ho sollevato l'argomento, occorre rispondere alla domanda: e se l'hardware, fisico o virtuale, non supporta i protocolli flow? Oppure se la loro attivazione \u00e8 vietata (ad esempio nei segmenti industriali per garantire l'affidabilit\u00e0)? O se la loro attivazione comporta un alto carico della CPU (cosa che pu\u00f2 succedere su hardware obsoleto)? Per affrontare questa problematica esistono sensori virtuali specializzati (flow sensor), che in sostanza sono comuni hub che fanno passare il traffico attraverso di essi e lo trasmettono come flow a un modulo di raccolta. Tuttavia, in questo caso ci troviamo ad affrontare un'intera serie di problemi, come abbiamo discusso sopra riguardo ai mezzi di intercettazione dei pacchetti. Quindi, \u00e8 necessario comprendere non solo i vantaggi della tecnologia di analisi dei flussi, ma anche i suoi limiti.<\/p>\n<p>Un altro aspetto importante da tenere a mente quando si parla degli strumenti di analisi del flusso. Se per quanto riguarda i normali strumenti di generazione di eventi di sicurezza utilizziamo la metrica EPS (eventi al secondo), per l'analisi della telemetria questo indicatore non \u00e8 applicabile; viene sostituito da FPS (flussi al secondo). Cos\u00ec come nel caso dell'EPS, non \u00e8 possibile calcolarlo in anticipo, ma si pu\u00f2 stimare il numero approssimativo di flussi generati da un dispositivo in base al suo compito. Puoi trovare tabelle su Internet con valori approssimativi per diversi tipi di dispositivi aziendali e condizioni, che ti permetteranno di ipotizzare quali licenze ti servono per gli strumenti di analisi e quale sar\u00e0 la loro architettura. Il fatto \u00e8 che il sensore IDS ha una capacit\u00e0 di filtraggio limitata che pu\u00f2 \"sostenere\" e anche il collettore di flussi ha le sue limitazioni che \u00e8 necessario comprendere. Pertanto, nelle reti ampie e territorialmente distribuite ci sono di solito pi\u00f9 collettori. Quando parlavo di <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">come viene monitorata la rete all'interno di Cisco<\/a><\/noindex>, ho gi\u00e0 citato il nostro numero di collettori: sono 21. E questo per una rete distribuita su cinque continenti e composta da circa mezzo milione di dispositivi attivi).<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome sistema di monitoraggio Netflow utilizziamo la nostra soluzione <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, progettato specificamente per affrontare le sfide della sicurezza. Ha molti motori integrati per la rilevazione di attivit\u00e0 anomale, sospette e manifestamente dannose, consentendo di rilevare un'ampia gamma di minacce, dal mining di criptovalute alle fughe di informazioni, dalla diffusione di malware alle frodi. Come la maggior parte degli analizzatori di flusso, Stealthwatch \u00e8 costruito su uno schema a tre livelli (generatore - raccoglitore - analizzatore), ma \u00e8 arricchito da una serie di interessanti caratteristiche che sono importanti nel contesto del materiale trattato. Innanzitutto, si integra con soluzioni di cattura dei pacchetti (ad esempio, Cisco Security Packet Analyzer), consentendo di registrare sessioni di rete selezionate per successivi approfondimenti e analisi. In secondo luogo, per ampliare le capacit\u00e0 di sicurezza, abbiamo sviluppato un protocollo speciale chiamato nvzFlow, che consente di<\/p>\n<p>\u00c8 chiaro che parlando dei sistemi di analisi Netflow in termini di sicurezza, il mercato non \u00e8 limitato a una sola soluzione di Cisco. \u00c8 possibile utilizzare sia soluzioni commerciali che gratuite o parzialmente gratuite. \u00c8 piuttosto strano se nel blog di Cisco cito come esempio soluzioni dei concorrenti, quindi dir\u00f2 qualche parola su come la telemetria di rete pu\u00f2 essere analizzata utilizzando due strumenti popolari, simili nel nome, ma comunque diversi: SiLK e ELK.<\/p>\n<p>SiLK \u00e8 un insieme di strumenti (the System for Internet-Level Knowledge) per l'analisi del traffico, sviluppato dall'CERT\/CC americano e che supporta, nel contesto dell'articolo odierno, Netflow (le versioni 5 e 9, le pi\u00f9 popolari), IPFIX e sFlow e attraverso varie utilit\u00e0 (rwfilter, rwcount, rwflowpack, ecc.) eseguire varie operazioni sulla telemetria di rete per rilevare segni di attivit\u00e0 non autorizzate. Ma \u00e8 necessario sottolineare un paio di punti importanti. SiLK \u00e8 uno strumento da linea di comando e condurre analisi operative, richiede continuamente l'immissione di comandi del tipo (rilevamento di pacchetti ICMP di dimensione superiore a 200 byte):<\/p>\n<p><code>rwfilter --flowtypes=all\/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15<\/code><\/p>\n<p>non \u00e8 molto comodo. Puoi utilizzare l'interfaccia grafica iSiLK, ma non ti faciliter\u00e0 molto la vita, risolvendo solo la funzione di visualizzazione, non sostituendo l'analista. E questo \u00e8 il secondo punto. A differenza delle soluzioni commerciali, che gi\u00e0 includono una solida base analitica, algoritmi per il rilevamento delle anomalie, flussi di lavoro e cos\u00ec via, nel caso di SiLK dovrai fare tutto questo da solo, il che richieder\u00e0 da te competenze leggermente diverse rispetto all'uso di strumenti gi\u00e0 pronti all'uso. Questo non \u00e8 n\u00e9 buono n\u00e9 cattivo \u2014 \u00e8 una caratteristica di quasi tutti gli strumenti gratuiti, che presuppongono che tu sappia cosa fare e che l'utensile ti aiuter\u00e0 in questo (gli strumenti commerciali dipendono meno dalle competenze degli utenti, sebbene presuppongano comunque che gli analisti comprendano almeno le basi delle indagini e del monitoraggio della rete). Ma torniamo a SiLK. Il ciclo di lavoro di un analista con esso appare come segue:<\/p>\n<ul>\n<li>Formulazione dell'ipotesi. Dobbiamo capire cosa cercheremo all'interno della telemetria di rete, conoscere gli attributi unici con cui identificheremo le varie anomalie o minacce.<\/li>\n<li>Costruzione del modello. Dopo aver formulato l'ipotesi, programmiamo la stessa utilizzando Python, shell o altri strumenti non inclusi in SiLK.<\/li>\n<li>Test. \u00c8 il momento di verificare la correttezza della nostra ipotesi, che viene confermata o smentita mediante le utility SiLK, che iniziano con 'rw', 'set', 'bag'.<\/li>\n<li>Analisi dei dati reali. Nella gestione industriale, SiLK ci aiuta a identificare qualcosa e l'analista deve rispondere alle domande \"Abbiamo trovato ci\u00f2 che ci aspettavamo?\", \"Questo corrisponde alla nostra ipotesi?\", \"Come ridurre il numero di falsi allarmi?\", \"Come migliorare il tasso di riconoscimento?\" e cos\u00ec via.<\/li>\n<li>Miglioramento. Nella fase finale, miglioriamo quanto fatto in precedenza: creiamo modelli, ottimizziamo e raffiniamo il codice, riformuliamo e chiarifichiamo l'ipotesi, e altro ancora.<\/li>\n<\/ul>\n<p>Questo ciclo sar\u00e0 applicabile anche a Cisco Stealthwatch, solo che quest'ultimo automatizza questi cinque passaggi al massimo, riducendo il numero di errori dell'analista e aumentando la tempestivit\u00e0 nella rilevazione degli incidenti. Ad esempio, in SiLK puoi arricchire le statistiche di rete con dati esterni su indirizzi IP malevoli utilizzando script scritti a mano, mentre in Cisco Stealthwatch questa \u00e8 una funzione integrata che ti mostra immediatamente un segnale di allerta se nel traffico di rete si verifica un'interazione con indirizzi IP in una blacklist.<\/p>\n<p>Se si sale nella piramide \"di costo\" per il software di analisi del flusso, a SiLK, completamente gratuito, segue un ELK condizionatamente gratuito, composto da tre componenti chiave: Elasticsearch (indicizzazione, ricerca e analisi dei dati), Logstash (input\/output dei dati) e Kibana (visualizzazione). A differenza di SiLK, dove bisogna scrivere tutto da soli, ELK ha gi\u00e0 molte librerie\/moduli pronti (alcuni a pagamento, altri no) che automatizzano l'analisi della telemetria di rete. Ad esempio, il filtro GeoIP in Logstash consente di associare gli indirizzi IP osservati alla loro posizione geografica (mentre Stealthwatch ha questa funzione integrata).<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nELK ha anche una community abbastanza ampia che scrive componenti mancanti per questa soluzione di monitoraggio. Ad esempio, per lavorare con Netflow, IPFIX e sFlow, puoi utilizzare il modulo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, se non sei soddisfatto del modulo Logstash Netflow, che supporta solo Netflow.<\/p>\n<p>Anche se offre maggiore tempestivit\u00e0 nella raccolta di flussi e nella loro ricerca, ELK al momento non ha un'analisi integrata ricca per la rilevazione di anomalie e minacce nella telemetria di rete. Ci\u00f2 significa che seguendo il ciclo di vita descritto in precedenza, dovrai descrivere autonomamente i modelli di violazione e poi utilizzarli nel sistema operativo (non ci sono modelli integrati).<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCi sono naturalmente estensioni pi\u00f9 sofisticate per ELK, che gi\u00e0 includono alcuni modelli per l'individuazione di anomalie nella telemetria di rete, ma queste estensioni costano e qui sorge la domanda se valga la pena \u2014 scrivere un modello simile da soli, acquistare la sua implementazione per il proprio strumento di monitoraggio o comprare una soluzione pronta nella classe Network Traffic Analysis.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn realt\u00e0, non voglio entrare in polemica su cosa sia meglio, spendere soldi e acquistare una soluzione pronta per il monitoraggio di anomalie e minacce nella telemetria di rete (ad esempio, Cisco Stealthwatch) oppure risolvere autonomamente e adattare SiLK, ELK o nfdump o OSU Flow Tools a ogni nuova minaccia (parlo degli ultimi due di essi, dalla volta scorsa)? Ognuno sceglie per s\u00e9 e ognuno ha le proprie motivazioni per scegliere una delle due opzioni. Volevo solo mostrare che la telemetria di rete \u00e8 uno strumento molto importante per garantire la sicurezza della rete della propria infrastruttura interna e non dovrebbe essere trascurato, per non unirsi alla lista di aziende il cui nome viene menzionato nei media con epiteti come \u201chackerate\u201d, \u201cche non rispettavano i requisiti di sicurezza informatica\u201d, \u201cche non pensano alla sicurezza dei propri dati e a quelli dei clienti\u201d. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">ha raccontato<\/a><\/noindex> In conclusione, vorrei elencare alcuni consigli chiave ai quali vale la pena attenersi nella strutturazione del monitoraggio della sicurezza informatica della propria infrastruttura interna:<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNon limitatevi solo al perimetro! Utilizzate (e scegliete) l'infrastruttura di rete non solo per il trasferimento del traffico da un punto A a un punto B, ma anche per affrontare questioni di sicurezza informatica.<\/p>\n<ol>\n<li>Esplorate i meccanismi di monitoraggio della sicurezza informatica esistenti nel vostro hardware di rete e sfruttateli.<\/li>\n<li>Per il monitoraggio interno, date la preferenza all'analisi della telemetria: consente di rilevare fino all'80-90% di tutti gli incidenti di sicurezza informatica, facendo ci\u00f2 che non \u00e8 possibile con la cattura dei pacchetti di rete e risparmiando spazio di archiviazione per tutti gli eventi di sicurezza informatica.<\/li>\n<li>Per il monitoraggio dei flussi utilizzate Netflow v9 o IPFIX: forniscono pi\u00f9 informazioni nel contesto della sicurezza e permettono di monitorare non solo IPv4, ma anche IPv6, MPLS, ecc.<\/li>\n<li>Utilizzate un protocollo di flusso non campionato: fornisce maggiori informazioni per la rilevazione delle minacce. Ad esempio, Netflow o IPFIX.<\/li>\n<li>Sfruttate un protocollo di flusso non campionato: offre pi\u00f9 dettagli per la rilevazione delle minacce. Ad esempio, Netflow o IPFIX.<\/li>\n<li>Controlla il caricamento delle tue apparecchiature di rete: potrebbe non riuscire a gestire anche il protocollo flow. In tal caso, considera l'applicazione di sensori virtuali o di un Netflow Generation Appliance.<\/li>\n<li>Implementa il controllo principalmente a livello di accesso: questo ti dar\u00e0 la possibilit\u00e0 di vedere il 100% di tutto il traffico.<\/li>\n<li>Se non hai scelta e stai utilizzando apparecchiature di rete russe, scegli quelle che supportano i protocolli flow o dispongono di porte SPAN\/RSPAN.<\/li>\n<li>Combina sistemi di rilevazione\/prevenzione delle intrusioni ai confini con sistemi di analisi del traffico all'interno della rete (compresi i cloud).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer quanto riguarda l'ultimo consiglio, vorrei portare un'illustrazione che ho gi\u00e0 menzionato in precedenza. Vedi che se in passato il servizio di sicurezza Cisco costruiva quasi interamente il proprio sistema di monitoraggio della sicurezza basandosi su sistemi di rilevazione delle intrusioni e metodi basati su firme, ora solo il 20% degli incidenti ricade su di essi. Un altro 20% \u00e8 basato sui sistemi di analisi del traffico, il che indica che queste soluzioni non sono un capriccio, ma strumenti reali nell'attivit\u00e0 dei servizi di sicurezza delle moderne imprese. Inoltre, hai per la loro implementazione ci\u00f2 che \u00e8 pi\u00f9 importante: l'infrastruttura di rete, il cui investimento pu\u00f2 essere ulteriormente protetto assegnando funzioni di monitoraggio della sicurezza alla rete.<\/p>\n<p><img decoding=\"async\" alt=\"I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo scelto di non trattare il tema della reazione alle anomalie o minacce rilevate nei flussi di rete, ma penso sia chiaro che il monitoraggio non deve fermarsi solo alla rilevazione della minaccia. Dovrebbe essere seguito da una reazione, preferibilmente in modalit\u00e0 automatica o automatizzata. Ma questo \u00e8 gi\u00e0 un argomento per un altro materiale.<\/p>\n<p>Informazioni aggiuntive:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/products\/ios-nx-os-software\/ios-netflow\/index.html\">Descrizione di Cisco IOS Netflow<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/community.cisco.com\/t5\/security-documents\/netflow-support-matrix\/ta-p\/3644638\">Matrice di compatibilit\u00e0 di Netflow in diverse soluzioni Cisco<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/dam\/en\/us\/td\/docs\/security\/stealthwatch\/netflow\/Cisco_NetFlow_Configuration.pdf\">Guida alla configurazione di Netflow su diverse piattaforme Cisco<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">Comunit\u00e0 sFlow<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ciscolive.com\/c\/dam\/r\/ciscolive\/us\/docs\/2015\/pdf\/LTRSEC-3336.pdf\">Laboratorio sull'uso di Stealthwatch, SiLK ed ELK per analizzare Netflow dal punto di vista della sicurezza<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/\">Sito di SiLK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/analysis-handbook.pdf\">Guida di trecento pagine sull'uso di SiLK con un sacco di esempi<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/logstash\/current\/netflow-module.html\">Modulo Netflow di Logstash<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.cisco.com\/security\/step-by-step-setup-of-elk-for-netflow-analytics\">Guida passo passo di Cisco per l'analisi di Netflow in ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">Analisi di NetFlow v.9 Cisco ASA con Logstash (ELK)<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Soluzione Cisco Stealthwatch<\/a><\/noindex><\/li>\n<\/ul>\n<p>PS. Se ti \u00e8 pi\u00f9 facile percepire a voce tutto ci\u00f2 che \u00e8 stato scritto sopra, puoi guardare una presentazione di un'ora che ha servito da base per questa nota.<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"ncDRZsueETo\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/ncDRZsueETo\/hqdefault.jpg\" alt=\"Guarda il video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/464601\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439. \u0410 \u0435\u0441\u043b\u0438 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0443\u0442\u043e\u0447\u043d\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u0438 \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c, \u043a\u0430\u043a \u0432\u044b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0432\u0430\u0435\u0442\u0435 \u0430\u0442\u0430\u043a\u0438 \u0432\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u043e\u0442\u0432\u0435\u0442\u043e\u043c \u0431\u0443\u0434\u0435\u0442, \u043a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u0443\u043f\u043e\u043c\u0438\u043d\u0430\u043d\u0438\u0435 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0430\u0442\u0430\u043a (intrusion detection systems, IDS). \u0418 \u0442\u043e, \u0447\u0442\u043e \u0431\u044b\u043b\u043e \u0435\u0434\u0438\u043d\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37437","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47I protocolli Flow come strumento di monitoraggio della sicurezza della rete interna | ProHoster","description":"Quando si parla di monitoraggio della sicurezza di una rete aziendale o governativa interna, a molti viene in mente il controllo delle fughe di informazioni e l'implementazione di soluzioni DLP.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:17:38+00:00","article:modified_time":"2019-10-31T19:17:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37437","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 17:49:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:26:28","updated":"2026-01-23 17:49:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}