Detecção de Anomalias Baseada em Análise de Entropia no Tráfego da RNP

Sidney C. de Lucena[1,2], Alex Soares de Moura[1,2]

1Universidade Federal do Estado do Rio de Janeiro (UNIRIO)Av. Pasteur, 458 – Urca

22290-240 – Rio de Janeiro, RJ

2Rede Nacional de Ensino e Pesquisa (RNP)Rua Lauro Müller, 116/3902 – Botafogo

22290-906 – Rio de Janeiro, RJ

{sidney,alex.moura}@uniriotec.br, {sidney,alex}@rnp.br

Abstract. Anomaly detection in network traffic is a complex and important activity that uses special methods for its analysis. Anomaly detection based in entropy analysis has been studied in several works. This article applies entropy analysis with Holt-Winters forecasting to detect anomalies in the traffic of RNP's backbone. Two weeks of traffic samples were collected from the main router of RNP's network and the entropy analysis was handled in conjunction with free open-source tools largely adopted for network management. It was shown that the proposed analysis increases the efficiency of the methods normally used by network operators to detect anomalies.

Resumo. A detecção de anomalias de tráfego em redes de computadores é uma atividade fundamental e complexa que requer métodos especiais de análise. Estudos para detecção de anomalias baseados em análise de entropia vêm sendo abordados em diversos trabalhos. Este artigo aplica análise de entropia com estimativa de Holt-Winters para detecção de anomalias no tráfego da RNP. Foram amostradas duas semanas de tráfego do principal roteador da RNP e a análise de entropia fez uso de ferramentas de software livre largamente adotadas para gerência de redes. Foi mostrado que esta análise melhora a eficiência do processo atualmente usado por diversos administradores de rede para detecção de anomalias.

1. Introdução

Dada a importância das redes de computadores para as comunidades de educação e pesquisa, e para a sociedade da informação como um todo, a compreensão da natureza das anomalias de tráfego em redes de computadores tornou-se um problema importante e de solução complexa [Lakhina 2005]. Entende-se por anomalia de tráfego tudo aquilo que foge a um padrão de normalidade no tráfego da rede. Independente do fato destas

13º Workshop de Gerência e Operação de Redes e Serviços 163

anomalias serem intencionais ou não, torna-se importante analisá-las por conta dos inúmeros prejuízos que podem decorrer destes eventos, tais como a exaustão de recursos nos roteadores e nas conexões das redes. Além da infra-estrutura da rede, certas anomalias de tráfego podem também impactar a utilização de serviços e seu acesso por diversas comunidades de usuários.

A complexidade em se diagnosticar anomalias advém do fato de que as mesmas podem ter as mais variadas formas e causas, como o erro humano na configuração de um protocolo de roteamento, falhas de fornecimento elétrico e até um malicioso e massivo ataque distribuído de negação de serviço (Distributed Denial of Service – DDoS) direcionado a serviços ou à infra-estrutura da rede. A detecção de anomalias em redes – principalmente em backbones – é desafiadora devido à necessidade de se analisar uma grande quantidade de dados a procura de padrões. Segundo [Monsores 2006], diagnosticar anomalias envolve a detecção, identificação e quantificação de eventos no tempo que tenham causado algum problema no tráfego da rede.

Dentre os diversos tipos de anomalias que podem ocorrer nas redes de computadores, destacam-se algumas que são notórias por causar freqüentes transtornos aos usuários, tais como: ataques de negação de serviço distribuído (DDoS), infestações viróticas automatizadas (worms), exércitos de máquinas controladas sem autorização (botnets), varreduras de portas maliciosas (port scans), correio eletrônico não solicitado em massa (spam) e tráfegos repentinos – muitas vezes legítimos – e temporários (flash crowds), para citar alguns. Na maioria dos casos, estes tipos possuem características específicas que se diferem na maneira como estas anomalias se manifestam e interferem no tráfego da rede.

Algumas formas de detecção são baseadas na identificação de elementos no tráfego que estejam explicitamente associados a algum tipo de anomalia, como uma determinada seqüência de caracteres dentro de um pacote ou uma seqüência específica de pacotes de determinado tipo [Estevez-Tapiador 2004]. Este tipo de detecção utiliza, portanto, uma assinatura que identifica determinado tipo de anomalia. Costuma ser onerosa do ponto de vista computacional porque exige a inspeção de cada pacote IP que trafega por uma ou mais conexões de rede. Outra forma de detecção se baseia numa assinatura estatística do tráfego de rede associado a determinado tipo de anomalia [Estevez-Tapiador 2004]. Através do comportamento dos fluxos de pacotes é possível verificar se há ou não a presença de alguma anomalia correlata, sem que para isso seja necessário inspecionar cada pacote IP trafegado. Esta abordagem é mais adequada para redes de backbone, dado o grande volume de pacotes que costuma atravessar seus roteadores.

