Netflow no Gerenciamento e Segurança de Rede

Nesse post reproduzo artigo de minha autoria publicado na revista RTI - edição de Julho/12. Vocês poderão ver a edição virtual da revista em http://www.arandanet.com.br/midiaonline/rti/index.html 

As áreas de rede e segurança trabalham como duas retas paralelas na maior parte das empresas, com interesses diferentes porém não antagônicos. Enquanto a primeira se preocupa em fazer com que os dados trafeguem o mais rápido possível até o seu destino, a outra procura garantir que cheguem com segurança.  Um observador externo diria com razão que esses objetivos são na verdade complementares, já que os dados precisam trafegar ao mesmo tempo com velocidade e segurança.  Mas é de outro ponto em comum que gostaria de comentar nesse artigo: ambos tem a mesma deficiência: falta de visibilidade da rede. Tanto os administradores de rede como de segurança gerenciam equipamentos limitados em fornecer uma visão completa sobre o tráfego que passa pela rede. Essa limitação não afeta inicialmente os objetivos de cada área, mesmo com ela é possível garantir os requerimentos de velocidade e segurança, mas visibilidade significa conhecimento. Ao se conhecer melhor e mais profundamente o tráfego aumenta-se consideravelmente a eficiência da administração.

Foi certamente levando isso em consideração que a Cisco criou em 1996 o protocolo Netflow para coleta de informações de tráfego. Em poucos anos se tornou o padrão da indústria e motivou o IETF a iniciar um grupo de trabalho para a criação de um padrão formal, IPFIX (Internet Protocol Flow Information eXport), definido em várias RFCs e presente na maior parte dos switches e roteadores de diferentes fabricantes. É interessante observar que apesar do nome criado pela IETF e por concorrentes, como JFlow pela Juniper e NetStream pela 3Com, hoje HP, o termo original continuou como o mais usado, mesmo por aqueles que não são usuários Cisco. A versão mais atual e base das RFCs é a 9 embora a mais utilizada seja a 5.

O serviço está baseado na coleta das informações básicas dos fluxos de comunicação de rede e seu envio a um analisador que irá gerar informações gerenciais como a base de referencia (baseline) do tráfego, os protocolos mais utilizados ou um mapa completo da comunicação de rede. A coleta ocorre normalmente no próprio equipamento de rede embora haja produtos especializados nessa função, chamados de coletores. O seu êxito está em responder às perguntas de “quem”, “o que”, “quando”, “onde” e “como” em relação à rede.  É importante ressaltar que ele não inclui a inspeção total dos pacotes (deep packet inspection), a única forma de dizer com precisão o que está sendo transmitido.  Mas para a administração pura de rede, que não leva em conta segurança, essa informação não é necessária e os benefícios são muitos: planejamento de capacidade, previsão de crescimento de rede, planejamento de QoS, detecção de anomalias, remanejamento de equipamentos ociosos, entre outros.  Por tudo isso sua implementação e uso é recomendado para empresas de qualquer porte e tamanho de orçamento. Há inclusive versões disponíveis de analisadores e coletores em código aberto.

Uso em Segurança

Por permitir a detecção de anomalias o protocolo passou rapidamente a ser utilizado também em segurança, já que um ataque de rede, interno ou externo, é por definição uma anomalia. Há quem inclusive defenda que essa deveria ser a forma como as empresas detectam ataques de rede, em crítica direta à segurança de perímetro representada pelos firewalls e IPS. Eu discordo e defendo o uso combinado, para não dizer integrado, dessas tecnologias. A segurança de perímetro ainda é o melhor filtro de tráfego indesejado e é ainda insubstituível. Por outro lado há carências que são supridas pela detecção de anomalias. 

A primeira delas é a segurança da rede interna, normalmente implementada com os mesmos produtos utilizados no perímetro.  É muito complexo e dispendioso analisar todo o tráfego interno com produtos instalados em determinados segmentos de rede. Complexo porque dificilmente uma rede de grande porte terá um só ponto onde se poderá instalar um único equipamento. Dispendioso porque o volume de tráfego será bem mais alto, exigindo produtos mais parrudos.  Como os dados de netflow são coletados nos equipamentos de rede já existentes, por onde passa todo o tráfego de rede, ambos temas são solucionados. A segunda carência é justamente relacionada aos ataques DoS e principalmente DDoS, áreas em que firewalls e IPS são limitados. Para isso a detecção de anomalias é bem mais eficiente. A terceira é que por mais avançado que seja, um equipamento perimetral ainda depende de assinaturas ou algoritmos para detectar um ataque. Algo completamente novo não será detectado, mas pode (repito, pode) ser detectado como anomalia.

Mais recentemente a Cisco expandiu o uso do protocolo em segurança ao criar o NSEL (NetFlow Security Event Logging), extensão do Netflow implementada em firewalls que inclui informações de como um determinado fluxo foi tratado pelo dispositivo, ou seja, se os pacotes foram ou não bloqueados. Essa informação já é exportada pelos firewalls através de eventos syslog ou outros métodos, mas de acordo com os entusiastas há vantagens em concentrar tudo em um único analisador, além é claro de melhorar os resultados gerenciais, que dirão não somente se há um flow anômalo mas também se este flow foi ou não bloqueado por um firewall. Esse é um ótimo exemplo de integração de segurança perimetral com detecção de anomalias.

Outra maneira de integrar Netflow, firewalls e IPS é via os sistemas SIEM, abordados nos últimos dois artigos aqui na RTI. Quanto mais informação é recebida pelo sistema melhor será seus alertas, relatórios e ações relativas a compliance e resposta a incidentes.  Em geral o SIEM não receberia diretamente os dados de flow mas eventos gerados pelo analisador, como um alerta de desvio de baseline, computador desconhecido comunicando-se ou outra anomalia. Nenhuma das três possibilidades de uso do Netflow em segurança são excludentes, muito pelo contrário, e dependendo da situação particilar de cada empresa há vantagens claras em utilizar todas elas.