Publicado por: revistainternacionaldoconhecimento | 18/10/2010

ENGENHARIA – Uma Estratégia de Monitoramento do Tráfego de Redes baseada em NetFlow/IPFIX. Por Raphael R. Martins , Luiz Claudio Schara Magalhães e João L. Fernandes

Uma Estratégia de Monitoramento do Tráfego de Redes
baseada em NetFlow/IPFIX

Raphael R. Martins 1, Luiz Claudio Schara Magalhães 1, João L. Fernandes 2

1 Departamento de Engenharia de Telecomunicações – Universidade Federal Fluminense. Rua Passos da Pátria, 156 – Niterói – RJ – Brasil

2 Departamento de Ciência da Computação – Universidade Federal Fluminense (UFF).
Rua Passos da Pátria, 156 – Niterói – RJ – Brasil

raphael@vm.uff.br, schara@icarai.midiacom.uff.br, ccmjlf@vm.uff.br

Abstract. Analyzing the existing technologies for monitoring network usage, those based on flows (NetFlow / IPFIX) have proved to be more efficient. Open source applications that can generate quantitative graphs of network use are already available, providing information on the source and destination of flows. This paper presents an example of using a monitoring tool which was integrated into the network of the Federal Fluminense University (Brazil). We show that the information obtained through the tool can be used to ensure the quality and the safety of communications in computer networks.

Resumo. Analisando as tecnologias existentes para monitoramento do uso de redes, aquelas que se baseiam em fluxos (NETFLOW/ IPFIX) têm se apresentado mais eficientes. Já estão disponíveis aplicações do tipo “open source”, que permitem gerar gráficos da intensidade do uso da rede, fornecendo informações sobre a origem e o destino das transmissões. Neste trabalho, apresenta-se uma visão sobre a atividade de monitoramento de redes, através de uma ferramenta de monitoramento de fluxo integrada à rede da Universidade Federal Fluminense (Brasil). Mostra-se que as informações obtidas através da ferramenta podem ser utilizadas para garantir a qualidade e a segurança das comunicações em redes de computadores.

1. Introdução

Do início da Internet até agora, são registrados, anualmente, grande aumento do número de redes e computadores conectados. Segundo pesquisa da IDC (International Data Corporation) [1], o acesso à Internet, no Brasil, acumulou 15 milhões de novas conexões no segundo semestre de 2009. Contribuem para este aumento a grande diversidade de serviços que, a cada dia, são disponibilizados na rede, atraindo empresas, pessoas e negócios. Os avanços tecnológicos na área, como a popularização das redes sem fio, aliados à queda de preço dos equipamentos, também constituem fatores consideráveis para este crescimento. Como consequência, grandes desafios têm sido
impostos aos administradores de rede, que são os responsáveis pela garantia da qualidade e da segurança dos serviços prestados. Diante deste cenário, conhecer a utilização dos recursos da rede torna-se fundamental. As informações obtidas ao se monitorar uma rede viabilizam a realização de estudos, visando ao planejamento das ações de curto, médio e longo prazo, além de propiciarem um profundo conhecimento do comportamento da rede sob diversas situações. Estas informações também revelamfragilidades estruturais a serem tratadas pela equipe de segurança.
O presente trabalho vem chamar a atenção para a importância da atividade de monitoramento de redes de computadores, atividade que vem se tornando cada vez mais necessária perante o aumento do uso dos recursos computacionais interligados. A crescente velocidade das conexões e as inúmeras questões de segurança (como, por exemplo, impedir acessos indevidos e a contaminação por vírus) evidenciam a necessidade de tecnologias que sejam eficazes e que contribuam para a efetiva garantia da qualidade dos serviços. É nesse sentido que este trabalho estuda o monitoramento de fluxos de dados em redes, com base nas informações de origem e destino das comunicações. Esta tecnologia, inicialmente proposta pela Cisco com o nome de NetFlow, já se encontra em fase de padronização pelo IETF (Internet Engineering Task Force) [2]. Para avaliá-la, apresentamos um estudo de caso, tendo como cenário a rede da Universidade Federal Fluminense (UFF – Localizada na cidade de Niterói, no Estado do Rio de Janeiro – Brasil), abrangendo todas as suas 76 sub-redes. Os resultados apresentados foram obtidos a partir de cinco meses de medições, quando inúmeros casos de falhas de segurança foram detectados pela ferramenta. Os testes mostraram que, a partir do monitoramento dos fluxos IP, é possível conhecer o padrão de funcionamento da rede, designado aqui como PFR, cujas informações são essenciais para a administração, o planejamento e a segurança dos serviços.