Em [Lakhina 2005] é apresentada uma metodologia que faz uso de análise de entropia para detecção de anomalias baseada numa assinatura estatística de tráfego. Os autores adotam esta análise tanto para a detecção quanto também para a classificação da anomalia em uma lista de tipos, incluindo o tipo day-zero, ou seja, anomalias que ainda são desconhecidas (como, por exemplo, um novo worm). A metodologia consegue inferir um padrão de tráfego normal através do uso de técnicas de estruturação e agrupamento de dados para mineração, aprendizado e classificação do tráfego anômalo.

164 13º Workshop de Gerência e Operação de Redes e Serviços

A eficiência desta proposta foi aferida com sucesso usando amostras de tráfego da principal rede acadêmica dos EUA, a Abilene, e da rede acadêmica que agrega as diversas redes acadêmicas da Europa, a Géant.

Existem diversas soluções de mercado que se destinam à detecção de anomalias em redes de diversos tipos. Algumas soluções são mais apropriadas a ambientes de redes locais e datacenters, como os IDS’s (Intrusion Detection Systems) e os IPS’s (Intrusion Prevention Systems). Outras soluções se destinam a redes maiores, como as redes de campus, a rede de um ISP (Internet Service Provider) ou mesmo a rede de um ponto de troca de tráfego de Internet (PTT). Em diversas situações, estas soluções possuem um custo elevado se comparado com o investimento de implantação e manutenção destas redes.

Em se tratando de redes acadêmicas financiadas pelos governos, seja a nível metropolitano, nacional ou mesmo continental, é muito comum a adoção de ferramentas de software livre para a gerência destas redes. Tais ferramentas também têm sido utilizadas para a descoberta de certos tipos de anomalias de tráfego, porém elas oferecem recursos extremamente limitados se comparadas com ferramentas comerciais [Arbor 2008].

O presente artigo propõe o uso de análise de entropia dos fluxos de pacotes, combinado com a estimativa de Holt-Winters, para melhorar a eficiência das técnicas atualmente usadas pelos administradores de redes que se valem de ferramentas de software livre para a detecção dos ataques mais comuns. Até onde foi possível verificar na literatura, a combinação destas técnicas é uma abordagem inédita. Esta proposta foi aplicada a duas semanas de tráfego coletado em um ponto nevrálgico da Rede Ipê, nome dado ao backbone da rede acadêmica brasileira, a Rede Nacional de Ensino e Pesquisa - RNP. Apesar da ausência de relatórios de incidentes de segurança no período observado, os resultados mostram que esta metodologia consegue ser agregada com muito pouco custo às ferramentas de software livre tradicionais mais em uso e propicia, conforme esperado, uma melhor sensibilidade na identificação de ataques.

A Seção 2 do artigo descreve a análise de entropia como forma de detecção de anomalias, a Seção 3 cita as ferramentas de software livre comumente usadas pelos administradores para encontrar ataques e mostra como agregar a estimativa de Holt-Winters à análise de entropia, a Seção 4 mostra os resultados obtidos para o tráfego da Rede Ipê e, por fim, a Seção 5 apresenta as conclusões e os trabalhos futuros.

2. Detecção de Anomalias usando Análise de Entropia

A técnica de detecção de anomalias de tráfego usando entropia é recente, conforme apresentado por [Lakhina 2005] e [MacKey 2003]. Em [Lakhina 2005], os autores usam a entropia de Shannon como forma de avaliar o grau de concentração de determinadas distribuições de probabilidade. O foco da medida são as distribuições dos números de portas e as distribuições dos endereços IP, tanto de origem quanto de destino para ambos os casos, obtidas para fluxos de pacotes amostrados durante um intervalo fixo de tempo. A concentração ou dispersão dessas quatro distribuições servem como indicativo da

13º Workshop de Gerência e Operação de Redes e Serviços 165

presença de algum tipo de anomalia.

