{"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\/pt\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Quando se trata de monitoramento da seguran\u00e7a de redes corporativas internas ou institucionais, muitos associam isso ao controle de vazamentos de informa\u00e7\u00f5es e \u00e0 implementa\u00e7\u00e3o de solu\u00e7\u00f5es DLP. Mas se tentarmos esclarecer a quest\u00e3o e perguntar como voc\u00ea detecta ataques na rede interna, a resposta geralmente ser\u00e1 uma men\u00e7\u00e3o a sistemas de detec\u00e7\u00e3o de intrus\u00f5es (intrusion detection systems, IDS). E o que era a \u00fanica op\u00e7\u00e3o h\u00e1 10-20 anos, hoje se torna um anacronismo. Existe uma alternativa mais eficaz, e em alguns casos, a \u00fanica possibilidade de monitoramento da rede interna - usar protocolos de fluxo, que inicialmente eram destinados \u00e0 solu\u00e7\u00e3o de problemas de rede, mas que ao longo do tempo se transformaram em uma ferramenta muito interessante de seguran\u00e7a. \u00c9 sobre quais protocolos de fluxo existem e quais deles ajudam melhor a detectar ataques de rede, onde \u00e9 mais eficaz implementar o monitoramento de fluxo, em que prestar aten\u00e7\u00e3o ao implantar tal esquema, e at\u00e9 mesmo como isso pode ser<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>N\u00e3o vou me aprofundar na quest\u00e3o \"Por que \u00e9 necess\u00e1rio monitorar a seguran\u00e7a da infraestrutura interna?\" A resposta parece ser clara. Mas se voc\u00ea ainda quiser se certificar de que hoje isso \u00e9 imprescind\u00edvel, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">veja<\/a><\/noindex> um pequeno v\u00eddeo apresentando 17 maneiras de invadir uma rede corporativa protegida por um firewall. Portanto, vamos considerar que entendemos que o monitoramento interno \u00e9 necess\u00e1rio e agora s\u00f3 resta saber como organiz\u00e1-lo.<\/p>\n<p>Eu destacaria tr\u00eas fontes principais de dados para monitoramento da infraestrutura em n\u00edvel de rede:<\/p>\n<ul>\n<li>\"tr\u00e1fego bruto\", que capturamos e submetemos \u00e0 an\u00e1lise em sistemas de an\u00e1lise,<\/li>\n<li>eventos a partir dos dispositivos de rede pelos quais o tr\u00e1fego passa,<\/li>\n<li>informa\u00e7\u00f5es sobre o tr\u00e1fego obtidas por meio de um dos protocolos de fluxo.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA captura de tr\u00e1fego bruto \u00e9 a op\u00e7\u00e3o mais popular entre os especialistas em seguran\u00e7a, pois surgiu historicamente como a primeira. Os sistemas de detec\u00e7\u00e3o de intrus\u00f5es de rede (o primeiro sistema comercial de detec\u00e7\u00e3o de intrus\u00f5es foi o NetRanger da Wheel Group, adquirido pela Cisco em 1998) tratavam exatamente da captura de pacotes (e, posteriormente, de sess\u00f5es), nas quais se buscavam certas assinaturas (\u201cregras decisivas\u201d na terminologia da FSTEC), sinalizando ataques. Certamente, \u00e9 poss\u00edvel analisar tr\u00e1fego bruto n\u00e3o apenas com IDS, mas tamb\u00e9m com outros meios (como Wireshark, tcpdump ou a funcionalidade NBAR2 no Cisco IOS), mas geralmente eles carecem de uma base de conhecimento que distingue uma ferramenta de seguran\u00e7a da informa\u00e7\u00e3o de uma ferramenta de TI comum.<\/p>\n<p>Portanto, sistemas de detec\u00e7\u00e3o de intrus\u00f5es. O m\u00e9todo mais antigo e mais popular de detec\u00e7\u00e3o de ataques de rede, que est\u00e1 se saindo bem em sua tarefa no per\u00edmetro (n\u00e3o importa qual \u2014 corporativo, de centro de dados, segmento, etc.), mas falha em redes modernas comutadas e definidas por software. No caso de uma rede constru\u00edda com base em comutadores comuns, a infraestrutura dos sensores de detec\u00e7\u00e3o de intrus\u00f5es se torna grande demais \u2014 voc\u00ea ter\u00e1 que instalar um sensor para cada conex\u00e3o com o n\u00f3 cujos ataques deseja monitorar. Qualquer fabricante, claro, ficar\u00e1 feliz em vender-lhe centenas e milhares de sensores, mas creio que seu or\u00e7amento n\u00e3o suportar\u00e1 tais despesas. Posso dizer que mesmo na Cisco (onde somos desenvolvedores do NGIPS), n\u00e3o conseguimos fazer isso, embora, aparentemente, o pre\u00e7o n\u00e3o devesse ser um problema \u2014 afinal, \u00e9 nossa pr\u00f3pria solu\u00e7\u00e3o. Al\u00e9m disso, surge a quest\u00e3o de como conectar o sensor nesse caso. Em um ponto de interrup\u00e7\u00e3o? E se o pr\u00f3prio sensor falhar? Exigir a presen\u00e7a de um m\u00f3dulo de bypass no sensor? Usar divisores (tap)? Tudo isso encarece a solu\u00e7\u00e3o e a torna invi\u00e1vel para empresas de qualquer porte.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoc\u00ea pode tentar \"anexar\" um sensor a uma porta SPAN\/RSPAN\/ERSPAN e direcionar para ela o tr\u00e1fego das portas necess\u00e1rias do switch. Essa op\u00e7\u00e3o parcialmente resolve o problema descrito no par\u00e1grafo anterior, mas gera outro \u2014 a porta SPAN n\u00e3o consegue receber todo o tr\u00e1fego que ser\u00e1 direcionado a ela \u2014 ela n\u00e3o ter\u00e1 capacidade suficiente. Teremos que sacrificar algo. Ou deixar algumas das portas sem monitoramento (neste caso, voc\u00ea precisar\u00e1 prioriz\u00e1-las), ou direcionar n\u00e3o todo o tr\u00e1fego da porta, mas apenas um tipo espec\u00edfico. Em qualquer caso, poderemos perder alguns ataques. Al\u00e9m disso, a porta SPAN pode estar ocupada para outros fins. Assim, teremos que revisar a topologia existente da rede e, possivelmente, fazer ajustes nela para cobrir ao m\u00e1ximo sua rede com o n\u00famero atual de sensores dispon\u00edveis (e coordenar isso com a TI).<\/p>\n<p>E se sua rede usar rotas assim\u00e9tricas? E se voc\u00ea tiver implantado ou planejar implantar SDN? E se voc\u00ea precisar monitorar m\u00e1quinas virtualizadas ou cont\u00eaineres, cujo tr\u00e1fego nem chega ao switch f\u00edsico? Essas quest\u00f5es n\u00e3o s\u00e3o apreciadas pelos fabricantes tradicionais de IDS, pois n\u00e3o sabem como respond\u00ea-las. Talvez eles tentem convenc\u00ea-lo de que todas essas tecnologias modernas s\u00e3o apenas uma moda e que voc\u00ea n\u00e3o precisa delas. Talvez eles falem sobre a necessidade de come\u00e7ar pequeno. Ou talvez digam que voc\u00ea deve instalar uma poderosa m\u00e1quina central na rede e direcionar todo o tr\u00e1fego para ela usando balanceadores. Qualquer que seja a op\u00e7\u00e3o sugerida, voc\u00ea precisa entender claramente o qu\u00e3o adequada ela \u00e9 para voc\u00ea. E s\u00f3 depois disso tomar uma decis\u00e3o sobre a abordagem para o monitoramento da seguran\u00e7a da infraestrutura de rede. Retornando \u00e0 captura de pacotes, quero dizer que esse m\u00e9todo continua sendo muito popular e importante, mas seu prop\u00f3sito principal \u00e9 o controle das fronteiras; fronteiras entre sua organiza\u00e7\u00e3o e a Internet, fronteiras entre o datacenter e o restante da rede, fronteiras entre o sistema de controle e o segmento corporativo. Nesses pontos, os IDS\/IPS cl\u00e1ssicos ainda t\u00eam seu lugar e desempenham bem as fun\u00e7\u00f5es para as quais foram projetados.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVamos passar para a segunda op\u00e7\u00e3o. A an\u00e1lise de eventos provenientes de dispositivos de rede tamb\u00e9m pode ser utilizada para fins de detec\u00e7\u00e3o de ataques, mas n\u00e3o como o mecanismo principal, pois permite detectar apenas uma pequena classe de intrus\u00f5es. Al\u00e9m disso, possui uma certa reatividade \u2014 o ataque deve acontecer primeiro, depois deve ser registrado pelo dispositivo de rede, que de alguma forma sinalizar\u00e1 o problema de seguran\u00e7a. Existem v\u00e1rias maneiras de fazer isso. Pode ser syslog, RMON ou SNMP. Os \u00faltimos dois protocolos para monitoramento de rede, no contexto da seguran\u00e7a, s\u00e3o utilizados somente se precisamos detectar um ataque DoS ao pr\u00f3prio equipamento de rede, pois com RMON e SNMP podemos, por exemplo, rastrear a carga do processador central do dispositivo ou suas interfaces. Esta \u00e9 uma das maneiras mais \u201cbaratas\u201d (syslog ou SNMP est\u00e3o dispon\u00edveis para todos), mas tamb\u00e9m a mais ineficaz entre todas as formas de monitoramento da seguran\u00e7a da infraestrutura interna \u2014 muitos ataques ficam simplesmente ocultos para ele. Claro que n\u00e3o devemos negligenci\u00e1-los e a an\u00e1lise do syslog ajuda a identificar altera\u00e7\u00f5es na configura\u00e7\u00e3o do pr\u00f3prio dispositivo, sua compromiss\u00e3o, mas a detec\u00e7\u00e3o de ataques em toda a rede n\u00e3o \u00e9 muito adequada.<\/p>\n<p>A terceira op\u00e7\u00e3o \u00e9 a an\u00e1lise das informa\u00e7\u00f5es sobre o tr\u00e1fego que passa por um dispositivo que suporta um dos v\u00e1rios protocolos de fluxo. Neste caso, independentemente do protocolo, a infraestrutura de trabalho com fluxos deve necessariamente consistir em tr\u00eas componentes:<\/p>\n<ul>\n<li>Gera\u00e7\u00e3o ou exporta\u00e7\u00e3o de fluxo. Esta fun\u00e7\u00e3o geralmente \u00e9 atribu\u00edda a um roteador, switch ou outro dispositivo de rede, que, ao permitir o tr\u00e1fego de rede passar por ele, destaca os par\u00e2metros-chave que s\u00e3o ent\u00e3o enviados para o m\u00f3dulo de coleta. Por exemplo, o protocolo Netflow da Cisco \u00e9 suportado n\u00e3o apenas em roteadores e switches, incluindo os virtuais e industriais, mas tamb\u00e9m em controladores sem fio, firewalls e at\u00e9 servidores.<\/li>\n<li>Coleta de fluxo. Considerando que em uma rede moderna geralmente h\u00e1 mais de um dispositivo de rede, surge a tarefa de coletar e consolidar fluxos, que \u00e9 resolvida com a ajuda dos chamados coletores, que processam os fluxos recebidos e depois os transmitem para an\u00e1lise.<\/li>\n<li>An\u00e1lise de fluxo. O analisador assume a principal tarefa intelectual e, aplicando diferentes algoritmos aos fluxos, faz determinadas infer\u00eancias. Por exemplo, no contexto da fun\u00e7\u00e3o de TI, esse analisador pode identificar gargalos na rede ou analisar o perfil de carga do tr\u00e1fego para futuras otimiza\u00e7\u00f5es. Para a seguran\u00e7a da informa\u00e7\u00e3o, esse analisador pode detectar vazamentos de dados, a propaga\u00e7\u00e3o de malware ou ataques DoS. <\/li>\n<\/ul>\n<p>N\u00e3o se deve pensar que uma arquitetura de tr\u00eas camadas \u00e9 muito complexa \u2014 todas as outras op\u00e7\u00f5es (exceto, talvez, sistemas de monitoramento de rede que operam com SNMP e RMON) funcionam de acordo com ela. Temos um gerador de dados para an\u00e1lise, que pode ser um dispositivo de rede ou um sensor independente. Temos um sistema de coleta de alarmes e um sistema de gerenciamento de toda a infraestrutura de monitoramento. Os dois \u00faltimos componentes podem ser integrados em um \u00fanico n\u00f3, mas em redes mais ou menos grandes, eles geralmente s\u00e3o distribu\u00eddos por pelo menos dois dispositivos, para garantir escalabilidade e confiabilidade.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAo contr\u00e1rio da an\u00e1lise de pacotes, que se baseia no estudo do cabe\u00e7alho e do corpo dos dados de cada pacote e das sess\u00f5es que deles s\u00e3o compostas, a an\u00e1lise de fluxos baseia-se na coleta de metadados sobre o tr\u00e1fego de rede. Quando, quanto, de onde e para onde, como... estas s\u00e3o as perguntas que a an\u00e1lise de telemetria de rede responde por meio de v\u00e1rios protocolos de fluxo. Inicialmente, eles foram utilizados para analisar estat\u00edsticas e encontrar problemas de TI na rede, mas depois, com o desenvolvimento de mecanismos anal\u00edticos, tornou-se poss\u00edvel aplic\u00e1-los \u00e0 mesma telemetria para fins de seguran\u00e7a. Vale ressaltar que a an\u00e1lise de fluxos n\u00e3o substitui e n\u00e3o anula a captura de pacotes. Cada um desses m\u00e9todos tem sua pr\u00f3pria \u00e1rea de aplica\u00e7\u00e3o. Mas, no contexto deste artigo, a an\u00e1lise de fluxos \u00e9 a que melhor se adapta ao monitoramento da infraestrutura interna. Voc\u00ea tem dispositivos de rede (e n\u00e3o importa se operam em uma paradigma de software definido ou de acordo com regras est\u00e1ticas) que um ataque n\u00e3o pode contornar. Um sensor IDS cl\u00e1ssico pode ser contornado, mas um dispositivo de rede que suporta o protocolo de fluxo n\u00e3o pode. Esta \u00e9 a vantagem desse m\u00e9todo. <\/p>\n<p>Por outro lado, se voc\u00ea precisar de provas para as autoridades policiais ou para seu pr\u00f3prio grupo de investiga\u00e7\u00e3o de incidentes, n\u00e3o poder\u00e1 fazer sem captura de pacotes \u2014 a telemetria de rede n\u00e3o \u00e9 uma c\u00f3pia do tr\u00e1fego que pode ser usada na coleta de evid\u00eancias; ela \u00e9 necess\u00e1ria para a detec\u00e7\u00e3o em tempo real e a tomada de decis\u00f5es na \u00e1rea de seguran\u00e7a da informa\u00e7\u00e3o. Em contrapartida, usando a an\u00e1lise de telemetria, voc\u00ea pode \"registrar\" n\u00e3o todo o tr\u00e1fego de rede (caso contr\u00e1rio, a Cisco e os data centers cuidar\u00e3o disso :-), mas apenas aquele que participa do ataque. Ferramentas de an\u00e1lise de telemetria, nesse sentido, complementam bem os mecanismos tradicionais de captura de pacotes, permitindo que sejam feitos capturas seletivas e armazenamento. Caso contr\u00e1rio, voc\u00ea ter\u00e1 que ter uma enorme infraestrutura de armazenamento.<\/p>\n<p>Vamos imaginar uma rede operando a 250 Mbit\/s. Se voc\u00ea quiser armazenar todo esse volume, precisar\u00e1 de um armazenamento de 31 MB para um segundo de transmiss\u00e3o de tr\u00e1fego, 1,8 GB para um minuto, 108 GB para uma hora e 2,6 TB para um dia. Para armazenar os dados di\u00e1rios de uma rede com largura de banda de 10 Gbit\/s, voc\u00ea precisar\u00e1 de um armazenamento de 108 TB. E alguns reguladores exigem que os dados de seguran\u00e7a sejam armazenados por anos... A grava\u00e7\u00e3o \"sob demanda\", que a an\u00e1lise de fluxos ajuda a implementar, reduz consideravelmente esses n\u00fameros. A prop\u00f3sito, se falarmos sobre a rela\u00e7\u00e3o entre o volume de dados gravados da telemetria de rede e a captura completa dos dados, ela \u00e9 de aproximadamente 1 para 500. Para os valores mencionados acima, o armazenamento da decodifica\u00e7\u00e3o completa de todo o tr\u00e1fego di\u00e1rio seria de 5 e 216 GB, respectivamente (pode-se at\u00e9 gravar em um pen drive comum).<\/p>\n<p>Se os m\u00e9todos de an\u00e1lise de dados de rede brutos quase n\u00e3o mudam de fornecedor para fornecedor, no caso da an\u00e1lise de fluxos a situa\u00e7\u00e3o \u00e9 diferente. Existem v\u00e1rias op\u00e7\u00f5es de protocolos de fluxos, e as diferen\u00e7as entre elas devem ser conhecidas especialmente no contexto da seguran\u00e7a. O protocolo mais popular \u00e9 o Netflow, desenvolvido pela Cisco. Existem v\u00e1rias vers\u00f5es deste protocolo, que diferem nas suas capacidades e na quantidade de informa\u00e7\u00f5es sobre o tr\u00e1fego que s\u00e3o registradas. A vers\u00e3o atual \u00e9 a nove (Netflow v9), que serviu de base para o padr\u00e3o industrial Netflow v10, tamb\u00e9m conhecido como IPFIX. Hoje, a maioria dos fornecedores de rede suporta precisamente Netflow ou IPFIX em seu equipamento. Por\u00e9m, h\u00e1 diversas outras op\u00e7\u00f5es de protocolos de fluxo \u2014 sFlow, jFlow, cFlow, rFlow, NetStream, etc., sendo que o sFlow \u00e9 o mais popular. \u00c9 ele que mais frequentemente \u00e9 suportado pelos fabricantes nacionais de equipamentos de rede devido \u00e0 sua facilidade de implementa\u00e7\u00e3o. Quais s\u00e3o as principais diferen\u00e7as entre o Netflow, que se tornou um padr\u00e3o de facto, e o sFlow? Eu destacaria algumas. Primeiro, o Netflow tem campos ajust\u00e1veis pelo usu\u00e1rio, ao contr\u00e1rio dos campos fixos no sFlow. E, segundo, e isso \u00e9 o mais crucial em nosso caso, o sFlow coleta o que se chama de telemetria amostrada; ao contr\u00e1rio da telemetria n\u00e3o amostrada do Netflow e do IPFIX. Qual \u00e9 a diferen\u00e7a entre eles?<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nImagine que voc\u00ea decidiu ler o livro \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 de meus colegas \u2014 Gary McIntyre, Joseph Muniz e Nadeem AlFardan (no link voc\u00ea pode baixar uma parte do livro). Voc\u00ea tem tr\u00eas op\u00e7\u00f5es para alcan\u00e7ar esse objetivo \u2014 ler o livro na \u00edntegra, skim (passar os olhos) por ele, parando a cada 10 ou 20 p\u00e1ginas, ou tentar encontrar um resumo dos conceitos principais em algum blog ou servi\u00e7o como o SmartReading. Portanto, a telemetria n\u00e3o amostrada \u00e9 como ler cada \u201cp\u00e1gina\u201d do tr\u00e1fego de rede, ou seja, analisar os metadados de cada pacote. A telemetria amostrada \u00e9 um estudo seletivo do tr\u00e1fego na esperan\u00e7a de que nas amostras selecionadas se encontre o que voc\u00ea precisa. Dependendo da velocidade do canal, a telemetria amostrada ir\u00e1 disponibilizar para an\u00e1lise a cada 64, 200, 500, 1000, 2000 ou at\u00e9 10000 pacotes.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo contexto da monitora\u00e7\u00e3o de seguran\u00e7a da informa\u00e7\u00e3o, isso significa que a telemetria amostrada \u00e9 boa para detectar ataques DDoS, varreduras e propaga\u00e7\u00e3o de malware, mas pode perder ataques at\u00f4micos ou multi-pacotes que n\u00e3o foram inclu\u00eddos na amostra enviada para an\u00e1lise. A telemetria n\u00e3o amostrada n\u00e3o tem essas desvantagens e seu espectro de detec\u00e7\u00e3o de ataques \u00e9 muito mais amplo. Aqui est\u00e1 uma pequena lista de eventos que podem ser detectados usando ferramentas de an\u00e1lise de telemetria de rede.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nObviamente, algum analisador de c\u00f3digo aberto de Netflow n\u00e3o permitir\u00e1 isso, pois sua principal tarefa \u00e9 coletar telemetria e realizar uma an\u00e1lise b\u00e1sica do ponto de vista de TI. Para identificar amea\u00e7as de seguran\u00e7a da informa\u00e7\u00e3o com base em fluxos, \u00e9 necess\u00e1rio equipar o analisador com diversos mecanismos e algoritmos que consigam identificar problemas de ciberseguran\u00e7a com base em campos padr\u00e3o ou personalizados do Netflow, enriquecendo os dados padr\u00e3o com informa\u00e7\u00f5es externas de v\u00e1rias fontes de Threat Intelligence, entre outras.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPortanto, se voc\u00ea tiver a op\u00e7\u00e3o, escolha o Netflow ou IPFIX. Mas mesmo que seu equipamento funcione apenas com sFlow, como \u00e9 o caso dos fabricantes nacionais, mesmo assim voc\u00ea pode extrair valor dele no contexto de seguran\u00e7a. <\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo ver\u00e3o de 2019, realizei uma an\u00e1lise das capacidades dispon\u00edveis por fabricantes de hardware de rede russo, e todos eles, exceto NSG, Pol\u00edgono e Kraftway, afirmavam suportar sFlow (pelo menos, Zelax, NatEx, Eltex, QTech, Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA pr\u00f3xima quest\u00e3o que voc\u00ea enfrentar\u00e1 \u00e9 onde implementar o suporte ao fluxo para fins de seguran\u00e7a? Na verdade, a quest\u00e3o n\u00e3o est\u00e1 exatamente formulada corretamente. Nos equipamentos modernos, o suporte a protocolos de fluxo est\u00e1 quase sempre presente. Portanto, eu reformularia a pergunta de outra maneira: onde \u00e9 mais eficaz coletar a telemetria em termos de seguran\u00e7a? A resposta ser\u00e1 bastante \u00f3bvia: no n\u00edvel de acesso, onde voc\u00ea ver\u00e1 100% de todo o tr\u00e1fego, onde ter\u00e1 informa\u00e7\u00f5es detalhadas sobre os hosts (MAC, VLAN, ID da interface), onde poder\u00e1 at\u00e9 monitorar o tr\u00e1fego P2P entre os hosts, o que \u00e9 cr\u00edtico para detectar varreduras e a dissemina\u00e7\u00e3o de malware. No n\u00edvel do n\u00facleo, parte do tr\u00e1fego pode simplesmente n\u00e3o ser vis\u00edvel, e no n\u00edvel de per\u00edmetro voc\u00ea ver\u00e1, bem, se tiver sorte, um quarto de todo o seu tr\u00e1fego de rede. Mas se, por algum motivo, houver dispositivos desconhecidos em sua rede, permitindo que invasores \"entrem e saiam\" contornando o per\u00edmetro, ent\u00e3o a an\u00e1lise da telemetria a partir dele n\u00e3o trar\u00e1 resultado algum. Portanto, para uma cobertura m\u00e1xima, recomenda-se habilitar a coleta de telemetria precisamente no n\u00edvel de acesso. Vale ressaltar que mesmo quando falamos sobre virtualiza\u00e7\u00e3o ou cont\u00eaineres, nos comutadores virtuais modernos, o suporte ao fluxo tamb\u00e9m \u00e9 frequentemente encontrado, permitindo controlar o tr\u00e1fego ali.<\/p>\n<p>Mas, j\u00e1 que levantei o tema, \u00e9 preciso responder \u00e0 pergunta: e se, de fato, o equipamento, f\u00edsico ou virtual, n\u00e3o suportar protocolos de fluxo? Ou se sua ativa\u00e7\u00e3o for proibida (por exemplo, em segmentos industriais para garantir a confiabilidade)? Ou se sua ativa\u00e7\u00e3o levar a uma alta carga do processador central (isso acontece em equipamentos desatualizados)? Para resolver essa quest\u00e3o, existem sensores virtuais especializados (flow sensor), que s\u00e3o, na verdade, simples divisores que permitem que o tr\u00e1fego passe por eles e o transmitem na forma de fluxo para o m\u00f3dulo de coleta. No entanto, neste caso, enfrentamos todos os problemas que discutimos anteriormente relacionados \u00e0s ferramentas de captura de pacotes. Ou seja, \u00e9 preciso entender n\u00e3o apenas as vantagens da tecnologia de an\u00e1lise de fluxos, mas tamb\u00e9m suas limita\u00e7\u00f5es.<\/p>\n<p>Mais um ponto importante a se lembrar ao falar sobre ferramentas de an\u00e1lise de fluxos. Se, em rela\u00e7\u00e3o \u00e0s ferramentas convencionais de gera\u00e7\u00e3o de eventos de seguran\u00e7a, aplicamos a m\u00e9trica EPS (eventos por segundo), para a an\u00e1lise de telemetria essa m\u00e9trica n\u00e3o \u00e9 aplic\u00e1vel; ela \u00e9 substitu\u00edda por FPS (fluxos por segundo). Assim como no caso do EPS, sua previs\u00e3o n\u00e3o \u00e9 poss\u00edvel, mas podemos estimar o n\u00famero aproximado de fluxos que um dispositivo gera, dependendo de sua fun\u00e7\u00e3o. Na Internet, voc\u00ea pode encontrar tabelas com valores aproximados para diferentes tipos de dispositivos corporativos e condi\u00e7\u00f5es, que permitir\u00e3o que voc\u00ea estime quais licen\u00e7as voc\u00ea precisa para ferramentas de an\u00e1lise e qual ser\u00e1 sua arquitetura. O fato \u00e9 que um sensor IDS \u00e9 limitado por uma certa largura de banda, que ele pode \"extrair\", e o coletor de fluxos tamb\u00e9m tem suas limita\u00e7\u00f5es, que precisam ser compreendidas. Portanto, em grandes redes distribu\u00eddas geograficamente, geralmente h\u00e1 v\u00e1rios coletores. Quando descrevi, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">como a rede \u00e9 monitorada dentro da Cisco<\/a><\/noindex>, j\u00e1 mencionei o n\u00famero de nossos coletores - s\u00e3o 21. E isso em uma rede espalhada por cinco continentes e que conta com cerca de quinhentos mil dispositivos ativos).<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo sistema de monitoramento de Netflow, usamos nossa pr\u00f3pria solu\u00e7\u00e3o <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, que \u00e9 especificamente voltado para resolver quest\u00f5es de seguran\u00e7a. Possui muitos motores integrados para detectar atividades an\u00f4malas, suspeitas e claramente maliciosas, permitindo a detec\u00e7\u00e3o de uma ampla gama de amea\u00e7as \u2014 desde minera\u00e7\u00e3o de criptomoedas at\u00e9 vazamento de informa\u00e7\u00f5es, desde a dissemina\u00e7\u00e3o de malware at\u00e9 fraudes. Assim como a maioria dos analisadores de fluxo, o Stealthwatch \u00e9 constru\u00eddo em uma arquitetura de tr\u00eas n\u00edveis (gerador \u2014 coletor \u2014 analisador), mas \u00e9 complementado por uma s\u00e9rie de caracter\u00edsticas interessantes que s\u00e3o importantes no contexto do material em quest\u00e3o. Primeiro, ele se integra com solu\u00e7\u00f5es de captura de pacotes (por exemplo, Cisco Security Packet Analyzer), permitindo gravar sess\u00f5es de rede selecionadas para investiga\u00e7\u00e3o e an\u00e1lise aprofundadas posteriores. Em segundo lugar, especialmente para expandir as quest\u00f5es de seguran\u00e7a, desenvolvemos um protocolo especial chamado nvzFlow, que permite \u201ctransmitir\u201d a atividade de aplicativos em n\u00f3s finais (servidores, esta\u00e7\u00f5es de trabalho, etc.) para telemetria e envi\u00e1-la ao coletor para an\u00e1lise adicional. Se na sua vers\u00e3o original o Stealthwatch funciona com qualquer protocolo de fluxo (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) em n\u00edvel de rede, o suporte ao nvzFlow permite correlacionar dados tamb\u00e9m em n\u00edvel de n\u00f3, aumentando assim a efetividade de todo o sistema e permitindo a visualiza\u00e7\u00e3o de mais ataques do que os analisadores de fluxo de rede convencionais.<\/p>\n<p>\u00c9 claro que, ao falar sobre sistemas de an\u00e1lise Netflow do ponto de vista da seguran\u00e7a, o mercado n\u00e3o se limita a uma \u00fanica solu\u00e7\u00e3o da Cisco. Voc\u00ea pode usar tanto solu\u00e7\u00f5es comerciais quanto gratuitas ou freemium. \u00c9 um tanto estranho se eu citar solu\u00e7\u00f5es de concorrentes no blog da Cisco, ent\u00e3o direi algumas palavras sobre como a telemetria de rede pode ser analisada com duas ferramentas populares, cujos nomes s\u00e3o semelhantes, mas ainda assim diferentes \u2014 SiLK e ELK.<\/p>\n<p>SiLK \u00e9 um conjunto de ferramentas (o Sistema para Conhecimento em N\u00edvel da Internet) para an\u00e1lise de tr\u00e1fego, desenvolvido pelo CERT\/CC dos EUA e que suporta, no contexto deste artigo, Netflow (as vers\u00f5es mais populares 5 e 9), IPFIX e sFlow. Com a ajuda de v\u00e1rias utilidades (rwfilter, rwcount, rwflowpack, etc.), ele realiza diversas opera\u00e7\u00f5es sobre a telemetria de rede com o objetivo de detectar sinais de atividades n\u00e3o autorizadas. No entanto, \u00e9 importante destacar alguns pontos. SiLK \u00e9 uma ferramenta de linha de comando e realiza an\u00e1lises operacionais continuamente atrav\u00e9s de comandos do tipo (detec\u00e7\u00e3o de pacotes ICMP maiores que 200 bytes):<\/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>n\u00e3o \u00e9 muito conveniente. Voc\u00ea pode usar a interface gr\u00e1fica iSiLK, mas ela n\u00e3o facilita muito sua vida, cumprindo somente a fun\u00e7\u00e3o de visualiza\u00e7\u00e3o, e n\u00e3o de substitui\u00e7\u00e3o do analista. Esse \u00e9 o segundo ponto. Ao contr\u00e1rio das solu\u00e7\u00f5es comerciais, que j\u00e1 possuem uma base anal\u00edtica s\u00f3lida embutida, algoritmos de detec\u00e7\u00e3o de anomalias e fluxos de trabalho, no caso do SiLK, voc\u00ea ter\u00e1 que realizar tudo isso por conta pr\u00f3pria, o que exigir\u00e1 de voc\u00ea um conjunto de compet\u00eancias um pouco diferente em compara\u00e7\u00e3o ao uso de ferramentas prontas para o trabalho. Isso n\u00e3o \u00e9 bom nem ruim \u2014 \u00e9 uma caracter\u00edstica de quase qualquer ferramenta gratuita, que pressup\u00f5e que voc\u00ea saiba o que fazer, enquanto ela apenas o ajuda nesse processo (a ferramenta comercial \u00e9 menos dependente das compet\u00eancias de seus usu\u00e1rios, embora tamb\u00e9m presuma que os analistas compreendam pelo menos os fundamentos de investiga\u00e7\u00f5es e monitoramento de rede). Mas vamos voltar ao SiLK. O ciclo de trabalho de um analista com ele se apresenta da seguinte forma:<\/p>\n<ul>\n<li>Formula\u00e7\u00e3o de hip\u00f3teses. Precisamos entender o que vamos procurar dentro da telemetria de rede, conhecer os atributos \u00fanicos pelos quais identificaremos certas anomalias ou amea\u00e7as.<\/li>\n<li>Constru\u00e7\u00e3o do modelo. Ap\u00f3s formular a hip\u00f3tese, programamos ela utilizando Python, shell ou outras ferramentas que n\u00e3o est\u00e3o inclu\u00eddas no SiLK.<\/li>\n<li>Teste. Chegou a hora de verificar a validade de nossa hip\u00f3tese, que \u00e9 confirmada ou refutada por meio de utilit\u00e1rios SiLK, que come\u00e7am com 'rw', 'set', 'bag'.<\/li>\n<li>An\u00e1lise de dados reais. Em opera\u00e7\u00e3o industrial, o SiLK nos ajuda a identificar algo e o analista deve responder \u00e0s perguntas \"Encontramos o que esper\u00e1vamos?\", \"Isso corresponde \u00e0 nossa hip\u00f3tese?\", \"Como reduzir o n\u00famero de falsos positivos?\", \"Como melhorar a taxa de reconhecimento?\" e assim por diante.<\/li>\n<li>Melhoria. Na fase final, aprimoramos o que foi feito anteriormente \u2014 criamos modelos, melhoramos e otimizamos o c\u00f3digo, reformulamos e esclarecemos a hip\u00f3tese, entre outras.<\/li>\n<\/ul>\n<p>Este ciclo tamb\u00e9m ser\u00e1 aplic\u00e1vel ao Cisco Stealthwatch, embora este \u00faltimo automatize ao m\u00e1ximo esses cinco passos, reduzindo o n\u00famero de erros do analista e aumentando a rapidez na detec\u00e7\u00e3o de incidentes. Por exemplo, no SiLK, voc\u00ea pode enriquecer as estat\u00edsticas de rede com dados externos sobre IPs maliciosos atrav\u00e9s de scripts que voc\u00ea mesmo escreveu, enquanto no Cisco Stealthwatch \u2014 esta \u00e9 uma fun\u00e7\u00e3o incorporada, que imediatamente lhe mostra um alerta se houver intera\u00e7\u00e3o com endere\u00e7os IP da lista negra na sua rede.<\/p>\n<p>Se formos mais alto na pir\u00e2mide \"de pagamento\" de software de an\u00e1lise de fluxo, o SiLK absolutamente gratuito ser\u00e1 seguido pelo ELK, que \u00e9 condicionalmente gratuito e consiste em tr\u00eas componentes principais \u2014 Elasticsearch (indexa\u00e7\u00e3o, busca e an\u00e1lise de dados), Logstash (entrada\/sa\u00edda de dados) e Kibana (visualiza\u00e7\u00e3o). Ao contr\u00e1rio do SiLK, onde tudo precisa ser escrito manualmente, o ELK j\u00e1 possui muitas bibliotecas\/m\u00f3dulos prontos (alguns pagos, outros n\u00e3o) que automatizam a an\u00e1lise de telemetria de rede. Por exemplo, o filtro GeoIP no Logstash permite vincular os IPs observados a suas localiza\u00e7\u00f5es geogr\u00e1ficas (no Stealthwatch isso \u00e9 uma fun\u00e7\u00e3o integrada).<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO ELK tamb\u00e9m possui uma comunidade bastante ampla que desenvolve componentes faltantes para esta solu\u00e7\u00e3o de monitoramento. Por exemplo, para trabalhar com Netflow, IPFIX e sFlow, voc\u00ea pode usar o m\u00f3dulo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, se voc\u00ea n\u00e3o estiver satisfeito com o M\u00f3dulo Netflow do Logstash, que suporta apenas Netflow.<\/p>\n<p>Oferecendo mais agilidade na coleta de fluxo e na busca nele, o ELK atualmente n\u00e3o possui uma an\u00e1lise rica incorporada para detec\u00e7\u00e3o de anomalias e amea\u00e7as na telemetria de rede. Ou seja, seguindo o ciclo de vida descrito acima, voc\u00ea ter\u00e1 que descrever os modelos de viola\u00e7\u00f5es por conta pr\u00f3pria e, em seguida, us\u00e1-los no sistema em opera\u00e7\u00e3o (n\u00e3o h\u00e1 modelos incorporados l\u00e1).<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nExistem, \u00e9 claro, extens\u00f5es mais avan\u00e7adas para ELK, que j\u00e1 incorporam alguns modelos de detec\u00e7\u00e3o de anomalias na telemetria de rede, mas essas extens\u00f5es custam dinheiro e aqui a quest\u00e3o \u00e9 se vale a pena \u2014 escrever um modelo semelhante por conta pr\u00f3pria, comprar a implementa\u00e7\u00e3o para seu sistema de monitoramento ou adquirir uma solu\u00e7\u00e3o pronta da classe Network Traffic Analysis.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe fato, n\u00e3o quero entrar na pol\u00eamica sobre o que \u00e9 melhor: gastar dinheiro e comprar uma solu\u00e7\u00e3o pronta para monitorar anomalias e amea\u00e7as na telemetria de rede (por exemplo, Cisco Stealthwatch) ou entender como funciona e adaptar o SiLK, ELK ou nfdump ou OSU Flow Tools (me referindo aos \u00faltimos dois). <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">falou<\/a><\/noindex> Cada um escolhe para si e cada um tem seus motivos para optar por uma das duas alternativas. Eu s\u00f3 queria mostrar que a telemetria de rede \u00e9 uma ferramenta muito importante na garantia da seguran\u00e7a da infraestrutura interna e n\u00e3o deve ser negligenciada, para n\u00e3o se juntar \u00e0 lista de empresas cujo nome \u00e9 mencionado na m\u00eddia com ep\u00edtetos como 'invadida', 'que n\u00e3o cumpria requisitos de seguran\u00e7a da informa\u00e7\u00e3o', 'que n\u00e3o se preocupa com a seguran\u00e7a de seus dados e dados de clientes'.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConcluindo, gostaria de listar algumas dicas-chave que deveriam ser seguidas ao estabelecer o monitoramento da seguran\u00e7a da informa\u00e7\u00e3o em sua infraestrutura interna:<\/p>\n<ol>\n<li>N\u00e3o se limite apenas ao per\u00edmetro! Use (e escolha) a infraestrutura de rede n\u00e3o apenas para transmitir tr\u00e1fego de um ponto A para um ponto B, mas tamb\u00e9m para abordar quest\u00f5es de ciberseguran\u00e7a.<\/li>\n<li>Estude os mecanismos existentes de monitoramento de seguran\u00e7a da informa\u00e7\u00e3o em seu equipamento de rede e utilize-os.<\/li>\n<li>Para o monitoramento interno, d\u00ea prefer\u00eancia \u00e0 an\u00e1lise de telemetria \u2014 ela permite detectar at\u00e9 80-90% de todos os incidentes de seguran\u00e7a da informa\u00e7\u00e3o, fazendo o que \u00e9 imposs\u00edvel com a captura de pacotes de rede e economizando espa\u00e7o para o armazenamento de todos os eventos de seguran\u00e7a da informa\u00e7\u00e3o.<\/li>\n<li>Para monitorar fluxos, use Netflow v9 ou IPFIX \u2014 eles fornecem mais informa\u00e7\u00f5es no contexto de seguran\u00e7a e permitem monitorar n\u00e3o apenas IPv4, mas tamb\u00e9m IPv6, MPLS, etc.<\/li>\n<li>Utilize um protocolo de fluxo n\u00e3o amostrado \u2014 ele fornece mais informa\u00e7\u00f5es para a detec\u00e7\u00e3o de amea\u00e7as. Por exemplo, Netflow ou IPFIX.<\/li>\n<li>Verifique a carga do seu equipamento de rede \u2013 pode ser que ele n\u00e3o consiga lidar com o processamento do protocolo flow. Nesse caso, considere o uso de sensores virtuais ou de um Netflow Generation Appliance.<\/li>\n<li>Implemente o controle principalmente no n\u00edvel de acesso \u2013 isso permitir\u00e1 que voc\u00ea veja 100% de todo o tr\u00e1fego.<\/li>\n<li>Se n\u00e3o houver outra escolha e voc\u00ea usar equipamentos de rede russos, escolha aqueles que suportam protocolos flow ou que possuem portas SPAN\/RSPAN.<\/li>\n<li>Combine sistemas de detec\u00e7\u00e3o\/preven\u00e7\u00e3o de intrus\u00f5es\/ataques nas bordas com sistemas de an\u00e1lise de fluxos na rede interna (incluindo nas nuvens).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuanto ao \u00faltimo conselho, gostaria de trazer uma ilustra\u00e7\u00e3o que j\u00e1 mencionei antes. Voc\u00ea pode ver que, enquanto anteriormente o servi\u00e7o de seguran\u00e7a da informa\u00e7\u00e3o da Cisco quase que totalmente constru\u00eda seu sistema de monitoramento da seguran\u00e7a da informa\u00e7\u00e3o baseado em sistemas de detec\u00e7\u00e3o de intrus\u00f5es e m\u00e9todos de assinatura, agora apenas 20% dos incidentes s\u00e3o associados a eles. Outros 20% v\u00eam de sistemas de an\u00e1lise de fluxos, o que indica que essas solu\u00e7\u00f5es n\u00e3o s\u00e3o um capricho, mas uma ferramenta real nas atividades dos servi\u00e7os de seguran\u00e7a da informa\u00e7\u00e3o das empresas modernas. Al\u00e9m disso, voc\u00ea tem para a sua implementa\u00e7\u00e3o a coisa mais importante \u2013 a infraestrutura de rede, cujo investimento pode ser adicionalmente protegido ao atribuir \u00e0 rede tamb\u00e9m fun\u00e7\u00f5es de monitoramento da seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n<p><img decoding=\"async\" alt=\"Protocolos de fluxo como ferramenta de monitoramento da seguran\u00e7a da rede interna\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEu intencionalmente n\u00e3o abordei o tema da resposta a anomalias ou amea\u00e7as detectadas nos fluxos de rede, mas acredito que est\u00e1 claro que o monitoramento n\u00e3o deve se limitar apenas \u00e0 detec\u00e7\u00e3o de amea\u00e7as. Deve haver uma resposta, preferencialmente em modo autom\u00e1tico ou automatizado. Mas isso j\u00e1 \u00e9 tema para um material separado.<\/p>\n<p>Informa\u00e7\u00f5es adicionais:<\/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\">Descri\u00e7\u00e3o do 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\">Matriz de suporte ao Netflow em v\u00e1rias solu\u00e7\u00f5es da 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\">Guia de configura\u00e7\u00e3o do Netflow em v\u00e1rias plataformas da Cisco<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">Comunidade 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\">Aula pr\u00e1tica sobre o uso do Stealthwatch, SiLK e ELK para an\u00e1lise do Netflow do ponto de vista da seguran\u00e7a<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/\">Site do SiLK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/analysis-handbook.pdf\">Guia de trezentas p\u00e1ginas sobre o uso do SiLK com uma abund\u00e2ncia de exemplos<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/logstash\/current\/netflow-module.html\">M\u00f3dulo Netflow do 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\">Guia passo a passo da Cisco para a an\u00e1lise de Netflow no ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">An\u00e1lise do NetFlow v.9 do Cisco ASA usando Logstash (ELK)<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Solu\u00e7\u00e3o Cisco Stealthwatch<\/a><\/noindex><\/li>\n<\/ul>\n<p>P.S. Se for mais f\u00e1cil para voc\u00ea compreender ouvindo, pode assistir a uma apresenta\u00e7\u00e3o de uma hora que serviu de base para esta 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=\"Por que no hosting comum a administra\u00e7\u00e3o do PrestaShop \u00e9 lenta, e no seu n\u00e3o \u00e9?\" 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.3 - 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\/pt\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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\udd47Protocolos Flow como ferramenta de monitoramento de seguran\u00e7a da rede interna | ProHoster","description":"Quando se trata de monitoramento de seguran\u00e7a de redes corporativas ou governamentais internas, muitos associam isso ao controle de vazamentos de informa\u00e7\u00f5es e \u00e0 implementa\u00e7\u00e3o de solu\u00e7\u00f5es DLP.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}