2. Monitoramento de redes

O monitoramento de redes consiste na coleta e no registro de dados sobre o funcionamento dos elementos que as compõem. Os objetivos dessa tarefa podem ser variados, como, por exemplo: levantamentos estatísticos, análises de tráfego, programação de alertas, dentre outros. A análise pode ser feita somente por um período, ou de forma contínua, e com base em tecnologias diversas. Para escolher a melhor tecnologia de monitoramento de redes, é fundamental se ater aos objetivos, ou seja, quais resultados se esperam alcançar, para, então, selecionar os dados a serem coletados, pois só a coleta dos dados corretos trará os resultados esperados. Assim, se o que se deseja saber é o percentual de disponibilidade mensal da rede, será necessário registrar dados que reflitam essa disponibilidade, como, por exemplo, a quantidade de horas por mês que a rede ficou indisponível. Se, por outro lado, o que se deseja saber são os horários de maior utilização, uma estratégia seria registrar o total de bytes trafegados em determinados intervalos ao longo do dia e da noite. Os dois casos podem ser resolvidos com a utilização do protocolo SNMP (Simple Network Management Protocol).
Entretanto, ele não oferece facilidades para identificar quais as redes ou os hosts (internos e externos) demandaram mais consultas a um determinado servidor. O monitoramento de redes pode ser realizado a partir de dois métodos: o ativo e o passivo. No método ativo, um tráfego de prova é gerado e transmitido de forma controlada ao longo de um ou mais caminhos (roteadores) da rede. Durante a transmissão, é observada, nos receptores, a qualidade dos dados trafegados, bem como o desempenho da rede. Ao se utilizar esse método, é preciso considerar dois aspectos: o primeiro, é que o desempenho da rede é afetado pelo próprio tráfego de prova e o segundo, é que, nos casos em que o roteamento for dinâmico, o desempenho da medição pode ser melhor ou pior dependendo da rota escolhida. No método passivo, o tráfego real (ou sua estatística) é capturado em um ou mais pontos da rede para, então, ser analisado [3]. As métricas tradicionais de desempenho de rede são: retardo, perda de pacotes e vazão [4].

2.1 Sistemas de monitoramento de redes
Para facilitar a tarefa de monitoramento de redes foram criados softwares conhecidos como ”Sistemas de Monitoramento de Redes”, que conjugam as tecnologias existentes na análise de redes com a flexibilidade de programação, tornando a coleta e, muitas vezes, a análise dos dados, um processo automatizado. Um dos recursos essenciais que deve estar presente em um sistema de monitoramento é o armazenamento dos dados coletados, visando à formação de históricos. A partir dos históricos da atividade de uma rede, são feitas as análises que podem servir a diversas finalidades como, por exemplo, o planejamento de curto, médio e longo prazo objetivando a garantia da qualidade dos serviços executados na rede. Outro uso dos registros visa à garantia do funcionamento da rede de acordo com critérios previamente estabelecidos como, por exemplo, os SLAs (Service Level Agreements). Os provedores de serviços na área de telecomunicações, cujos contratos estejam baseados em SLAs, devem adotar como prática o monitoramento das redes sob sua responsabilidade, já que, normalmente, constitui condições de garantia contratual a manutenção de índices de quantidade e da qualidade do tráfego. Negligenciar tal controle pode acarretar grandes prejuízos à empresa.