Um exemplo claro da aplicabilidade desta medida é o caso dos DDoS, ataques distribuídos de negação de serviço. Neste tipo de ataque, várias máquinas infectadas disparam pacotes para uma vítima específica. Na rede que conduz os atacantes à vítima, durante o ataque é possível notar a presença de vários fluxos com valores diversificados para o IP de origem e um mesmo valor para o IP de destino. Isto implica numa distribuição dispersa para os endereços IP de origem e concentrada para os endereços IP de destino destes fluxos [Lakhina 2005]. Outro exemplo interessante é o caso dos ataques do tipo port scan. Neste ataque, uma determinada máquina faz a varredura de diversas portas de uma ou mais máquinas numa rede qualquer em busca de algum tipo de vulnerabilidade. Desta forma, os fluxos durante o ataque apresentam distribuição concentrada para os valores de endereços IP, tanto de origem como de destino, e distribuição dispersa para os valores de porta de destino [Lakhina 2005].

2.1. Entropia de Shanon

A entropia de Shannon é definida como [Shannon 1948]:

ES=−∑i=0

Npi log2 pi (1)

onde N é o número de diferentes ocorrências no espaço amostral sob análise e pi a probabilidade associada a cada ocorrência i. Na abordagem usada em [Lakhina 2005], N corresponde ao número de diferentes valores para o campo em análise – IP de origem, IP de destino, porta de origem ou porta de destino – que ocorreram durante um intervalo fixo de tempo e pi é a probabilidade de cada um desses diferentes valores i. O resultado deste cálculo varia entre 0 e log2N. O valor mínimo indica concentração máxima na distribuição medida, ou seja, um único valor i ocorreu durante todo o intervalo de observação. O valor máximo indica dispersão total na distribuição medida, ou seja, uma distribuição uniforme com probabilidade igual a 1/N para todas as ocorrências dentro do intervalo de observação. Em outras palavras, quanto menor o valor da entropia, mais concentrada é a distribuição, e quanto maior seu valor, mais dispersa é a distribuição.

2.2. Obtenção dos Fluxos de Pacotes

Basicamente, um fluxo IP pode ser definido como uma seqüência unidirecional de pacotes que possuam mesmo IP de origem, mesmo IP de destino, mesma porta de origem e mesma porta de destino. O intervalo de tempo entre pacotes de um mesmo fluxo não deve ultrapassar um valor máximo, tipicamente igual a 15 segundos. Caso ocorra, o fluxo expira e o novo pacote pertencerá a um novo fluxo [Cisco 2008]. Outros critérios também costumam ser adotados para decretar o término de um fluxo IP, como os bytes RST e FIN para conexões TCP ou um tempo de vida máximo para fluxos IP, geralmente 30 minutos.

Há duas maneiras para se obter uma leitura dos fluxos de pacotes que trafegam por uma rede. A primeira consiste da captura de todos os pacotes que passam por uma

166 13º Workshop de Gerência e Operação de Redes e Serviços

ou mais interfaces de rede de um determinado equipamento para, posteriormente, consolidar as informações na forma de fluxo de pacotes. Fisicamente, a maneira que se dá esta captura varia bastante. Uma das formas mais usuais é através do espelhamento de porta em switches, onde uma cópia de qualquer quadro que tenha trafegado é enviado para uma porta específica. O processo para consolidar os fluxos é oneroso e exige um processamento rápido para evitar que os pacotes capturados sejam perdidos por falta de espaço em memória. A segunda maneira para obter os fluxos de pacotes, muito menos custosa, se vale da capacidade de alguns roteadores de exportar esta informação já consolidada. Trata-se de um recurso muito comum em roteadores de gerações mais recentes, porém nem sempre encontrada em roteadores de pequeno porte. Os fluxos são estruturados segundo um formato padrão e exportados em UDP para uma estação coletora que armazena estes dados de acordo com o aplicativo usado [Cisco 2008].

Dentre os padrões usados para estruturar as informações dos fluxo de pacotes, podemos citar o Sflow [Phaal 2001] e o NetFlow [Cisco 2008]. Destes, as versões 5 e 9 do padrão NetFlow [Claise 2004], desenvolvido e patenteado pela Cisco Systems em 1996, são as mais usadas. A versão 9, inclusive, serviu como ponto de partida para um grupo de trabalho do IETF desenvolver um novo padrão, chamado IPFIX [Leinen 2004]. Embora proprietário, o NetFlow é um formato aberto e amplamente usado em equipamentos de diversos fabricantes. O registro NetFlow de cada fluxo é composto pelos seguintes campos: versão do NetFlow, número seqüencial, interfaces de entrada e saída no roteador, carimbos de tempo de início e fim do fluxo, número de bytes e pacotes observados no fluxo, endereços IP de origem e destino, portas de origem e destino, protocolo IP, valor do campo Type of Service (ToS) e, nos fluxos TCP, a união de todas as flags TCP observadas durante o tempo de vida do fluxo. A captura destas informações é realizada para cada interface lógica do roteador mediante configuração. Os registros NetFlow são exportados pelo roteador a medida que os fluxos expiram.

