{"id":5241,"date":"2023-02-03T16:09:57","date_gmt":"2023-02-03T19:09:57","guid":{"rendered":"https:\/\/base4sec.com\/nao-categorizado\/por-que-usar-dados-de-fluxo-para-monitoramento\/"},"modified":"2023-02-03T16:09:57","modified_gmt":"2023-02-03T19:09:57","slug":"por-que-usar-dados-de-fluxo-para-monitoramento","status":"publish","type":"post","link":"https:\/\/base4sec.com\/pt-br\/technical-pt-br\/por-que-usar-dados-de-fluxo-para-monitoramento\/2023\/02\/03\/","title":{"rendered":"Por que usar dados de fluxo para monitoramento?"},"content":{"rendered":"
\n
\n
\n
\n

No ponto em que estamos localizados na crescente curva de evolu\u00e7\u00e3o tecnol\u00f3gica e, por consequ\u00eancia, das amea\u00e7as digitais, cresce na mesma intensidade a necessidade por visibilidade em rela\u00e7\u00e3o aos dados que est\u00e3o passando pelas infraestruturas dos mais variados tipos de organiza\u00e7\u00f5es. A demanda por essa visibilidade pode esbarrar em diversos aspectos t\u00e9cnicos, que variam desde a necessidade de boas estrat\u00e9gias para posicionamento dos equipamentos de captura at\u00e9 a necessidade por grandes quantidades de hardware para armazenamento e processamento dos dados capturados. Outro item que precisa de aten\u00e7\u00e3o \u00e9 o valor que os dados capturados t\u00eam, ou seja, \u00e9 importante saber se o que est\u00e1 sendo guardado traz de fato a visibilidade e a capacidade de monitoramento almejadas. Dessas ideias, naturalmente surgem algumas perguntas, e em rodas de discuss\u00e3o de Blue Teamers quest\u00f5es que est\u00e3o sempre presentes s\u00e3o: o que devo capturar? Capturar todo o trafego por menos tempo (devido \u00e0s limita\u00e7\u00f5es de hardware)? Capturar somente os metadados e realizar correla\u00e7\u00f5es com os logs dispon\u00edveis? Para responder a essas perguntas, somente um bom clich\u00ea: \u00c9 necess\u00e1rio trabalhar com equil\u00edbrio, pois ambas as abordagens trazem visibilidade e t\u00eam vantagens e desvantagens.<\/p>\n

A princ\u00edpio \u00e9 poss\u00edvel pensar que o cen\u00e1rio ideal \u00e9 ter o tr\u00e1fego completamente capturado para apoiar as atividades de resposta a incidentes, threat hunting, SOC, CSIRT, etc, uma vez que atrav\u00e9s da captura completa \u00e9 poss\u00edvel reconstruir a comunica\u00e7\u00e3o entre cliente e servidor e ter uma vis\u00e3o real do que ocorreu, mas, embora isso realmente possa parecer o melhor dos mundos para investiga\u00e7\u00f5es, a quantidade hist\u00f3rica dispon\u00edvel n\u00e3o vai passar de alguns dias ou semanas, devido \u00e0 grande quantidade de recursos necess\u00e1ria. Isso se torna um problema quando precisamos investigar algo que ocorreu num per\u00edodo anterior \u00e0 capacidade hist\u00f3rica, sem considerar os problemas que podem surgir quando se trata de tr\u00e1fego criptografado. Uma alternativa equilibrada \u00e9 obter metadados desse tr\u00e1fego integrados com logs, o que pode cobrir uma boa parte da organiza\u00e7\u00e3o em rela\u00e7\u00e3o a estat\u00edsticas sobre as conex\u00f5es realizadas entre os utilizadores da infraestrutura.<\/p>\n

Dentro deste contexto, o objetivo deste artigo \u00e9 discutir a segunda op\u00e7\u00e3o citada no par\u00e1grafo anterior, que \u00e9 uma abordagem interessante \u00e0 captura completa de tr\u00e1fego e que \u00e9 capaz de entregar boa visibilidade sobre temas como: quem se comunica com quem, quando ocorreu essa comunica\u00e7\u00e3o, por quanto tempo e com que frequ\u00eancia. Trata-se de capturar os fluxos de dados, export\u00e1-los e criar m\u00e9tricas de monitoramento baseadas nesses fluxos, atrav\u00e9s de protocolos como o que a Cisco originalmente deu o nome de NetFlow, e que posteriormente foi \u201ctraduzido\u201d para uma vers\u00e3o opensource \u00e0 qual foi dado o nome de IPFIX. Esse tipo de abordagem pode ser altamente ben\u00e9fico para o monitoramento cont\u00ednuo de uma organiza\u00e7\u00e3o, uma vez que possibilita manter rastreabilidade hist\u00f3rica muito maior sobre as comunica\u00e7\u00f5es pelo simples fato de que exige menos dos recursos de armazenamento quando comparado com captura completa de tr\u00e1fego.<\/p>\n

Este \u00e9 o primeiro de uma s\u00e9rie de 2 posts sobre esse assunto. Nele vamos definir alguns conceitos e refletir sobre estrat\u00e9gias de monitoramento e, em outro momento, abordaremos ferramentas, t\u00e9cnicas e demonstra\u00e7\u00f5es pr\u00e1ticas.<\/p>\n

O que \u00e9 Netflow\/Fluxo de dados\/Flow?<\/span><\/p>\n

Buscando a informa\u00e7\u00e3o direto na fonte, a RFC 7011 de 2013 que especifica o protocolo IPFIX, define o fluxo de dados, ou simplesmente flow, como sendo o seguinte: \u201cum conjunto de pacotes IP passando num ponto de observa\u00e7\u00e3o dentro da rede durante um certo intervalo de tempo, sendo que todos os pacotes que pertencem a um flow em particular t\u00eam um conjunto de propriedades em comum.\u201d<\/p>\n

As propriedades dos flows, tamb\u00e9m chamadas de flow-keys s\u00e3o cada campo que: (i) pertencem ao cabe\u00e7alho do pacote em si; (ii) s\u00e3o propriedades do pacote, como o tamanho em bytes; (iii) s\u00e3o derivadas da atividade de Tratamento dos Pacotes, como por exemplo o n\u00famero do Autonomous System (ASN).<\/p>\n

Trocando em mi\u00fados, cada flow \u00e9 um conjunto de pacotes agregados, ou seja, os pacotes n\u00e3o s\u00e3o considerados individualmente, como em uma abordagem de captura completa. \u00c9 como se as sequ\u00eancias de pacotes tivessem uma esp\u00e9cie de assinatura que \u00e9 usada para juntar os v\u00e1rios elementos de uma comunica\u00e7\u00e3o em um \u00fanico flow. Os flows cont\u00eam metadados valiosos sobre as comunica\u00e7\u00f5es e devem ser exportados por algum equipamento por onde o tr\u00e1fego passa, chamado de \u2018exportador\u2019 (normalmente firewalls, switches e roteadores), e coletados para an\u00e1lise posterior.<\/p>\n

Ainda segundo a RFC, a coleta desse fluxo serve para fins administrativos ou quaisquer outros, tais quais os citados no in\u00edcio desta publica\u00e7\u00e3o, como visibilidade, mas tamb\u00e9m troubleshooting, detec\u00e7\u00e3o de amea\u00e7as, monitoramento de performance e, por consequ\u00eancia, seguran\u00e7a!<\/p>\n

Metadados<\/span><\/p>\n

Como dito anteriormente, um equipamento exportador de fluxos identifica um flow como sendo um conjunto de pacotes com caracter\u00edsticas em comum pertencentes a uma determinada comunica\u00e7\u00e3o. Essas caracter\u00edsticas contidas nos pacotes s\u00e3o no m\u00ednimo: porta da interface de entrada, endere\u00e7os de IP de origem e destino, portas de origem e destino, protocolo e tipo de servi\u00e7o. Curiosamente estes tamb\u00e9m podem ser considerados como os principais atributos da comunica\u00e7\u00e3o que ser\u00e3o \u00fateis para an\u00e1lise posterior, sempre lembrando que se trata de metadados, ou seja: o conte\u00fado dos pacotes n\u00e3o est\u00e1 dispon\u00edvel. Falaremos sobre isso mais tarde.
\n\"imagem
\nExporta\u00e7\u00e3o<\/span><\/p>\n

Os processos de captura e an\u00e1lise de fluxos dependem basicamente de 3 componentes: um equipamento \u201cexportador\u201d; um equipamento \u201ccoletor\u201d; e, por \u00faltimo, um equipamento\/software analisador dos fluxos.
\n\"imagem
\nUm flow \u00e9 exportado quando cumpre certos requisitos: (i) o fluxo se torna inativo, ou seja, nenhum novo pacote relacionado a esse flow \u00e9 recebido at\u00e9 atingir o timeout (que \u00e9 configur\u00e1vel); (ii) o flow ainda est\u00e1 tramitando pacotes, por\u00e9m atinge o timeout estabelecido; (iii) algo na comunica\u00e7\u00e3o indica que ela foi terminada, por exemplo, flags TCP do tipo FIN ou RST.<\/p>\n

Ap\u00f3s isso, os flows s\u00e3o transmitidos ao coletor, que \u00e9 normalmente um equipamento centralizador para v\u00e1rios exportadores. Essa transmiss\u00e3o costuma ser feita via UDP, por\u00e9m os equipamentos mais modernos t\u00eam capacidade de transmitir via TCP para agregar algum controle, o que pode trazer algum impacto em rela\u00e7\u00e3o ao desempenho do dispositivo.<\/p>\n

O coletor tamb\u00e9m armazena esses flows para an\u00e1lise posterior via software, analisador dedicado, SIEM etc. Ao final da exporta\u00e7\u00e3o, o que temos para analisar s\u00e3o os conjuntos de metadados das comunica\u00e7\u00f5es, que tipicamente incluem: endere\u00e7os e portas de origem e destino (quando se trata de comunica\u00e7\u00f5es TCP ou UDP), Type of Service, timestamps de in\u00edcio e fim da comunica\u00e7\u00e3o, informa\u00e7\u00f5es sobre as interfaces de entrada e sa\u00edda do equipamento, flags TCP e protocolo encapsulado (tipo de dado tramitando, seja TCP ou UDP), informa\u00e7\u00f5es sobre protocolos de roteamento como BGP (next-hop, AS de origem, AS de destino…). A tabela abaixo mostra os campos presentes no cabe\u00e7alho do protocolo netflow V5.
\n\"imagem
\nOk, mas por que os dados de flows s\u00e3o \u00fateis?<\/span><\/p>\n

Os dados de fluxo s\u00e3o um importante aliado porque mostram, a um custo baixo, um resumo estat\u00edstico das comunica\u00e7\u00f5es que tramitam pelos exportadores. Por isso existe a necessidade de uma boa estrat\u00e9gia para escolher boas posi\u00e7\u00f5es de exporta\u00e7\u00e3o, ou seja, selecionar os equipamentos com maior potencial de visibilidade (firewalls, switches, roteadores). A depender da ferramenta escolhida para realizar a an\u00e1lise, (e h\u00e1 v\u00e1rias, tanto open source quanto comerciais) \u00e9 poss\u00edvel enxergar coisas como:<\/p>\n

\u2022<\/b>\u00a0Estat\u00edsticas de tr\u00e1fego divididas por aplica\u00e7\u00e3o; protocolo; dom\u00ednio; IP e porta de origem e destino;
\n\u2022<\/b>\u00a0Resumo estat\u00edstico (Top N) de endere\u00e7os, comunica\u00e7\u00f5es e at\u00e9 Autonomous Systems (AS);
\n\u2022<\/b>\u00a0Resumo estat\u00edstico das informa\u00e7\u00f5es descritas acima com enriquecimento pelas ferramentas de an\u00e1lise de flow\u00b8 ou pelo SIEM, como Geolocation e outros.<\/p>\n

Esse tipo de informa\u00e7\u00e3o ajuda a entender quest\u00f5es sobre a infraestrutura da organiza\u00e7\u00e3o. \u00c9 poss\u00edvel descobrir se existem aplica\u00e7\u00f5es proibidas sendo executadas; encontrar gargalos ou equipamentos com defeito; descobrir anomalias de excesso ou consumo exagerado de banda por algum equipamento; entender conex\u00f5es estranhas a endere\u00e7os de pa\u00edses com alto \u00edndice de ataques cibern\u00e9ticos, assim como ASs com m\u00e1 reputa\u00e7\u00e3o; comunica\u00e7\u00e3o com servidores de comando e controle, entre outras coisas.<\/p>\n

Novamente: os dados de flow n\u00e3o agregam o conte\u00fado das comunica\u00e7\u00f5es. Pensando nisso, um analista que disp\u00f5e apenas dessas informa\u00e7\u00f5es deve sempre associar alguns fatores para obter intelig\u00eancia desse tipo de metadado. A mesma observa\u00e7\u00e3o se aplica aos dados criptografados, mesmo onde o tr\u00e1fego \u00e9 completamente capturado. Essa associa\u00e7\u00e3o de fatores pode ser feita pensando:<\/p>\n

1.\u00a0<\/b>\u00a0Na direcionalidade do tr\u00e1fego \u2013 saber qual deveria ser a dire\u00e7\u00e3o t\u00edpica da conversa entre cliente e servidor, por exemplo: \u00e9 leg\u00edtimo que um servidor X da rede DMZ acesse um qualquer servi\u00e7o na internet na porta 1234?
\n2.\u00a0<\/b>\u00a0No tr\u00e1fego esperado associado ao protocolo envolvido na comunica\u00e7\u00e3o \u2013 conhecendo bem o funcionamento de certos protocolos, \u00e9 poss\u00edvel ter uma ideia se o tr\u00e1fego deveria ter uma dura\u00e7\u00e3o maior ou menor, uma quantidade de dados maior ou menor, e a partir disso encontrar anomalias;
\n3.\u00a0<\/b>\u00a0Em an\u00e1lises baseadas no tempo \u2013 para identificar picos de tr\u00e1fego que podem indicar transfer\u00eancia de arquivos, ou comunica\u00e7\u00f5es estranhas que podem se referir a respostas a comandos;<\/p>\n

Associando esses fatores \u00e9 poss\u00edvel criar baselines de monitoramento para, atrav\u00e9s das estat\u00edsticas disponibilizadas pelos flows, saber, por exemplo, se uma conex\u00e3o SSH (normalmente porta 22\/tcp) com dura\u00e7\u00e3o r\u00e1pida demais, ou se uma conex\u00e3o HTTP (porta 80\/tcp) demorada demais s\u00e3o acessos leg\u00edtimos ou s\u00e3o poss\u00edveis ataques. A tabela abaixo mostra exemplos de observa\u00e7\u00f5es que podem ser feitas associando os fatores descritos<\/p>\n

\"imagem
\nOs dados de flow tamb\u00e9m podem ser uma boa alternativa para tr\u00e1fego criptografado, quando a organiza\u00e7\u00e3o n\u00e3o disp\u00f5e de inspe\u00e7\u00e3o de TLS\/SSL: isso se mostra \u00fatil porque, caso n\u00e3o exista a capacidade de inspecionar tr\u00e1fego criptografado, uma captura completa desse tipo de tr\u00e1fego se torna um enorme desperd\u00edcio de recursos, principalmente quando falamos de armazenamento.<\/p>\n

Estrat\u00e9gias de captura<\/span><\/p>\n

\"imagem
\nNa estrutura acima, h\u00e1 v\u00e1rios locais onde os dados podem ser coletados. Honestamente, qualquer ponto de agrega\u00e7\u00e3o da rede \u00e9 um \u00f3timo candidato \u00e0 captura, tanto completa quanto somente dos flows. O primeiro ponto a ser observado \u00e9 que h\u00e1 diferentes n\u00edveis de criticidade e valor dos dados. Ao entender estes, juntamente com os volumes de dados produzidos em cada segmento, a organiza\u00e7\u00e3o pode planejar uma solu\u00e7\u00e3o de captura.<\/p>\n

Como sugest\u00e3o, os potenciais pontos de agrega\u00e7\u00e3o do cen\u00e1rio acima est\u00e3o diferenciados por cores.<\/p>\n

\u2022<\/b>\u00a0Na cor verde, pontos de exporta\u00e7\u00e3o de flow;
\n\u2022<\/b>\u00a0na cor vermelha, pontos onde pode ser necess\u00e1ria a captura completa; e,
\n\u2022<\/b>\u00a0Em \u00e2mbar, pontos que cont\u00eam muita informa\u00e7\u00e3o e s\u00e3o candidatos \u00e0 exporta\u00e7\u00e3o de flow, por\u00e9m, com menor prioridade.<\/p>\n

Se voc\u00ea ainda est\u00e1 numa fase de planejamento da captura dos dados, ou se pretende realizar uma reestrutura\u00e7\u00e3o do projeto de captura na sua infraestrutura, os passos a seguir podem dar uma no\u00e7\u00e3o do que fazer.\u00a01: Identificar os dados cr\u00edticos<\/b><\/p>\n

Capturar o tr\u00e1fego completo est\u00e1 longe de ser uma estrat\u00e9gia barata para a maioria das organiza\u00e7\u00f5es (se voc\u00ea tem condi\u00e7\u00f5es para isso, sinta-se privilegiado!). O primeiro passo que podemos tomar \u00e9 identificar quais s\u00e3o os dados mais cr\u00edticos da organiza\u00e7\u00e3o para definir a melhor estrat\u00e9gia para a visibilidade desses dados. Para esses dados e os ativos que os armazenam ou nos quais eles trafegam, voc\u00ea provavelmente vai precisar de captura completa.<\/p>\n

2: Entender a sua rede<\/b><\/p>\n

Parece \u00f3bvio, mas precisa ser dito: muitas organiza\u00e7\u00f5es n\u00e3o t\u00eam conhecimento, mesmo que em alto n\u00edvel dos seus sistemas e equipamentos (por exemplo: S.O e IP de todos os ativos). Uma boa estrat\u00e9gia pode ser come\u00e7ar mapeando os caminhos a partir dos dados cr\u00edticos para a Internet e para os sistemas desktop dos administradores que controlam esses dados.<\/p>\n

3: Identificar pontos de estrangulamento e pontos cr\u00edticos da rede<\/b><\/p>\n

Conhecendo bem a rede, \u00e9 poss\u00edvel identificar os pontos onde v\u00e1rias sub redes ou VLANs se encontram e considerar o n\u00edvel ideal de captura de dados. Em seguida, identificar as redes cr\u00edticas que operam com switches e roteadores e verificar suas capacidades de captura. Estes dispositivos est\u00e3o entre usu\u00e1rio e dados e a Internet (se os sistemas forem capazes de se conectar \u00e0 Internet).<\/p>\n

4: Identificar centros de gravidade cr\u00edticos<\/b><\/p>\n

Encontrar no ambiente, locais que possuem altas concentra\u00e7\u00f5es de determinado objeto: dados cr\u00edticos! Ao definir estes centros, a organiza\u00e7\u00e3o est\u00e1 pensando no que \u00e9 realmente importante em termos de prote\u00e7\u00e3o. Entretanto, os centros de gravidade cr\u00edticos incluem coisas diferentes, dependendo do tipo de neg\u00f3cio.<\/p>\n

A seguir, alguns exemplos:<\/p>\n

\u2022<\/b>\u00a0Reposit\u00f3rios de c\u00f3digo fonte (empresas de software)
\n\u2022<\/b>\u00a0Sistemas cont\u00e1beis (setor financeiro e empresas de capital aberto)
\n\u2022<\/b>\u00a0Sistemas administradores de sistemas (tendem a conter planos, senhas, diagramas e software)
\n\u2022<\/b>\u00a0Aplica\u00e7\u00f5es web desenvolvidas internamente usando credenciais (AD, LDAP)
\n\u2022<\/b>\u00a0Servidores DNS<\/p>\n

5: Planejar os exportadores de flow e pontos de captura completa<\/b><\/p>\n

Em locais de alto volume de tr\u00e1fego, como gateways de Internet, \u00e9 mais interessante capturar os fluxos de dados. Em pontos cr\u00edticos de estrangulamento de dados e dispositivos de rede cr\u00edticos, pode ser interessante implementar as duas abordagens: tanto fluxos quanto a captura completa.<\/p>\n

6: Verificar requisitos de conformidade<\/b><\/p>\n

Dados de flow podem ajudar a cumprir requisitos de conformidade de registros, por\u00e9m \u00e9 necess\u00e1rio verificar junto \u00e0 norma se eles s\u00e3o suficientes, e em quais pontos esses metadados podem ser usados para cumprir algum requisito.<\/p>\n

Conclus\u00e3o<\/span><\/p>\n

Apesar de todas as vantagens, capturar flow n\u00e3o \u00e9 uma bala de prata e n\u00e3o vai resolver todos os problemas de monitoramento da organiza\u00e7\u00e3o e traz consigo alguns inconvenientes, como por exemplo:<\/p>\n

\u2022<\/b>\u00a0\u00e9 poss\u00edvel identificar os equipamentos, mas \u00e9 necess\u00e1rio fazer an\u00e1lises e associa\u00e7\u00f5es para descobrir os usu\u00e1rios envolvidos com aquele tr\u00e1fego;
\n\u2022<\/b>\u00a0NATs podem tornar a captura inconsistente, porque o flow \u00e9 gravado no exportador, portanto \u00e9 necess\u00e1rio observar isso na hora de configur\u00e1-lo;
\n\u2022<\/b>\u00a0N\u00e3o custa repetir: n\u00e3o \u00e9 poss\u00edvel ver o conte\u00fado da comunica\u00e7\u00e3o atrav\u00e9s flows.<\/p>\n

Nesse sentido, \u00e9 sempre importante equilibrar, variar as abordagens e considerar as diversas possibilidades para melhorar a seguran\u00e7a e gerenciamento de uma maneira geral. Dados de fluxo s\u00e3o apenas mais um dos grandes aliados para prote\u00e7\u00e3o de infraestruturas.<\/p>\n

Finalizando o racioc\u00ednio, os flows s\u00e3o poderosos para monitoramento de qualquer rede e fornecem grande visibilidade da infraestrutura a baixo custo, justamente porque grande parte das organiza\u00e7\u00f5es j\u00e1 possui ativos capazes de export\u00e1-los, tanto em ambientes predominantemente on-premise quanto em ambientes de cloud ou h\u00edbridos: fornecedores como AWS e GCP disponibilizam os dados de fluxo para o cliente. Frequentemente, o que falta \u00e9 simplesmente ativar a exporta\u00e7\u00e3o dos flows e apontar para um coletor\/analisador. Para o caso de n\u00e3o existirem coletores\/analisadores dispon\u00edveis na organiza\u00e7\u00e3o, criar uma estrutura para an\u00e1lise \u00e9 relativamente simples e barato. Compra de hardware extra raramente \u00e9 necess\u00e1ria.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n