Figura 1. Estrutura de funcionamento do SNMP

2.2. Tecnologias para monitoramento de redes.

Protocolo SNMP

A preocupação com a manutenção do estado do funcionamento da rede nasceu junto com a elaboração do protocolo IP – a RFC789 já aborda a queda da Arpanet em 27 de outubro de 1980 [5]. O ICMP [6] tinha como objetivo principal reportar erros nos datagramas IP entre as unidades conectadas. A partir da proposta do modelo OSI para o gerenciamento de redes, surgiram vários protocolos, dentre os quais podemos citar o CMISE/CMIP (Common Management Information Protocol). O SNMP, proposto pelo IETF, é o mais utilizado até hoje, com presença em todos os dispositivos de rede gerenciáveis. O SNMP é formado por uma estrutura modular. As informações são coletadas diretamente nos dispositivos de rede, que oferecem suporte a este protocolo, através da interação entre uma Entidade Gerenciadora e um Agente de Gerenciamento. Uma Entidade Gerenciadora pode gerenciar diversos dispositivos.
Por sua vez, um dispositivo pode ter diversos Objetos Gerenciados (vide Figura 1). Os Módulos MIB são constituídos por Objetos MIB que, em última análise, constituem as funcionalidades propriamente ditas, como, por exemplo, um contador de pacotes de uma interface de rede. A Figura 1 mostra as ligações entre os módulos previstos no protocolo SNMP. É possível verificar que uma Entidade Gerenciadora está ligada a diversos Dispositivos Gerenciados. Num cenário real, isto é representado por um servidor conectado a diversos componentes da rede, como Switches, hosts e servidores. Esses dispositivos possuem Objetos Gerenciados, que são componentes do dispositivo, como uma interface de rede, memória ou processador. O Agente de Gerenciamento faz a leitura das informações registradas por um Objeto MIB e envia o resultado para a Entidade Gerenciadora.

Monitoramento de fluxos – NetFlow e IPFIX

O aumento da complexidade das redes demandou um maior detalhamento da informação sobre os dados trafegados. O SNMP, apesar de toda a sua versatilidade, não oferecia facilidades para formação de bases de dados que auxiliassem na descoberta de aspectos mais subjetivos. Uma tentativa foi feita, chamada de METER MIB, padronizada pelo IETF na RFC2027 [7]; entretanto, segundo [8], não houve aceitação pela indústria. Nessa época, uma tecnologia da CISCO SYSTEM chamada de NetFlow, tornava-se cada vez mais popular. Em outubro de 2001, o IETF reuniu um novo grupo de trabalho para especificar os requisitos de um protocolo de medição de fluxos (IPFIX – IP Flow Information eXport). Era preciso algo que revelasse as tendências e comportamentos da rede levando a uma caracterização de tráfego mais detalhada e próxima dos elementos geradores de tráfego. Considerando a popularização da Internet como rede global e tendo como base o protocolo IP, com seus campos de endereço de origem e de destino (bem como portas de origem e de destino), nascia então um novo padrão de coleta de informações sobre a rede, baseada nos registro dos fluxos do protocolo IP. Em 2004, a IETF liberou a RFC 3917 [2] – IPFIX. Mais tarde, através da RFC3955 [9] (após avaliação de quatro outros protocolos: CRANE, Diameter, LFAP e Streaming IPDR), selecionou-se o protocolo NetFlow, versão 9, como base para a especificação do IPFIX. A justificativa para a escolha do NetFlow deveu-se à simplicidade desse protocolo, já que não possuía mecanismos de transporte, segurança, confiabilidade e redundância e, deste modo, o trabalho de construção dessas estruturas poderia ser realizado com todo o cuidado, a fim de fazê-lo o mais simples possível, evitando, assim, a sua sobrecarga [10].

NetFlow