Nos roteadores de redes que concentram um volume considerável de tráfego, é comum se usar métodos de amostragem para minimizar a carga de processamento por conta da geração dos registros de fluxo. Normalmente, isto é feito capturando-se apenas um pacote a cada tanto que entra pela interface monitorada. Valores típicos são 1 para 100 ou mesmo 1 para 1000, dependendo das capacidades envolvidas. Outro motivo para se fazer amostragem é diminuir a quantidade de registros gerados e, conseqüentemente, usar menos espaço de armazenamento da estação coletora.

2.3. Análise por Pares Origem-Destino

Em [Lakhina 2005] os autores realizam as análises de entropia de acordo com o que foi chamado de “par origem-destino” (OD pairs). Este termo é usado para descrever uma tupla formada por um ponto de entrada (origem) e um ponto de saída (destino) na rede. Cada fluxo faz parte de um determinado par OD e as análises de entropia são realizadas para todos os possíveis pares OD. Isto significa que, para cada par OD, as entropias de IP de origem, IP de destino, porta de origem e porta de destino são calculadas a cada cinco minutos de acordo com os fluxos que passam neste par OD. O resultado desta operação são quatro matrizes, uma para cada tipo de entropia, com os pares OD num eixo, a seqüência de intervalos de tempo no outro eixo e os respectivos

13º Workshop de Gerência e Operação de Redes e Serviços 167

valores de entropia em cada posição da matriz. Toda a metodologia para identificação e classificação de anomalias utilizada pelos autores baseia-se nestas matrizes e os autores entendem que esta é a maneira mais eficiente de se detectar anomalias na rede.

A construção destas matrizes e, mais especificamente, a identificação de a qual par OD um determinado fluxo pertence, necessariamente precisa levar em conta informações de topologia e roteamento. Isto adiciona um grau de complexidade razoável ao problema, dado que será necessário conhecer de antemão o ponto de saída da rede a partir do IP de destino. Isto nem sempre é trivial, dada a possibilidade de haver múltiplos pontos de saída para um mesmo sistema autônomo e diversas políticas de balanceamento de rotas.

3. Análise de Entropia Usando Previsão de Holt-Winters

3.1. Métodos Usuais para Detecção de Anomalias

A maioria dos administradores de redes acadêmicas e de instituições governamentais usam ferramentas de software livre para a detecção de anomalias. Os procedimentos adotam técnicas simples baseadas em volumes de tráfego que passam por determinadas interfaces. Alguns aplicativos são capazes de exibir os n maiores fluxos de tráfego para critérios diversificados de filtragem. Quando um ou mais fluxos ultrapassam determinado volume de tráfego, um sinal de alerta pode ser gerado para o administrador de rede.

Alguns métodos são ainda mais rústicos. Simplesmente verificam todos os agregados de tráfego que passam pelas interfaces de rede em busca de uma taxa de pacotes por segundo que ultrapasse determinado valor. Nenhuma informação de fluxo IP é considerada, apenas registros coletados através de leituras SNMP e armazenados em arquivos do tipo RRD [Bogaerdt 2008].

Das ferramentas de software livre que processam informações de fluxo, uma das mais populares é o Nfsen [Haag 2005]. O Nfsen é uma interface gráfica para o Nfdump, que é uma ferramenta de comando de linha similar ao TCPdump, capaz de filtrar e extrair diversas informações de fluxos NetFlow armazenados pelo programa Nfcapd [Nfdump 2007]. É comum usar o Nfsen para verificar se há uma porta desconhecida dentre as n mais usadas, o que pode ser um indicativo de algum worm se alastrando. Ou ainda para olhar os fluxos IP de maior volume em busca de algum possível ataque de DoS ou DDoS. Este tipo de uso é mais reativo do que preventivo, muitas vezes motivado por uma reclamação originada pela vítima. Uma alternativa interessante é usar algum programa escrito especificamente para verificar um possível ataque em curso e, a partir de alguma sinalização, usar o Nfsen para investigar os fluxos envolvidos.

3.2. Estimativa de Holt-Winters

A necessidade de se detectar um comportamento que fuja a um certo padrão histórico implica na construção de um baseline para o tráfego analisado. Um exemplo

168 13º Workshop de Gerência e Operação de Redes e Serviços