A versão 9 do protocolo NetFlow, conforme descrito na RFC3954, apresenta a seguinte especificação: “Elementos de rede (roteadores e switches) reúnem dados sobre os fluxos e exportam para um coletor. Os dados coletados fornecem uma medição de granulação fina, altamente detalhada e flexível, para contabilidade dos recursos utilizados”.
Em seu artigo [10], a CISCO descreve um fluxo como um conjunto de pacotes IP, com os mesmos atributos, que atravessa um roteador ou switch. Esses atributos são a identificação do pacote IP, ou a impressão digital do pacote, e determina se o pacote é único ou similar a outros pacotes. Os seguintes atributos do pacote IP são usados pelo NetFlow v9: Endereço IP de origem, Endereço IP de destino, Porta de origem, Porta de destino, Tipo de protocolo de camada 3, Classe de Serviço e Interface do roteador ou Switch. Todos os pacotes de mesmo endereço IP de origem e destino, porta de origem e destino, protocolo, interface e classe de serviço são agrupados em um fluxo e, a partir daí, pacotes e bytes são registrados. Um novo fluxo só é criado quando é recebido um pacote que não pertence a nenhum outro fluxo. Um fluxo é unidirecional. Isto significa que os dados enviados de uma máquina A para uma máquina B, constituem um fluxo e os dados da máquina B, transmitidos em resposta à transmissão inicial da máquina A, constituem outro fluxo. Essa tecnologia é escalar, pois uma grande quantidade de informação de rede é condensada em uma base de dados chamada NetFlow Cache.

Figura 2. Funcionamento do NetFlow

A Figura 2 ilustra o funcionamento do Netflow. Existem duas maneiras de se obter acesso aos fluxos registrados no roteador ou switch. A primeira, é através da interface de comandos – desta forma, o acesso à informação é imediato. A outra forma é exportar os fluxos para um servidor, chamado pela CISCO de NetFlow Colector. O Netflow Colector tem a tarefa de montagem e compreensão dos fluxos exportados, além de combinar ou agregá-los para produção de relatórios que podem ser utilizados, por exemplo, para análise do tráfego e da segurança.
Ao contrário do SNMP, o processo que exporta os fluxos é acionado por condicionantes próprias e, uma vez configurado o IP do NetFlow Colector, este receberá os fluxos sempre que um fluxo chegar ao fim (quando o TCP possuir a flag FIN) ou quando um fluxo expirar. Pode-se considerar que um fluxo expirou sempre que estiver inativo por um determinado tempo (Nenhum pacote é recebido para esse fluxo) ou, caso o tempo de vida do um fluxo seja maior do que o tempo-limite configurado (longos downloads sendo executados). O valor de tempo padrão para os fluxos inativos é de 15 segundos, e, para o tempo máximo de vida do fluxo, é de 30 minutos. Quando cerca de 30 a 50 fluxos são agrupados e, normalmente, transportados via protocolo UDP para o servidor NetFlow Colector, cria-se um histórico a partir dos dados recebidos [11].

3. Estudo de caso

Considerando como cenário a rede da Universidade Federal Fluminense e, além disso, todos os aspectos relacionados ao gerenciamento e monitoramento abordados até agora, descrever-se-á um estudo de caso, que objetivou avaliar a tecnologia de monitoramento de fluxos IP na rede da UFF. Os objetivos específicos foram: montar uma estrutura de monitoramento de fluxos e coletar os dados ao longo de cinco meses, visando à caracterização de tráfego de forma global e individual, para cada uma das 76 redes que compõem a rede da Universidade, bem como analisar os resultados obtidos.

Figura 3. Testbed utilizado. Servidor de monitoramento conectado à porta do
Switch, com espelhamento habilitado, de modo a receber cópia do trafego da
UFF oriundo do link de Internet. NTI, HUAP e PV são Unidades da UFF que
abrigam os dispositivos de rede.

3.1. Metodologia utilizada

Para coletar os dados, foram utilizadas as seguintes ferramentas: SoftFlowd – Gerador de pacotes no formato NetFlow; Nfdump – Coletor de Pacotes NetFlow e o Nfsen – Visualizador gráfico do tráfego. A estratégia objetivou o monitoramento de todo o tráfego passando através do enlace entre a UFF e a Internet. Para tanto, utilizou-se o recurso de espelhamento de porta. A configuração permitiu que o servidor de monitoramento recebesse uma cópia de cada quadro Ethernet processado na interface do switch do link de Internet. O testbed pode ser observado na Figura 3. O hardware utilizado para o servidor foi fornecido pelo Laboratório MidiaCom/UFF (Laboratório de
Pesquisas em Comunicação de Dados Multimídia), com as seguintes características: processador com dois núcleos de 3.2 GHz, 2GB de memória RAM, placa de rede de 1Gbit ethernet e quatro discos SATA de 160 GB. Posteriormente, os discos de 160 foram substituídos por dois discos de 500GB, de forma a aumentar a capacidade de armazenamento do tráfego ao logo do tempo. O Sistema Operacional utilizado pelo servidor de monitoramento foi a distribuição Linux Fedora, versão 10. Todas as bibliotecas auxiliares foram instaladas através do software Yum, de acordo com as exigências das aplicações utilizadas (Nfsen, Nfdump e SoftFlowd)

3.2. Obtendo os dados

Para obtenção dos dados através das ferramentas, foram criados três perfis de captura dos fluxos: Redes_UFF, Protocolos e Anel_UFF, que serão detalhados a seguir:
Redes_UFF – Neste perfil, foram configurados filtros para registrar a atividade individual de cada rede da UFF.
Protocolos – Neste perfil, foram configurados filtros para registrar a atividade das portas do protocolo TCP e UDP mais utilizadas na Internet.
Anel_UFF – Neste perfil, foram configurados filtros para registrar a atividade dos switches que compõem o Anel da rede da UFF.
Para efeito deste artigo, detalharemos apenas o Perfil Redes UFF.

3.3 Criando filtros

Após a criação do perfil, é necessário fazer a programação dos filtros ou canais, como são chamados no Nfsen. Um filtro deixa passar para o perfil apenas os fluxos que correspondam aos critérios definidos, sendo que o mais comum é definir filtros por: protocolo (TCP, UDP, ICMP, GRE, ESP, AH, RSVP), versão de protocolo TCP (ipv4, ipv6), endereço IP, origem e destino, rede, porta, interface ou a combinação destes através de expressões.

3.4. Análises dos resultados do Perfil Redes UFF

O perfil Redes_UFF objetivou registrar individualmente a atividade de cada rede da UFF. Foram criados 76 filtros, um para cada rede. Os arquivos gerados pelo sistema, por padrão, armazenam cinco minutos do tráfego de cada rede e são identificados por ano, dia, mês, hora e minutos. Todos os arquivos foram armazenados na pasta e subpastas do perfil Redes_UFF. Cada pasta recebeu como nome o endereço de uma rede da UFF.
Cinco meses de dados foram coletados, inicialmente, e mais um mês adicional visando conhecer os impactos das modificações efetuadas nos parâmetros de configuração do gerador de pacotes (programa SoftFlowd). Para o processamento dos dados coletados, foram utilizados scripts do Linux (Shell Script), em conjunto com as ferramentas AWK e o próprio Nfdump.

Figura 4. Gráfico filtrado, mostrando a atividade de duas redes. Protocolo TCP.

Processamento dos dados coletados – Execução dos scripts

Após o término do período de captura dos fluxos, iniciou-se o processamento dos arquivos armazenados, visando conhecer o perfil de funcionamento da rede (PFR), através da consolidação dos registros de tráfego de cada rede da UFF. Os scripts foram escritos utilizando-se as linguagens: Shell Script, Awk e o próprio Nfdump, sendo que a primeira foi utilizada para as rotinas básicas de programação; a segunda, para os recursos de ordenação e filtragem; e a terceira, para leitura dos arquivos. As rotinas consistiam em varrer todas as pastas de armazenamento do perfil Redes_Uff, entrando na pasta correspondente, a cada mês, e executando o comando Nfdump seguido dos parâmetros, de modo a obter a totalização dos dados trafegados. Na Figura 4, podemos observar um exemplo de Gráfico mostrando o tráfego de duas sub-redes, obtido através
do recurso de filtros do Nfsen.