simples seria usar a taxa média do tráfego e seu desvio padrão para arbitrar limiares mínimo e máximo de variação desta taxa. Qualquer valor fora destes limites seria considerado uma anormalidade. Esta técnica simples apresenta problemas se aplicada a curvas que possuam sazonalidade e/ou tendências naturais de crescimento, uma vez que tanto a taxa média quanto o desvio-padrão vão variar ao longo do tempo.

Uma forma de estimar a taxa média para um tráfego real cujo valor representativo pode sofrer variações ao longo do tempo é através de exponential smoothing [Brutlag 2000]. Trata-se de um estimador que faz uma soma ponderada entre a taxa atual e a taxa média acumulada ao longo do tempo. Esta ponderação é representada por um coeficiente α, onde 0 < α < 1:

x t1= X t1− x t (2)

onde xt é a média histórica e Xt o valor corrente. Em geral, tem-se um valor em torno de 0.1 para α. Entretanto, este estimador não é apropriado para casos onde exista algum tipo de periodicidade. Para estes casos, um estimador mais apropriado é o Holt-Winters [Brutlag 2000].

A predição de Holt-Winters é apropriada para casos de sazonalidade porque ela divide a série temporal em três partes superpostas: um termo que denota a periodicidade da série, um segundo termo que indica a tendência de crescimento da série e, por fim, um termo que expressa uma parte residual. Cada um desses três termos é tratado de forma separada através de uma estimativa de exponential smoothing. Isto significa que três coeficientes, α, β e γ, devem ser atribuídos, um para cada termo. Abaixo se encontram as expressões para a estimativa de Holt-Winters, onde at corresponde à componente residual, bt à componente de tendência, ct à componente periódica e m é o tamanho do período:

x t1=a tbtc t1−m (3)

a t=X t−ct−m1−at−1bt−1 (4)

bt=a t−a t−11−bt−1 (5)

c t= X t−at 1−c t−m (6)

Em [Brutlag 2000], a estimativa de Holt-Winters é usada para detecção de comportamentos anômalos em séries temporais.

3.3. Estimativa de Holt-Winters para Análise de Entropia

De maneira a introduzir a análise de entropia dos fluxos IP ao cenário atual de ferramentas livres para gerência de redes, propõe-se que os registros NetFlow coletados tenham os valores de entropia calculados para cada intervalo de cinco minutos e que os

13º Workshop de Gerência e Operação de Redes e Serviços 169

resultados sejam armazenados em bases RRD, uma para cada parâmetro (IP de origem, IP de destino, porta de origem e porta de destino). De maneira a uniformizar o grau de concentração/dispersão informado pela medida de entropia, os valores calculados devem ser normalizados por log2N, onde N corresponde ao número de ocorrências do respectivo parâmetro para cada intervalo de cinco minutos.

O armazenamento das informações de entropia em bases RRD permite que os administradores de rede tratem estas medidas a partir de ferramentas tradicionais de visualização, como o Cacti [Cacti 2007], ou mesmo de manipulação de bases RRD, como o RRDtool [Bogaerdt 2008], possibilitando a geração de alarmes conforme os recursos destas ferramentas. Geralmente, esta geração de alarmes é baseada em limiares estaticamente configurados. Tal abordagem é por demais simplificada e limitaria a análise de entropia a casos de variação extrema. Para uma análise mais refinada, deve ser adotada uma estimativa de baseline, através da qual é possível avaliar o comportamento padrão de certa medida de entropia e os eventuais desvios que podem sinalizar uma anomalia. Conforme mostrado nos exemplos da seção 4 (mais adiante), o comportamento sazonal da entropia sugere a adoção da estimativa de Holt-Winters para analisar possíveis desvios do baseline. Este algoritmo já é implementado como uma função especial do RRDtool [RRDtool 2008].

O uso de análise de entropia para os fluxos coletados se constitui em importante ferramenta de alerta para administradores de rede. Diferente do que é mostrado em [Lakhina 2005], a abordagem aqui proposta é mais simples e menos ousada, se prestando apenas a sinalizar que determinado tipo de anomalia, dentre algumas de características mais conhecidas, pode estar em curso. Posteriormente, o administrador de rede poderá usar o Nfsen para uma investigação direcionada ao tipo de anomalia sinalizada. Para identificar qual o tipo de anomalia que pode estar ocorrendo, faz-se necessário um apanhado dos quatro valores de entropia calculados dentro do mesmo intervalo de tempo. De posse desses valores, pode-se atribuir uma possível classificação, conforme exemplo abaixo:

a) DoS:entropia baixa para IP de origem (origem específica),entropia baixa para IP de destino (alvo específico);

b) DDoS:entropia alta para IP de origem (origem dispersa),entropia baixa para IP de destino (alvo específico),entropia alta para porta de origem (portas aleatórias);

c) Port Scan:entropia baixa para IP de destino (mesmo IP com portas sendo varridas),entropia alta para porta de destino (muitas portas sendo varridas);

d) Worm Scan:entropia alta para IP de origem (possível Botnet),entropia alta para IP de destino (procura possíveis vítimas),

170 13º Workshop de Gerência e Operação de Redes e Serviços

entropia alta para porta de origem (várias conexões para múltiplos destinos),entropia baixa para porta de destino (explora a vulnerabilidade de alguns serviços).

Muitas variações desta classificação são permitidas uma vez que existem várias possibilidades de ataques.

4. Análise do Tráfego da RNP

A detecção de anomalia proposta, usando análise de entropia e estimativa de Holt-Winters foi verificada a partir de dados colhidos do backbone da RNP, a Rede Ipê. Foram utilizadas duas semanas de registros NetFlow versão 5 das principais interfaces do roteador modelo Juniper M320 localizado no ponto de presença do Estado de São Paulo (PoP-SP). Este roteador é responsável pela troca de tráfego com importantes sistemas autônomos, além de fazer parte do núcleo da Rede Ipê. Uma importante conexão deste roteador é um enlace de 1 Gbps com a Internet comercial, porém a coleta NetFlow não estava habilitada para a respectiva interface durante o período observado. Por padrão, toda coleta de fluxo na Rede Ipê usa taxa de amostragem de 1 a cada 100 pacotes e é habilitada sempre na entrada das interfaces. O período de coleta se deu entre 00:00 do dia 14/02/2008 e 00:00 do dia 28/02/2008, totalizando cerca de 60 Gbytes de dados, e foram analisadas as interfaces para as seguintes redes:

• PTT-Terremark: importante ponto de troca de tráfego localizado na Fapesp que comporta, dentre outros participantes, os sistemas autônomos da Oi e do Google, ligado com a RNP a 1 Gbps;

• PTT-Metro: ponto de troca de tráfego de iniciativa do Registro .br que, dentre outros participantes, conta com o Terra, a CTBC, a GVT, Brasil Telecom, Impsat, Telefônica, Yahoo e UOL, ligado com a RNP a 1 Gbps;

• Rede Clara: rede continental que interliga diversas redes acadêmicas da América Latina e possui trânsito para a Internet 2 e para a Géant, que é a rede continental que interliga as redes acadêmicas européias, ligado com a RNP a 155 Mbps;

• Embratel: sistema autônomo que abriga diversos sítios nacionais, ligado com a RNP a 155 Mbps.

As estatísticas de tráfego para cada um desses pontos podem ser encontradas em [CEO-RNP 2008].

4.1. Limitações para a Verificação do Método

A verificação do método não é completa por limitação das informações disponíveis a respeito de ataques que ocorreram na Rede Ipê durante o período observado. Os únicos registros de ataque existentes na RNP são os comunicados oficiais ao sistema de tratamento de chamados do Centro de Engenharia e Operações (CEO) da

13º Workshop de Gerência e Operação de Redes e Serviços 171

RNP. Durante o período analisado, nenhuma comunicação de ataque foi direcionada à equipe do CEO, o que compromete a verificação de falsos positivos e negativos gerados pelo método. Todas as informações utilizadas, incluindo os arquivos contendo os fluxos IP, foram gentilmente cedidas pelo CEO mediante solicitação formal dos autores.

4.2. Processamento dos Dados

O processo para obtenção das entropias para os quatro parâmetros em cada uma das interfaces listadas começa pela utilização do nfdump. Como cada arquivo gerado pelo nfcapd possui todos os fluxos capturados no roteador para um determinado período de tempo - no caso, cinco minutos - através do nfdump pode-se filtrar os fluxos capturados na entrada de uma interface específica e, ao mesmo tempo, obter um dos parâmetros desejados (IP de origem, IP de destino, porta de origem e porta de destino). O comando é repetido para cada um dos quatro parâmetros, gerando arquivos separados contendo todos os valores ocorridos em cada fluxo durante um intervalo específico. A partir daí, usa-se um programa escrito para calcular as entropias de cada parâmetro para cada intervalo de cinco minutos.

4.3. Gráficos de Entropia com Estimativas de Holt-Winters

Para a estimativa de Holt-Winters foram utilizadas algumas funções especiais do RRDtool, conforme descrito em [Brutlag 2000]. Esta implementação do Holt-Winters calcula, a partir da estimativa gerada, um intervalo de confiança que fornece um limiar superior e inferior para o que pode ser considerado como comportamento normal. O cálculo deste intervalo nada mais é do que um exponential smoothing para o desvio entre valor estimado e valor real, usando γ como coeficiente de amortização:

desvio t=∣X t−x t∣1−desviot−m (7)

onde Xt é o valor real e xt o valor estimado. Os limiares superior e inferior correspondem ao intervalo

x t−.desvio t−m , x t .desviot−m (8)

onde δ é um fator multiplicador, geralmente com valor entre 2 e 3. Foram usados os seguintes valores para os parâmetros da estimativa de Holt-Winters no RRDtool: α = 0,01; β = 0,0035; γ = 0,01; δ = 2 e m = 288 (equivalente ao número de conjuntos de 5 minutos contidos em um dia). Esses valores não são default e foram atribuídos de forma empírica, baseada em sugestões encontradas em [Brutlag 2000]. Os resultados gerados para os limiares superior e inferior são armazenados numa fila circular cujo tamanho é também um parâmetro do RRDtool e seu valor deve ser maior que m. Para os resultados gerados, utilizou-se um tamanho de fila circular igual a 1440, o que equivale a cinco dias de armazenamento.

Nas Figuras 1, 2, 3 e 4 são mostrados os gráficos obtidos a partir do RRDtool para as entropias de IP de origem, IP de destino, porta de origem e porta de destino dos

172 13º Workshop de Gerência e Operação de Redes e Serviços

fluxos coletados para as interfaces PTT-Terremark, PTT-Metro, Rede Clara e Embratel, respectivamente. Apesar das duas semanas de coleta, apenas a última semana foi mostrada para uma melhor visualização, todavia a estimativa de Holt-Winters considerou todo o período de coleta. Os gráficos mostram também os limiares superior e inferior calculados a partir das estimativas, toda vez que a entropia excursionar fora destes limites, tem-se um indicativo de anomalia. O RRDtool sinaliza estes casos para as últimas 24 horas do gráfico através de barras verticais.

Figura 1. Entropias para fluxos IP provenientes do PTT-Terremark

Figura 2. Entropias para fluxos IP provenientes do PTT-Metro SP

13º Workshop de Gerência e Operação de Redes e Serviços 173

Figura 3. Entropias para fluxos IP provenientes da Rede Clara

Figura 4. Entropias para fluxos IP provenientes da Embratel SP

Na Figura 1, que mostra as medidas para o PTT-Terremark, pode-se verificar um indício de worm scan por volta das 12:00 do dia 23, um possível port scan por volta das 06:00 do dia 24 e um novo indício de worm scan em torno das 12:00 deste mesmo dia. Na Figura 2, que traz as medidas para o PTT-Metro, não há nenhum indicativo de anomalia. Entretanto, verifica-se a presença de oscilações nos intervalos de confiança, para as quatro entropias, que parecem não condizer com o comportamento padrão das mesmas. Um melhor ajuste dos parâmetros do Holt-Winters se faz necessário para uma maior confiabilidade desta análise. Na Figura 3, que mostra as medidas para a Rede Clara, há um indicativo de port scan no dia 22, às 00:00, 06:00 e 10:00, um possível worm scan partindo de uma mesma máquina de origem às 06:00 do dia 23, um possível DOS às 12:00 deste mesmo dia e um possível DDoS às 15:00 do dia 24. Finalmente, na Figura 4, que traz as medidas para a Embratel SP, verifica-se um indício de port scan às 03:00 do dia 21, um possível ataque partindo de uma mesma máquina de origem para uma rede de destino explorando uma determinada vulnerabilidade às 06:00 do dia 24 e, às 07:00 do dia 25, um indício de port scan conjugado com uma varredura de rede.

De uma maneira geral, os parâmetros da estimativa de Holt-Winters podem ser melhor ajustados de forma individualizada para cada interface, permitindo uma estimativa mais adequada dos limiares superior e inferior para as curvas de entropia.

174 13º Workshop de Gerência e Operação de Redes e Serviços

Vale lembrar que uma mesma configuração destes parâmetros foi aplicada para todas as curvas de entropia das quatro interfaces observadas. Outra questão importante é quanto ao tempo necessário para que a estimativa de Holt-Winters “aprenda” o padrão de comportamento das curvas de entropia. Acredita-se que o tempo usado nos testes, duas semanas, pode não ter sido suficiente para uma estimativa mais apurada dos limiares de desvio.

5. Conclusão e Trabalhos Futuros