Figura 5. Tabulação dos sumários do perfil Redes_UFF, ranking do mês de
Janeiro, selecionando as 20 redes com a maior quantidade de fluxos.

Inicialmente, a consulta aos arquivos gerados pelo sistema buscou conhecer as maiores ocorrências para cada rede (Figura 5), de acordo com os seguintes critérios: portas ordenadas por quantidade de fluxos e portas ordenadas por quantidade de bytes. Além disso, foram coletados os sumários mensais nos quais constam: Total de fluxos, Total de bytes, Total de pacotes, Média de bits/s, Média de Pacotes/s, Média de bits por pacotes.

4. Detectando comportamentos anômalos

Nesse tópico, mostrar-se-á como a tecnologia de monitoramento de fluxos contribui para a detecção de comportamentos anômalos. Dentre os benefícios observados, destaca-se a capacidade de identificar o uso indevido da rede. São evidenciadas situações nas quais estações de trabalho e servidores se tornam agentes controlados por terceiros e não economizam os recursos computacionais disponíveis, causando prejuízos ao funcionamento de todos os elementos envolvidos. Será relatada agora, passo a passo, a identificação da alteração do PFR e identificação do host (chegando até ao código fonte da aplicação geradora do tráfego anômalo).

Figura 6. Painel de informações, indicando o valor de 470 fluxos por segundo –
protocolo SSH.

A primeira informação que levou a identificar a alteração do PFR foi a elevada quantidade de fluxos do protocolo SSH (Figura 6 – superior). O painel de informaçõesdo sistema Nfsen indicava 470 fluxos/s, bem maior do que os valores registrados pelo protocolo HTTP, que, em geral, tem sempre maior utilização por se tratar do acesso as páginas WEB (vide Figura 6 – inferior).

Figura 7. Painel de informações. As setas indicam a elevação da quantidade de
fluxos da rede 200.20.10.64.

Também nos gráficos do perfil Redes_UFF, foi possível identificar que a rede 200.20.10.64 apresentava expressiva elevação da quantidade de fluxos, conforme mostra a Figura 7

Figura 8. Identificação do endereço IP 200.20.10.73, pertencente ao host
gerador do tráfego que alterou o PFR da rede 200.20.10.64.

O sistema Nfsen possui recursos que facilitam a identificação dos elementos geradores do tráfego, a partir da seleção das imagens no gráfico. Dessa forma, foi obtido o endereço IP 200.20.10.64. A Figura 8 mostra um relatório constituído pelos dez endereços que tiveram a maior quantidade de fluxos registrados, dentre os quais o IP 200.20.10.73 aparece em primeiro lugar. A partir do endereço, foi possível chegar até o equipamento agressor.
Após a identificação do gerador do evento, os administradores da respectiva rede foram contatados, desligando a máquina. Foi possível ter acesso ao referido computador e, após pesquisa nos logs do sistema, identificou-se que o método de acesso utilizado foi a quebra de uma senha de usuário (de composição fraca). No sistema de arquivos foram encontrados diversos scripts, cujo algoritmo tinha o objetivo de vasculhar redes específicas em busca de máquinas rodando aplicativos de acesso remoto. Uma vez identificados os endereços, outra parte do código se encarregava de disparar um ataque de dicionário, do tipo força bruta, na tentativa de obter acessos indevidos. A Figura 9 mostra que, após o desligamento da máquina, o evento foi finalizado, confirmando, portanto, que o ataque partia do referido equipamento.

Figura 9. Retorno ao padrão de normalidade.

Programando alertas

Após passar o período de monitoramento detectando os eventos de segurança, a partir da observação dos gráficos buscaram-se algumas alternativas para automatizar este processo. Os mais de quarenta casos de segurança, registrados ao longo do período, mostraram que houve expressivas elevações da quantidade de fluxos durante a ocorrência dos eventos. Com base nessas informações, buscou-se uma forma de programar os alertas de acordo com as etapas a seguir:

1.preparação e execução de um script para extrair dos arquivos do sistema de monitoramento as informações referentes à quantidade de fluxos gerados por
determinada rede;
2.importação do arquivo resultante da execução do script, em planilha eletrônica, de
modo a calcular os valores de referência a serem utilizados para a programação
do alerta;
3.programação dos alertas no sistema Nfsen;
4.avaliação dos alertas emitidos pelo sistema.
Os testes foram realizados, utilizando uma funcionalidade do sistema Nfsen que permite programar alertas em função do acompanhamento das variáveis: fluxos, pacotes e bytes. Para a programação do alerta foi utilizada a variável “fluxo”. A rede utilizada para os testes foi a de endereço 200.20.7.0, e o período compreendido entre janeiro e abril de 2009. A análise das amostras aponta que a distribuição de fluxos, no período considerado, era aproximadamente normal. O objetivo do procedimento foi encontrar o valor ideal, de forma que os alertas só fossem emitidos quando a quantidade de fluxos alcançasse índices que estivessem fora do padrão de funcionamento da rede (PFR).
Assim, para a realização dos testes, foi escolhido como referência o valor correspondente à média, acrescida do desvio padrão da distribuição, ou seja, aproximadamente 6000 fluxos a cada 5 minutos.
Foram coletados, também, alertas emitidos entre julho e setembro de 2009. Durante a análise, constatou-se que alguns alertas foram emitidos pelo mesmo agente, e que isso se repetiu durante todo o período de teste, de forma regular. Foi o caso do endereço IP 200.20.7.37, que fazia acessos com expressiva quantidade de fluxos (25491 fluxos/s) ao endereço IP 200.130.35.8. A análise dos fluxos não evidenciou nenhum caráter de segurança. Verificando que os acessos eram direcionados a um único endereço (200.130.25.8), registrado para uma instituição parceira da UFF (Rede Nacional de Ensino e Pesquisa), consideramos que os acessos pudessem ser de interesse das instituições e, nesse caso, uma opção seria aplicar um filtro de modo que o sistema não emitisse alertas para os fluxos estabelecidos entre esses dois endereços.
Em outro caso, o endereço 200.20.7.112 acessou 1882 vezes o endereço 201.49.208.251, registrado como www.parperfeito.com.br, que, somados à carga existente na rede, fez com que o alerta fosse emitido. Para efeito do teste, realizou-se o bloqueio do referido endereço acessado. Isso restabeleceu o PFR, e o alerta deixou de ser emitido. A hora do alerta, 7h30 da manhã, atraiu a atenção, pois, com base em registros anteriores, a rede, nesse horário, deveria estar ociosa. Isso fez perceber como as informações do PFR, associadas ao tempo, contribuem para a identificação de acessos indevidos considerando o caráter da Instituição.

5. Considerações finais

Os scripts foram executados em todas as 76 redes, e objetivaram conhecer o universo das portas mais utilizadas e a sua expressividade com relação ao total de recursos consumidos pela própria rede, bem como o impacto causado na rede UFF como um todo. Os sumários existentes ao final de cada resultado (emitido pelo programa NFdump) serviram para construção de rankings mensais, em função da quantidade de fluxos registrados. Inicialmente, os dados registrados a partir do perfil Redes_UFF permitiram:

• conhecer o universo das redes que mais consomem os recursos da rede UFF;
• conhecer o universo das portas utilizadas por cada rede;
• determinar o consumo dos recursos da rede, por porta, em relação ao consumo
total da rede;
• determinar o valor percentual do consumo dos recursos individuais de cada rede,
em relação ao total registrado para a rede da UFF no período;
• gerar os gráficos comparativos e de acompanhamento;
• programar alertas em função da alteração do PRF da rede;
• detectar o uso indevido dos recursos.