Conforme verificado pelos resultados apresentados na seção 4.3, o método proposto usa análise de entropia combinado com estimativas de Holt-Winters para potencializar o uso das ferramentas tradicionais de gerência de rede, mais especificamente o RRDtool, para a detecção de certos tipos de anomalias, como os ataques de DDoS e os worms. As ações subseqüentes devem fazer uso de ferramentas como o Nfsen para identificação dos fluxos envolvidos e, a partir desta identificação, fazer a confirmação dos possíveis ataques. Um processo de mitigação dos ataques confirmados pode ser rapidamente iniciado de forma a minimizar os danos causados.

Ajustes nos parâmetros da estimativa de Holt-Winters ainda devem ser aprimorados para uma melhor avaliação do padrão de entropia. De maneira a possibilitar uma verificação mais completa do método proposto, como trabalho futuro será negociado junto ao Centro de Engenharia e Operações (CEO) da RNP a adoção deste sistema em caráter experimental. A implantação do mesmo necessariamente não deve interferir com os sistemas de gerência em produção no CEO, mas apenas sinalizar seus técnicos quando uma anomalia for detectada. Após esta detecção, o Nfsen pode ser usado para identificar os possíveis fluxos envolvidos e, a partir desta identificação, os administradores das redes atacadas poderão ser contactados para confirmar o suposto ataque. Tal sistemática permitirá um melhor ajuste dos parâmetros do Holt-Winters e uma medição bastante realística dos índices de falsos positivos e negativos que podem ser gerados pelo método. Novas formas de identificação de padrões anômalos no comportamento da entropia, como feito com a estimativa de Holt-Winters, também são alvo de estudos futuros.

Referências

Arbor Networks, Inc (2008) “Peakflow SP Data Sheet”, http://www.arbornetworks.com/index.php?option=com_docman&task=doc_download&gid=6, 23/03/2008.

Bogaerdt, A. V. D. (2008) “RRD Tutorial”, http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html, 23/03/2008

Brutlag, J. D. (2000) “Aberrant Behavior Detection in Time Series for Network Monitoring”, Proceedings of the 14th Systems Administration Conference (LISA 2000).

Cacti (2007) “The Complete RRDtool-based Graphing Solution”, http://cacti.net/features.php, 23/03/2008.

CEO-RNP (2008) “Operação do Backone RNP”, http://www.rnp.br/ceo/, 23/03/2008.

13º Workshop de Gerência e Operação de Redes e Serviços 175

Cisco Systems, Inc.(2008) “Netflow Services Solution Guide”, http://www.cisco.com/en/US/docs/ios/solutions_docs/netflow/nfwhite.pdf, 23/03/2008.

Claise, B. Ed. (2004) “RFC 3954 - Cisco Systems NetFlow Services Export Version 9”, http://www.faqs.org/rfcs/rfc3954.html.

Estevez-Tapiador, J. M., Garcia-Teodoro, P., Diaz-Verdejo, J. E. (2004) “Anomaly Detection Methods in Wired Networks: a Survey and Taxonomy”, Computer Comunications, 27, 1569-1584.

Haag, P. (2005) “Watch your Flows with Nfsen and Nfdump”, 50th RIPE Meeting, Stockholm, http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-nfsen-nfdump.pdf,

Lakhina, A., Crovella, M., and Diot, C. (2005) “Mining anomalies using traffic feature distributions”, Proceedings of the ACM SIGCOMM'2005, Philadelphia, PA, USA

Leinen, S. (2004) “RFC 3955 - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)”, http://www.faqs.org/rfcs/rfc3955.html

MacKey, D. J. C. (2003) “Information Theory, Inference, and Learning Algorithms”, Cambridge University Press, Cambridge, UK.

Monsores, M. L., Ziviani, A., Rodrigues, P. S. S. (2006) “Detecção de Anomalias de Tráfego usando Entropia Não-Extensiva”, Anais do XXIV Simpósio Brasileiro de Redes de Computadores – SBRC'2006.

Nfdump (2007) “NFDUMP”, http://nfdump.sourceforge.net/, 23/03/2008.

Phaal, P., Panchen, S., McKee, N. (2001) “RFC 3176 - InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks”, http://www.ietf.org/rfc/rfc3176.txt.

RRDtool (2008) “Aberrant Behavior Detection with Holt-Winters Forecasting”, http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html, 23/03/2008.

Shannon, C. E. (1948) “A mathematical theory of communication”, Bell System Technical Journal, 27:379-423 and 623-656.

176 13º Workshop de Gerência e Operação de Redes e Serviços