Fica demonstrado, dessa forma, que os dados colhidos pelo sistema de monitoramento de fluxos formam um valoroso manancial de informações. O tráfego de cada rede é consolidado a cada cinco minutos, gerando, ao final do dia, um conjunto de 288 arquivos (24 horas X 60 minutos / 5 minutos). A partir desses arquivos, foi possível obter, com riqueza de detalhes, as características individuais do funcionamento de cada rede. O PFR é obtido após um período de monitoramento da rede, concentrando-se em parâmetros como: média de fluxos, bytes, pacotes e relação de portas mais utilizadas.
Todos os resultados coletados até agora contribuem para estabelecer o PFR de cada rede da UFF, sendo possível delimitar o universo das portas utilizadas pelas aplicações que consomem mais recursos da rede. Também foi possível extrair dados estatísticos, através da contabilização dos sumários da atividade mensal da rede. E, finalmente, foi possível comparar a atividade das redes, através da composição de um ranking, e acompanhar a variabilidade da posição de cada elemento ao longo de cinco meses.
Salienta-se, ainda, que o método utilizado para programação dos alertas foi apenas uma escolha inicial para realização dos testes. Com certeza, tal procedimento merece um tratamento adequado, de forma a sistematizar o cálculo dos valores de referência para qualquer rede. É importante ressaltar, também, que os processos que irão determinar os padrões de funcionamento deverão considerar diferentes períodos de funcionamento da rede. Além disso, deverão ser considerados os finais de semana e os feriados prolongados. Assim, para efeito de detecção de eventos que comprometam a segurança, é necessário calcular a provável carga da rede, para cada período de funcionamento da mesma, sob pena de se emitirem alertas falsos ou de se ignorarem alertas importantes [11]. Nesse sentido, tais aspectos merecerão, por certo, ser objeto de
trabalhos futuros.

Referências

[1] Bruder, J. P.: “Barômetro Cisco de Banda Larga no Brasil, 2005-2010” IDCInternational
Data Corporation – 2009
[2] Quittek J. “RFC 3917 – Requirements for IP Flow Information Export (IPFIX)”,
http://www.ietf.org/rfc/rfc3917.txt, 2004.
[3] Park, J. “A Survey on Flow-based Internet Traffic Measurement Technologies”,
Asian Info-communications Council, Electronics and Telecommunications
Research Institute (ETRI) in Korea, 2005.
[4] Paxson V. “RFC 2330 – Framework for IP Performance Metrics”
http://www.ietf.org/rfc/rfc2330.txt, 1998.
[5] Kurose, J. F. and Ross, K. W. (2004) “Redes de Computadores e a Internet”,
Addison-Wesley, 2004.
[6] Postel, J. “RFC 792 – Internet Control Message Protocol”,
http://www.ietf.org/rfc/rfc792.txt, 1981.
[7] Brownlee, N. “RFC2027Traffic Flow Measurement: Meter MIB”
http://www.faqs.org/rfcs/rfc2720.html, 1999.
[8] Quittek, J., Zseby T., Carle G. and Zander S. “Traffic Flow Measurements
within IP Networks:Requirements, Technologies, and Standardization” IEEE
– Proceedings of the 2002 Symposium on Applications and the Internet, 2001.
[9] Leinen S. “RFC3955 – Evaluation of Candidate Protocols for IP Flow
Information Export (IPFIX)” http://www.ietf.org/rfc/rfc3955.txt, 2004.
[10] CISCO Systems, “Introduction to Cisco IOS® NetFlow”, 2007.
[11] Miloucheva I., Nassri A., Hofmann U. “Traffic Measurement and Monitoring
Roadmap”, Information Society Tecnology, NGN, 2002.


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Categorias

%d blogueiros gostam disto: